This is the mail archive of the
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: Fri, 20 Jun 2014 16:48:15 +0200
- 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>
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
> 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
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
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.