Hi Philip, thanks for the feedback. > On Jul 16, 2024, at 1:46 AM, Philip Homburg <pch-dnso...@u-1.phicoh.com> > wrote: > >> the changes from draft-ietf-dnsop-zoneversion-09 to -10 address or >> incorporate the following points recently raised: > > Sorry for the late response. I didn't pay much attention to the actual > wording of the draft while it was informational. > > I think it would be good to add two sentences to the introduction. The first > is the following: > > If a DNS zone has no meaningful SOA Serial number then the > SOA-SERIAL ZONEVERSION option SHOULD NOT be returned in a reply.
I’m not sure about this. Since every zone will have a SOA record, and every SOA record will have a serial value, I suppose the question becomes whether or not a serial number is “meaningful”. I don’t know how a name server would determine meaningfulness. What would be the harm in returning a SOA-SERIAL zone version if it were not supposedly meaningful? A user/client can see the value by querying SOA directly. Note also that a name server can always choose to not honor a client’s request for zone version info, as per section 3.2 item (d). > > This can be inserted right before 'To accommodate these use cases, new > ZONEVERSION types could be defined in future specifications.' > > The second addition: > > The ZONEVERSION option as defined in this draft SHOULD NOT be used by > recursive resolvers, client-side forwarders, etc. to decide when to flush > a cache or otherwise how long to cache data. I’m okay with something like this, but can you provide any more text about why they should not use zone version data in caching decisions? DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
