This is the mail archive of the
mailing list for the glibc project.
Re: [PING] Re: DNSSEC support in stub-resolver
- From: Petr Spacek <pspacek at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 19 May 2014 14:11:34 +0200
- Subject: Re: [PING] Re: DNSSEC support in stub-resolver
- Authentication-results: sourceware.org; auth=none
- References: <535E41F5 dot 5020109 at redhat dot com> <20140428133201 dot GB24365 at domone dot podge> <5360BBBD dot 30901 at redhat dot com> <53737979 dot 9060006 at redhat dot com> <20140515213246 dot GA25777 at domone dot podge> <20140516005235 dot GA13048 at spoyarek dot pnq dot redhat dot com> <20140516094423 dot GA25382 at domone dot podge>
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
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.
option/env variable to only trust localhost resolvers.
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