On 21 June 2014 11:59, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
I never associated denial of service with a feature. No, a denial of service for dnssec once you login to a hotel or an airport, or when you connect to your vpn isn't acceptable.
I probably don't understand what you actually mean because what I
think you're saying is that daemons should be allowed to overwrite
resolv.conf with whatever crud they want and even if the AD bit is
sent from an untrusted server we should forward it as trusted so that
applications using DNSSEC do not break.
Only applications that explicitly ask only for trusted responses (i.e.
responses from trusted nameservers) will experience such a denial of
service and it is obvious why - the DNS configured by DHCP or somebody
else is *not* trusted. Alternatively, DHCP, etc. can be patched to
overwrite resolv.conf in a manner that they can indicate which servers
are trusted. That is how one would set up DHCP on a closed network
for example.
I also like clean solutions, when they work. At this moment we have a messy situation with /etc/resolv.conf and we need to extend it in a sensible way. Yes, if the situation was ideal the proposed solutions would be different, but we need to work at the current situation.
The current situation is messy only if we assume that applications
that overwrite resolv.conf refuse to play along. Such applications
may well overwrite whatever new file you decide to write because they
have root and they've essentially decided not to play along.
So the options I see as being the best way forward are:
1. Maintain backward compatibility by implying that 'nameserver'
servers are trusted and introduce an 'untrusted-nameserver' keyword
that applications that modify resolv.conf decide on when to implement.
For example, they use the new keyword when connecting to ad hoc
wireless networks or have an option letting users choose