Hostname resolves on PC but not in pfSense
-
@McMurphy
Maybe the firewall is in a different domain?
Try to append the domain. -
Tried that...
-
@McMurphy
Try to add the device in the DHCP Static Mappings under the DHCP server -
It's on a different subnet at the other end of the VPN
-
@McMurphy
So what do you get if you try to query the host name on the command prompt:dig @192.168.1.11 server2.<domain> -
@McMurphy if you want unbound to forward to some dns, this 192.168.1.11 IP down some vpn tunnel or not you would have to disable rebind protection for that domain. Unless it was going to return public IPs?
The directed query test suggested by @viragomann is a good test to validate you can talk to this 1.11 IP and it answers your query how you expect. This would be step 1.. If you then want unbound to do it, you would have setup a domain override for this domain to go ask that 1.11 for anything in that domain, and would need to turn off rebind protection for this domain.
-
@viragomann said in Hostname resolves on PC but not in pfSense:
dig @192.168.1.11 server2.<domain>
Without the domain suffix:
With the domain suffix:
-
Excluded the domain from rebind protection and it worked:
https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html#dns-forwarderThank you.
-
@McMurphy said in Hostname resolves on PC but not in pfSense:
Without the domain suffix:
Not sure why anyone thinks just a host name should resolve? For dns to work it has to be a fqdn.
edit: this can work on clients, because of search suffix, ie you ping say host, and the client will auto add suffixes to what you are asking for.. A good way to see this in action is set debug on say nslookup
See how it comes back fully qualified
$ ping nas Pinging nas.home.arpa [192.168.9.10] with 32 bytes of data: Reply from 192.168.9.10: bytes=32 time<1ms TTL=64Notice the search suffix, and specific dns suffix for the interface. In my case home.arpa - these can be adjusted, you can have multiples of them, etc.
$ ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : i9-win Primary Dns Suffix . . . . . . . : home.arpa Node Type . . . . . . . . . . . . : Broadcast IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : home.arpa Ethernet adapter Local: Connection-specific DNS Suffix . : home.arpa Description . . . . . . . . . . . : Killer E2600 Gigabit Ethernet Controller Physical Address. . . . . . . . . : B0-4F-13-0B-FD-16 DHCP Enabled. . . . . . . . . . . : YesSee only asked for nas, but it actually asked for nas.home.arpa - which is fully qualified, and the dns has a record for that.
$ nslookup Default Server: sg4860.home.arpa Address: 192.168.9.253 > set debug > nas Server: sg4860.home.arpa Address: 192.168.9.253 ------------ Got answer: HEADER: opcode = QUERY, id = 2, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 1, authority records = 0, additional = 0 QUESTIONS: nas.home.arpa, type = A, class = IN ANSWERS: -> nas.home.arpa internet address = 192.168.9.10 ttl = 3600 (1 hour) ------------ ------------ Got answer: HEADER: opcode = QUERY, id = 3, rcode = NOERROR header flags: response, auth. answer, want recursion, recursion avail. questions = 1, answers = 0, authority records = 0, additional = 0 QUESTIONS: nas.home.arpa, type = AAAA, class = IN ------------ Name: nas.home.arpa Address: 192.168.9.10 >If i just ask for nas, which is not a fqdn - it doesn't know what I am asking for
$ dig nas ; <<>> DiG 9.16.49 <<>> nas ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10560 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;nas. IN A ;; AUTHORITY SECTION: . 484 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2024032802 1800 900 604800 86400 ;; Query time: 12 msec ;; SERVER: 192.168.9.253#53(192.168.9.253) ;; WHEN: Fri Mar 29 00:02:38 Central Daylight Time 2024 ;; MSG SIZE rcvd: 107Other ways those can resolve locally, is client will do a mdns query, or just a broadcast for it - and the device itself could answer..
-
I know we discussed this above however I have the same problem;
The hostname can be resolved on pfSense using dig
The hostname cannot be resolved on pfSense using nslookup:
I have disabled the rebind check for the domain in the resolver:
https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html
-
OK, looks like I have it fixed.
I reread your post above and added domain specific override to the resolver and it now works.
What is interesting to note is that if I removed the Resolver's disable rebind custom command it still works.
