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

[Shreyas Zare]

Hi Dave,

On Tue, Aug 10, 2021 at 9:48 PM Dave Lawrence <tale at dd.org> wrote:

> Shreyas Zare writes:
> > 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.
>
> To be clear, and this could well be something that community was not
> really clear on until after 2308 was written, just being "within the
> zone cut" is not sufficient to know that it is really in the zone even
> when you are at the same label depth.
>
> Imagine an auth server that has this configuration:
>
> $origin example.com.
> . ns ns1.example.com.
> . ns ns2.example.com.
> foo cname bar
> bar ns ns1.example.com.
> bar ns ns2.example.com.
>
> $origin bar.example.com.
> . ns ns1.example.com.
> . ns ns2.example.com.
> . txt "record in child"
>
> A query to {ns1,ns2}.example.com for txt could be legitimately replied
> to by the auth with just the foo cname bar record, and noerror as
> rcode.  Can a resolver tell for sure whether that means the txt for
> bar.example.com doesn't exist so that it could negative cache that?
> Just having the soa in additional wouldn't be a sufficient indication.
>
> Yes, I've acknowledged in a prior message that I didn't pick up on the
> auths in question giving an nxdomain for ds, which certainly muddies
> the water for the specific original example, which already had a tree
> configuration problem that would erroneously lead it to nxdomain even
> if it didn't have that problem with types.  I'm just making clear that
> the resolver implementation needs handle the lookup of the cname
> target as distinct from whatever appears in the answer beyond the
> first cname.
>

Thanks for the response. It helped me to improve my implementation.

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