[DNSOP] Re: Last Call: <draft-ietf-dnsop-zoneversion-09.txt> (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC

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

On 04. 07. 24 10:00, Joe Abley wrote:
> On 4 Jul 2024, at 08:38, Petr Špaček <[e-mail]> wrote:
> 
>> when re-reading this document I've realized one limitation which is not explicitly mentioned:
>>
>> ---
>> 3.2. Responders
>>
>> ... A name server MAY also include more than one ZONEVERSION option in the response if it is authoritative for more than one zone of the corresponding QNAME. A name server MUST NOT include more than one ZONEVERSION option for a given TYPE and LABELCOUNT.
>> ---
>>
>> The current option cannot be used to represent version info for answer like this:
>>
>> QNAME:
>> qname.zone1.test. A
>>
>> Answer:
>> qname.zone1.test.  CNAME target.zone2.test.
>> target.zone2.test. A     192.0.2.1
>>
>> When the responder is authoritative for both zones - zone1.test. and zone2.test. - then there's no way to represent ZONEVERSION for zone2.test.
> 
> I think this is a consequence of the loose language you quoted "more than one zone of the corresponding QNAME". I think this language should be made clearer. I think it is vague, as written.
> 
> I think the intention is that if the server is authoritative for zone1.example and zone2.zone1.example then a query for label.zone2.zone1.example could return ZONEVERSION data for both zone1.example and zone2.zone1.example using LABELCOUNT == 2 and 3, respectively.


To be clear:
Let's not hang too tight on this particular example. It could be 
something crazy like

qname.zone1.test. CNAME target2.example.
target2.example. CNAME final.example.net.
final.example.net. A 192.0.2.1

(i.e. zone names have nothing in common except for the root)

> I don't think there was any intention that your example would result in ZONEVERSION data for zone2.test being returned. I agree it might be nice if there was a way to do that, but I haven't thought hard enough to have an opinion beyond "nice". I suppose one way to handle this would be to use an offset pointer for the zone name, à la label compression, rather than using LABELCOUNT. Then you could report a ZONEVERSION for any terminated list of labels present in the message, regardless of whether it is present in the QNAME. Maybe that would be hard to implement, though.

That same thought occurred to me as well but I think it would be hard - 
decompression typically happens way before the message is processed.

> Anyway, assuming my interpretation of that phrase above is accurate and there's no appetite to change the encoding, I don't know that there's a way of of phrasing the intent in a small handful of words. I think multiple sentences and probably an example will be required.

-- 
Petr Špaček
Internet Systems Consortium