On 18. 07. 24 15:42, Philip Homburg wrote:
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.
I'm one of the guys who implemented a server which ignored SOA serial
semantics on purpose - because its distributed multi-master backend
offered only eventual consistency.
Of course it had to expose _some_ value for SOA serial, but the fake
serial did not have the properties promised in RFC 1034, and there is no
way to make it so.
I believe some PowerDNS installations suffer from the same problem.
With this experience in mind I support Philip's proposal to add
instruction for authors of such servers. It does not hurt anyone and
it's a good reminder for authors of weird software.
If there's trouble with defining "meaningful" then we can try this
alternative wording:
----
If a DNS zone's SOA Serial number does not conform to RFC 1034 semantics
then the SOA-SERIAL ZONEVERSION option SHOULD NOT be returned in a reply.
----
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 don't agree with the proposed text above. I have a feeling there is a
room for optimization if we do proper analysis - but at the same time
this can be done later on in a separate document, so silence here is
IMHO fine.
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.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
