From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8716 Path: news.gmane.org!not-for-mail From: Josiah Worcester Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Would love to see reconsideration for domain and search Date: Thu, 22 Oct 2015 23:00:32 +0000 Message-ID: References: <20151022215608.GA8645@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01634ab8d9e27e0522b9761c X-Trace: ger.gmane.org 1445554858 24897 80.91.229.3 (22 Oct 2015 23:00:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Oct 2015 23:00:58 +0000 (UTC) To: musl@lists.openwall.com, Rich Felker Original-X-From: musl-return-8729-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 23 01:00:57 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZpOqu-0002hp-Qc for gllmg-musl@m.gmane.org; Fri, 23 Oct 2015 01:00:57 +0200 Original-Received: (qmail 21750 invoked by uid 550); 22 Oct 2015 23:00:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21727 invoked from network); 22 Oct 2015 23:00:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=yRwtRYye+qlRkx/fyh20AzrsMV+iOUPBAUTG9H1jhm8=; b=YhLAwz+mkxw+DbAKfwHcKkJOUBwkjcGnUqVWsFK6B/tPX91dT0ofWKKUtbEpJ+ZtPl 2AuVlHLzccjqakkIhdaSvpw63WBDz/yO0ivWmChya7RV7JbxNWiX4XgRIbWt/vzh2tOD mI9SeMg2SV1+injzssQPD2GcgPeg4hed6PoTwQ1iwstWaAd97kAzdmDC281YheSaxAxP ids7gxSAjwr2833cEAPlI3BWYOxUJ6hf2WIv76nEFqAbHDRQ3rpQ3GnIDmnkAtMnkC+o EshVrUijIOzli3Ah8HveZ+4s1qpg4SY9cVa3gOj/tgBX3yrBsY/e8OIVraE0jBJBDzNB W39g== X-Received: by 10.182.126.129 with SMTP id my1mr13233224obb.6.1445554841832; Thu, 22 Oct 2015 16:00:41 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:8716 Archived-At: --089e01634ab8d9e27e0522b9761c Content-Type: text/plain; charset=UTF-8 On Thu, Oct 22, 2015 at 3:37 PM Tim Hockin wrote: > On Thu, Oct 22, 2015 at 2:56 PM, Rich Felker wrote: > > On Thu, Oct 22, 2015 at 02:24:11PM -0700, Tim Hockin wrote: > >> Hi all, > >> > >> I saw this thread on the web archive but am not sure how to respond to > >> the thread directly as a new joinee of the ML. I hope this finds its > >> way... > > > > No problem; just starting a new thread like this and quoting the old > > one is fine. > > > >> I am one of the developers of Kubernetes and I own the DNS portion, in > >> particular. I desperately want to use Alpine Linux (based on musl) > >> but for now I have to warn people NOT to use it because of this issue. > >> > >> On Fri, Sep 04, 2015 at 02:04:29PM -0400, Rich Felker wrote: > >> > On Fri, Sep 04, 2015 at 12:11:36PM -0500, Andy Shinn wrote: > >> >> I'm writing the wonderful musl project today to open discussion > >> >> about the future possibility of DNS search and domain keyword > >> >> support. We've been using musl libc (by way of Alpine Linux) for > >> >> new development of applications as containers that discover each > >> >> other through DNS and other software defined networking. > >> >> > >> >> In particular, we are starting to use applications like SkyDNS, > >> >> Consul, and Kubernetes, all of which rely on local name > >> >> resolution in some way using search paths. Many users of the > >> >> Alpine Linux container image have also expressed their desire for > >> >> this feature at > >> >> https://github.com/gliderlabs/docker-alpine/issues/8. > >> >> > >> >> On the functional differences between glibc page, the domain and > >> >> search keyword "Support may be added in the future if there is > >> >> demand". So please consider this request an addition to whatever > >> >> demand for the feature already exists. > >> >> > >> >> Thank you for your time and great work on the musl libc project! > >> > > >> > I think this is a reasonable request. I'll look into it more. > >> > > >> > One property I do not want to break is deterministic results, so > >> > when a search is performed, if any step of the search ends with > >> > an error rather than a positive or negative result, the whole > >> > lookup needs to stop and report the error rather than falling > >> > back. Falling back is not safe and creates a situation where DoS > >> > can be used to control which results are returned. > >> > >> I understand your point, though the world at large tends to disagree. > >> Everyone has a primary and secondary `nameserver` record (or should). > >> If the first one times out, try the second. Most resolver libs seem > >> to accept a SERVFAIL response or a timeout as a signal to try the next > >> server, and I would encourage you to do the same. > > > > musl intentionally does not do this because it yields abysmal > > performance. If the first nameserver is overloaded or the packet is > > lost, you suffer several-second lookup latency. > > But at least it works eventually. You're faced with a choice. Wait 2 > seconds for ns1 to timeout and then fail in a way that most apps don't > handle well or wait for 2 seconds and then (usually) get a fast > response from ns2. > > It seems better in every way to eventually succeed, though I agree > it's a bit less visible. > With musl's current design, you get a request to ns1 and ns2, and the first authoritative response wins. So, if ns1 fails then all is well and performance isn't even notably impacted. What you are describing appears to be how you would *have* to implement it if you decide against considering all servers equal, but instead try and serve the union of their responses (that is, wait for timeout and then fail). 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. > >> Stopping on positive response or NXDOMAIN seems to be commonly > >> accepted with a caveat. You can't query all nameservers and just take > >> the first NXDOMAIN to respond. You can only accept NXDOMAIN if all of > >> the higher-priority (listed first in resolv.conf) nameservers have > >> timed out or SERVFAIL'ed. You can issue queries in parallel, but you > >> must process responses in order, which is what you describe below. > > > > Timeout or servfail is not sufficient to accept an nxdomain from a > > lower-priority server. To preserve consistency of results under > > transient failure, you actually have to wait for the nxdomain from the > > I have to disagree. Some non-forwarding DNS servers use SERVFAIL to > indicate "I am not serving for that domain" specifically to make the > client move to their next nameserver. if ns1 returns SERVFAIL, try > ns2. If ns1 times out, try ns2. Otherwise what good is ns2? > Note that this means that any condition where ns1 can't be accessed changes what DNS resolves to. If you wish to prevent unexpected behavior when ns1 can't be accessed, you simply have to get a response from ns1 first, and only ever query ns2 when the response from ns1 indicates you may. > > > higher-priority server. Either way, this very much pessimizes usage > > cases like running "netstat" with huge numbers of connections where > > many of the ip addresses fail to reverse. Being able to return > > immediately as soon as any one of the nameservers responds with > > nxdomain makes the difference between a <1s netstat run and a 5-10s > > netstat run. > > Sure it's faster but it's WRONG. Returning a random number would be > faster, too, but it is equally wrong. This is why netstat (and myriad > other tools) has a `-n` flag. Again, musl's design assumes that all nameservers are hosting the same space, and thus a single nxdomain is authoritative. If this is the case, then this is perfectly correct. If it's not the case, then it's wrong (and you need to wait for literally everything to nxdomain, and if there's a timeout from a single server you *need* to report that). > > Thus, if we add extensions to support the kind of result unioning you > > want across multiple nameservers, I think they should be configurable > > and off-by-default. A simple option in resolv.conf could turn them on. > > And there could be options for requiring nxdomain from all servers > > (true union) or just for highest-priority when accepting negative > > results. > > I can't agree with this. It's reasonable to make options for these, > but I think the non-standard behaviors should be off by default. > Consider this from the point of view of a system like Docker or > Kubernetes, which generate resolv.conf for you - they have no idea > what libc your apps are using, so it's unreasonable to ask them to > turn off libc-specific flags. However, the end user knows, and it is > perfectly sane to ask them to explicitly opt-in to non-standard > optimized behaviors. > > >> > While it would be possible to parallelize the search while > >> > serializing the results (i.e. waiting to accept a result from the > >> > second query until the first query finished with a negative > >> > result), I think the consensus during the last round of > >> > discussion of this topic was that the complexity cost is too > >> > great and the benefit too small. Ideally, the first query should > >> > always succeed, anyway. > >> > >> The real world is not ideal. Not all nameservers are identically > >> scoped - you MUST respect the ordering in resolv.conf - to do > >> otherwise is semantically broken. If implementation simplicity means > >> literally doing queries in serial, then that is what you should do. > > > > Even legacy resolvers had the option to rotate the nameservers for > > load-balancing, so I think it's a stretch to say the ordering is > > supposed to be semantic. My view has always been that multiple > > nameservers in resolv.conf are for redundancy, not for serving > > conflicting records. > > You argued above that you should not try a secondary server in case of > timeout or SERVFAIL. Obviously you would not try it on success nor > NXDOMAIN. When do you see a secondary being used at all? > If I understand correctly, what you are expecting is this: Try resolving from ns1. If that domain does not exist on ns1, try ns2. If that domain does not exist on ns2, report failure. The only way to do this in a consistent fashion is actually to fall through to the secondary if and only if you get an nxdomain from ns1. > > As for rotate, note that it is an option and OFF by default in every > mainstream resolver implementation. > > But this point is sort of academic for us - we're moving to a > forwarding nameserver so really there is only the primary nameserver. > We just need you to ask the first nameserver first. > > >> Similarly, you can't just search all search domains in parallel and > >> take the first response. The ordering is meaningful. > > > > Indeed, search domains are like that, because they inherently produce > > ambiguity/overlapping namespaces with different definitions. This is > > why myself and others who weighed in on the original question of > > supporting them were against, but left the option open to revisit the > > topic if users who need them show up. > > Yeah, I scanned the related threads. I understand the issue in > theory, but in practice these are things configured by admins. If > there's a conflict or ambiguity, you should solve that, not jettison > powerful functionality. > > >> > I also have a few questions: > >> > > >> > 1. Do you need multiple search items, or just a single domain? > >> > Any setup with multiple searches necessarily has suboptimal > >> > performance because ndots is not sufficient to make the right > >> > initial choice of query. If you do need this functionality, a > >> > unioning proxy dns server may be a better option than resolv.conf > >> > domain search; it would give much better performance. > >> > >> We use multiple search paths and ndots > 1. I'm not sure what you > >> mean by "unioning" here. Search path ordering is as meaningful as > >> nameserver ordering. You can't avoid making the query for each search > >> suffix in the worst case, and it has the same restriction as > >> nameserver - the search order must be respected. > >> > >> There does seem to be some different implementations that search for > >> the "naked" query first vs last, though. I think the semantically > >> correct (but pessimal performance) is to search for that last. > > > > The traditional behavior is to do the naked query first if the query > > string has at least 'ndots' dots, and to do the search domains first > > otherwise. Also I believe a final dot always suppresses search. > > > > My point was that with ndots=1 (default) and only a single search > > domain, the _expected_ result is that the first query succeed. But if > > you have ndots>1 or multiple search domains, you expect a portion of > > your queries to fall back at least once. This adds significant > > latency. > > It adds latency, but the magnitude is very much determined by the > installation. In our case it is negligible and well worth the cost. > I fear you're optimizing without data - it should be the site-admin's > problem to configure things in an acceptable way. libc doesn't get to > decide what "acceptable" means. > > > In such a situation, you can avoid the additional latency (except on > > the first query of a given record) by running a local caching > > nameserver that does the search and unioning for you, rather than > > having the stub resolver in libc do it. Then subsequent queries > > succeed immediately using the cache. The reason I asked about usage > > case (ndots=1 vs ndots>1, single vs multiple search) is that, in the > > multi-fallback case, it might make more sense (from a performance and > > clean design standpoint) to implement this with a caching nameserver > > on localhost rather than in musl. > > We might be moving to a per-machine local DNS agent, which would cache > as you describe. HOWEVER, there's a pretty important piece that I > guess I left out. Docker and Kubernetes and similar systems run many > containers per machine. Each container has a potentially different > search path. I might run 100 or more containers on a single machine - > I can't run 100 DNS caches, and I can't put that back on users. > Why not? 100 DNS caches shouldn't be particularly expensive. > > So from our perspective the search paths MUST come from the containers > themselves, even if we run a machine local cache to mitigate latency > and SPOF. > > >> > 2. For your intended applications, is there a need to support > >> > ndots>1? Such configurations are generally not friendly to > >> > applications that expect to be able to resolve normal internet > >> > domain lookups, and performance for such lookups will be very bad > >> > (because the search domains first have to fail). > >> > >> DNS is a very lightweight protocol. We have not measured any > >> practical detriment for having 6 search domains and ndots=5. In the > >> normal case it fails very quickly. That aside, it should be my > >> business if I want to (mis)configure my system that way :) > > > > I suspect we have different definitions of quick... :) > > Quick is situational. In a cloud-based mostly-webapp stack, 50ms to > do a name lookup ain't so bad, given the relative infrequency of that > operation. Also most names actually DO resolve on the first or second > search path. > > >> > 3. The glibc behavior is just to swap the order of search when > >> > the query string has >=ndots dots in it, but would it be > >> > acceptable never to try the search domains at all in this case? > >> > That would yield much better performance for nxdomain results and > >> > avoid unexpected positive results due to weird subdomains > >> > existing in your search domain (e.g. a wildcard for > >> > *.us.example.com would cause *.us to wrongly resolve for > >> > non-existant .us domains). > >> > >> I think that would be correct. If I have 3 dots and ndots=2, search > >> paths should be ignored. > > > > Glad we agree on this. > > > > I hope you feel like this conversation is productive. I don't want to > > rule out anything/"say no" right away, but rather try to get a better > > understanding of your requirements first and figure out what makes the > > most sense to do on musl's side. > > Absolutely. I'm happy to engage. Obviously our use case is a bit > outside of what musl was really aiming for, but it offers a really > nice base for very efficient containers. A lot of people want to use > Alpine and it breaks my heart to tell them they can't. > --089e01634ab8d9e27e0522b9761c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 22= , 2015 at 3:37 PM Tim Hockin <thoc= kin@google.com> wrote:
On Th= u, Oct 22, 2015 at 2:56 PM, Rich Felker <dalias@libc.org> wrote:
> On Thu, Oct 22, 2015 at 02:24:11PM -0700, Tim Hockin wrote:
>> Hi all,
>>
>> I saw this thread on the web archive but am not sure how to respon= d to
>> the thread directly as a new joinee of the ML.=C2=A0 I hope this f= inds its
>> way...
>
> No problem; just starting a new thread like this and quoting the old > one is fine.
>
>> I am one of the developers of Kubernetes and I own the DNS portion= , in
>> particular.=C2=A0 I desperately want to use Alpine Linux (based on= musl)
>> but for now I have to warn people NOT to use it because of this is= sue.
>>
>> On Fri, Sep 04, 2015 at 02:04:29PM -0400, Rich Felker wrote:
>> > On Fri, Sep 04, 2015 at 12:11:36PM -0500, Andy Shinn wrote: >> >> I'm writing the wonderful musl project today to open = discussion
>> >> about the future possibility of DNS search and domain key= word
>> >> support. We've been using musl libc (by way of Alpine= Linux) for
>> >> new development of applications as containers that discov= er each
>> >> other through DNS and other software defined networking.<= br> >> >>
>> >> In particular, we are starting to use applications like S= kyDNS,
>> >> Consul, and Kubernetes, all of which rely on local name >> >> resolution in some way using search paths. Many users of = the
>> >> Alpine Linux container image have also expressed their de= sire for
>> >> this feature at
>> >> https://github.com/gliderlabs/= docker-alpine/issues/8.
>> >>
>> >> On the functional differences between glibc page, the dom= ain and
>> >> search keyword "Support may be added in the future i= f there is
>> >> demand". So please consider this request an addition= to whatever
>> >> demand for the feature already exists.
>> >>
>> >> Thank you for your time and great work on the musl libc p= roject!
>> >
>> > I think this is a reasonable request. I'll look into it m= ore.
>> >
>> > One property I do not want to break is deterministic results,= so
>> > when a search is performed, if any step of the search ends wi= th
>> > an error rather than a positive or negative result, the whole=
>> > lookup needs to stop and report the error rather than falling=
>> > back. Falling back is not safe and creates a situation where = DoS
>> > can be used to control which results are returned.
>>
>> I understand your point, though the world at large tends to disagr= ee.
>> Everyone has a primary and secondary `nameserver` record (or shoul= d).
>> If the first one times out, try the second.=C2=A0 Most resolver li= bs seem
>> to accept a SERVFAIL response or a timeout as a signal to try the = next
>> server, and I would encourage you to do the same.
>
> musl intentionally does not do this because it yields abysmal
> performance. If the first nameserver is overloaded or the packet is > lost, you suffer several-second lookup latency.

