On 30 May 2025, at 21:07, Sarah Tarrant <starr...@staff.rfc-editor.org> wrote: > Ted - Thank you for helping me understand the phrasing with "traditional DNS > Update protocol". I spent some time looking through the other instances in > the document, and your explanation really helped me understand.
Yes, it's actually a bit confusing in the document. You touched on this in the initial AUTH48 edit, but I think we didn't get rid of all the ambiguity, so it's no wonder you are confused. The document uses the terms "DNS Update" and "DNS Update message" to mean the same thing, but also uses the term "DNS Update" to refer to the "DNS Update protocol." I think an edit to fix this would be too much to suggest at this stage in the process, but that's probably how this confusion arose. Oh, and we also use "DNS Update" in the context of protocol elements, like "DNS Update Adds". Sigh. Anyway, I do see an issue here in 3.2.5.1: hen regenerating a key or or only in the event that the SRP update This change wasn't fully applied: In section 3.2.5.3, unplugged is a bit anachronistic these days. OLD: The lifetime of the KEY records is set using the KEY-LEASE field of the Update Lease Option and SHOULD be set to a much longer time, typically 14 days. The result being that even though a device may be temporarily unplugged -- disappearing from the network for a few days -- it makes a claim on its name that lasts much longer. Therefore, even if a device is unplugged from the network for a few days, and its services are not available for that time, no other device can come along and claim its name the moment it disappears from the network. In the event that a device is unplugged from the network and permanently discarded, then its name is eventually cleaned up and made available for reuse. NEW: The lifetime of the KEY records is set using the KEY-LEASE field of the Update Lease Option and SHOULD be set to a much longer time, typically 14 days. The result being that even though a device may be temporarily disconnected or powered off -- disappearing from the network for a few days -- it makes a claim on its name that lasts much longer. Therefore, even if a device is unplugged from the network for a few days, and its services are not available for that time, no other device can come along and claim its name the moment it disappears from the network. In the event that a device is disconnected from the network and permanently discarded, then its name is eventually cleaned up and made available for reuse. This change was omitted from Stuart's update: Also in 3.2.5.4, OLD: Note that this document does not update the SRV specification [RFC2782 <https://www.rfc-editor.org/authors/rfc9665.html#RFC2782>]: Authoritative DNS servers still MUST NOT compress SRV record targets. The requirement to accept compressed SRV records in updates only applies to SRP registrars, and SRP registrars that are also authoritative DNS servers still MUST NOT compress SRV record targets in DNS responses. We note also that Multicast DNS [RFC6762 <https://www.rfc-editor.org/authors/rfc9665.html#RFC6762>] similarly compresses SRV records in mDNS messages. NEW: Note that this document does not update the SRV specification [RFC2782 <https://www.rfc-editor.org/authors/rfc9665.html#RFC2782>]: Authoritative DNS servers still MUST NOT compress SRV record targets. The requirement to accept compressed SRV records in updates only applies to SRP registrars. SRP registrars that are also authoritative DNS servers still MUST NOT compress SRV record targets in DNS responses. We note also that Multicast DNS [RFC6762 <https://www.rfc-editor.org/authors/rfc9665.html#RFC6762>] similarly compresses SRV records in mDNS messages. I think Stuart didn't understand the purpose of this change. The reason to break this into two sentences is not for readability. It's that it makes the meaning clearer. "SRP registrars" at the end of the sentence in the new text is talking about all SRP registrars. "SRP registrars" at the beginning of the second sentence is talking about SRP registrars that are also authoritative DNS servers. The current text makes this distinction a lot less clear. Sorry to add one more cycle, but hopefully this is the last one.
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
