This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: resolv.conf format for DNSSEC [was: DNSSEC support in stub-resolver]
- From: Rich Felker <dalias at libc dot org>
- To: Nikos Mavrogiannopoulos <nmav at redhat dot com>
- Cc: Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org
- Date: Fri, 20 Jun 2014 10:59:30 -0400
- Subject: Re: resolv.conf format for DNSSEC [was: DNSSEC support in stub-resolver]
- Authentication-results: sourceware.org; auth=none
- References: <535E41F5 dot 5020109 at redhat dot com> <loom dot 20140612T135904-448 at post dot gmane dot org> <20140612160823 dot E308B2C39C1 at topped-with-meat dot com> <1402659130 dot 6191 dot 52 dot camel at dhcp-2-127 dot brq dot redhat dot com> <53A3EF1E dot 2070909 at redhat dot com> <20140620134554 dot GV179 at brightrain dot aerifal dot cx> <1403275695 dot 30440 dot 35 dot camel at dhcp-2-127 dot brq dot redhat dot com>
On Fri, Jun 20, 2014 at 04:48:15PM +0200, Nikos Mavrogiannopoulos wrote:
> On Fri, 2014-06-20 at 09:45 -0400, Rich Felker wrote:
>
> > > Is it a good enough reason to create new file, let's say
> > > /etc/resolv-sec.conf for the purpose of declaring name servers as
> > > trusted?
> >
> > I don't think so. Rather this issue would be a good impetus for
> > getting such broken DHCP clients fixed. If the user wants resolv.conf
> > updated for the DHCP-provided nameservers, this should be done via a
> > callback script that can merge in other static settings, not direct
> > overwriting.
> > Note that there are already other options that suffer
> > from this overwriting issue (e.g. domain/search, options, etc.) so
> > making a new config file just for the DNSSEC options is a band-aid not
> > a proper fix.
>
> Yes, but these options if overwritten do not cause resolving to fail. If
Are you sure? Malicious ISPs/access points overwrite nameserver with
the address of nameservers that return wrong results. Overwriting
domain/search prevents lookups based on them from working. Overwriting
options almost surely prevents certain setups from working.
> the DNSSEC settings are lost it means that every application that
> depends on that will fail. That's a significant difference. It may have
> been that resolv.conf's semantics are known to too many people to change
> now.
>
> Nevertheless, if glibc adopts a different format than the one that is
> currently implemented for c-ares, we'd certainly consider it, but as it
> is now, there isn't any (counter)proposal.
IMO if you're going to try to fix the overwriting problem you should
fix it by allowing any option in the intended-never-to-be-overwritten
secondary file rather than restricting it to DNSSEC options. This
would, at least partly, solve the overwriting problem in general. Such
a file should be processed after the main resolv.conf and should
perhaps support a new option to discard everything that was already
read from resolv.conf.
Rich