pfSense Does Not Resolve domain/hostnames
-
Hello folks,
This is my first post. So, if I miss something please, be gentle!
Now, let me tell you my configuration ;
I have a modem which is used as bridge and behind the modem I have a server. My server is virtualized and it's first port gets the internet from modem and I set the pfsense's wan port to first port of the server and I configured secondary port of the server as lan. pfSense distrubutes the internet other vm's and AP.
I have installed HAProxy, Acme SSL. HaProxy handles with the request and sends the traffic the back-end web server, email server, etc. Recently,
I discovered my pfsense box can ping ips but does not resolv the host/domain names. All the VM's and Clients have no issue but pfsense. What could be the problem?
I have made some research and applied but not solution.
-
@cemsonmez said in pfSense Does Not Resolve domain/hostnames:
I have made some research ...
?
Normally, not needed, as you already know the solution.
I'll explain : out of the box, pfSense uses a resolver, so DNS just works without any setup from your side. There is nothing add, modify or what so ever. "Doing things with DNS can even be counter productive". Something you've probably proven correct.The fact that you use a 'barebone' or VM solution doesn't matter.
"Acme SSL" is a script that runs ones every night and has nothing to with DNS.
HAproxy ... I can't tell, never used it.
It probably is subjected to the golden rule : if set up incorrectly, it will break DNS (to begin with) ;)First things first : "pfSense Does Not Resolve domain/hostnames",
you mean pfSense can't resolve, for example :or do you mean : it doesn't have the DNS names of the LAN devices ?
You can solve that using : ISC (and not the KEA DHCP server) and then start adding your devices one by one :That is : add the devices that you want to know 'by host name', most probably the ones that host servcies like printers, NAS, etc etc - not your doorbell etc.
-
@Gertjan thank you for your quick and explanatory response.
Yes, I mean pfsense can't resolve as the example you provided. It does not resolve google.com but can ping to the ip address if I directly write the ip address instead of domain name. That's my issue.
-
-
@Gertjan Unfortunately, it didn't work.
In addition, I have no option as pfb_unbound in "Python Module Script".
-
@cemsonmez said in pfSense Does Not Resolve domain/hostnames:
In addition, I have no option as pfb_unbound in "Python Module Script".
Your not using the pfSense package "pfBlocker". That's fine.
@cemsonmez said in pfSense Does Not Resolve domain/hostnames:
Unfortunately, it didn't work.
test on the command line of pfSEnse itself, console, or better : SSH :
unbound listens to what interfaces ? :
[24.03-RELEASE][root@pfSense.bhf.tld]/root: sockstat -4 | grep 'unbound' unbound unbound 56202 5 udp4 *:53 *:* unbound unbound 56202 6 tcp4 *:53 *:* unbound unbound 56202 9 udp4 *:853 *:* unbound unbound 56202 10 tcp4 *:853 *:* unbound unbound 56202 11 tcp4 127.0.0.1:953 *:*
so it slistening on all interfaces.
Test on local and every local 'LAN' interface :[24.03-RELEASE][root@pfSense.bhf.tld]/root: dig @127.0.0.1 www.google.com +short 142.250.75.228 [24.03-RELEASE][root@pfSense.bhf.tld]/root: dig @192.168.1.1 www.google.com +short 142.250.75.228
-
@cemsonmez in System/General what are your DNS settings?
-
@cemsonmez so on pfsense do a dig +trace to say www.google.com what do you get?
[24.03-RELEASE][admin@sg4860.home.arpa]/root: dig www.google.com +trace ; <<>> DiG 9.18.20 <<>> www.google.com +trace ;; global options: +cmd . 82804 IN NS h.root-servers.net. . 82804 IN NS l.root-servers.net. . 82804 IN NS c.root-servers.net. . 82804 IN NS b.root-servers.net. . 82804 IN NS d.root-servers.net. . 82804 IN NS m.root-servers.net. . 82804 IN NS e.root-servers.net. . 82804 IN NS f.root-servers.net. . 82804 IN NS i.root-servers.net. . 82804 IN NS k.root-servers.net. . 82804 IN NS j.root-servers.net. . 82804 IN NS g.root-servers.net. . 82804 IN NS a.root-servers.net. . 82804 IN RRSIG NS 8 0 518400 20240829170000 20240816160000 20038 . s/TZ5D4Lqo4G6rG0DwW1czp002OZSPiSsawdrLeQGGT0zRzr6KQat6rP zBWbL2lb3mDzKqj1W2mkTZX4UqhWBU9h7EnouOK50MkhI+Tjz4HEtzsP SLXeUIPVFvt8+srI0eJFkBHl+9g7RoTL3+RePRkQpd0uEsNBub1rE67s afgg9IKWuHCIlUPGD4TubQ015rN9Dkxi/y9PquEctYGZGsFW3yAzVwBU khgAbHs2OqeEbRLmiQTr9G6APbjSYK8ViL1XtLMQbY4ZGBJv1oMZZliB MtUBAkasvzsKNTa44QsLWt8/dQ6Sr4HgRU3WLgIXvPRi4Fb/DeXSyAXn t9uQ+w== ;; Received 733 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A com. 86400 IN RRSIG DS 8 1 86400 20240830050000 20240817040000 20038 . mf8sM0yyc5mu38cJQiOQgnwJKyEnsAml15u1Wunjm/V6pl5S+M9RGEnK cItw2CEjfUDDO4Bt7z0c5miB+1wOwdRG1tG5Kh1XhFXw1RHxKjKJF5t7 a7JZiaz8ANApVs9w9dLsf+mSIM/FYBIynXFkjqZzZDto2ypJMH6vf/AV AjVH4hW6n6bk51mPOr71e9iNkRqse3qn5HDOzmSMn2nvt6+83vuz9a0m XeCcAwDHAvnCqwI4xdexkqK0DI1tIVWIOh3avrbVdWvNv68zi3C4xndG 9NkVcAnbHXM87Yi1HoWV61MAt+K348zHaz4khuZh+iNgK3I+BZ/Y2NaO nZRKWg== ;; Received 1174 bytes from 199.7.83.42#53(l.root-servers.net) in 25 ms google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 13 2 86400 20240824002459 20240816231459 59354 com. nmampY6bO/ry/wbsFPe2jlPdCElphx7zIvduxBQ99MImR1ZCsMmoV8AH /sLaYiUpkqEplnswldjkk/7FhTqTpA== S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 86400 IN NSEC3 1 1 0 - S84BR9CIB2A20L3ETR1M2415ENPP99L8 NS DS RRSIG S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 86400 IN RRSIG NSEC3 13 2 86400 20240821015013 20240814004013 59354 com. z2znCIL267RmO7zQJCvBl6Y8lsxTNgYfb+RIJcsyd0koXkI8ILG1GD78 Vj7GacssgbYJZCOG7yZVmnOZ278biw== ;; Received 648 bytes from 192.41.162.30#53(l.gtld-servers.net) in 8 ms www.google.com. 300 IN A 172.217.2.36 ;; Received 59 bytes from 216.239.32.10#53(ns1.google.com) in 26 ms [24.03-RELEASE][admin@sg4860.home.arpa]/root:
-
@Gertjan I don't know how but the issue is solved.
The reports that you requested as below ;
[2.7.2-RELEASE][root@pfSense.yatgak.com]/root: sockstat -4 | grep 'unbound' unbound unbound 57702 5 udp4 *:53 *:* unbound unbound 57702 6 tcp4 *:53 *:* unbound unbound 57702 10 udp4 *:853 *:* unbound unbound 57702 11 tcp4 *:853 *:* unbound unbound 57702 13 tcp4 127.0.0.1:953 *:* unbound unbound 57702 24 tcp4 185.118.176.73:13208 8.8.8.8:853 unbound unbound 57702 25 tcp4 185.118.176.73:34300 8.8.4.4:853
[2.7.2-RELEASE][root@pfSense.yatgak.com]/root: dig @127.0.0.1 www.google.com +short 216.58.212.100
[2.7.2-RELEASE][root@pfSense.yatgak.com]/root: dig @10.0.0.1 www.google.com +short 216.58.212.100
-
@SteveITS 8.8.8.8 and 8.8.4.4
-
@johnpoz I get following;
[2.7.2-RELEASE][root@pfSense.yatgak.com]/root: dig www.google.com +trace ; <<>> DiG 9.18.19 <<>> www.google.com +trace ;; global options: +cmd . 86395 IN NS h.root-servers.net. . 86395 IN NS g.root-servers.net. . 86395 IN NS k.root-servers.net. . 86395 IN NS l.root-servers.net. . 86395 IN NS m.root-servers.net. . 86395 IN NS b.root-servers.net. . 86395 IN NS e.root-servers.net. . 86395 IN NS j.root-servers.net. . 86395 IN NS f.root-servers.net. . 86395 IN NS c.root-servers.net. . 86395 IN NS a.root-servers.net. . 86395 IN NS i.root-servers.net. . 86395 IN NS d.root-servers.net. . 86395 IN RRSIG NS 8 0 518400 20240830050000 20240817040000 20038 . dBd6Gb/yyysp6/r6RF8XZSF9V4XgkHi4W3Mq5Ilp5sxINZwq2CTKMnvD cvpJ2gxp5FU6ZynVHidtWiTQrixMH0ZXWU30ccVEbbjedGwpsd8/zzP3 LOXdi4fORDg6ZqI134RjJZPoAGpIPItL0MuRLUHpjSGfPdI1Td1e5QKj IK2pdz1XK1ipaYKY/a7W9/W/qdB3wRiSnnPKQlkq3JyEzAsSka2fHrNm XwsA65uwqfils1aeOKyeIjk+yuVkztwyW++GoETU2HRu+F6qeAc95jrZ AfNBtTsFjDJth1B7UdMtnquqsVi3n/ZlAY6UR58uCy1NKmog3EXTKMWd 4i8fgg== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms ;; UDP setup with 2001:500:1::53#53(2001:500:1::53) for www.google.com failed: host unreachable. ;; UDP setup with 2001:500:1::53#53(2001:500:1::53) for www.google.com failed: host unreachable. ;; UDP setup with 2001:500:1::53#53(2001:500:1::53) for www.google.com failed: host unreachable. ;; UDP setup with 2001:7fd::1#53(2001:7fd::1) for www.google.com failed: host unreachable. ;; UDP setup with 2801:1b8:10::b#53(2801:1b8:10::b) for www.google.com failed: host unreachable. www.google.com. 182 IN A 216.58.212.100 ;; Received 59 bytes from 192.36.148.17#53(i.root-servers.net) in 73 ms
Sorry for flooding...
-
@cemsonmez did you paste that wrong?
Because the root servers
;; Received 59 bytes from 192.36.148.17#53(i.root-servers.net) in 73 ms
is not going to give the IP of www.google.com
www.google.com. 182 IN A 216.58.212.100
Not possible.. If you didn't somehow mess up that paste then your dns is being intercepted.. The root server will not give you anything other than the NS of the tld you asked for..
Here is how the root servers would answer that question
$ dig @192.36.148.17 www.google.com ; <<>> DiG 9.16.50 <<>> @192.36.148.17 www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60623 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: d037c0c4ec13377c0100000066c0f81d613eb2445a183139 (good) ;; QUESTION SECTION: ;www.google.com. IN A ;; AUTHORITY SECTION: com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. ;; ADDITIONAL SECTION: m.gtld-servers.net. 172800 IN A 192.55.83.30 l.gtld-servers.net. 172800 IN A 192.41.162.30 k.gtld-servers.net. 172800 IN A 192.52.178.30 j.gtld-servers.net. 172800 IN A 192.48.79.30 i.gtld-servers.net. 172800 IN A 192.43.172.30 h.gtld-servers.net. 172800 IN A 192.54.112.30 g.gtld-servers.net. 172800 IN A 192.42.93.30 f.gtld-servers.net. 172800 IN A 192.35.51.30 e.gtld-servers.net. 172800 IN A 192.12.94.30 d.gtld-servers.net. 172800 IN A 192.31.80.30 c.gtld-servers.net. 172800 IN A 192.26.92.30 b.gtld-servers.net. 172800 IN A 192.33.14.30 a.gtld-servers.net. 172800 IN A 192.5.6.30 m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30 l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30 k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30 j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30 i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30 h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30 g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30 f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30 e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30 d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30 c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30 b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30 a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30 ;; Query time: 110 msec ;; SERVER: 192.36.148.17#53(192.36.148.17) ;; WHEN: Sat Aug 17 14:21:01 Central Daylight Time 2024 ;; MSG SIZE rcvd: 870
They tell you the NS for .com and give you their IPs.. They would not ever answer with the IP of some fqdn like what you posted.
quick test.. do a query directly to say 1.2.3.4 - which is never going to answer a dns query, because it doesn't do dns.. If you get a response its a smoking gun that your dns has been intercepted
[24.03-RELEASE][admin@sg4860.home.arpa]/root: dig @1.2.3.4 www.google.com ;; communications error to 1.2.3.4#53: timed out ;; communications error to 1.2.3.4#53: timed out ;; communications error to 1.2.3.4#53: timed out ; <<>> DiG 9.18.20 <<>> @1.2.3.4 www.google.com ; (1 server found) ;; global options: +cmd ;; no servers could be reached [24.03-RELEASE][admin@sg4860.home.arpa]/root:
There have been some past threads about nordvpn doing this - are you using a vpn service?
And resolving while being intercepted is going to fail most of the time, especially if doing dnssec - it should really always fail. for any domain that is using dnssec.
-
@johnpoz thank you for digging it. I have checked with 1.2.3.4 and it gives result too. I provide it below;
[2.7.2-RELEASE][root@pfSense.yatgak.com]/root: dig @1.2.3.4 www.google.com ; <<>> DiG 9.18.19 <<>> @1.2.3.4 www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38279 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 295 IN A 216.58.212.100 ;; Query time: 72 msec ;; SERVER: 1.2.3.4#53(1.2.3.4) (UDP) ;; WHEN: Sat Aug 17 22:32:36 +03 2024 ;; MSG SIZE rcvd: 59
I recently installed opera and enabled VPN on it. In addition my cell phone has also VPN service enabled in a browser.
As a result, my dns has been intercepted as you told. What should I do now?
And big Thank You!
-
@cemsonmez vpn on opera and on some cell phone wouldn't have pfsense dns intercepted..
If your not running pfsense connection through a vpn, then something upstream of psfense is doing it - is pfsense behind a router? Or your isp is doing it.
-
@johnpoz I have installed pfSense on a VM. The internet directly coming into wan port of pfsense. I have reinstalled pfsense. It still gives some ip for google.com at 1.2.3.4. Why could this be happen?
[2.7.2-RELEASE][root@pfSense.yatgak.com]/root: dig @1.2.3.4 www.google.com ; <<>> DiG 9.18.19 <<>> @1.2.3.4 www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24302 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 205 IN A 216.58.212.100 ;; Query time: 68 msec ;; SERVER: 1.2.3.4#53(1.2.3.4) (UDP) ;; WHEN: Tue Aug 20 12:00:15 +03 2024 ;; MSG SIZE rcvd: 59
-
@cemsonmez said in pfSense Does Not Resolve domain/hostnames:
dig @1.2.3.4 www.google.com
[24.03-RELEASE][root@pfSense.bhf.tldroot: dig @1.2.3.4 www.google.com ;; communications error to 1.2.3.4#53: timed out ;; communications error to 1.2.3.4#53: timed out ;; communications error to 1.2.3.4#53: timed out ; <<>> DiG 9.18.20 <<>> @1.2.3.4 www.google.com ; (1 server found) ;; global options: +cmd ;; no servers could be reached
For me, 1.2.3.4 doesn't answer, most probably because it doesn't exist.
But you can make a.b.c.d like 1.2.3.4 answer DNS requests. And if it is not you, your ISP or VPN (saw some nice examples recently, as some of them also intercept DNS now).
Wasn't it @johnpoz who showed why 1.2.3.4 answers to DNS recently ?
It could be explain by a simple NAT LAN firewall rule that redirect any DNS traffic (UDP, destination port 53) to localhost or LAN IP where unbound is listening ...
Or your ISP(VPN) is intercepting as your DNS traffic as it is worth $$ -
Yeah I have gone over multiple ways to spot interception a few times. There are quite a few ways to do it.. But doing a query to an IP that doesn't actually answer dns and getting an answer is pretty easy to see your being intercepted.
He is doing the query on pfsense itself - that would be kind of hard for pfsense itself to be doing the interception ;)
So this vm gets a public IP on its wan, not some rfc1918 address? What device does this host your vm is running on plug into to get internet?
If your not doing the interception yourself, and you don't have pfsense routing out a vpn - that would point to your isp doing it. But yeah its pretty difficult to have resolving work if your being intercepted.
-
@johnpoz You are right, pfsense box gets the public IP. I get internet directly from my pfsense box (wan) and share the internet over lan of pfsense.
I don't do any interception at least by doing it on purpose.
Reinstalling pfsense box fixed the issue about resolving domain/hostnames.
Thank you... @Gertjan @johnpoz @SteveITS for your help. I wish, you all get help in the world that you live in more than you did!