This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PING] Re: DNSSEC support in stub-resolver

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.


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]