This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Silence resolver logging for DNAME records when DNSSEC is enabled


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]