This is the mail archive of the libc-alpha@sourceware.org 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: Building consensus over DNSSEC enhancements to glibc.


On Fri, Nov 06, 2015 at 10:42:38AM +0100, Petr Spacek wrote:
> On 5.11.2015 02:23, Rich Felker wrote:
> > On Wed, Nov 04, 2015 at 03:44:48PM -0500, Carlos O'Donell wrote:
> >> Community,
> >>
> >> I have written up a summary of the mailing list discussions
> >> surrounding DNSSEC and the enhancements required to better
> >> support it in glibc.
> >>
> >> https://sourceware.org/glibc/wiki/DNSSEC
> >>
> >> Any thoughts or comments would be much appreciated.
> > 
> > While I'm not opposed to clean ways to expose DNSSEC trust to
> > applications, I don't see a bit libc role in the ideal client setup:
> > you just run a local nameserver that verifies DNSSEC and replies with
> > ServFail upon receiving forged reslts/results that are supposed to be
> > signed but aren't.
> 
> This scheme is okay in principle and we want to deliver it in Fedora, however,
> it is missing one important aspect: It has to fail safe.
> 
> If the local validating resolver is not available for whatever reason the
> application cannot rely on AD bit - doing so would be a security nightmare
> because an attacker could easily spoof SSL/SSH key fingerprints etc.

In such a configuration, if the local validating resolver is not
available, all lookups fail with an inconclusive error.

Presumably you're assuming having a non-local backup nameserver
configured. Such a configuration is inherently broken and insecure.
resolv.conf should contain nothing but "nameserver 127.0.0.1" on a
DNSSEC enabled system.

Rich


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