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

[Ted Lemon <[e-mail]>]

On Wed, Aug 9, 2023 at 12:47 PM Paul Wouters via Datatracker <
[e-mail]> 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.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>         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
point.