Re: Building consensus over DNSSEC enhancements to glibc.

On 11/04/2015 03:44 PM, 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.

(I am not a DNS nerd, but I *am* a security nerd.)

The conversation so far has convinced me of something I've suspected for
a while: The nameservers configured in /etc/resolv.conf *cannot* be
trusted - not even 127.0.0.1.  The only approach that seems viable to me
is to scrap the idea of outsourcing DNSSEC validation to a local DNS server.

That doesn't mean every process has to do its own DNSSEC validation.
Rather, this seems like a job for ... nscd.  Remember nscd?  Let's dust
that off and repurpose it as a DNSSEC-aware recursive resolver.  Its
behavior is to send queries to whatever's in /etc/resolv.conf, but *not*
ask for DNSSEC validation; instead, it manually retrieves all of the
necessary ancillary records and does the validation itself.  This solves
the problem that's being argued over, because the configuration that
random things muck with (which server to send queries to) is completely
decoupled from the question of who is responsible for signature
verification.  It's never the configured nameserver; it's always nscd.

(If nscd is not running, or if no trust root is available, we could
either fall back to DNSSEC-blind behavior, or we could just fail all
domain lookups.  I suspect that wants a knob, and I think that knob
belongs in nsswitch.conf.)

On the API-level issues, I suggest:

 - getaddrinfo, gethostbyname, etc. should return SERVFAIL (in DNS-ese)
if any zone in between the requested name and the root is supposed to be
signed but doesn't validate.  "Trust flags for the data [they] return"
are practically guaranteed to be misinterpreted in a security-unsafe manner.

 - The lower-level API provided by libresolv *might* be able to provide
a mode in which untrusted and fraudulent records are marked and passed
through, but I am nervous about that.

 - "Higher-level APIs for key material access" and "new flags to
increase the usability of the existing APIs with regard to DNSSEC"
should be prototyped in an external library before inclusion in glibc.

 - The nscd-to-application protocol should be stabilized and documented
so that external libraries (eg. libc-ares) can talk to it too.

zw