But at least it works eventually.=C2=A0 You're faced with a choice.=C2= =A0 Wait 2
seconds for ns1 to timeout and then fail in a way that most apps don't<= br> handle well or wait for 2 seconds and then (usually) get a fast
response from ns2.

It seems better in every way to eventually succeed, though I agree
it's a bit less visible.

With musl&= #39;s current design, you get a request to ns1 and ns2, and the first autho= ritative response wins. So, if ns1 fails then all is well and performance i= sn't even notably impacted. What you are describing appears to be how y= ou would *have* to implement it if you decide against considering all serve= rs equal, but instead try and serve the union of their responses (that is, = wait for timeout and then fail).

Consider what wou= ld happen if ns1 and ns2 have different responses, but ns1 for whatever rea= son times out (potentially an attacker). Then you get the results for ns2, = even though ns1 is intended to override it.
=C2=A0
>> Stopping on positive response or NXDOMAIN seems to be commonly
>> accepted with a caveat.=C2=A0 You can't query all nameservers = and just take
>> the first NXDOMAIN to respond.=C2=A0 You can only accept NXDOMAIN = if all of
>> the higher-priority (listed first in resolv.conf) nameservers have=
>> timed out or SERVFAIL'ed.=C2=A0 You can issue queries in paral= lel, but you
>> must process responses in order, which is what you describe below.=
>
> Timeout or servfail is not sufficient to accept an nxdomain from a
> lower-priority server. To preserve consistency of results under
> transient failure, you actually have to wait for the nxdomain from the=

