Re: DNSSEC support in stub-resolver

[P J P <pj dot pandit at yahoo dot co dot in>]

> On Monday, 28 April 2014 5:26 PM, Petr Spacek wrote:
> =============

> Basic assumption is that only administrator knows if recursive resolver and 
> communication channel are trusted for DNSSEC validation or not.
> (E.g. Unbound vs. old dnsmasq ; IPSec vs. plain IP considerations.)
> 
> This trust must be expressed somehow.
> 
> If we consider machines using DHCP(d), it seems that we need to have 
> per-resolver configuration.
> 
> dhcpclient will mess with /etc/resolv.conf as usual, so global switch like 
> "resolver-trusted=true" could be dangerous. Imagine a case where admin 
> 
> installed local resolver, turned it on and then moved to another network. 
> Dhcpclient rewrote nameserver lines in /etc/resolv.conf. In that case the 
> system is vulnerable!
> 

> This reasoning leads to the question:
> How can we handle per-resolver options?
> 
> Examples (in no particular order; all names are random):
> 
> 1) Extend nameserver line in /etc/resolv.conf
> nameserver 127.0.0.1 trusted=true
> nameserver 192.0.2.1 # default is trusted=false
> I'm afraid that this will not work. I expect many programs parsing 
> /etc/resolv.conf and expecting the "classical" format ...
> 

> 2) Put per-resolver configuration to a separate (optional!) file
> E.g. /etc/resolv.ext (propose your own name)
> nameserver 127.0.0.1 trusted=true
> It seems a bit weird but maybe it is the cleanest option we have...
> 

> 3) Extend option syntax in /etc/resolv.conf
> options trusted:127.0.0.1
> I have no idea how in/compatible this change can be.
> 

> 4) Add a new verb to /etc/resolv.conf
> trusted-nameservers 127.0.0.1 192.0.2.1 2001:DB8::1234
> 

> Which option do you like? Propose your own!

  Options 3 & 4 are better, I'd vote for 4. For these seem least intrusive.

---
Regards
   -Prasad
http://feedmug.com