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

[Paul Vixie]

On Mon, Aug 09, 2021 at 11:01:02AM -0400, Dave Lawrence wrote:
> 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.

regardless of whether there is a delegation, or whether it's to the same
server, if it sends an NXDOMAIN then it should expect that to be cached.

> 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.  ...

perhaps it's not as explicit as it could be, but it's very much defined.
if you see a CNAME then you know its owner exists. so if you see an
NXDOMAIN you know it can only refer to the target (canonical) name. (QED)

> ... 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.

funny you should mention that. akamai used to return cross-zone CNAME
chains, and correctly functioning full resolvers ignored them as part of
kashpureff resistance. eventually, akamai stopped returning cross-zone
chains. perhaps that was your doing?

> 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.  ...

it is, and must be, the same as that. CNAME is dispositive; RFC 1035 could
be more explicit but not clearer on that topic:

+---
| 3.3.1. CNAME RDATA format
| 
|     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|     /                     CNAME                     /
|     /                                               /
|     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 
| where:
| 
| CNAME           A <domain-name> which specifies the canonical or primary
|                 name for the owner.  The owner name is an alias.
+---

where it says "the owner name is an alias" it means "so, the rcode of a
response does not describe the status of that alias, but rather, of the
canonical name."

===

fun:

negatively caching the target of the final CNAME target is correct if the
rcode is NXDOMAIN and if no zone boundary has been crossed. however, one
only knows that a zone boundary has not been crossed if one is holding
cached data for the target name, and can witness that no delegation point
was crossed during the interval described by the TTL of that data. in
practice, CNAME chains aren't trusted, and restart almost always occurs.

-- 
Paul Vixie