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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Fri, 20 Feb 2015 13:35:33 -0500
- 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>
On 02/20/2015 03:10 AM, Florian Weimer wrote:
> On 02/19/2015 08:05 PM, Siddhesh Poyarekar wrote:
>> DNAME records are a convenient way to set up RRSIG for an entire
>> subtree of a domain name tree instead of signing each of those
>> records. Querying on such domains result in messages about a
>> mismatch in the query type and returned record type. This patch
>> disables the logging of this message for DNAME records if the DO
>> bit is set.
>
> Can we remove the logging altogether? Or at least for the
> RES_USE_DNSSEC case?
Sure.
> The DO bit essentially means, “I'm fine with receiving unknown RR
> types”, it's not really related to DNSSEC. The reason for that is the
> fact that the DNSSEC protocol was changed twice (once for DNSSECbis,
> which is completely unrecognizable to the previous implementation, and
> once for NSEC3), and the flag was reused.
I would like to clarify this a bit for anyone reading, and please
correct me if I'm wrong.
DNSSECbis is the working draft of a new version of DNSSEC, the
"bis" is 2nd in latin. IETF has informal rules for naming things
"bis" as "coming after the RFC." The DNSSECbis documents also
update NSEC3. They are not a distinct independent implementation.
My understanding was that DNSSEC would remain the umbrella name for
what can be deployed as supporting NSEC and/or NSEC3 (still flawed)
and/or NSEC5 (requires online hashing) [1]
Whether the implementation of NSEC3 or NSEC5 support the DO-bit is
what might be in question. Though DNSSEC as the original implemetnation
does support it.
In all of these cases the use of the DO-bit remains. No further RFC
removes the use of the DO-bit from the client side protocol. None
that I am aware of.
> So unless there is a compelling reason for logging this information,
> I'd say just remove it.
Sounds good to me.
Cheers,
Carlos.
[1] https://www.cs.bu.edu/~goldbe/papers/nsec5.pdf