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

[Petr Spacek]

On 21.6.2014 09:33, Siddhesh Poyarekar wrote:
> 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
I took some time to think about it and I agree with Siddhesh. It seems safer 
to fail closed than to risk a security issue.

My reasoning is:
- If the DHCP client is aware of the new option it will handle it as 
necessary/reasonable.
- If the DHCP client blindly overwrites the file then we can assume that it is 
old and it is better not to risk.

Anyway, my expectation is that the new configuration option will be used in 
mainly two situations:
- Validating resolver is running on local machine - resolv.conf always points 
to 127.0.0.1 and DHCP client can't touch it anyway.
- Validating resolver is running on hypervisor/container host - resolv.conf is 
configured by container management tools and is never overwritten from inside.

> 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
I'm afraid that we can't do that because it would open backdoor to existing 
systems which upgraded glibc but not other software.

> 2. Break backward compatibility by implying that 'nameserver' servers
> are not trusted and introduce 'trusted-nameserver' keyword that
> applications that modify resolv.conf decide on when to use.  The
> backward compatibility breakage won't matter because the keyword only
> affects applications that use AI_SECURE_ONLY and none of those exist
> yet.
So it basically doesn't break backwards compatibility because it is a new 
feature :-) As I said earlier, I like the second (this) approach.

-- 
Petr Spacek  @  Red Hat