Hi Petr It's not clear to me what you want answered; also surely you know the expected behaviour. I'll try to provide an answer.
On Fri, Jul 04, 2025 at 04:08:25PM +0200, Petr Špaček wrote:
> 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/
Much of the RFC 6672 text above that is used in the example appears
borrowed from RFC 2672 (the former DNAME RFC) section 4.1, which in turn
appears to borrow it from RFC 1034 section 4.3.2 (at least the parts
used for the example above).
>
> 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].)
The "parent zone names" is confusing, as by parent zone names, we may
think of super-domains. It would've been better if it said "parent
zone's names".
The "parent zone names that were occluded" are names in the zone tree
data in the parent zone, which includes the DNS node of the zone cut.
When there's a zone cut at a DNS node, the child zone is authoritative
for everything at that node including the NS records for that node.
For example, if one queries the com. zone for example.com./NS, it would
not return an answer respose; it would return a delegation response
telling the client where it can go to get an answer for example.com./NS.
AA=0 and the data is in the authority section.
[muks@wg1 ~]$ dig +dnssec +noqr @a.gtld-servers.net example.com NS
; <<>> DiG 1.99.3.20250623003957.08c26b66c1 <<>> +dnssec +noqr
@a.gtld-servers.net example.com NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39792
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;example.com. IN NS
;; AUTHORITY SECTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
example.com. 86400 IN DS 370 13 2
BE74359954660069D5C63D200C39F5603827D7DD02B56F120EE9F3A8 6764247C
example.com. 86400 IN RRSIG DS 13 2 86400 20250709011309
20250702000309 40097 com.
TqB0PMRdz4BghWfqDMGbSS/8qwXkymPcjoWDnmPg9sVqK+OYrNQQUCoR 4pa+ySrKEV5tm\
GZb6P8wQK6jvmoK9Q==
;; Query time: 23 msec
;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
;; WHEN: Fri Jul 04 15:16:54 GMT 2025
;; MSG SIZE rcvd: 235
[muks@wg1 ~]$
When there is a zone cut, everything at and under that node is occluded
(except the case of DS and RRSIG). While remain a part of the zone for
zone data consistency, they cannot be returned as answers.
>
> 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).
RFC 1034 4.2.1. says:
"The authoritative data for a zone is simply all of the RRs attached
to all of the nodes from the top node of the zone down to leaf nodes
or nodes above cuts around the bottom edge of the zone."
i.e., the authoritative data stops at the node *above* the node of the
zone cut.
RFC 1034 was written in a time when the language used was not rigorous,
and it appears the name server query response algorithm text was
borrowed into later drafts without improving it.
The step 3. A. above should not match non-authoritative data, as it is
not part of the zone for purposes of answering query.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
