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: Florian Weimer <fweimer at redhat dot com>
- To: Petr Spacek <pspacek at redhat dot com>, Rich Felker <dalias at libc dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 16 Nov 2015 14:22:06 +0100
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <563CED63 dot 1070201 at redhat dot com> <20151106182835 dot GC3818 at brightrain dot aerifal dot cx> <563D0953 dot 9020707 at redhat dot com> <56407C19 dot 2080906 at redhat dot com> <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>
On 11/16/2015 12:16 PM, Petr Spacek wrote:
> 'Not using DNSSEC: same situation as now' goes directly against the gold DNS
> standard. Please see original (i.e. pre-DNSSEC) RFC 1035:
> http://tools.ietf.org/html/rfc1035#page-26 section 4.1.1 Header section format.
>
> It clearly states what to do with bits 9, 10 (AD), and 11 in message header:
> "Reserved for future use. Must be zero in all queries and responses." So, if
> you decide not to use/ignore DNSSEC please do it in a standard-compilant and
> at the same time secure way: Zero out these bits unconditionally.
I'm sorry, but this argument is invalid. DNSSEC violates this clause in
RFC 1035. As a result, you cannot blame host A for turning
non-compliant when speaking to host B, which implements DNSSEC, violates
RFC 1035 requirements, and indirectly causes the non-compliance of host A.
In general, the DNS RFCs do not support this level of exegesis.
>From a technical point of view, clearing reserved protocol elements has
caused significant issues in the past; see the ECN signaling problems
encountered in the wild for an example. This is why I have reservations
about your proposal above, no matter what the RFCs say here.
Florian