DNSSEC and SSL/TSL for outgoing DNS queries
-
Yesterday my area experienced a power outage and to my surprise everything did NOT come back up once power was restored. After a day of troubleshooting I pinpointed the root cause was having two settings enabled under ServicesDNS > Resolver > General Settings:
-
DNSSEC
-
Use SSL/TLS for outgoing DNS Queries to Forwarding Servers
The behaviour after the power returned was that I had internet access (could browse and ping raw ip) but DNS resolution was failing which caused my VPN tunnels to throw TLS certificate errors and all clients on the network to be unable to browse the internet. Once I disabled those two DNS settings though, everything worked.
I've had these settings configured for some time now and haven't had DNS issues. But this was the first time I've had them enabled before a power outage. I could confirm via wireshark captures and several site-checkers that my DNS queries were indeed getting encrypted so I know they were working.
Which leads me to my question: Is it expected behaviour that these settings only work after VPN tunnels have been established and after the DNS Resolver service has started? Is there some sort of initial DNS server negotiation that needs to take place over cleartext before I can enable these settings? Is there a way to have these enabled and still be able to recover from an outage without first needing to disable, then re-enable them?
-
-
@tikiyetti if your going to forward there is little point to dnssec being checked - where you forward either does dnssec or it doesn't - clicking that check box is only going to be problematic.. When you click forward, it should auto uncheck and prevent use of dnssec..
-
@tikiyetti
You also might want to check if the pfSense time is correct when you start the system.
At early booting, before unbound is started, NTP is started, and as there is no resolver or forwarder running yet, and you've set up forward DNS servers, these are used.
If not, 8.8.8.8 and 8.8.4.4 (by memory) are hard coded in pfSense (!) and used.
The thing is : if unbound is used with the DNSEC option, the correct time is needed. Because certificate usage need a very correct time.But as @johnpoz said : you are forwarding, so disable DNSSEC, making the unbound task much more simpler and less error prone.
-
@gertjan said in DNSSEC and SSL/TSL for outgoing DNS queries:
If not, 8.8.8.8 and 8.8.4.4 (by memory) are hard coded in pfSense (!) and used.
Huh - no that can not be true..
-
@johnpoz
I know.It's part of a chicken and egg issue.
'Time' can not work before 'DNS'. And if DNS uses DNSSEC, it needs the exact time. -
@gertjan I agree dnssec needs correct time - but I don't buy that pfsense hardcoded 8.8.8.8 to be used for dns??
Is that just checking that dns query can be made? Its not actually used to look up something?
edit:
If dns fails it fails, if do too wrong time and using dnssec so be it.. Please don't tell me that pfsense will at some point use 8.8.8.8 to query something it needs or a client asks for - unless specifically set to do so by the admin of that pfsense box..I would much rather just see a complete failure of dns then to fallback to something like googledns - unless I the admin of pfsense specifically set it to use those.
Running a resolver - in what scenario would I want my box to ask googledns for anything - even a test if can talk outbound on 53.. Not a fan of such a thing at all - query one of the root servers for something if you want to know if you can talk outbound on 53..
-
Most likely explanation is that the clock is off, though on 2.6.0 / 22.01 and later we do quite a lot at boot to ensure the clock is accurate:
https://redmine.pfsense.org/issues/12769
Read the linked commits for info on how to manually override the upstream NTP servers as well, it might help if your location has issues reaching the hardcoded ones.
Or if you're on an older release, upgrade.
All that said, as others have mentioned, if you are in forwarding mode, DNSSEC is pretty much useless anyhow, so you may as well shut that off.
-
@johnpoz I forward to CloudFlare's DNS 1.1.1.1 which, from what I've read, does DNSSEC.
-
@gertjan Thanks for the input, hadn't considered that.I forward to 1.1.1.1. When you say the pfsense time needs to be correct does that mean it needs to be in-sync with a specific timezone? Or in-sync with the DNS server I forward to?
I've disabled the two settings for now and since had two more power outages and everything has restored without issue so fortunately I'm not racing to fix anything but I would like to ensure I have all the right configurations to make DNSSEC work.
-
@tikiyetti yeah cloudflare already does dnssec - so having your unbound trying to do it again is just going to cause possible problems. Cause extra queries, and more than likely just slow down time when client asks for something and gets a response.
If what your looking for fails dnssec, which cloudflare is doing at their resolvers - then it won't give you an answer..
Here is query to a quad9 IP that specifically does not do dnssec
-
@jimp Thank you. I'm on 2.4.5-RELEASE-p1. So if I want DNSSEC then it only makes sense to put my pfsense into resolver mode, right? And if I do that then I need to specify an NTP server?
-
@johnpoz gotchya. ok makes much more sense now. Thank you. I'll just leave it disabled then. Didn't realize it was redundant to have that enabled when using the appropriate DNS server.
-
@tikiyetti for starters you should really update pfsense, that version is quite dated.
If you want to do your own dnssec, then yes you should just resolve which is what unbound does out of the box. Or if your wanting to forward then just pick a dns that does it already and uncheck dnssec in unbound.
I am not aware of any of the major dns providers that do not do dnssec out of the box - some of them have special IPs you can point to that don't do it - like the 9.9.9.10 IP for quad9, etc.. But pretty much any of the major players are doing it out of the box. So there is little point to having unbound try and do it if your forwarding - more likely than not just going to cause you possible issues at some point or another. Its just extra work for something that is already being done.
If you order a cheeseburger, do you scrape off the cheese when you get it an put your own cheese on?
If you want to control putting cheese on your burger, just order it plain (resolve) and then do your own thing for the cheese ;)