[Dnsmasq-discuss] proxy-dnssec, how does it work (with unbound as upstream)

[Peter Russel]

Hi

Simon, you question (summary of what you're trying to achieve)

Obviously, I'm running pihole-FTL, which is dnsmasq + pi-hole features.

- dnsmasq is configured with unbound as upstream
- dnsmasq cache-size= 0
- dnsmasq DNSSEC not enabled
- unbound (latest master compiled) as recursive resolver with DNSSEC
- unbound uses cachedb module (redis)
- unbound is configured to use response policy zones (RPZ)
- knot-resolver used for entries like "server=/v.firebog.net/127.10.10.5#5555"
- knot resolver has DNSSEC capabilities.

A lot of websites are hosted at cloud providers, this implies some
regular websites have the same IP as known DOH servers, that are
listed in one of my RPZ zones.

The RPZ zone looks like (example):
dns.opendns.com CNAME .
32.220.220.67.208.rpz-ip CNAME .
32.222.222.67.208.rpz-ip CNAME .
128.35.zz.35.119.2620.rpz-ip CNAME .
128.53.zz.53.119.2620.rpz-ip CNAME .

Both the domain and the IP are blocked by unbound RPZ.
In order to allow me to visit regular sites, sharing the same IP as
the known DOH server, I use knot-resolver (server= entries), this to
bypass the RPZ config for known regular sites.

Since, in my opinion, it isn't very efficient to have unbound OR
knot-resolver validate DNSSEC, then forward the reply to dnsmasq, and
let dnsmasq do the DNSSEC validation all over again, I want to use
proxy-dnssec, thus evaluating the DNSSEC info, using the data already
available in EDE, supplied by unbound or knot-resolver.

Dominik, your questions and comments.

Thanks for explaining "add-cpe-id=01234", meaning that it informs
upstream that it is capable of processing EDNS data, nothing more.
This implies dnsmasq cannot be the cause of "not receiving EDE" data?
As I understood from you comments on discourse, the same could be
achieved with "add-mac=base64"?

Since you "somewhat" agree this might be caused by unbound, NOT
caching EDE data, it was my intention to wait for the unbound PRs to
be merged into master, than restart testing (unless instructed
otherwise by one of you).

I started posting only, because another pi-hole user is also testing
the feature (proxy-dnssec), and noticed the same inconsistencies, be
it under different circumstances (docker, using dnsmasq
cache-size=10000, no redis, ...)

I don't really understand why dig queries (both on the pi-hole
terminal and from a remote windows machine always provide the correct
status (SECURE), while site visits, using a browser provide
inconsistent statuses (SECURE / INSECURE) I assume dig replies are
also cached...

Again, thank you both for your interest in this, your valuable time and effort.