I have to disagree.=C2=A0 Some non-forwarding DNS servers use SERVFAIL to indicate "I am not serving for that domain" specifically to make = the
client move to their next nameserver.=C2=A0 if ns1 returns SERVFAIL, try ns2.=C2=A0 If ns1 times out, try ns2.=C2=A0 Otherwise what good is ns2?
=

Note that this means that any condition wh= ere ns1 can't be accessed changes what DNS resolves to. If you wish to = prevent unexpected behavior when ns1 can't be accessed, you simply have= to get a response from ns1 first, and only ever query ns2 when the respons= e from ns1 indicates you may.
=C2=A0

> higher-priority server. Either way, this very much pessimizes usage > cases like running "netstat" with huge numbers of connection= s where
> many of the ip addresses fail to reverse. Being able to return
> immediately as soon as any one of the nameservers responds with
> nxdomain makes the difference between a <1s netstat run and a 5-10s=
> netstat run.

Sure it's faster but it's WRONG.=C2=A0 Returning a random number wo= uld be
faster, too, but it is equally wrong.=C2=A0 This is why netstat (and myriad=
other tools) has a `-n` flag.

=C2=A0Again, = musl's design assumes that all nameservers are hosting the same space, = and thus a single nxdomain is authoritative. If this is the case, then this= is perfectly correct. If it's not the case, then it's wrong (and y= ou need to wait for literally everything to nxdomain, and if there's a = timeout from a single server you *need* to report that).
=C2=A0
> Thus, if we add extensions to support the kind of result unioning you<= br> > want across multiple nameservers, I think they should be configurable<= br> > and off-by-default. A simple option in resolv.conf could turn them on.=
> And there could be options for requiring nxdomain from all servers
> (true union) or just for highest-priority when accepting negative
> results.

