resolv.conf format for DNSSEC [was: DNSSEC support in stub-resolver]

[Petr Spacek]

On 13.6.2014 18:31, Rich Felker wrote:
> On Fri, Jun 13, 2014 at 01:32:10PM +0200, Nikos Mavrogiannopoulos wrote:
>> On Thu, 2014-06-12 at 09:08 -0700, Roland McGrath wrote:
>>> Are there other systems with DNSSEC support built in?
>>> What syntax do they use for resolv.conf?
>>
>> I'm not aware of any system with dnssec built-in on libc and the ones I
>> know I don't think they distinguish between trusted and non-trusted name
>> servers. As it is now applications use external libraries for the dnssec
>> operations (e.g., libunbound, or APIs like [0,1]), and these libraries
>> have their own configuration, rather than rely on resolv.conf.
>
> I really question the need for this. At worst it may even be a source
> of vulnerabilities. Linking cryptographic code into every process's
> namespace exposes them to bugs in said code (and by now we all know
> how that ends).
>
> IMO the right way to do DNSSEC is to run a nameserver (recursive or
> just caching) on localhost, list it as the only nameserver in
> resolv.conf, and have it be responsible for verification of trust.
> Then in case of any vulnerability, the worst that happens is the
> attacker gaining control over name resolution on the host, rather than
> gaining full privilege elevation to the privilege level of the process
> performing the lookup.
>
> Perhaps I'm missing something and the intent of this thread is only to
> add mechanisms for the resolver to report whether the nameserver
> claims the response is trusted, rather than actually doing any
> verification on the client side. If so, that might not be
> unreasonable.

That is exactly the point.

This thread is exactly about "run a nameserver (recursive or just caching) on 
localhost" + *make sure that system is secure even if the server is not 
running locally* (because admin never installed it etc.).

We are not going add/link glibc with crypto code.

Have a nice day!

-- 
Petr Spacek  @  Red Hat