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.