I can't agree with this.=C2=A0 It's reasonable to make options for = these,
but I think the non-standard behaviors should be off by default.
Consider this from the point of view of a system like Docker or
Kubernetes, which generate resolv.conf for you - they have no idea
what libc your apps are using, so it's unreasonable to ask them to
turn off libc-specific flags.=C2=A0 However, the end user knows, and it is<= br> perfectly sane to ask them to explicitly opt-in to non-standard
optimized behaviors.

>> > While it would be possible to parallelize the search while >> > serializing the results (i.e. waiting to accept a result from= the
>> > second query until the first query finished with a negative >> > result), I think the consensus during the last round of
>> > discussion of this topic was that the complexity cost is too<= br> >> > great and the benefit too small. Ideally, the first query sho= uld
>> > always succeed, anyway.
>>
>> The real world is not ideal.=C2=A0 Not all nameservers are identic= ally
>> scoped - you MUST respect the ordering in resolv.conf - to do
>> otherwise is semantically broken.=C2=A0 If implementation simplici= ty means
>> literally doing queries in serial, then that is what you should do= .
>
> Even legacy resolvers had the option to rotate the nameservers for
> load-balancing, so I think it's a stretch to say the ordering is > supposed to be semantic. My view has always been that multiple
> nameservers in resolv.conf are for redundancy, not for serving
> conflicting records.

