[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181228172124.GP23599@brightrain.aerifal.cx>
Date: Fri, 28 Dec 2018 12:21:24 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: DNS resolver patch
On Thu, Dec 27, 2018 at 08:18:16PM +0100, Florian Weimer wrote:
> * 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;
> }
Can you elaborate or provide a citation on how this "looks like a
referral"? I don't see any obvious difference between this and a
nodata response except possibly RA==0, which would only happen when
you have an auth-only nameserver listed in your resolv.conf. This
would not be useful for unioning in musl because it depends on an
ordering between the nameservers rather than providing a true union;
at least one of the servers is going to be recursive and return an
nxdomain or nodata which could be seen before the auth-only local
server responds.
> (Oops: When EDNS support is enabled, this check is buggy because
> anhp->arcount is not necessarily zero due to the OPT record.)
FTR, also not an issue for musl since we intentionally don't do EDNS.
> 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.
Refused and other errors are pretty much ignored in musl; they're at
least not conclusive unless all nameservers have responded with an
error, since another one could still succeed.
Rich
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.
