[dns-operations] Ultra DNS responding with NXDOMAIN for "www.uber.com"

[Mark Andrews]

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 <tale at dd.org> 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
> dns-operations at lists.dns-oarc.net
> 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: marka at isc.org