[DNSOP] Re: Fwd: New Version Notification for draft-ietf-dnsop-zoneversion-10.txt

[Petr Špaček <[e-mail]>]

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