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