Re: [dnssd] Paul Wouters' Discuss on draft-ietf-dnssd-update-lease-08: (with DISCUSS and COMMENT)

Ted Lemon <> Wed, 09 August 2023 17:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FD13C15198E for <>; Wed, 9 Aug 2023 10:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lCKm8kkaNmIB for <>; Wed, 9 Aug 2023 10:32:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 70D28C15199B for <>; Wed, 9 Aug 2023 10:32:33 -0700 (PDT)
Received: by with SMTP id 00721157ae682-5899ed05210so1543707b3.3 for <>; Wed, 09 Aug 2023 10:32:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1691602352; x=1692207152; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7Y06uM4ynZUQGZovIQqDJs2rQF1yHME+KdkF5iQfghI=; b=zXDXC4hxqz1i/YNZ4NkAXUb69VPzusk8X2QMxOtUKXgQ1KZEu+Abll87SqWgYQ9I0P IVfl4JOFmhpuUZ7znYkRrU1r+hORBFRY3UXJ8ckqPW2ZH+tWSsR+GeHGs4gdhMRY9ySE +53+Fr9QQrYK6eVjAgi+MlxF0JQFSIg/AYCo2PgjfrKXtbqx6eSSmdvLNOVnNkBsPo0c AWFRNEMPyLo7R0slMNMk6Ln1q1a4LYBfJ7sBza25KU1D/oLNk+s6pdOnmDEUAUmpcaud zIZ0YBQTF1V3H7aJMC9BKgPA3Owde3EY+PNqAXZceamJwJNo0vkTWeq0hJWtS4QdoSm9 pM+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1691602352; x=1692207152; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7Y06uM4ynZUQGZovIQqDJs2rQF1yHME+KdkF5iQfghI=; b=WtUtCo0Kw/I4b33l2FJcKsf4w1Bg9vnUgPWA1eLMYLCa8rlSlD4BNyfBbTOZvbbDs0 zrIDfq0H3rO6ZqHeVSn/pDLMc2V9q796oMKSVzmk648pMvYjRWtMgueez4BrzAh/efuy 3S3k2fR9HtgLBYALHB8rUnZS3VBCgOLU19EtFu+Gy0wgpD29FxRDEKLXzOl+70E58eFc IQS9nfRWscz3s/esLBH/WOCRAccH5yyKCkKNNtHaEJsh/hHgH7PijCm81bqA+vy9JXE7 j4PnnCweN1SiX4GVjeKKtFlkbYftNGEe+JOYOHg6lVyoNckt4QYskIaQ5kIJqMhU04mt Fxdw==
X-Gm-Message-State: AOJu0YwhplROu3CkO0AatXXAbTLP7XntJhNhvTs8RULJfgOzPc/wn8hs aaVUBUIl5WXga+O/bokXK9v6lx/qRWMbEW580II4lQ==
X-Google-Smtp-Source: AGHT+IGB7lw1UV1AEmfnqKTspHBOlJ0y+HQJ/Q/gPKxIfNzeK2JBCArd4hFKT2sUay3IkCtssLUp7AMA8laiTTnZDxM=
X-Received: by 2002:a0d:e811:0:b0:576:d65d:2802 with SMTP id r17-20020a0de811000000b00576d65d2802mr3504567ywe.3.1691602352553; Wed, 09 Aug 2023 10:32:32 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ted Lemon <>
Date: Wed, 09 Aug 2023 13:31:56 -0400
Message-ID: <>
To: Paul Wouters <>
Cc: The IESG <>,,,,
Content-Type: multipart/alternative; boundary="000000000000535d2a060280dd49"
Archived-At: <>
Subject: Re: [dnssd] Paul Wouters' Discuss on draft-ietf-dnssd-update-lease-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Aug 2023 17:32:35 -0000

On Wed, Aug 9, 2023 at 12:47 PM Paul Wouters via Datatracker <> wrote:

> I wonder why there is no method for a "leaving client" to cleanup and
> delete
> its record. Eg a laptop's "lid down" event could be used to delete the
> records
> it has a LEASE on. It could do this without any wire changes by requesting
> a
> LEASE value of 0. It could even use a KEY_LEASE value of non-zero to still
> keep
> a claim to the name but signal that it is currently not available. Is
> there a
> reason this was left out of the draft? As the stated goal of the draft is a
> more up to date DNS zone, this seems like a logical part of the solution
> to me.

Bear in mind that DNS Update specifies a way to remove records. The only
case where the lease expiry time really matters is when the lease is
allowed to elapse. In SRP, we added the "lease 0" mechanism as a way to
remove all RRs on a name, but we didn't do that here because for DNS Update
separate from SRP it's not really all that compelling. I looked at making
the change you've suggested here, because I think it does make some sense
in principle, but it's actually a pretty significant change, and I don't
think it adds any actual value—we'd be doing it just for completeness, not
because we expect anyone to use it. I don't see the point in this—it would
just be another thing we'd have to carefully get right, and that would
never get used.

The primary goal of publishing update lease as a separate document is
historical: update lease has been in use in Apple's DNS update mechanism
since ~2005, and in fact the original version of the document,
draft-sekar-dns-ul, was published in June of 2005. Since the historical use
of update lease did not use a lease time of zero, there's no need to
document that here.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
>         The Update Lease option SHOULD specify a time interval that is no
>         shorter than 1800 seconds (30 minutes). Requestors MAY specify a
>         shorter lease if they anticipate that the records being updated
>         will change sooner than 30 minutes.
> I feel this section tries to impose a restriction that it immediately
> breaks.
> As implementer there is nothing I can do with this section except ignore
> this
> text.
> There is also no way of deleting by setting an update with 0 seconds (as
> one
> "SHOULD" not use < 3600).

Here "SHOULD" is intended to mean "RECOMMENDED" which I think is
equivalent. We could change the text to say "A minimum interval of 1800
seconds (30 minutes) is RECOMMENDED as a value for the update lease option
when no need exists for a shorter lease interval." But I think the text
already says that, n'est ce pas?

>         If the Update Lease of a resource record elapses without being
>         refreshed, the server MUST NOT return the expired record in
>         answers to queries. The server MAY delete the record from its
>         database.
> The meaning here is open to interpretation. If the record is in the
> "database",
> one could assume it is also being served. And if the record must not be
> returned
> why is there a MAY to keep it in a "database". I think the second sentence
> is better
> just removed and left to implementations to handle.

Makes sense. I will do this in the document update post-IESG-review.

> NIT: [I-D.ietf-dnssd-srp]  is not pointing to the latest version

This is just an artifact of the order of publication. Presumably this and
SRP will be published together, so this shouldn't be an issue at that