Hello dnsop.
It seems to me that both
RFC 1034 section 4.3.2. Algorithm
RFC 6672 section 3.2 Server Algorithm
have a bug/are inconsistent with RFC 2136/RFC 5936.
TL;DR these two algorithms do not handle occluded data correctly.
Quote from RFC 9499 section 7. Zones:
Occluded name:
"The addition of a delegation point via dynamic update will render
all subordinate domain names to be in a limbo, still part of the zone
but not available to the lookup process. The addition of a DNAME
resource record has the same impact. The subordinate names are said to
be 'occluded'." (Quoted from [RFC5936], Section 3.5)
Excerpt of the algorithm in 6672 is:
2. Search the available zones for the zone which is the nearest
ancestor to QNAME. If such a zone is found, go to step 3;
otherwise, step 4.
3. Start matching down, label by label, in the zone. The matching
process can terminate several ways:
A. If the whole of QNAME is matched, we have found the node.
If the data at the node is a CNAME, and QTYPE does not match
CNAME, copy the CNAME RR into the answer section of the
response, change QNAME to the canonical name in the CNAME RR,
and go back to step 1.
Otherwise, copy all RRs which match QTYPE into the answer
section and go to step 6.
B. If a match would take us out of the authoritative data, we
have a referral. This happens when we encounter a node with
NS RRs marking cuts along the bottom of a zone.
...
6. Using local data only, attempt to add other RRs that may be
useful to the additional section of the query. Exit.
Example zone where this breaks:
test. SOA ...
test. NS ...
sub.test. NS elsewhere.
sub.test. TXT "occluded TXT, even though it is not covered by RFC 9499"
occluded.sub.test. TXT 'nobody should see this!'
Query which hits this bug:
QNAME=occluded.sub.test.
QTYPE=TXT
Now I'm a dumb machine and execute the algorithm:
- step 2 - found zone 'test.'
- step 3A - found node! not CNAME -> goto step 6
- step 6 - respond, go for weekend
/insert mushroom cloud ASCII art here/
This seems to be just wrong, and RFC 2136 section 7.18 seems to support
this conclusion. Quote:
7.18. Previously existing names which are occluded by a new zone cut
are still considered part of the parent zone, for the purposes of
zone transfers, even though queries for such names will be referred
to the new subzone's servers. If a zone cut is removed, all parent
zone names that were occluded by it will again become visible to
queries. (This is a clarification of [RFC1034].)
I suppose RFC 6672 should have switched steps 3A and 3B?
Second catch is that NS RR type can 'occlude' data which are on the
_same_ node, which is missing in RFC 9499 definition (or rather 2136
definition of occlusion).
Is my brain overheated and I don't understand anything anymore?
Or should I file an erratum?
Have a great weekend everyone.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
