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

Peter Russel jpgpi250 at gmail.com
Thu Apr 13 06:37:16 UTC 2023


Hi Simon

Unfortunately, it looks like I've been shouting victory a little soon.

The results are perfect when using dig, however, when using a browser
(firefox, edge) the results are unreliable / inconsistent.

The assumption is that adding the setting "add-cpe-id=01234" ensures
dnsmasq will ALWAYS request EDE information from upstream (unbound).
Can you confirm this?

There are currently 2 possible causes why it doesn't work perfectly.

1. the dnsmasq setting "add-cpe-id=01234" doesn't do what is expected
(always request EDE)

2. unbound doesn't store the EDE information in it's cache. Apparently
there are two PRs that haven't been merged in to master yet, that
would accomplish this, see the unbound issue
https://github.com/NLnetLabs/unbound/issues/873, comment from gthess.

Note that I also have knot-resolver installed on my system (using it
for script related tasks - normally inactive).
The pi-hole scripts will use knot-resolver as upstream (configured
using server= dnsmasq setting, example
"server=/v.firebog.net/127.10.10.5#5555"). The results from queries
with knot-resolver as upstream are also inconsistent. I have no idea
if knot-resolver caches EDE info, there is a lot less info available
for knot-resolver...

I'm waiting for the unbound PR's to be merged in to master, so I can
compile unbound with these changes, possibly excluding or confirming
this as the cause.

Could you confirm the setting "add-cpe-id=01234" does instruct dnsmasq
to always request EDE, if NOT, is it possible to do this in another
way?

Note that the changes made by the pi-hole developers have been
implemented in pi-hole-FTL, the dnsmasq code for proxy-dnssec hasn't
been changed, so using EDE only works with pi-hole, not with the
official dnsmasq v2.89

Don't know if you have a direct line with the pi-hole developer, if
you do, you could discuss this directly, I'm just the middle man here,
knowledgeable enough to test, not to change the code...



More information about the Dnsmasq-discuss mailing list