Netgate Documentation on DNS over TLS and NOT using DNSSEC
-
I don't understand of the following Note in the documentation is relevant anymore.
DNSSEC is not generally compatible with forwarding mode, with or without DNS over TLS.I don't think DNS over TLS and DNSSEC are mutually exclusive.
What could be the harm. Seems both are needed these days. I use 2.7.2 and Cloudflare 1.1.1.2 and 1.0.0.2.
-
Here’s how I understand it. Your Cloudflare forwarders are already are using DNSSEC. If you’re forwarding servers do not use DNSSEC or you are using the root servers then you would have it checked on. Having it on when you are forwarding to DNSSE servers can create problems. Like, double validation, leading to conflicting checks, blocked or broken DNS responses, your firewall not trusting validated responses, mismatched trust anchors or an incomplete chain of trust.
-
@Uglybrian said in Netgate Documentation on DNS over TLS and NOT using DNSSEC:
If you’re forwarding servers do not use DNSSEC
If they are not doing it - asking for it isn't going magically work.. If you forward , dnssec should be off.. Either where you forward is doing it or they are not - if they are not, having it enabled is only going to cause issues.
I don't think DNS over TLS and DNSSEC are mutually exclusive.
They are since to use dot your forwarding - when you forward you shouldn't have dnssec enabled.
If you want to forward, be it normal over 53, or using doh or dot.. Use of dnssec is going to be nothing but problematic.
If you want to forward and use dnssec, then pick something to forward too that is doing it.. Most any of the major players are doing it, or have an IP you can use that does it.
-
@johnpoz said in Netgate Documentation on DNS over TLS and NOT using DNSSEC:
If they are not doing it - asking for it isn't going magically work.. If you forward , dnssec should be off.. Either where you forward is doing it or they are not - if they are not, having it enabled is only going to cause issues.
Good to know, thank you.
-
@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 ^^
