Local DNS Issue: DNS_PROBE_FINISHED_NXDOMAIN
-
Hi -
TLDR: DNS Names will not resolve for my locally hosted infrastructure (physical and virtual).
I've been battling the DNS gods and boy, they are angry at me. I had an issue where I could not resolve hostnames on some VLANs that I have and while trying to fix it I somehow broke my ability to resolve local hosts. I can reach all of the hosts their with IP without issue (ping, SSH, GUI, etc) and when I'm on a host that I cannot reach via hostname I can query websites by name without issue (ie dig google.com).
I use my pfsense as my firewall, DNS server, and DHCP (resolver) server. One each VLAN I have port 53 open to the firewall itself. I've removed services I thought could be interfering (Tailscale & pfblockerng) but this did not resolve the issue. I've tried flushing my my DNS on the client I'm using and rebooting the entire system but no luck. I'm out of ideas and upgrading to the Pfsense 4100 now that my 3100 is EOL is starting to look like a good rebuild opportunity but I'd like to avoid this.
Setup:
Firewall - Netgate Pfsense 3100 (now EOL but will upgrade to the 4100 in the future)
Switch: Ubiquiti - Lite 8 PoE
AP: Ubiquiti - U6+DNS Resolver Settings:
DHCP Settings:
the DHCP server is enabled for each interface. Each interface has the same settings (blank field using the default value for that interface) you see here.
Where should I begin trying to fix this?
Thanks,
Vinny
-
@vinny147 said in Local DNS Issue: DNS_PROBE_FINISHED_NXDOMAIN:
Where should I begin trying to fix this?
Fixing what? If unbound has no entries for a host, how would it resolve?
Kea is unable to register dhcp as of yet. Did you have those from before, did you have statics set? Which you registered - those should be carried over.
If you have some fqdn boxA.home.arpa that you want to resolve - set a reservation so its always say 192.168.1.42, and then create a host override to resovle boxa.home.arpa to 192.168.1.42
edit:
Also - with browsers, common issue is the browser is using doh and not your local dns, so no they would never be able to resolve your local resources.From your pc or whatever device your using do a dns query via your fav tool, dig, host, nslookup, doggo, kdig, dnslookup, etc.
C:\tools\doggo>doggo.exe nas.home.arpa NAME TYPE CLASS TTL ADDRESS NAMESERVER nas.home.arpa. A IN 3449s 192.168.9.10 192.168.3.10:53C:\tools\dnslookup>dnslookup.exe nas.home.arpa dnslookup v1.10.0 Server: 192.168.3.10 dnslookup result (elapsed 3.2899ms): ;; opcode: QUERY, status: NOERROR, id: 25634 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;nas.home.arpa. IN A ;; ANSWER SECTION: nas.home.arpa. 3518 IN A 192.168.9.10user@i9-win:~$ kdig nas.local.lan ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 26301 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION: ;; nas.local.lan. IN A ;; ANSWER SECTION: nas.local.lan. 3585 IN A 192.168.9.10 ;; Received 47 B ;; Time 2023-11-29 13:46:45 CST ;; From 192.168.3.10@53(UDP) in 3.5 ms user@i9-win:~$C:\>nslookup nas.home.arpa Server: pi.hole Address: 192.168.3.10 Non-authoritative answer: Name: nas.home.arpa Address: 192.168.9.10192.168.3.10 is my pihole, but it forwards to unbound on pfsense.
I can directly query it.. as well
C:\tools\doggo>doggo.exe nas.home.arpa @192.168.9.253 NAME TYPE CLASS TTL ADDRESS NAMESERVER nas.home.arpa. A IN 3600s 192.168.9.10 192.168.9.253:53 -
@johnpoz Thanks for the advice, I've added host a host override for each host and it now resolves.
What I don't understand is I did have static IPs in place for a number of my hosts and did not have a host override but it could resolve. It then stopped working. Is this related to migrating to Kea during my most recently system upgrade? My guess is the route was in a cache and it was referencing that so it worked but once it was cleared it stopped working.
I'm still learn the ins and outs so bear with me :)
-
@vinny147 yeah kea is missing some features currently, I believe static reservations should of carried over.. But don't think you can actually setup new ones in it, etc. I have only flipped over to it a few times and for short periods to validate it hands out IPs, etc.
They might of been a bit more clear on exactly what features are not ready yet, maybe they were a bit eager to get people to move over. But it will hand out IPs from your pool, etc. So in that sense it is a viable dhcpd..
But users are known for not reading release notes anyway ;) heheh
If you can do reservations, and setup a host override that is good solution.. And not all too bad if you only have say a hand full of devices. now if you had hundreds that could be a real pita.
But there is nothing keeping you from continuing to use isc dhcp. I currently still using it because I use some of the options that are not quite ready yet. I just turned off the warning about isc being deprecated..
-
@vinny147 reading release notes? huh? ;)
This helps a lot, thank you.
Are you aware of any ways folks have scripted the ability to create host overrides from triggers outside of pfsense? Was doing some googling and didn't see anything.
-
@vinny147 said in Local DNS Issue: DNS_PROBE_FINISHED_NXDOMAIN:
reading release notes? huh? ;)
Exactly
https://docs.netgate.com/pfsense/en/latest/releases/23-09.html#rn-23-09-kea
