23.01 Upgrade unbound Issue
-
The default configuration has Forwarding off and DNSSEC on. Someone enabling forwarding should probably disable DNSSEC manually but that isn't rejected by validation or changed automatically.
-
Forwarding is probably several msecs faster.
Are there other major advantages for not doing resolving ?
And thus not doing DNSSEC ?I've just checked https://dnsviz.net/d/linkedin.com/dnssec/ - so they do DNSSEC.
I've asked my unbound : dig @127.0.0.1 linkedin.com +trace and saw that 'dnssec' flaf was set : the result was 100 % valid.
I mean, I was happy the day I didn't need to use these ISP DNS servers any more.
I could, finally, use the real thing : the root servers ! The ones that define DNS, and are close to core Internet. Resolving means : I need nobody, I mean not needed external resources, for 'DNS' to work. DNSSEC is just a nice bonus.Who wants to inform me why I should consider 'forwarding' ?
No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@gertjan said in 23.01 Upgrade unbound Issue:
Who wants to inform me why I should consider 'forwarding' ?
Won't be me, you couldn't get me to forward my dns to anyone to be honest.. There is zero point to it if you can resolve. Only reason would might be if your on a horrible connection and just can not reliably resolve - say sat or something, or your on a connection that is messing or blocking dns other than to them, etc. vpn might do that - you know for your own good <rolleyes>
Forwarding is probably several msecs faster.
Who says - might there be a few ms longer to resolve something from scratch, ok.. sure.. But once have the gltds cached, and for that matter the authoritative ns for any specific domain. When I need to look up say host.somedomain.tld would go direct to that domains ns.. Which might/could be faster or slower than say some forwarders ns.
But that I can tell you for sure, is every query to some forwarder is going to take X ms, at best - where maybe slower when they have to resolve it, because its not in their cache, etc.
using a forwarder for faster lookups is not really a valid reason to use them.. At best your talking a few ms anyway - who cares? if you think 10ms here or there is making a difference in your overall experience in internet browsing - your not understanding how any of it works to be honest. Or how fast 10ms is ;) That is ms, not minutes not seconds.. .010 seconds..
-
@gertjan It's another layer of filtering/security. Encrypted connection out to a known DNS provider. For filtering we have a couple of different tiers based on how much filtering we want the location to have. Quad9 for example does some basic DNS blocking. Some sites get NextDNS connections so IT can manage rules centrally there rather than running pfBlocker locally. Some get wide open Cloudflare DNS servers. Some get filtered Cloudflare.
-
Some ISPs break acting as a resovler in various ways as well, either rate limiting or address limiting who you can reach on common DNS ports, or other similar shenanigans.
DNS over TLS/DNS over HTTPS are OK if you really trust the provider on the other end. Those are for privacy and not for authentication/validation, though. If you forward you have to trust that the upstream DNS servers are also not changing your query results in unexpected ways.
-
@jimp I understand your logic. Is it therefore a regression in unbound, if it worked with DNSSEC enabled in prior pfSense versions? If the answer is, "it's not supposed to work" then I can understand that too. I'm just trying to help people out.
Worst case, after people upgrade to 23.01 and have a problem then they won't have it enabled for future upgrades anyway. Perhaps a "if you are using forwarding and have problems disable this option" note on that setting, if it's not too much handholding. -
The answer really depends entirely on the upstream resolver behavior, so there is no way to know. If we put a note on the option then it's likely to be missed since they'd have to already know which option they'd need to disable to see that or to know their problem is related to forwarding, which isn't obvious. Bit of a chicken/egg issue there.
This is already covered in the docs under troubleshooting DNS issues:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/dns.html#check-dns-service
-
@jimp
It just seemed like a lot of people were now/newly hitting it on 23.01 so unbound behavior apparently changed. I need to check that setting when we get to updating the rest of our, and all our clients, routers.
(Always good to read the docs. Not sure I cited it this thread but I have in others.) -
Mmm, it does seem like something has changed there causing people to hit this who weren't before. I wonder if it's some secondary effect though like they were always hitting it but cached values were hiding it until the upgrade.
-
@stephenw10 I have not had time to look through all the changes in unbound. But were we not on like 1.15.something, and now we are on 1.17.1 - have to assume lots of changes to unbound in such a big jump in version numbers.
is it also possible that something changed with say quad9.. I had not noticed their actual recommendation to disable dnssec if you forward to them until recently where it was pointed out in a thread. Has that been their standing recommendation for a long time, or did they possible make some changes that now make it the dnssec failures hit more often? If using 1.17.1 unbound?
-
I haven't noticed any issues on my 23.01 "Test Box"
And i even use DNSSEC w. Forwarding.
Making my 20 meters from the pfSense to my two linux DNS servers "super secure" ...
/Bingo
-
That's your own hosted DNS resolvers? Interesting. They support DNSSec I preseume.
It seems unlikely any upstream change, at Quad9, would have coincided with 23.01 release. But perhaps people just started checking after upgrading. I agree some behaviour change in Unbound seems most likely to me.
Steve
-
@stephenw10 I just did a breeze over of the changes and bug fixes in unbound from 1.15 to 1.17.1 and nothing jumped out at me.. But possible something that was fixed now triggers more failures that should of failed before but didn't, etc.
I despise forwarding, so while I will turn it on to show how it can be done. I have no desire to leave it on for any length of time to see if errors occur on specific domains I might be going to, etc. Or after a amount of time..
if someone could point out a specific query that fails when forwarding using dnssec and forwarding, but works fine with just forwarding to a dnssec resolver, be it over tls or just clear, etc. I would be up for looking into that.
-
I'm only forwarding because:
1:
I already had a working linux DNS/DHCP setup , that does dynamic DHCP entries in DNS.2:
Unbound DHCP adding "hosts", created unacceptable reload/delays.
I want my DHCP devices to be resolvable, and more important to have "sane names" in the DNS system.DNSSEC all 20 meters on a local network ... Is kind'a "well it hasen't broke yet" , and my Bind9's are setup to accept it.
/Bingo
-
@bingo600 said in 23.01 Upgrade unbound Issue:
only forwarding because
Your forwarding to your own dns? What does it do then to resolve public dns. Forwarding to your own internal resolvers is different ball game than forwarding to some outside dns ;)
-
@johnpoz said in 23.01 Upgrade unbound Issue:
@bingo600 said in 23.01 Upgrade unbound Issue:
only forwarding because
Your forwarding to your own dns? What does it do then to resolve public dns.
My bind9's knows all my DNS names & Dynamic (DHCP) DNS names , and will resolve public names if asked to do so.
That made the decision on setting pfSense to query those , super easy ....
On (almost) all of my lan's/vlan's - I only allow DNS (UDP/TCP 53) to the def-gw ip (pfSense), all other DNS servers are blocked.
So client's can only ask pfSense , that asks my linux'es , they resolve local names , and ask A-Root for the rest ...
My Phone Vlan + MMedia Vlan (ATV etc) , asks a Pi-Hole directly , that asks my linux'es.
It cleans out a lot of "noise" on phones , and blocks a lot of ATV "callbacks" , and gives me the possibility to block stuff manually.But you use Pi-Hole so .. You know that :-)
I (hate DOH) .... Have floating rules on most IF's that "try to block" DOH .... , using internet based lists, that pfS downloads once a day.
Forwarding to your own internal resolvers is way different than forwarding to some outside dns ;)
I know , and might be why i'm not hit , and haven't removed DNSSEC
/Bingo -
@johnpoz said in 23.01 Upgrade unbound Issue:
specific query that fails when forwarding using dnssec and forwarding
Not sure if it was this thread or another (and was in the redmine) but I posted "nslookup linkedin.com" failed for me, repeatedly. I restarted unbound while testing, to no avail. Unchecking the DNSSEC option (which I believe restarts unbound unfortunately, for A/B testing) let it work immediately. I was unable to replicate it later, but I did not leave it with DNSSEC enabled for several hours as it was originally. So it may be time based, or Microsoft may have changed something, or something else triggers it.
re: why forward, Quad9 and others add malware protection. No it's not necessary but is a value to some.
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 said in 23.01 Upgrade unbound Issue:
Quad9 and others add malware protection
That for sure could be a valid reason - but most browsers do that on their own to be honest.
https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware-protection-work
Not saying better or worse than what a bad site filtering might do - but that feature is not worth me sending all my dns traffic to them. Other might find it worth while sure..
-
@steveits said in 23.01 Upgrade unbound Issue:
linkedin.com
They are not even using dnssec.. But I see this error checking their dns
linkedin.com/TXT: No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (2600:2000:2210::43, 2600:2000:2220::43, 2600:2000:2230::43, 2600:2000:2240::43, UDP_-_EDNS0_4096_D_KN)
-
I have experienced in my setup , that "Unbound" caches a "non resolved answer too".
If i have forgotten to add ie. a new host to my zone , and i try to resolve it on a client. I get a "not found" as i should
But when i then add the host to bind9 , and retry the "lookup" , then i still get a "not found" from unbound.
If i try to resolve the name on the bind9 linux machine, it resolves fine.
Cure is to restart unbound , then it begins to work.I know the "zones" specifies the TTL , but does it have to "cache a bad answer too" ...
I might have to dig into my "Cricket book" .....
Prob. to find out that TTL also applies to "non resolvables too, for that zone".Well just don't GOOF in the first place ...
/Bingo
If you find my answer useful - Please give the post a 👍 - "thumbs up"
pfSense+ 23.05.1 (ZFS)QOTOM-Q355G4 Quad Lan.
CPU : Core i5 5250U, Ram : 8GB Kingston DDR3LV 1600
LAN : 4 x Intel 211, Disk : 240G SAMSUNG MZ7L3240HCHQ SSD