You argued above that you should not try a secondary server in case of
timeout or SERVFAIL.=C2=A0 Obviously you would not try it on success nor NXDOMAIN.=C2=A0 When do you see a secondary being used at all?

If I understand correctly, what you are expecting i= s this:
Try resolving from ns1.
If that domain does not= exist on ns1, try ns2.
If that domain does not exist on ns2, rep= ort failure.

The only way to do this in a consiste= nt fashion is actually to fall through to the secondary if and only if you = get an nxdomain from ns1.
=C2=A0

As for rotate, note that it is an option and OFF by default in every
mainstream resolver implementation.

But this point is sort of academic for us - we're moving to a
forwarding nameserver so really there is only the primary nameserver.
=C2=A0We just need you to ask the first nameserver first.

>> Similarly, you can't just search all search domains in paralle= l and
>> take the first response.=C2=A0 The ordering is meaningful.
>
> Indeed, search domains are like that, because they inherently produce<= br> > ambiguity/overlapping namespaces with different definitions. This is > why myself and others who weighed in on the original question of
> supporting them were against, but left the option open to revisit the<= br> > topic if users who need them show up.

Yeah, I scanned the related threads.=C2=A0 I understand the issue in
theory, but in practice these are things configured by admins.=C2=A0 If
there's a conflict or ambiguity, you should solve that, not jettison powerful functionality.

