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: Nikos Mavrogiannopoulos <nmav at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org
- Date: Sat, 21 Jun 2014 02:22:23 -0400 (EDT)
- 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> <20140620145929 dot GW179 at brightrain dot aerifal dot cx>
> > > 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.
I think people are used to it they don't even notice. Hotels and airports do that all the time, and poison DNS replies with their captive portals.
> > 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.
That sounds like a reasonable option.
regards,
Nikos