[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151023081259.GX28311@example.net>
Date: Fri, 23 Oct 2015 10:12:59 +0200
From: u-uy74@...ey.se
To: musl@...ts.openwall.com
Subject: Re: Re: Would love to see reconsideration for domain and
search
On Thu, Oct 22, 2015 at 11:00:32PM +0000, Josiah Worcester wrote:
> > On Thu, Oct 22, 2015 at 02:24:11PM -0700, Tim Hockin wrote:
> > 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.
> 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 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.
> > 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).
> > 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.
+1 to the level 1 comments
+1 to solving the particular problem of a certain deployment
(the massive reliance on search paths)
inside the deployment, not in a general purpose library
It looks unrealistic to both have redundancy and differing/conflicting
data on different servers in a consistent fashion, by the mere mechanisms
of resolv.conf.
Nice that musl chose consistency and redundancy.
Good if there is an option suitable for systems which need differing
functionality, but please not at an extra cost for other parties.
A DNS cache looks of course like the right option for fine tuning the
desired resolution behaviour.
Rune
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.
