I pass the test on that website with OSX Mojave (Safari 13.0.4, and Firefox 71).
I additionally pass the test on Ubuntu (Firefox 71) and Pop!_OS (Firefox 71).
The test also passes on IOS 13 (Safari) on an iPhone 11 Pro.
Unfortunately can't help you with Windows – I don't have access to a machine that runs it at my home.
So it seems that it works fine on BSD/*NIX machines. May be a Windows only issue.
I would love to see the answers in the gui.
EDIT: Looks like i am getting info?
fwiw proxy-dnssec is working as intended with stubby sending the work upstream.
11:54:05 dnsmasq[1183]: query[A] dismail.de from 192.168.1.116
11:54:05 dnsmasq[1183]: forwarded dismail.de to 127.0.0.2
11:54:05 dnsmasq[1183]: query[A] dismail.de from 192.168.1.116
11:54:05 dnsmasq[1183]: forwarded dismail.de to ::2
11:54:05 dnsmasq[1183]: forwarded dismail.de to 127.0.0.2
11:54:05 dnsmasq[1183]: forwarded dismail.de to ::2
11:54:05 dnsmasq[1183]: forwarded dismail.de to 127.0.0.2
11:54:06 dnsmasq[1183]: dnssec-query[DS] dismail.de to 127.0.0.2
11:54:06 dnsmasq[1183]: dnssec-query[DNSKEY] de to 127.0.0.2
11:54:06 dnsmasq[1183]: reply de is DNSKEY keytag 45580, algo 8
11:54:06 dnsmasq[1183]: reply de is DNSKEY keytag 43434, algo 8
11:54:06 dnsmasq[1183]: reply de is DNSKEY keytag 18318, algo 8
11:54:06 dnsmasq[1183]: reply dismail.de is DS keytag 50809, algo 8, digest 2
11:54:06 dnsmasq[1183]: dnssec-query[DNSKEY] dismail.de to 127.0.0.2
11:54:06 dnsmasq[1183]: query[A] dismail.de from 192.168.1.116
11:54:06 dnsmasq[1183]: dnssec retry to 127.0.0.2
11:54:06 dnsmasq[1183]: reply dismail.de is DNSKEY keytag 50809, algo 8
11:54:06 dnsmasq[1183]: reply dismail.de is DNSKEY keytag 21153, algo 8
11:54:06 dnsmasq[1183]: validation result is SECURE
11:54:06 dnsmasq[1183]: reply dismail.de is 116.203.7.146
11:54:06 dnsmasq[1183]: query[A] dismail.de from 192.168.1.116
11:54:06 dnsmasq[1183]: cached dismail.de is 116.203.7.146
11:54:06 dnsmasq[1183]: query[AAAA] dismail.de from 192.168.1.116
11:54:06 dnsmasq[1183]: forwarded dismail.de to 127.0.0.2
11:54:06 dnsmasq[1183]: query[AAAA] dismail.de from 192.168.1.116
11:54:06 dnsmasq[1183]: forwarded dismail.de to ::2
11:54:06 dnsmasq[1183]: forwarded dismail.de to 127.0.0.2
11:54:06 dnsmasq[1183]: forwarded dismail.de to ::2
11:54:06 dnsmasq[1183]: forwarded dismail.de to 127.0.0.2
11:54:07 dnsmasq[1183]: validation result is SECURE
11:54:07 dnsmasq[1183]: reply dismail.de is 2a01:4f8:1c0c:80ac::80:1
2019-12-22 12:17:02 A duckduckgo.com windows10 OK (forwarded)
INSECURE IP (695.1ms)
This is straight from my gui I get dnssec responses.
What am i missing here?
This issue is unbound specific?
Is there an actual feature request buried in here that we can act upon?
It seems to me that I have shown that pihole can proxy dnssec and show the relevant information. I would think that shows the request has already been implemented.
Unless they are asking for a proxy dnssec switch or it being in operation by default.
You are correct, however these three screenshots show when it is switched off in pihole.
Not sure if it could matter or not but port 53 is blocked on the wan in my network.
At first i had both on. I switched it off after the above post. It was only dnssec proxy at that point (The toggle was off in the screenshots).
The results still display as intended in the gui for me. Like i said port 53 is blocked so anything dns related is going through stubby out of 853 or sometimes 443 depending on my resolver. I would assume that would make the pihole toggle useless.
EDIT: I am using an older and modified admin lte that could be why i have it working in the gui.
Pi-hole Version v4.3.2 Web Interface Version v4.3 (Update available!) FTL Version v4.3.1
I believe that nothing has to be done yet until proxy-dnssec gets fixed.
In the future, when it is fixed, it will be favorable to:
SECURE, BOGUS, or INSECURE in admin-LTE as per the behaviour when Use DNSSEC validation is ticked in the settings page.proxy-dnssec as a separate switch in Settings -> DNS -> Advanced DNS settings. It should gray out Use DNSSEC to make it clear to the user that the settings are independent of each other. Furthermore, include a warning where:Copy the DNSSEC Authenticated Data bit from upstream servers to downstream clients and cache it. This is an alternative to having dnsmasq validate DNSSEC, but it depends on the security of the network between dnsmasq and the upstream servers, and the trustworthiness of the upstream servers (e.g. you are running a local resolver – Unbound, Knot, dnscrypt-proxy).
However, as the thread has established, this feature is currently broken. DNSMASQ scrubs the ad bit in its cache. Thus, once a verified query is cached, it does not forward that bit to clients anymore.
It requires that a hack/workaround be implemented (as of DNSMASQ 2.80) wherein cache-size=0 must be set – thus preventing anything from being cached and making sure that the ad bit will always be forwarded.
Hi all
I did a few more tests myself and I still see the caching of --proxy-dnssec not working. Proxing itself is working as long as cache-size is 0.
At the moment I have my dns resolvers configured as
a) Upstream unbound on OpenWrt device with dnssec and qname-minimization
b) OpenWrt dnsmasq with --proxy-dnssec and cache-size 0
c) pi-hole with dnssec enabled
b is calling a, and now shows correct ad flags as it proxies the queries correctly from unbound
c is calling b, but has it's own dnssec validation as I don't want to loose the caching
I like the pi-hole because it is not only blocking ads but also shows what's going on in the network. That's why all my devices use the pi-hole (and this requires the dnssec ad flag to by set correctly on each response whether it comes from cache or not).
I did send a first question on the dnsmasq mailing list but didn't get a response so far. As now is christmas time I will follow up with this issue (caching with --proxy-dnssec) next year.
I got an answer from Simon which brings light to the problem.
Thanks for looking at this.
The history of this option is that it was added a long time ago, before
DNSSEC validation was added to dnsmasq, It purpose is to tell dnsmasq to
effectively trust the upsteam nameserver and the network between dnsmasq
and the upstream nameserver. For most purposes it is obsoleted by DNSSEC
validation within dnsmasq.
Looking at the caching behaviour, I think there's a fundamental problem
which makes it impossible to get correct behaviour in all cases. The
problem is that there is only one AD bit, but possibly many resource
records in the reply. The AD bit will only be set if ALL the RRs are
DNSSEC validated so that they can all be trusted. In that case, it's
fine to cache that information and return an answer from the cache with
the AD bit set when all the cached RRs are cached as secure.
Now consider a common case of a CNAME to an A record where the CNAME is
DNSSEC signed, but the A record is not. www.comcast.com is a good
example. If we query www.comcast.com as an A record, we'll get back a
CNAME for www.comcast.com and the A record it points to. The A record is
not signed, so the AD bit is not set. As the AD bit is not set, we can
only cache the two records (the CNAME and the A record) as NOT secure.
Now imagine a query just for the CNAME: answering from the cache which
is populated by the earlier query will yield an answer without AD, which
is wrong. The CNAME is signed, and a query just for the CNAME should
have the AD bit set, and will do when answered upstream.
The AD bit doesn't have enough information to cache the DNSSEC status of
individual RRsets when the answer contains more than one. The only
correct solution is the behaviour when --proxy-dnssec is not set and
DNSSEC validation is not enabled: dnsmasq should never return AD, and
nothing downstream of it should rely on that bit.
TL;DR -- proxy-dnssec is broken by design and should be deprecated. If
you want valid AD bits in answers from dnsmasq, enable DNSSEC validation
in dnsmasq.
An interesting problem!
Cheers,
Simon.
The explanation on the ad bit caching is really helpful for understanding the issue with the cache.
For it does not look like we get the caching fixed ... I will go for my setup so far as:
a) the pi-hole announced to the clients with dnssec validation and caching. This way it serves the ad flag correctly as this is needed for the postfix. The pi-hole has one upstream which is
b) the dnsmasq in my OpenWrt router which is responsible for my network (dhcp). This one is set up with --proxy-dnssec and cache-size 0. This way it serves the ad flag correctly to the other services running on the OpenWrt router. It has one upstream which is
c) an unbound on the OpenWrt router with dnssec, caching and qname-minimization enabled.
I really liked to have the --proxy-dnssec working with the cache (as I believe the validation in the unbound is enough for one network and I trust my unbound). But for me my current setup is ok.
Sven
So, this isn't a feature request anymore. I'll move it to a proper subject area.
I have my own domain as well, this means for me:
a) have a cname to dyndns entry (which is also dnssec signed), so: no, switching to other domains do not invalidate dnssec.
b) to have my own domain in my local network excluded from dnssec validation (as the names are resolved to internal ip addresses). unbound and dnsmasq both have this feature.
The whole problem with the cache is, that the ad flag indicates the answer in whole is validated or not (including cname to other domains...).
Whereas the cache in dnsmasq caches records (where we can have more of in a single answer).
So in case one of the records in the answer is not signed, there is no ad flag. But that doesn't mean that all of the records are unsigned.
It's a question if we need to cache all records as a client ist usally only interested in the result of the query he sends (and does not necessarily need all the other records that lead to the result). But for correctness it may be better to cache single records.
Anyway... for me my setup works.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.