On 4 Jul 2024, at 08:38, Petr Špaček <pspa...@isc.org> 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. 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. 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. Joe _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
