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

[Florian Weimer <fweimer at redhat dot com>]

On 02/20/2015 07:35 PM, Carlos O'Donell wrote:

> 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.

DNSSECbis is the current version of DNSSEC.  The first version had
shipping code but was never deployed widely, even less than the current
attempt.  It used the SIG/KEY/NXT record types previously referenced in
the glibc sources.  The current version (DNSSECbis) uses
RRSIG/DNSKEY/NSEC instead  (or NSEC3 instead of NSEC, which is not
backwards-compatible and could be argued to be a new version).

> 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]

I don't think NSEC5 is really a thing, it's more like IPv7.

> 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.

Sorry, I don't understand.

> 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.

The DO bit was introduced early because it was noticed that some clients
would choke on the unknown (to them) resource records sent along with
DNSSEC responses, so some mechanism was needed to suppress the record to
enable name resolution for those older implementations.

-- 
Florian Weimer / Red Hat Product Security