Re: DNS resolver patch

[Florian Weimer <fw@deneb.enyo.de>]

* Rich Felker:

> On Thu, Dec 06, 2018 at 07:46:02PM +0000, Laurent Bercot wrote:
>> >The musl resolver should be able to handle a resolver returning NODATA.
>> >That is popular for having a separate extranet infrastructure - your
>> >extranet DNS only contains records for your local domain and returns
>> >NODATA for requests outside that domain.
>> 
>> No, you are talking about servers containing data. The musl client
>> (which is not a resolver, because it only performs recursive queries)
>> should not contact those directly. It should contact a real resolver,
>> a.k.a. cache, and the cache will contact the servers containing data.
>> If the domain has been configured properly, the servers are never asked
>> for data that are outside that domain.
>> 
>> It is the single most annoying, most bug-prone, and most confusing
>> flaw of DNS to have "communication between the DNS client and the DNS
>> cache" (recursive queries) and "communication between the DNS cache
>> and the DNS server" (non-recursive queries) happen on the same port.
>> I'd even take a different _protocol_ if it could stop people from
>> misconfiguring DNS.
>> 
>> The default usage of BIND, which was "one single daemon is both a
>> cache and a server and we entertain the confusion", did a lot of harm
>> to the Internet. As your post illustrates, this harm pertains to this
>> day.
>
> I'm not sure what the relation to the confusion between querying an
> authoritative server and a recursive server is here, but the quoted
> interpretation of NODATA above is wrong independent of any such
> confusion. NODATA does not indicate that the server you asked doesn't
> know about the queried name. It indicates that that queried name
> exists but has no records of the requested type.

Maybe a referral looks like a NODATA response upon cursory inspection?

glibc has code which switches to the next configured nameserver upon
encountering what looks like a referral:

		if (anhp->rcode == NOERROR && anhp->ancount == 0
		    && anhp->aa == 0 && anhp->ra == 0 && anhp->arcount == 0) {
			goto next_ns;
		}

(Oops: When EDNS support is enabled, this check is buggy because
anhp->arcount is not necessarily zero due to the OPT record.)

REFUSED is handled the same way, so I think this enables the
misconfiguration A. Wilcox described.  Fortunately, we still only
support three name servers, so there is a limit to what people can do
with this.

Curiously this isn't something that was part of the original BIND stub
resolver code.  It's a fairly recent addition to the glibc stub
resolver, dating back to 2005 only.

Recognizing referrals reliably is quite hard; I wouldn't immediately
know how to implement that in a stub resolver.  (Back in 2005,
referrals with a non-empty answer section were still common, I think.)
It's easier in a recursive resolver because you can just follow the
referral (with some safeguards to deal with loops and other
nastiness).  And you can do a lameness check if you know that the
sever should be authoritative.