Netgate Documentation on DNS over TLS and NOT using DNSSEC
-
@Uglybrian here took me sec to lookup the url where quad9 gives the same advice
https://docs.quad9.net/Quad9_For_Organizations/DNS_Forwarder_Best_Practices/
Disable DNSSEC Validation
Since Quad9 already performs DNSSEC validation, DNSSEC being enabled in the forwarder will cause a duplication of the DNSSEC process, significantly reducing performance and potentially causing false BOGUS responses.
Not saying dns most likely won't work - you might not ever really run into a problem. But it is pointless and best case you are causing more dns traffic than is needed. Worse case is you run into issues actually returning an answer to what your looking for.
-
Was about to reply with the same link. FWIW in my experience forwarding with DNSSEC on can cause random DNS failures, which as I vaguely recall seemed more apparent on some domains than others...I would guess those with DNSSEC configured but didn't bother pursuing, given the fix.
Using DoT or not is not really relevant to the above. That's just how the router is making the query.
-
@SteveITS said in Netgate Documentation on DNS over TLS and NOT using DNSSEC:
Using DoT or not is not really relevant to the above
exactly - a forward is a forward is a forward.
-
@mark_lab_user said in Netgate Documentation on DNS over TLS and NOT using DNSSEC:
I don't think DNS over TLS and DNSSEC are mutually exclusive.
They are - for now.
These 13 servers are maintained by non-profit organizations.
Remember : the root servers know where the TLD servers can be found.
The same thing goes for the TLD servers, the ones that 'serve' the (at least 2) domain name servers.If these 'root' and 'TLD' servers were doing TLS out of the box, the execution path (== the number of CPU instruction needed to generate a DNS packet with TLS info) would increase .... 1000 or more fold.
And this for every DNS request (edit : caching will still work, so we are some what saved here).
So, all these servers will need an massive soft and hardware upgrade.
So.... the free DNS system as we know it, won't be 'free' anymore.The question is somewhat comparable as these two :
In the past, FM radio was invented. It was mono of course. Then, later on, 'stereo' was invented.
The mission was : how to send FM radio waves that are interpreted by mono receivers as a normal mono radio signal, but if the receiver (radio) is stereo capable, it will decode the stereo signal with the the 19 kHZ pilot tone, and crate a stereo signal.
Same thing for the TVs. It was black and white only, remember ?
And then some one wanted color... so the mission was : create a signal that works fine with the then sold B&W TV's, and if the TV was color, capable, it would a pilot signal (the famous 4,43 Mhz carrier) so encoded color info could be created. Also known as 'NTSC' or 'PAL'.For the DNS, an comparable solution has been found : after all, the billions of devices that are not DNSSEC aware still need to work.
DNSSEC capable devices, mostly resolvers, will use extra DNS requests to create chained 'certified' resolution path that validates the classic DNS records :
Let's test :[25.07-RC][root@pfSense.bhf.tld]/root: dig cnn.com +trace ; <<>> DiG 9.20.6 <<>> cnn.com +trace ;; global options: +cmd . 82763 IN NS e.root-servers.net. . 82763 IN NS f.root-servers.net. . 82763 IN NS g.root-servers.net. . 82763 IN NS h.root-servers.net. . 82763 IN NS i.root-servers.net. . 82763 IN NS j.root-servers.net. . 82763 IN NS k.root-servers.net. . 82763 IN NS l.root-servers.net. . 82763 IN NS m.root-servers.net. . 82763 IN NS a.root-servers.net. . 82763 IN NS b.root-servers.net. . 82763 IN NS c.root-servers.net. . 82763 IN NS d.root-servers.net. . 82763 IN RRSIG NS 8 0 518400 20250731050000 20250718040000 46441 . NRFnNWuVR08lRAe+87X58gD0xl2F0UVt34gFDsfoAmzpiOshPFt7LwBO +QcCtr9srtqmTTmPyz27lCAKSi+GNQ6F+vs0VyhDmXNuEd6gMQnfw6Tu rpm5tkcEsRYXU1htmr3pNXRUW1+SCHhLo/zQDP0JEe2YVfJ9qnzDl1sT gdF0s9Ed3pWzGCEbuE8f6vA+PCCadgo/xIWz2eteLKLRv9dBU0KxR30b aTU4tlCQpID9Ro3Xo2rFAr3024+FoyEnbIc0zu8cD8HMMhhLJrSogvI4 fRCLC9S4t/c5ltNdQyButyvNMzLhAMaDTwD8ha2ZgBd9FDHTVq/8KrPt BRjOgA== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A com. 86400 IN RRSIG DS 8 1 86400 20250731050000 20250718040000 46441 . WkMvN6EzzCAKLkLkoS0xtM1CgGVkkL6dEhZORU2btI6TrOAhPGQPCs6n t0Z+J6cAdlbKKuFwrQlERS/FlRh5OOfSfmj+e370PVyDrj7Y6Y/TUtI0 FTHBUJei+RNZ81dITCkwTWRmxRHFDdI8mk43NlFFuZEiPpRgYdXkd59I lP+hYF3IfSrLq0eA9TmY+ALfVUDPfpzFZQ3BWyJO8Jr4bXmGlt3S+HOa BFAh0v697JBwRiUdgtLSefsQp1GFGtlWBK/JpUabtbDM5jFavp35FC3l SYIItOhZOOohrZ9bmeBemNPfeQYxegHHg5I3yQJxa+5uMCE69OjIrlCv XLn/cg== ;; Received 1195 bytes from 2001:500:12::d0d#53(g.root-servers.net) in 38 ms cnn.com. 172800 IN NS ns-587.awsdns-09.net. cnn.com. 172800 IN NS ns-378.awsdns-47.com. cnn.com. 172800 IN NS ns-1652.awsdns-14.co.uk. cnn.com. 172800 IN NS ns-1242.awsdns-27.org. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20250722002513 20250714231513 40097 com. LIIPfcTghRBdCz5tqwNgOVDck+5y89zrjPYm6piSp3xALo4ed9l85kiG LpuDB+iuCHqrZEOwkGoNoZCcjKfjzA== FVT7IKJ9C0BTF07HNDO4FLBRB7D7NCL2.com. 900 IN NSEC3 1 1 0 - FVT7K43DJ0K7KJ384M71US54D3690VUI NS DS RRSIG FVT7IKJ9C0BTF07HNDO4FLBRB7D7NCL2.com. 900 IN RRSIG NSEC3 13 2 900 20250723013103 20250716002103 20545 com. a3qrXxTG+GQ3SXiDLPFTy5uKrbDprI7dVTTfhw072FvVBxlbJ2kAnI0z K5iLWWtZoGgE7+88UPBAAQCtBBbB1w== ;; Received 546 bytes from 2001:503:a83e::2:30#53(a.gtld-servers.net) in 22 ms cnn.com. 60 IN A 151.101.67.5 cnn.com. 60 IN A 151.101.195.5 cnn.com. 60 IN A 151.101.131.5 cnn.com. 60 IN A 151.101.3.5 cnn.com. 172800 IN NS ns-1242.awsdns-27.org. cnn.com. 172800 IN NS ns-1652.awsdns-14.co.uk. cnn.com. 172800 IN NS ns-378.awsdns-47.com. cnn.com. 172800 IN NS ns-587.awsdns-09.net. ;; Received 237 bytes from 2600:9000:5306:7400::1#53(ns-1652.awsdns-14.co.uk) in 24 msThe RSIG and DS records are "DNSSEC".
Compara this to a classic resolve 'no ddnssec request' :
[25.07-RC][root@pfSense.bhf.tld]/root: dig cnn.com +trace +nodnssec ; <<>> DiG 9.20.6 <<>> cnn.com +trace +nodnssec ;; global options: +cmd . 82598 IN NS m.root-servers.net. . 82598 IN NS a.root-servers.net. . 82598 IN NS b.root-servers.net. . 82598 IN NS c.root-servers.net. . 82598 IN NS d.root-servers.net. . 82598 IN NS e.root-servers.net. . 82598 IN NS f.root-servers.net. . 82598 IN NS g.root-servers.net. . 82598 IN NS h.root-servers.net. . 82598 IN NS i.root-servers.net. . 82598 IN NS j.root-servers.net. . 82598 IN NS k.root-servers.net. . 82598 IN NS l.root-servers.net. ;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. ;; Received 832 bytes from 2001:7fd::1#53(k.root-servers.net) in 21 ms cnn.com. 172800 IN NS ns-587.awsdns-09.net. cnn.com. 172800 IN NS ns-378.awsdns-47.com. cnn.com. 172800 IN NS ns-1652.awsdns-14.co.uk. cnn.com. 172800 IN NS ns-1242.awsdns-27.org. ;; Received 189 bytes from 2001:503:d2d::30#53(k.gtld-servers.net) in 25 ms cnn.com. 60 IN A 151.101.195.5 cnn.com. 60 IN A 151.101.67.5 cnn.com. 60 IN A 151.101.131.5 cnn.com. 60 IN A 151.101.3.5 cnn.com. 172800 IN NS ns-1242.awsdns-27.org. cnn.com. 172800 IN NS ns-1652.awsdns-14.co.uk. cnn.com. 172800 IN NS ns-378.awsdns-47.com. cnn.com. 172800 IN NS ns-587.awsdns-09.net. ;; Received 237 bytes from 205.251.196.218#53(ns-1242.awsdns-27.org) in 23 msCompare the two. Sit back, think a bit, and you'll find that many experts have though about the situation, and they have chosen the best possible solution.
The size of the info send over is ... 10 20 or 30 times more.
DNS packets can even be bigger as '1500' bytes so TCP has to be sued instead of the way faster UDP.World wide, a couple of extra 10 GKwh nuclear power plants have to be created, dedicated for the public DNS servers before the switch to "DNSSEC only" is made.
Compare the two. Sit back, think a bit, and you'll find out that many experts have thought about the situation for decades, and they have chosen the best possible solution
Netgate did the same thing : as soon as 'unbound' was avaible, they switched of the forwarder (dnsmasq) and activated the forwarder. After all, forwarding was pretty mandatory back then, often imposed by our ISPs, as they wouldn't allow DNS traffic to further then their own DNS servers. That changed as bandwidth is less an issue, now, we, as end users, can resolve our selves.
Because security comes first (and privacy comes later).
When you forward, you have to trust the DNS server where you forward to.Btw : I admit, I was brainwashed back then, when I was attending some of the DNSSEC seminars.
If you were lucky, they showed you why DNSSEC was needed : they spoofed the microsoft windows update domain name info, and then they updated a test windows PC, which started to pull in updates from specially crafted "update.Microsoft.com" look-alike clone, so a spoofed, NOT Microsoft server. No need to have a science degree to understand what will happen if this happens tomorrow in the wild ... the world economy will fail in minutes.
If DNS gets spoofed, even TLS (certificates) won't protect you.
You'll se a green padlock in your browser when you visit microsoft.com or your bank. But it won't be microsoft, neither your bank.edit : Forgot something.
The big fortune 500 companies, the ones that "offer" free ** DNS services, will not offer any DNSSEC services, as the can't do that : the sahre holders will forbid it for two reasons :
a) exploitation costs will explode - and net profit will plunge as there will be no extra income from a free service.
b) More people will start to thing : why ask 'X' for a DNS resolve if I can it from a certicate source.
Also : if you want' the phone number of paul, why ask Peter ?? Ask Paul !** not free, as they 'use' your DNS info : they sell it, and that's the reason they do it : they are in it for the the money ^^
-
@Gertjan Very comprehensive and the analogy to FM radio and Stereo is great. (And fun too!)
Maybe some of the more popular Netgate pfSense advocates should update their instructions and/or videos. Youtube will send you in the wrong direction about 90% of the time but there are some dedicated folks that seem to want to clarify or update their material.
I wonder how we can reach out to them?
-
@mark_lab_user said in Netgate Documentation on DNS over TLS and NOT using DNSSEC:
want to clarify or update their material.
So you want them to something with this wording?
DNSSEC is not generally compatible with forwarding mode, with or without DNS over TLS.
It seems pretty clear to me..
-
@johnpoz No. I want them to update their own material to reflect the fact that DNSSEC should be turned OFF inf the GUI DNS Resolver pages when using TLS.
-
@mark_lab_user.. Ah I would agree they could maybe add a note under dnssec checkbox. And to the forwarding checkbox that if forwarding dnssec should be disabled.
This should prob be listed under both options
"DNSSEC is not generally compatible with forwarding mode"
-
https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-config.html has:
DNSSEC works best when using the root servers directly, unless the forwarding servers support DNSSEC. Even if the forwarding DNS servers support DNSSEC, the response cannot be fully validated.
If upstream DNS servers do not support DNSSEC in forwarding mode or with domain overrides, DNS queries are known to be intercepted upstream, or clients have issues with large DNS responses, DNSSEC may need to be disabled.
https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html#enable-dns-over-tls-for-forwarded-queries has the quoted text:
DNSSEC is not generally compatible with forwarding mode, with or without DNS over TLS.
Using TLS (or not) is not actually related to this.
FWIW I did open a redmine a while back to auto disable it when forwarding, and it was declined.
Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
Upvote 👍 helpful posts! -
@SteveITS Somebody upvote me for this can of worms I just opened. I think I created lots of discussion.
-
@SteveITS Yeah I recall previous discussions on this - and while I agree with you prob should be just disabled when you forward. I can see the point in not doing it as well. I can not think of any scenario where it would actually work correctly when you forward. Doesn't mean there might not be some way to leverage it.. But I just don't see it, and have never seen it in real world that is for sure.
If the admin wants to shoot themselves in the foot, then hey they shoot themselves in the foot. But it sure couldn't hurt to remind users hey if your going to forward, this prob not a good idea. So I think a note under the options would be best of both worlds. You still allow freedom of configuration by the admin, but remind those that might not be reading all the documentation on a subject be it available by netgate or 3rd party sites or not. Hey this prob not a good configuration.
-
Not disagreeing with anything stated thus far—all interesting discourse to me. Merely sharing that I've been forwarding
unbound's recursive DoT lookups to Cloudflare and Quad9 simulatenously with DNSSEC enabled for many years without issue. I've never encountered any problems that seemed to stem from double validation, conflicting checks, blocked or broken answers, untrusted anwers, or mismatched trust anchors and/or an incomplete chain of trust. (And obviously, unless there was an apparent client DNS issue on my LAN, some of that could be happening without me even realizing.)I faintly recall troubleshooting/tweaking "EDNS Buffer Size" (
Services / DNS Resolver / Advanced Settings / Advanced Settings) at one point, and I currently have it set to "4096: Unbound Default". I think I also experimented with "Experimental Bit 0x20 Support" but ultimately left it off for improved performance. Those are the only DNSSEC-related tweaks I remember ever fiddling with.Nary do I see a 150+ ms query time when I'm paying attention.
-
@tinfoilmatt said in Netgate Documentation on DNS over TLS and NOT using DNSSEC:
I've never encountered any problems
And what have you gained by asking for something that has already been done.. You mention you leave 0x20 off for performance - but want to do a bunch of queries for dnssec that make no matter?
