> > If a DNS zone has no meaningful SOA Serial number then the > > SOA-SERIAL ZONEVERSION option SHOULD NOT be returned in a reply. > > Im 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 dont 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.
In my experience, putting garbage in a data field is likely to lead to problems later. Some implementations just don't have a sensible version number. With In the context of zone transfers, you need at least two poperties: if anything changes in the zone, then the zone's version also changes. Second, a sequence of version numbers viewed over a period of time, days or weeks, is increasing in serial arithmatic. Some implementations of authoritative servers just don't have that. However, if there is consensus that returning such version numbers in ZONEVERSION is fine, then I don't want to spoil the fun. Just making sure the issue was not overlooked. > > 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. > > Im okay with something like this, but can you provide any more text > about why they should not use zone version data in caching decisions? A new version of a zone should have no impact on how long data is cached. The TTL value of resource record is meant for that. It might be tempting to also include the version number of the zone in the decision when to declare data as stale, however some zones may see very frequent updates and this may reduce the life time of some resource records in the cache below what is reasonable. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
