[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5629FF5F.8060004@skarnet.org>
Date: Fri, 23 Oct 2015 11:35:27 +0200
From: Laurent Bercot <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: Re: Would love to see reconsideration for domain and
search
On 23/10/2015 10:12, u-uy74@...ey.se wrote:
> +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.
+1 to all this.
"search" in /etc/resolv.conf was *never* meant to list resolvers
serving different results. It was always meant to list backups
serving consistent results. Any other use of "search" lines is
abusing the mechanism; if it works with glibc, it is a testimony
that glibc doesn't care about consistency, not an argument that it
is a valid use case. The right way to proceed is to implement an
ad-hoc resolver that suits the specific wanted usage, not to
modify a libc that implements the proper behaviour.
--
Laurent
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.
