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

[Shreyas Zare]

Hi,

On Mon, Aug 9, 2021 at 8:35 PM Dave Lawrence <tale at dd.org> 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.
>
> 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.
>

The problem is that this is well defined in RFC2308 Section 2.1 that too
with example responses containing CNAME and recommended to use Type 2
response to indicate correct NXDOMAIN response. The text quoted below from
there is also quite clear:

   Note, in the four examples of NXDOMAIN responses, it is known that
>    the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
>    The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
>    exist.  On the other hand, in the referral example, it is shown that
>    "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
>    known one way or the other about the existence of "TRIPPLE.XX", other
>    than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
>    obtaining information about it.
>
>    Where no CNAME records appear, the NXDOMAIN response refers to the
>    name in the label of the RR in the question section.
>
>
The original issue with the response for "www.uber.com" matches exactly
with the Type 2 example. And all of the 3 CNAME records are within the zone
cut for the received SOA. To make the resolver work with this issue, the
negative cache implementation had to be removed for CNAMEs with NXDOMAIN
case.

Regards,
*Shreyas Zare*
Technitium <https://technitium.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20210810/21020755/attachment.html>