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: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org
- Date: Sat, 21 Jun 2014 02:29:31 -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> <20140620203955 dot GB1792 at spoyarek dot pnq dot redhat dot com>
> On Fri, Jun 20, 2014 at 04:48:15PM +0200, Nikos Mavrogiannopoulos wrote:
> > 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.
> Isn't that the feature?
I never associated denial of service with a feature. No, a denial of service for dnssec once you login to a hotel or an airport, or when you connect to your vpn isn't acceptable.
> > It may have been that resolv.conf's semantics are known to too many
> > people to change now.
> Agreed, but that does not preclude addition of an option in a manner
> that does not break backward compatibility. In fact, adding another
> configuration file just for DNSSEC is just messy.
I also like clean solutions, when they work. At this moment we have a messy situation with /etc/resolv.conf and we need to extend it in a sensible way. Yes, if the situation was ideal the proposed solutions would be different, but we need to work at the current situation.
regards,
Nikos