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

[Dominik Derigs]

Hey Peter,

On Thu, 2023-04-13 at 08:37 +0200, Peter Russel wrote:
> 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?
> 

it is not possible to "request" EDE codes. What happens here is that a
client has to signal EDNS(0) capability. unbound then adds EDE *at its
own discretion*.

Adding the "add-cpe-id" option ensures that dnsmasq always signals EDNS
capability upstream - even when the client didn't do so. Whether unbound
then replies with EDE data is entire up to unbound.

> 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.

Following the ubound issue, this makes some sense: EDE information will
not be available from cached queries.

> 
> 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...
> 

When you provide PCAPs (dnsmasq "dumpfile" option) with knot-resolver as
upstream, we can easily check if the replies contain EDNS. However, I
also encourage you to load them in Wireshark and play around yourself,
exploring what you see in the "additional records" section.

> 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?

See above, this is not what this option is doing. Adding it merely
ensures that dnsmasq *always* tells unbound that it can process EDNS
data - regardless of the client further downstream can do it.

> 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

I don't think dnsmasq does anything more than forwarding EDE codes it
received from upstream. There is no interpretation happening in dnsmasq.

> 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...

We listen and respond here, too, when we have something valuable to
contribute :-)

Dest,
Dominik