[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151027003021.GN8645@brightrain.aerifal.cx>
Date: Mon, 26 Oct 2015 20:30:21 -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 Fri, Oct 23, 2015 at 01:31:09AM -0400, Rich Felker wrote:
> > > 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.
I noticed in the process of trying to draft code to do this that there
will be a lot of code duplication with the resolv.conf parsing in
res_msend.c, and that this code has some stupid bugs (for example it
stops parsing after it gets 3 nameservers, so it might miss options
later in the file), so I think I'll take a look at factoring it into a
new function to gather all the interesting information from
resolv.conf that can be used in both places.
A couple additional things I noticed from resolv.conf(5):
1. The default domain used by glibc is not the dns root but rather the
domain portion of the local hostname determined by gethostname().
Is there any value in duplicating this? Does anyone want/need it?
2. It's not clear from the documentation of "search" whether its
presence overrides/suppresses the "domain" (default or set by
resolv.conf) or adds additional searches before or after it. Which
should it do?
While glibc/legacy behavior is worth looking at, I don't think we need
to look at things from a standpoint of exactly duplicating that.
Meeting real-world modern application needs while avoiding
inconveniencing users with stupid/unwanted behavior should be the
primary goal.
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.
