On 04. 07. 24 10:28, Joe Abley wrote:
Hey,
On 4 Jul 2024, at 09:15, Petr Špaček <[email protected]> wrote:
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)
Yep. I still think the language you quoted would benefit from some
clarification though. Perhaps:
1.2. Terminology
ADD:
In this document, an "enclosing zone" of a domain name means a zone in
which the domain name is present as an owner name, or any parent of that
zone. For example, if B.C.EXAMPLE and EXAMPLE are zones, but C.EXAMPLE
is not, the domain name A.B.C.EXAMPLE would have the enclosing zones
B.C.EXAMPLE, EXAMPLE and the root zone.
3.2 Responders
OLD:
A name server that (a) understands the ZONEVERSION option, (b)
receives a query with the ZONEVERSION option, (c) is authoritative
for the zone of the original QNAME, and (d) chooses to honor a
particular ZONEVERSION request responds by including a TYPE and
corresponding VERSION value in a ZONEVERSION option in an EDNS(0) OPT
pseudo-RR in the response message.
NEW:
A name server that (a) understands the ZONEVERSION option, (b)
receives a query with the ZONEVERSION option, (c) is authoritative
for one or more enclosing zones of the original QNAME, and (d) chooses to
honor a
particular ZONEVERSION request responds by including a TYPE and
corresponding VERSION value in one or more ZONEVERSION options in an
EDNS(0) OPT
pseudo-RR in the response message.
OLD:
A name server MAY include more than one ZONEVERSION option in the
response if it supports multiple TYPEs. 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.
NEW:
A name server MAY include more than one ZONEVERSION option in the
response if it supports multiple TYPEs. A name server MAY also
include more than one ZONEVERSION option in the response if it is
authoritative for more than one enclosing zone of the corresponding QNAME.
A
name server MUST NOT include more than one ZONEVERSION option for a
given TYPE and LABELCOUNT.
Sounds clearer to me. I gather there's no appetite to make the wire
format more generic and I think it's also fine.
Only comment I have is that LABELCOUNT could have been TYPE-dependent so
a new TYPE could define different mechanism to identify zone, but hey,
wasting 1 byte is not a big deal in the age of multi-gigabyte videos
playing in the background constantly.
Unrelated thoughts:
### OPCODE
Currently the document sorta implicitly talks about DNS queries - mainly
implied by the structure of section 3.2 and listed possible answer types
and RCODEs.
Should the document be explicitly limited to OPCODE=QUERY, or is there
value in allowing other opcodes?
E.g. RCODE=YXRRSET comes to mind, where it could be useful for
OPCODE=UPDATE as well as OPCODE=QUERY.
Oh, it just occured to me:
What if I throw in OPCODE=QUERY QTYPE=AXFR/IXFR just for fun.
Allow? Disallow? Leave undefined?
### Error handling advice
While re-reading it once more I wonder if sections 3.1 Initiators and
3.2 Responders should have some more words about when to do when various
MUST/SHOULDs are violated?
Say initiator gets answer with exactly duplicated ZONEVERSION. What now?
And what if LABEL and TYPE are duplicate but with different SERIAL
values? What now?
Drop it on the floor as signal FORMERR in both cases? Or process and
display as usual in the first but drop the second case? Or what?
This is my generic complains with dnsop documents - they often do not
say what's expected behavior when constraints are violated. We can take
it as a though experiment and see where we get.
Ad one specific case which _is_ defined:
> A name server MUST ignore invalid ZONEVERSION options present in the
query message.
Does that mean that server MUST ignore ZONEVERSION query with 60 000
bytes of payload and proceed as usual? I would say it warrants FORMERR :-)
If you think I'm insane, well, you might be right! In my defense I've
spent last year dealing with weird attacks misusing DNS protocol so I'm
in the under-contant-attack mood...
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
