This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: DNSSEC support in stub-resolver
- From: James Cloos <cloos at jhcloos dot com>
- To: libc-alpha at sourceware dot org
- Cc: Petr Spacek <pspacek at redhat dot com>
- Date: Sat, 03 May 2014 16:51:28 -0400
- Subject: Re: DNSSEC support in stub-resolver
- Authentication-results: sourceware.org; auth=none
- Copyright: Copyright 2014 James Cloos
- Openpgp: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc
- Openpgp-fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
- References: <535E41F5 dot 5020109 at redhat dot com>
My pipedream was to get the validating resolvers to listen(2) on a
well-known unix-domain socket(7), and have the stubs try that before
looking at resolv.conf(5). The api still would need an update to let
the apps know whether the answers are trust(ed|able).
But even that can be thwarted by any attacker who can replace the daemon
with their own.
The probable final answer is to require validating stubs, which do a
full top-down, non-caching verification. They would rely on resolv.conf
resolvers for their cache. This also requires an updated api for the
apps to know how much to trust any answers.
Any new api needs explicit notification of any BOGUS results.
In any case, to work without a local resolver, the stubs need to be
ready to retry over tcp if the reply is longer than 1 mtu.
(There are zones with results too large even with edns to query over
udp. Stub lookups fail when asking any non-localhost resolver but work
fine over the lo interface, given the latter's much larger mtu. From
what I can test, lo mtus range from 16k on freebsd to 64k on linux.)
(I cannot test, here, whether jumbo frames may be enough.)
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6