@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 ms

The 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 ms

Compare 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 ^^

@stephenw10,
all of pfSense are v24.11-RELEASE (amd64); as far as I can see now, KEA actually never worked for me since I migrated from ISC, regardless of the pfSense version.

@70tas

If one is created, its in /var/etc/

If none is created, the the update was deemed not necessary, and was skipped.
You can force an update of course. Delete the 'cache' file, you'll find it in /cf/conf/ - and the file starts with dyndns.... and end with dot cache.

@Gertjan oh I missed that - my bad.

@JonathanLee said in DNSSEC Resolver Test site:

https://wander.science/projects/dns/dnssec-resolver-test/

The patato checker.

Uncheck :
77b420f9-5499-4301-8050-7c1f6a6560d3-image.png

and do the test again.

So that page, and this one : http://www.dnssec-or-not.com/ test if you've checked the resolver's DNSSEC capability, or not ^^

That web site is part of my collection of web sites that test several DNS(SEC) related things.
I 'admin' several web servers ( = domain names), I also use site use this one https://dnsviz.net/d/test-domaine.fr/dnssec/ to check out a domain name DNSSEC capabilities, as I need to be sure it works = me not messing up things when deploying it.
test-domaine.fr is a domain I rent and use to test things before I apply them on the domains that can't afford down time when I mess up (again).
Remember : if you set up DNSSEC wrong on your web server, mail server ( actually DNS domain name server ), your domain name will 'vanish' from the Internet.
DNSSEC was considered rocket science not so long ago and maybe it still is, as using it really implies that you know what DNS is.

The good thing about pfSense : when you install it, and don't change (add, remove) any pfSense DNS settings, it will use DNSSEC out of the box without the user (admin) even being aware of anything.
DNSSEC = that's why resolving (yourself, locally) is such a good thing.
Forwarding means : you have to trust some one else.

Last time I checked, half of Europe's web site are using DNSSEC, and the US was ... not really using it.
That changed a lot the last several years : DNSSEC is now somewhat mandatory for all government hosted sites world wide.

@jamesdun

@jamesdun said in DNS problem:

if the new machine wasn't picking up the correct DNS server

Well, launch

ipconfig /all

and it tells you what DNS server it uses.
Normally, a new Windows PC will use DHCP is so it's 'plug and play'.

@jamesdun said in DNS problem:

Both machines show the correct DNS server when NSLookup is launched, although the old one also gives it a name and the new one fails to do the reverse lookup

Looks like the new machine isn't allowed to do DNS requests against pfSense ?

@jamesdun said in DNS problem:

and the new one fails to do the reverse lookup

Humm. The new one's DNS request gets refused ...

@AWeidner its just pfsense trying to proect you against a rebind. When you foward to something that is normal some external public NS - which normally should not be returning rfc1918.

You might want to read some of the history of rebind attacks. And why this good protection to have in place.

Hmm, yeah I'd expect it to only be resolving leases that were present before that change. Like if you add a new static dhcp lease on that interface I'd expect that to fail to resolve.

@Gertjan those 3 name server might be just his isp dns.. that first on is fibreop and the others are aliant - which are the same isp - with the fibre one being for their FTTH.

Yeah if you want to use those - you should have unbound forward to them - but I see little benefit to forwarding for dns, just let unbound resolve is better option imho.

I’m sorry didn’t fully explain - config file exported to exact same dell server with same intel nics and exact same Cisco 3500 switch and unfi ap both instances are identical
My only problem that needs a solution is how do force the use of either my vpn dns servers or ones I chose on things connected to my vpn client as the way it runs now is that dns leak testing displays my isp address which is fixed (at least in uk can’t tell if Comcast is fixed)
I can use dedicated dns on browsers and also on devices buts not very satisfactory.
Unfortunately I’m not anyway a networking expert just having to find my way around stuff - thou when I built it years ago it did exactly what I needed but something changed either with Pfsense or Nordvpn service (been there to find solutions but no help) anyways thanks for the help!

@madbrain said in Purpose of pools:

Is it only to allow for non-contiguous IP address ranges for dynamic leases ?

Not only no but that could well be one option for a much larger subnet (although that does seem rather haphazard). It's perhaps more commonly used to further segregate a predefined subnet to allow/disallow certain devices to use predetermined portions of the pool.

@Ghost-0 said in UniFi access points successfully adopt under ISC DHCP but won't adopt when KEA DHCP is enabled.:

I will read and try it

I've edited my post above.
A second, JSON text structure is also needed. It has to be 'defined' first :

3bf5cd46-1026-4266-8b1b-78c21fcf8392-image.png

{ "option-def": [ { "name": "unifi", "code": 1, "space": "vendor-encapsulated-options-space", "type": "string" } ] }

on the main
ea85cce3-d17b-430c-a2b5-e6573550e6dd-image.png

page.

Then, as said earlier, on every interface where you need the DHCP option 43, you have to put :

{ "option-data": [ { "name": "vendor-encapsulated-options" }, { "name": "unifi", "space": "vendor-encapsulated-options-space", "csv-format": false, "data": "C0A80109" } ] }

where "C0A80109" is hex for 192 168 1 9 => 192.168.1.9 if your controller uses 192.168.1.9 (an IP on my LAN network).
So you probably have to adapt that hex string.
The rest can be copied and places as-is.
That's in newbie range ^^

@mgaudette Did you made it working? We having same issue with redirect zones.

@patient0 that was my exact issue