All it requires for the cache to learn that the delegation doesn’t exist is to ask for the DS record at the delegation. This is done all the time by validating resolvers. Depending on query order for “correct” behaviour is not a good idea.
Note named hides the DS/NXDOMAIN response from queries for types other than DS because there are too many instances of these broken delegations but there is no RFC requirement to do this. If you want a delegation to work with all resolvers the delegating NS RRset needs to be present. Mark > On 8 Aug 2021, at 13:25, Dave Lawrence <[email protected]> wrote: > > I agree with Viktor that the parent should have delegation records for > the same-server child, but note that response with the rcode NXDOMAIN > for a CNAME chain shouldn't be causing a problem for a modern > resolver. A resolver should restart query processing with the target > of each CNAME in the chain, and ultimately come to its own conclusion > about whether the target at the end of the chain exists. > > I suspect that this issue existed for a while and the lack of > screaming about it hints to me that for the vast majority of clients > things continued to work fine. FWIW, from my network vantage point, > when querying edns126.ultradns.com for type A directly I get a > response that has rcode NOERROR and terminates the chain with an > address record. > > Shreyas, did you encounter a production resolver that was having a > problem with chain/NXDOMAIN response? > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
