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

[Dave Lawrence]

Paul Vixie writes:
> On Sun, Aug 08, 2021 at 03:20:24PM +0530, Shreyas Zare wrote:
> > ... The resolver I have does restart for the last CNAME regardless
> > of the RCODE but, the negative cache implementation based on RFC2308 and
> > RFC8020 caused the NXDOMAIN response to get cached causing the issue.
> 
> that's exactly what should happen.

In general yes, but not in this case--though this was also confounded
by the absence of a delegation point in the same-server parent leading
to the erroneous nxdomain.  If the delegation existed but the auth
didn't pursue its cname chasing down in to the subzone (which is a
fair choice for it to make) it would have just stopped the chain with
noerror and the resolver would have had to come back to resolve the
final target.

Unfortunately, with a single rcode covering a response but cnames
causing query restarts and effectively making multiple implicit
responses, we can't have just one proper rcode for the whole lot; it
isn't well-defined.  Me, I'd prefer it if the rcode for a chain was
noerror as long as the first name exists, but I also have seen first
hand the way that some implementations end up using the rcode from the
end.  I'd also prefer that auths only return the first cname and not
any chained data, since resolvers can't fully trust the chained data
anyway and should come back with another query.

In any event, this whole thing is not the same as the issue of
replying nxdomain for some qtypes at a name that otherwise gets
positive responses for other qtypes.  Those implementations do need a
serious kick, and thank you for your efforts in trying to get them
fixed.