>> > I also have a few questions:
>> >
>> > 1. Do you need multiple search items, or just a single domain= ?
>> >=C2=A0 =C2=A0 Any setup with multiple searches necessarily has= suboptimal
>> >=C2=A0 =C2=A0 performance because ndots is not sufficient to m= ake the right
>> >=C2=A0 =C2=A0 initial choice of query. If you do need this fun= ctionality, a
>> >=C2=A0 =C2=A0 unioning proxy dns server may be a better option= than resolv.conf
>> >=C2=A0 =C2=A0 domain search; it would give much better perform= ance.
>>
>> We use multiple search paths and ndots > 1.=C2=A0 I'm not s= ure what you
>> mean by "unioning" here.=C2=A0 Search path ordering is a= s meaningful as
>> nameserver ordering.=C2=A0 You can't avoid making the query fo= r each search
>> suffix in the worst case, and it has the same restriction as
>> nameserver - the search order must be respected.
>>
>> There does seem to be some different implementations that search f= or
>> the "naked" query first vs last, though.=C2=A0 I think t= he semantically
>> correct (but pessimal performance) is to search for that last.
>
> The traditional behavior is to do the naked query first if the query > string has at least 'ndots' dots, and to do the search domains= first
> otherwise. Also I believe a final dot always suppresses search.
>
> My point was that with ndots=3D1 (default) and only a single search > domain, the _expected_ result is that the first query succeed. But if<= br> > you have ndots>1 or multiple search domains, you expect a portion o= f
> your queries to fall back at least once. This adds significant
> latency.

