On 04. 07. 24 10:00, Joe Abley wrote:
On 4 Jul 2024, at 08:38, Petr Špaček <[email protected]> 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
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
