[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAO_RewZ4aWOdd6SZMDsFxYijJoThsE7FSVHxgCCauH1JriQ3Yw@mail.gmail.com>
Date: Mon, 26 Oct 2015 17:37:20 -0700
From: Tim Hockin <thockin@...gle.com>
To: musl@...ts.openwall.com
Subject: Re: Re: Would love to see reconsideration for domain and search
wrt 2) my understanding is that you get at-most-one-of `search` or `domain`.
On Mon, Oct 26, 2015 at 5:30 PM, Rich Felker <dalias@...c.org> wrote:
> 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.