It adds latency, but the magnitude is very much determined by the
installation.=C2=A0 In our case it is negligible and well worth the cost. I fear you're optimizing without data - it should be the site-admin'= ;s
problem to configure things in an acceptable way.=C2=A0 libc doesn't ge= t to
decide what "acceptable" means.

> In such a situation, you can avoid the additional latency (except on > the first query of a given record) by running a local caching
> nameserver that does the search and unioning for you, rather than
> having the stub resolver in libc do it. Then subsequent queries
> succeed immediately using the cache. The reason I asked about usage > case (ndots=3D1 vs ndots>1, single vs multiple search) is that, in = the
> multi-fallback case, it might make more sense (from a performance and<= br> > clean design standpoint) to implement this with a caching nameserver > on localhost rather than in musl.

We might be moving to a per-machine local DNS agent, which would cache
as you describe.=C2=A0 HOWEVER, there's a pretty important piece that I=
guess I left out.=C2=A0 Docker and Kubernetes and similar systems run many<= br> containers per machine.=C2=A0 Each container has a potentially different search path.=C2=A0 I might run 100 or more containers on a single machine -=
I can't run 100 DNS caches, and I can't put that back on users.
=

Why not? 100 DNS caches shouldn't be p= articularly expensive.
=C2=A0

So from our perspective the search paths MUST come from the containers
themselves, even if we run a machine local cache to mitigate latency
and SPOF.

>> > 2. For your intended applications, is there a need to support=
>> >=C2=A0 =C2=A0 ndots>1?=C2=A0 Such configurations are genera= lly not friendly to
>> >=C2=A0 =C2=A0 applications that expect to be able to resolve n= ormal internet
>> >=C2=A0 =C2=A0 domain lookups, and performance for such lookups= will be very bad
>> >=C2=A0 =C2=A0 (because the search domains first have to fail).=
>>
>> DNS is a very lightweight protocol.=C2=A0 We have not measured any=
>> practical detriment for having 6 search domains and ndots=3D5.=C2= =A0 In the
>> normal case it fails very quickly.=C2=A0 That aside, it should be = my
>> business if I want to (mis)configure my system that way :)
>
> I suspect we have different definitions of quick... :)

Quick is situational.=C2=A0 In a cloud-based mostly-webapp stack, 50ms to do a name lookup ain't so bad, given the relative infrequency of that operation.=C2=A0 Also most names actually DO resolve on the first or second=
search path.

>> > 3. The glibc behavior is just to swap the order of search whe= n
>> >=C2=A0 =C2=A0 the query string has >=3Dndots dots in it, bu= t would it be
>> >=C2=A0 =C2=A0 acceptable never to try the search domains at al= l in this case?
>> >=C2=A0 =C2=A0 That would yield much better performance for nxd= omain results and
>> >=C2=A0 =C2=A0 avoid unexpected positive results due to weird s= ubdomains
>> >=C2=A0 =C2=A0 existing in your search domain (e.g. a wildcard = for
>> >=C2=A0 =C2=A0 *.us.example.com would cause *.us to wrongly res= olve for
>> >=C2=A0 =C2=A0 non-existant .us domains).
>>
>> I think that would be correct.=C2=A0 If I have 3 dots and ndots=3D= 2, search
>> paths should be ignored.
>
> Glad we agree on this.
>
> I hope you feel like this conversation is productive. I don't want= to
> rule out anything/"say no" right away, but rather try to get= a better
> understanding of your requirements first and figure out what makes the=
> most sense to do on musl's side.

Absolutely.=C2=A0 I'm happy to engage.=C2=A0 Obviously our use case is = a bit
outside of what musl was really aiming for, but it offers a really
nice base for very efficient containers.=C2=A0 A lot of people want to use<= br> Alpine and it breaks my heart to tell them they can't.
--089e01634ab8d9e27e0522b9761c--