[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151023053108.GG8645@brightrain.aerifal.cx>
Date: Fri, 23 Oct 2015 01:31:09 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Re: Would love to see reconsideration for domain and
search
On Thu, Oct 22, 2015 at 10:13:18PM -0700, Tim Hockin wrote:
> >> > Consider what would happen if ns1 and ns2 have different responses, but ns1
> >> > for whatever reason times out (potentially an attacker). Then you get the
> >> > results for ns2, even though ns1 is intended to override it.
> >>
> >> I agree in theory. And yet this is how most resolvers work today.
> >> Are they all broken?
> >
> > No, the resolvers are not broken. The configuration is, at least the
> > way I see it. The intent of the resolvers is that they're
> > communicating with redundant servers, not a sequence of overlaid
> > hostname databases. If that assumption is satisfied, there's no
> > problem.
>
> The way you see it is not how everyone sees it, obviously. And
> there's not a standard or spec here that I know of. That said, as
> before, We can probably live with this assumption.
Indeed. But if you want to consider the overlaid model as the proper
one, then as we already noted, all existing implementations have an
exploitable bug where an attacker who can cause transient failures can
change the result of queries (rather than just making queries fail).
That seems rather undesirable.
> > BTW I think there are other strong reasons to move to a model based on
> > a local nameserver that does the unioning, not just performance. The
> > most compelling is DNSSEC, which requires a trusted channel between
> > the nameserver and the stub resolver in order for results to be
> > meaningful/trusted. In the future everybody should be running a
> > nameserver on localhost to do DNSSEC signature validation. In that
> > scheme, resolv.conf would just contain 127.0.0.1 (or could be omitted
> > entirely since that's the default, at least on musl).
>
> I can see a local nameserver doing resolution, but doing search
> expansion seems like a stretch (and superfluous since it is local).
Search would also get a lot of performance benefit from doing in the
caching nameserver, but I agree with your assessment that it's a
separate issue and that there's no _need_ to do it at that level to
ensure correctness. So for now let's focus on a plan for adding
suitable search domain support in musl.
I believe search only affects DNS queries, not hosts file lookups,
right? So it should be at the name_from_dns stage in lookup_name.c.
The simplest implementation approach is probably to wrap name_from_dns
with a name_from_dns_search function that reads the search domains and
repeatedly calls name_from_dns until it gets success.
One oddity/ugliness of search that needs to be considered is that
querying different address families may lead to differently-sourced
results. For example if you query example.us with ndots=2, a search
domain of example.com, and the following records present:
example.us.example.com A
example.us AAAA
then an AF_UNSPEC or AF_INET query yields a v4-only result for
example.us.example.com while an AF_INET6 query "sees through" to the
example.us record because the search of example.com fails. This seems
quite ugly and counter-intuitive, but I don't see any way to do better
that makes sense.
Also, are we agreed that queries with >=ndots dots, or a final dot (as
in example.com.) should never be searched (rather than searched after
first trying them in the root)?
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.
