This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Silence resolver logging for DNAME records when DNSSEC is enabled
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 23 Feb 2015 16:36:03 +0100
- Subject: Re: [PATCH] Silence resolver logging for DNAME records when DNSSEC is enabled
- Authentication-results: sourceware.org; auth=none
- References: <20150219190506 dot GA20188 at spoyarek dot pnq dot redhat dot com> <54E6EC01 dot 1060906 at redhat dot com> <54E77E75 dot 7050609 at redhat dot com> <54EAFF14 dot 3010203 at redhat dot com> <54EB4074 dot 9080406 at redhat dot com> <54EB415B dot 50303 at redhat dot com> <54EB4781 dot 5090109 at redhat dot com>
On 02/23/2015 04:30 PM, Carlos O'Donell wrote:
> Just to be clear, you mean to say:
>
> * The DO bit was reused in DNSSECbis.
Yes.
> * DNSSECbis itself is changed significantly from DNSSEC.
>
> - Uses new RRs.
Right.
> - Should not confuse NSEC3-unaware resolvers.
That would be “old DNSSEC-aware resolvers” (NSEC3 came later).
> - Should not cause NSEC-aware resolvers to mark
> NSEC3-aware systems from being marked as invalid
> signatures.
In DNSSEC terminology, DNSSECbis-signed zones should be marked as
Insecure (unsigned) by DNSSEC-gold (the original standard)-aware
resolvers. I.e., they would still return data to clients, but wouldn't
indicate it is signed. The other implementation choice would have been
claim there has been an attack and not return any data. (In practice,
there were bugs here, same thing happened with NSEC3.)
> * The semantics of the DO bit remain roughly the same.
That depends what the semantics are. If “DO” means “DNSSEC OK”, then
the semantics did change significantly. If it means “you can send along
random garbage, and I will cope”, semantics remained unchanged.
> * The DO bit can continue to be used as expected.
Yes, this mostly worked. The interop failure (Insecure vs Bogus) was
not caused by DO interpretation conflicts.
--
Florian Weimer / Red Hat Product Security