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: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: Nikos Mavrogiannopoulos <nmav at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, Rich Felker <dalias at libc dot org>, Petr Spacek <pspacek at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 21 Jun 2014 13:03:14 +0530
- 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> <1954454503 dot 21456984 dot 1403332171875 dot JavaMail dot zimbra at redhat dot com>
On 21 June 2014 11:59, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> 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.
I probably don't understand what you actually mean because what I
think you're saying is that daemons should be allowed to overwrite
resolv.conf with whatever crud they want and even if the AD bit is
sent from an untrusted server we should forward it as trusted so that
applications using DNSSEC do not break.
Only applications that explicitly ask only for trusted responses (i.e.
responses from trusted nameservers) will experience such a denial of
service and it is obvious why - the DNS configured by DHCP or somebody
else is *not* trusted. Alternatively, DHCP, etc. can be patched to
overwrite resolv.conf in a manner that they can indicate which servers
are trusted. That is how one would set up DHCP on a closed network
for example.
> 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.
>
The current situation is messy only if we assume that applications
that overwrite resolv.conf refuse to play along. Such applications
may well overwrite whatever new file you decide to write because they
have root and they've essentially decided not to play along.
So the options I see as being the best way forward are:
1. Maintain backward compatibility by implying that 'nameserver'
servers are trusted and introduce an 'untrusted-nameserver' keyword
that applications that modify resolv.conf decide on when to implement.
For example, they use the new keyword when connecting to ad hoc
wireless networks or have an option letting users choose
2. Break backward compatibility by implying that 'nameserver' servers
are not trusted and introduce 'trusted-nameserver' keyword that
applications that modify resolv.conf decide on when to use. The
backward compatibility breakage won't matter because the keyword only
affects applications that use AI_SECURE_ONLY and none of those exist
yet.
Siddhesh
--
http://siddhesh.in