Behaviour change of dig +dnssec between 9.11 and 9.16

[Tony Finch]

Josef Moellers <jmoellers at suse.de> wrote:
>
> For the last 1½ weeks, I've been trying to dig (pun intended) through
> the bind 9.16.18 source code to find how the RRSIG makes its way to the
> user's screen but have failed so far.

Um, yes, that does not sound easy at all :-)

The answer to your questions is how DNSSEC is layered on top of classic
DNS. The +dnssec option to dig corresponds to the EDNS "DO" flag. When the
client sets the DO=1 flag it is telling the server that it understands
DNSSEC so it would like to receive RRSIG records, and NSEC(3) for negative
responses, and it understands the tricky details of DS records.

The DO flag is hop-by-hop, so how you set it with dig does not necessarily
match how your server resolves the query recursively. And DO says nothing
about whether the client does validation. For example, BIND's resolver has
set DO=1 by default for many years, but (as Peter Davies said) it only
started validating by default recently. So most recursive servers query
authoritative servers with DO=1 even when they are not validating.

So, why might RRSIGs be dropped? There are several unlikely reasons; my
most plausible explanations are towards the end of this list...

  * Perhaps there is a resolver in the chain of forwarders and/or
    recursive servers between you and the authoritative server which sets
    DO=0 or which does not do EDNS at all, so it does not receive RRSIGs
    and can't pass them back towards you

  * Perhaps there's a forwrder that repeats the client's setting of DO,
    and caches an RRset with or without RRSIGs. (I think this would be a
    bug...)

  * Perhaps there are connectivity problems which cause the resolver to
    fall back to trying to query without EDNS, so there is no DO flag to
    set, and it can't receive RRSIG records

  * Perhaps there is a non-validating resolver that sets DO=1, so it
    receives RRSIG records, but it might decide not to cache or return the
    RRSIG records due to RFC 2181 trustworthiness ranking. (I think this
    would also arguably be a bug)

  * With your empty dig command, dig actually asks for the root NS
    records; whether you get an RRSIG or not depends on how the resolver
    makes its priming query, with DO=1 or DO=0

  * Your .org NS query hits special cases in DNS and DNSSEC. A zone has
    two NS RRsets, a delegation NS RRset in the parent which is not signed
    (which you will get for .org if you query a root server directly), and
    an authoritative apex NS RRset which is signed. Resolvers often do not
    query for the apex NS, so their cache will not contain the RRSIGs, but
    if a client queries specifically for the NS records, the resolver must
    go and fetch the apex NS set, because of RFC 2181 trustworthiness
    ranking. But you might see the unsigned NS RRset in the additional
    section of a response to some other query...

I think most of those are not relevant if everything in your resolver
chain is BIND. As well as the dnssec-validation setting, one thing that
did change between 9.11 and 9.16 is BIND's retry logic, which is less
willing to drop EDNS than it used to be. I don't know if BIND has changed
its priming queries; that could be related to the dnssec-validation
setting.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
Southeast Iceland: Southwesterly 4 to 6, occasionally 7 in northwest.
Moderate, occasionally rough in north. Drizzle, fog patches. Moderate,
occasionally very poor.