This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Building consensus over DNSSEC enhancements to glibc.
- From: Rich Felker <dalias at libc dot org>
- To: Petr Spacek <pspacek at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 16 Nov 2015 13:21:46 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <20151109180310 dot GO3818 at brightrain dot aerifal dot cx> <5641C454 dot 3030309 at redhat dot com> <20151110174923 dot GS3818 at brightrain dot aerifal dot cx> <56433969 dot 10405 at redhat dot com> <20151111154525 dot GW3818 at brightrain dot aerifal dot cx> <56436FB2 dot 2010302 at redhat dot com> <20151111170706 dot GY3818 at brightrain dot aerifal dot cx> <5649BB13 dot 6040907 at redhat dot com> <20151116162328 dot GR3818 at brightrain dot aerifal dot cx> <564A1CB0 dot 7080508 at redhat dot com>
On Mon, Nov 16, 2015 at 07:13:04PM +0100, Petr Spacek wrote:
> >> This third option is a 'must have' for incremental deployment. There are no
> >> flag days on the big Internet. Nobody can 'turn on DNSSEC' on all DNSSEC
> >> domains in the global DNS tree.
> >
> > As I understand it, all domains in the global DNS tree either require
> > signatures or have a way to obtain a signed chain of records saying
> > that they do not use DNSSEC. Either of these is sufficient to treat a
> > result as valid (i.e. not ServFail it).
> >
> > If this is incorrect, could you explain how/why?
>
> Technically this is correct if DNSSEC validator configuration contains trust
> anchor for root zone. It would not be true for other configurations.
If you don't have that, you have a broken installation. This is no
different from having a glibc that has been actively patched to break
any other security invariant.
> Anyway, this is exactly the case where unsigned answers are returned and must
> be accepted, which effectively means that parts of DNS tree can be attacked
> (because they did not bother do deploy DNSSEC) - this is my understanding of
> your variant (3) above.
If an application is expecting results for part of the tree to be
signed (because the DNSSEC infrastructure for it is in place), then as
long as the local nameserver validates DNSSEC, you can never get an
unsigned or forged result for that part of the tree. So I don't see
any use in application-level checking of whether the result was
signed. If it wasn't signed the application would never have gotten
it.
Rich