Hey Peter, On Thu, 2023-04-13 at 12:15 +0200, Peter Russel wrote: > > 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?
Yes. > As I understood from you comments on discourse, the same could be > achieved with "add-mac=base64"? Yes. > 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). Disabling unbound's cache should reveal already now if this is cache- related. Every resolution will be slow when all caches are disabled, however, they should at least be consistent. > 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, ...) Check out the dnsmasq man page entry for proxy-dnssec: Note that caching the Authenticated Data bit correctly in all cases is not technically possible. And indeed, when querying something like posteo.de, you will see the AD bit being set for the first (forwarded) but never for any later (cached) reply. As Pi-hole has no other chance than looking at the AD bit in proxy-dnssec mode, this translates into the first query being SECURE and all later ones are INSECURE. > 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... To sum this up: I agree with the man page sentiment that using "dnssec" is the better option. Yes, validation work will be duplicated, however, no additional traffic should be generated as your unbound already had to get all the DS and DNSKEY for its own validation so this all can be served from unbound's cache. I'm running dnsmasq with "dnssec" and am also running a local unbound for almost a decade in validation mode, too. Not that I could remember any issues in the past few years. Best, Dominik _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
