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. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
