[PING] Re: DNSSEC support in stub-resolver

[Petr Spacek]

On 16.5.2014 11:44, Ondřej Bílka wrote:
> On Fri, May 16, 2014 at 06:22:35AM +0530, Siddhesh Poyarekar wrote:
>> On Thu, May 15, 2014 at 11:32:46PM +0200, Ondřej Bílka wrote:
>>> I would start with simpler steps first, a huge patch for
There is something missing, apparently :-)

Personally, I don't think that difference between separate option for 
trust-localhost-only and general IP-address-based trust list would be "huge". 
It definitely adds some complexity but IMHO not a lot.

 >>> What about adding configure
>>> option/env variable to only trust localhost resolvers.
I'm afraid that it is not enough. It will not work at least for containers. 
Typically (in production environment), an application in container is not 
allowed to mess with firewall, routing etc. For example application in Docker 
container *can not* modify resolv.conf. Those values are 'given' by hypervisor.

>> The localhost resolver must be implicitly trusted, so there's no point
>> in adding an option to enable or disable that.  Maybe you meant 'add
>> an option to trust the configured resolvers'?  Then that is
>> essentially what Petr is proposing.
>>
>> Siddhesh
>
> No, by default we trust everything. I proposed option to trust localhost
> and distrust everything else. I do not see yet need for configure
> options beyond that.

IMHO even localhost cannot be trusted by default (for DNSSEC).

Let me explain my position:
This is not about mis-configuration or intentional attack from outside.
It is about crappy software users are running on their machines.

DNSSEC gives cryptographically-strong assurance that data sent to the 
application are okay. This is the place where cryptography and DNS meets.

As a result, recursive resolver must be carefully implemented - and that is 
the problem. There is *a lot* of crappy software in the wild (like dnsmasq). 
This 'crappy' software is susceptible to lies from outside and can be fooled 
to set AD bit to 1 even if no DNSSEC validation was done.

I want to see API which fails closed. Upgrade should not open a new security 
hole just because libc was upgraded but dnsmasq was not. For this reason I 
propose to distrust everything by default.


I hope this explains my reasoning. Have a nice day!

-- 
Petr Spacek  @  Red Hat