Behaviour change of dig +dnssec between 9.11 and 9.16

[Josef Moellers]

Hi Tony,

Thanks to you, too. A very excellent writeup. I think I can learn quite
a bit from that.
If only I could make up for your (both of you) efforts.

Stay healthy and take care,

Josef

On 29.06.21 16:10, Tony Finch wrote:
> 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.
> 


-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer