[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 27 Dec 2018 20:18:16 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: DNS resolver patch
* 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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
