[Dnsmasq-discuss] --proxy-dnssec?

[Simon Kelley]

On 20/12/2019 15:23, S.B. wrote:
>  
> Hi
> 
> I did a few tests with the --proxy-dnssec option and according to my
> tests it seems as if this feature is not working as documented.
> 
> If I query a dnssec signed domain I get an ad flag from my unbound which
> is my upstream server, but on every subsequent query that is answerd by
> dnsmasq from its cache there is no ad flag in the response. After the
> cache expired the first call again has an ad flag as provided from the
> upstream response.
> 
> Am I missunderstanding the --proxy-dnssec or am I doing something wrong?
> 
> Any help welcome.
> 

Thanks for looking at this.

The history of this option is that it was added a long time ago, before
DNSSEC validation was added to dnsmasq, It purpose is to tell dnsmasq to
effectively trust the upsteam nameserver and the network between dnsmasq
and the upstream nameserver. For most purposes it is obsoleted by DNSSEC
validation within dnsmasq.

Looking at the caching behaviour, I think there's a fundamental problem
which makes it impossible to get correct behaviour in all cases. The
problem is that there is only one AD bit, but possibly many resource
records in the reply. The AD bit will only be set if ALL the RRs are
DNSSEC validated so that they can all be trusted. In that case, it's
fine to cache that information and return an answer from the cache with
the AD bit set when all the cached RRs are cached as secure.

Now consider a common case of a CNAME to an A record where the CNAME is
DNSSEC signed, but the A record is not. www.comcast.com is a good
example. If we query www.comcast.com as an A record, we'll get back a
CNAME for www.comcast.com and the A record it points to. The A record is
not signed, so the AD bit is not set. As the AD bit is not set, we can
only cache the two records (the CNAME and the A record) as NOT secure.

Now imagine a query just for the CNAME: answering from the cache which
is populated by the earlier query will yield an answer without AD, which
is wrong. The CNAME is signed, and a query just for the CNAME should
have the AD bit set, and will do when answered upstream.

The AD bit doesn't have enough information to cache the DNSSEC status of
individual RRsets when the answer contains more than one. The only
correct solution is the behaviour when --proxy-dnssec is not set and
DNSSEC validation is not enabled: dnsmasq should never return AD, and
nothing downstream of it should rely on that bit.

TL;DR -- proxy-dnssec is broken by design and should be deprecated. If
you want valid AD bits in answers from dnsmasq, enable DNSSEC validation
in dnsmasq.

An interesting problem!


Cheers,

Simon.