This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: resolv.conf format for DNSSEC [was: DNSSEC support in stub-resolver]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]