DNS resolution issues after 26.03 update
-
Hi there,
I've come across a problem after updating to the latest release, which I will try to describe to my best:
I have a VPN connection (IPSec Site-to-Site) always up that allows me to connect to work. The work domain is let's say org.domain.com
On my work machine, which has a static DHCP handed by pfSense's DHCP server, I have the org.domain.com domain on the domain search list.
On the DNS resolver, under "domain overrides", I have org.domain.com - ip of dns server 1; org.domain.com - ip of dns server 2; org.domain.com - ip of dns server 3Also on the DNS resolver custom options I have
server:
private-domain: org.domain.comAnd this always worked. Whenever I tried to access any host.org.domain.com from my machine, it resolved immediately.
Since the update this simply stopped working. Still using ISC DHCP since Kea didn't resolve local hosts either, not sure if that's been sorted?
But regarding the private domain resolution, any ideas on why it stopped working? thank you. -
In fairness, the 26.03 update changed how Unbound handles private domains and domain overrides in a few ways worth checking. First, having private-domain: org.domain.com in custom options AND domain overrides for the same domain can cause a conflict in newer Unbound. The custom options block is now injected at a different point in the generated config, which can result in duplicate or conflicting directives. Try removing the private-domain line from custom options temporarily to see if that restores resolution.
Second, check what's actually in your Unbound config by running this from Diagnostics > Command Prompt:
grep -B2 -A10 "org.domain" /var/unbound/unbound.conf
If the domain override entries are there but resolution is still failing, the issue is likely the outbound interface, go to Services > DNS Resolver > Outgoing Network Interfaces and confirm your IPSec interface is still listed. The 26.03 update sometimes resets this to "All" which can cause the resolver to pick the wrong path for domain-overridden queries.
Third thing to try: switch from domain overrides to a proper forward zone. Under Services > DNS Resolver, there's a Forward Zones section where you can add org.domain.com with your three DNS server IPs. This uses Unbound's native forward-zone directive which is cleaner than the older domain_override mechanism and tends to survive updates better.
Regarding Kea DHCP, yes, local host registration issues with Kea and Unbound have been partially addressed in recent builds, but ISC DHCP is still the safer choice for now if your local hostname resolution matters.
What does the grep output show? That'll confirm whether the config is generating correctly or the issue is somewhere further down, grand so.
-
@RianKellyIT said in DNS resolution issues after 26.03 update:
Second, check what's actually in your Unbound config by running this from Diagnostics > Command Prompt:
grep -B2 -A10 "org.domain" /var/unbound/unbound.conf
.....
AI generated or what ?
For example : there are no domain or host names listed in pfSense's /var/unbound/unbound.conf@maverickws said in DNS resolution issues after 26.03 update:
...not sure if that's been sorted?
Yeah, and that's the good and the bad news.
Kea works just fine. So, if it doesn't work for you, what about : making it work.
A very good start would be : keep settings at a default (Netgate's choice) settings.
There might be special case situations where ISC works because of a legacy situation that kea can't support (as RFC ruled it out) but that's, imho, a rare situation.@RianKellyIT said in DNS resolution issues after 26.03 update:
In fairness, the 26.03 update changed how Unbound handles private domains and domain overrides in a few ways worth checking.
... nothing mentions that in the 26.03 Release notes.
What do you mean ?
@RianKellyIT said in DNS resolution issues after 26.03 update:
The custom options block is now injected at a different point in the generated config, which can result in duplicate or conflicting directives.
Fact checked :
where my own custom additions are :
which means that info/settings in "/var/unbound/remotecontrol.conf" will override whatever is set above.
If you wanted to override "remotecontrol" settings, which is, imho, never done.So, maybe
The custom options block is now injected at a different point in the generated config, which can result in duplicate or conflicting directives.
is true.
But I can't see how this related to the subject.@RianKellyIT said in DNS resolution issues after 26.03 update:
The 26.03 update sometimes resets this to "All" which can cause the resolver to pick the wrong path for domain-overridden queries.
Ah, 26.03 has some 'random' behavior now ? AI driven ?
If "All" is selected, which is the default 'Netgate / pfSense" setting, then unbound, the resolver will listen to the IPsec interface. Which it should do - right ?!@RianKellyIT said in DNS resolution issues after 26.03 update:
but ISC DHCP is still the safer choice for now if your local hostname resolution matters.
The author, the ones who wrote ISC DHCP, don't share your opinion.
ISC DHCP is very officially EOL.
Qualify software that isn't maintained since 2022 doesn't make it none-safe, true.
But doesn't make it imho, the best choice.
I use kea since it was included in pfSense and local host name resolution works fine since day one.Ok, I stop here, promised.
Have look at this pfSense file : /etc/hosts
These are the 'local' devices that unbound knows about. It knows them, as you have (the admin) have informed unbound about them, by means of DHCP dynamic or static leases, host name overrides, etc.
Do you find all the host names of your local 'LAN' devices ?This command :
[26.03-RELEASE][root@pfSense.bhf.tld]/root: sockstat -4 | grep ':53' unbound unbound 38537 5 udp4 *:53 *:* unbound unbound 38537 6 tcp4 *:53 *:*tells you on which interfaces unbound listens for DNS requests.
My example : all interfaces = "All".Check your IPsec interface : do you allow incoming DNS TCP and UDP port 53 traffic ?
For example, my OpenVPN server interface on pfSense uses 1982.168.3.1.
I use this interface, and ask for a DNSrequest :[26.03-RELEASE][root@pfSense.bhf.tld]/root: dig @192.168.3.1 google.com +short 142.251.208.238The next test should be done on the remote side : use for example nslookup, specify the IPSec tunnel IP, and launch a SNS request. You should get an asnwer.
Next step : on the remote side : what are really the DNS IP ('servers') that are used ?
It's common so see that browser have their own DNS override in place, and use something else, so your pfSense Resolver (unbound) is never sued, so it can never answer about local (pfSense LAN) hosts. -
hey guys thank you for all your answers. If you want to know the weirdest thing, this morning everything was just working. I have no idea what was it that prevented from working, but ... it is working perfectly now.
@Gertjan
I listen for DNS requests on the local interfaces and have the WAN interfaces for outbound upstream.Regarding the Kea local DNS registration working from day one ... I switched to Kea on day one, that was not the case, I switched back to ISC's. There were also plenty comments about that here on the forums, but no point in dwelling on the past, if it is working now I will test and swap back to Kea one of these days.
EDIT: After replying I did the quickest search and ...
This was the aforementioned issue I hope is sorted now.
Regarding the original "issue" ... again, seems like no issue. Have no idea what happened. Tunnel was up I could contact the DNS servers and resolved fine using dig, locally I was getting NXDOMAIN .. but whatever, it is working.
-
You've sited a post from 2023 ... that's a multiple live spans for a product as pfSense.
Kea-into-pfSense-GUI implementation is now done for .. dono .. 98+ % ?! ^^
Maybe the "Kea-DDNS integration" is missing ...@maverickws said in DNS resolution issues after 26.03 update:
This was the aforementioned issue I hope is sorted now.
That's a
-
@Gertjan hehe well I know from 2023 to today is a lifetime but wasn't quite all working since day one :P all good m8! cheers
-
@RianKellyIT said in DNS resolution issues after 26.03 update:
Under Services > DNS Resolver, there's a Forward Zones section
?? The only 7 instances of "forward" on the page are under "DNS Query Forwarding"...
