This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Building consensus over DNSSEC enhancements to glibc.
- From: Rich Felker <dalias at libc dot org>
- To: Paul Wouters <pwouters at redhat dot com>
- Cc: Simo Sorce <simo at redhat dot com>, Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org
- Date: Sat, 7 Nov 2015 19:32:00 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <563A6E40 dot 9040508 at redhat dot com> <20151105012328 dot GU8645 at brightrain dot aerifal dot cx> <563C760E dot 4060107 at redhat dot com> <20151106175956 dot GA3818 at brightrain dot aerifal dot cx> <563CED63 dot 1070201 at redhat dot com> <20151106182835 dot GC3818 at brightrain dot aerifal dot cx> <563D39AD dot 3050404 at redhat dot com>
On Sat, Nov 07, 2015 at 08:37:17AM +0900, Paul Wouters wrote:
> On 11/07/2015 03:28 AM, Rich Felker wrote:
>
> > On a system configured with DNSSEC you do not allow resolv.conf to be
> > changed by dhcp clients. Doing so is a bug.
>
> Life is more complicated than that. That's why things like
> dnssec-trigger exist to begin with.
>
> 1) Blocked port 53 except to local resolver
> 2) hotspots
> 3) transparent redirection to non-dnssec resolver
>
> Additionally, we are seeing more initiatives in the DPRIVE working
> group to work on dns privacy, so more and more we will see people
> who don't want to use the local resolvers for anything else but
> portal negotiation. Which is a good thing I think.
"Local resolver" means 127.0.0.1:53 to me. Not a resolver on the local
network (e.g. ISP provided). Perhaps there's a discrepency in our
usage of the term that's leading to misunderstanding here. Any
problems that can possibly arise can be handled by always using
127.0.0.1:53 and passing off the responsibility for whatever complex
behaviors are needed to the process bound to this port. That includes
dns privacy.
Rich