Single website won't resolve for clients - resolves fine for pfSense itself
-
@lparker my clients not having any problems
;; QUESTION SECTION: ;advantechwifi.com. IN A ;; ANSWER SECTION: advantechwifi.com. 10800 IN A 192.124.249.7so pfsense is just resolving? your not forwarding or anything.. Look in your unbound to who it would talk to resolve that?
So for example.. after I looked it up mine shows
[23.05-RELEASE][admin@sg4860.local.lan]/root: unbound-control -c /var/unbound/unbound.conf lookup advantechwifi.com The following name servers are used for lookup of advantechwifi.com. ;rrset 3476 2 0 7 0 advantechwifi.com. 3476 IN NS ns70.domaincontrol.com. advantechwifi.com. 3476 IN NS ns69.domaincontrol.com. ;rrset 86276 1 0 1 0 ns69.domaincontrol.com. 86276 IN A 97.74.104.45 ;rrset 86276 1 0 1 0 ns69.domaincontrol.com. 86276 IN AAAA 2603:5:2184::2d ;rrset 86276 1 0 1 0 ns70.domaincontrol.com. 86276 IN A 173.201.72.45 ;rrset 86276 1 0 1 0 ns70.domaincontrol.com. 86276 IN AAAA 2603:5:2284::2d Delegation with 2 names, of which 0 can be examined to query further addresses. It provides 4 IP addresses. 2603:5:2284::2d not in infra cache. 173.201.72.45 not in infra cache. 2603:5:2184::2d not in infra cache. 97.74.104.45 rto 293 msec, ttl 776, ping 1 var 73 rtt 293, tA 0, tAAAA 0, tother 0, EDNS 0 probed. [23.05-RELEASE][admin@sg4860.local.lan]/root: -
@johnpoz Thanks for the reply. Nope, no forwarding - just doing resolver and also have rules to force DNS requests to other servers to redirect to the pfSense itself. Here's the results I get:
/root: unbound-control -c /var/unbound/unbound.conf lookup advantechwifi.com The following name servers are used for lookup of advantechwifi.com. ;rrset 63832 13 1 5 0 com. 63832 IN NS l.gtld-servers.net. com. 63832 IN NS h.gtld-servers.net. com. 63832 IN NS f.gtld-servers.net. com. 63832 IN NS c.gtld-servers.net. com. 63832 IN NS e.gtld-servers.net. com. 63832 IN NS b.gtld-servers.net. com. 63832 IN NS i.gtld-servers.net. com. 63832 IN NS k.gtld-servers.net. com. 63832 IN NS m.gtld-servers.net. com. 63832 IN NS g.gtld-servers.net. com. 63832 IN NS d.gtld-servers.net. com. 63832 IN NS j.gtld-servers.net. com. 63832 IN NS a.gtld-servers.net. com. 63832 IN RRSIG NS 8 1 172800 20230615042524 20230608031524 46551 com. MNbi8BJDf/Kl/8plYBvpw tCh6ZcwT1ooih77DwHAf153EbK1hAxEhTIUpfTcYgvcluaKWCcctIkik7yIRelqoXORrryrG3EgGwoNuf2PsU1MG/NIILXprCWq1LKXARBS2 bobrBT/k8E2slwDlE9lFByZ1wnXwXVlZLENmvk7N9HkQ/Lgk6nUeDkmgOmuqwQHORd7g8wFaT5y4c1DLQk/2g== ;{id = 46551} ;rrset 59258 1 0 5 0 a.gtld-servers.net. 59258 IN A 192.5.6.30 ;rrset 19823 1 0 5 0 j.gtld-servers.net. 19823 IN A 192.48.79.30 ;rrset 9207 1 0 5 0 d.gtld-servers.net. 9207 IN A 192.31.80.30 ;rrset 23967 1 0 5 0 g.gtld-servers.net. 23967 IN A 192.42.93.30 ;rrset 22757 1 0 5 0 m.gtld-servers.net. 22757 IN A 192.55.83.30 ;rrset 64442 1 0 5 0 k.gtld-servers.net. 64442 IN A 192.52.178.30 ;rrset 68833 1 0 5 0 i.gtld-servers.net. 68833 IN A 192.43.172.30 ;rrset 27483 1 0 1 0 i.gtld-servers.net. 27483 IN AAAA 2001:503:39c1::30 ;rrset 11359 1 0 5 0 b.gtld-servers.net. 11359 IN A 192.33.14.30 ;rrset 21663 1 0 5 0 e.gtld-servers.net. 21663 IN A 192.12.94.30 ;rrset 65437 1 0 5 0 c.gtld-servers.net. 65437 IN A 192.26.92.30 ;rrset 30204 1 0 5 0 f.gtld-servers.net. 30204 IN A 192.35.51.30 ;rrset 37921 1 0 5 0 h.gtld-servers.net. 37921 IN A 192.54.112.30 ;rrset 47336 1 0 5 0 l.gtld-servers.net. 47336 IN A 192.41.162.30 Delegation with 13 names, of which 12 can be examined to query further addresses. It provides 14 IP addresses. 192.41.162.30 NoAuthButRecursive rto 240 msec, ttl 845, ping 56 var 46 rtt 240, tA 0, tAAAA 0, tot her 0, EDNS 0 probed. 192.54.112.30 NoAuthButRecursive rto 154 msec, ttl 845, ping 38 var 29 rtt 154, tA 0, tAAAA 0, tot her 0, EDNS 0 probed. 192.35.51.30 NoAuthButRecursive rto 54 msec, ttl 667, ping 38 var 4 rtt 54, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 192.26.92.30 NoAuthButRecursive rto 99 msec, ttl 741, ping 43 var 14 rtt 99, tA 0, tAAAA 0, tothe r 0, EDNS 0 probed. 192.12.94.30 NoAuthButRecursive rto 266 msec, ttl 882, ping 14 var 63 rtt 266, tA 0, tAAAA 0, tot her 0, EDNS 0 probed. 192.33.14.30 NoAuthButRecursive rto 106 msec, ttl 845, ping 34 var 18 rtt 106, tA 0, tAAAA 0, tot her 0, EDNS 0 probed. 2001:503:39c1::30 not in infra cache. 192.43.172.30 NoAuthButRecursive rto 220 msec, ttl 845, ping 24 var 49 rtt 220, tA 0, tAAAA 0, tot her 0, EDNS 0 probed. 192.52.178.30 NoAuthButRecursive rto 88 msec, ttl 845, ping 36 var 13 rtt 88, tA 0, tAAAA 0, tothe r 0, EDNS 0 probed. 192.55.83.30 NoAuthButRecursive rto 77 msec, ttl 845, ping 37 var 10 rtt 77, tA 0, tAAAA 0, tothe r 0, EDNS 0 probed. 192.42.93.30 NoAuthButRecursive rto 94 msec, ttl 845, ping 30 var 16 rtt 94, tA 0, tAAAA 0, tothe r 0, EDNS 0 probed. 192.31.80.30 NoAuthButRecursive rto 157 msec, ttl 845, ping 45 var 28 rtt 157, tA 0, tAAAA 0, tot her 0, EDNS 0 probed. 192.48.79.30 NoAuthButRecursive rto 185 msec, ttl 845, ping 57 var 32 rtt 185, tA 0, tAAAA 0, tot her 0, EDNS 0 probed. 192.5.6.30 NoAuthButRecursive rto 116 msec, ttl 845, ping 44 var 18 rtt 116, tA 0, tAAAA 0, tot her 0, EDNS 0 probed. -
@lparker well from that would seem you can not talk to the auth ns for that domain. Or haven't look in a long time for it, its only listing roots and the gltd servers..
So from pfsense if you do a trace - this would be a normal resolve path.. example
[23.05-RELEASE][admin@sg4860.local.lan]/root: dig advantechwifi.com +trace ; <<>> DiG 9.18.13 <<>> advantechwifi.com +trace ;; global options: +cmd . 65712 IN NS e.root-servers.net. . 65712 IN NS f.root-servers.net. . 65712 IN NS g.root-servers.net. . 65712 IN NS h.root-servers.net. . 65712 IN NS i.root-servers.net. . 65712 IN NS j.root-servers.net. . 65712 IN NS k.root-servers.net. . 65712 IN NS l.root-servers.net. . 65712 IN NS m.root-servers.net. . 65712 IN NS a.root-servers.net. . 65712 IN NS b.root-servers.net. . 65712 IN NS c.root-servers.net. . 65712 IN NS d.root-servers.net. . 65712 IN RRSIG NS 8 0 518400 20230622050000 20230609040000 60955 . XWAhVJyWxEZ3FhUBdiUyWs0G+xUNdbqfG/b+OiMs43cBQfxs+waRqAwV T5FSWBEraNrSJkEyFV3pnTgTE9xIVL+vwKVePLh9wTGsBaqHBqT2PeYk /kXi0Dog4YlGPx6wFqoSZMBDhtpwBernpFVcB6BbYVfxoPQpwTISRwEd lphtTnAlMvZ0Rcn322MTAbl6thD37Fxyy6xsXuvHXX4KslOGTCX+CTvV 1aZ8sQwo2hz//+uqv05n6cfMt7XGQ8ktRysLxptunhuGnuI0TCitqMN0 tuvAwfmKFhjPsSUuG4ps7153HwfYA4Sw1AqzIBy4v+U1Y8laP4T4VuLE AwX+ew== ;; Received 1097 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 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20230622050000 20230609040000 60955 . DHwyxGz3WHQd+E6QEijOKPKUPJrEUHnSGMhcr9HMImQ7U/mIsPP9sn7a LZs02sjKDa9nUtMjNsOCCEkF/VmlGPKa0AyPlIKr4hwtxqVslF2TSzI1 fzkCe4NOrDLn7J62XsMsNea4Lb4VjmXUejNjqe+o5/x18knpCKbB7TNz c361waQN8Y//Nnyut229ruvRfjKMCOyJa4e44Pg0/VrLLgWDs/efvH09 RwTJV/ssNx20lgeW9c6fe4yyH3fW91VQUHpVNg8j8FP/ULrsPOoMzjUB WGgKwu7i38sM+wiCUo7/VtK/8pUdVj1RZwJ/VhEglQPTKd4HHy4hcFWX SqxUOw== ;; Received 1177 bytes from 199.7.91.13#53(d.root-servers.net) in 12 ms advantechwifi.com. 172800 IN NS ns69.domaincontrol.com. advantechwifi.com. 172800 IN NS ns70.domaincontrol.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20230615042524 20230608031524 46551 com. opW1EZF0WaMz+df3vPSEQppiJ1Lj//YDFV/jDliPAJW+mSiYmFbJVQrq aNXtOgLzSD9VGKZ1ct/giCaP4pMt6RCCFaIKgpf7VwTCKtvOfV2IImZ5 y9iV8EQqx3oSFAD4BrchjjgsVzo+6k9pp1tyLdlbfO83DUibCyFuRNAc Tnsahwk274qiOF40DtdAXdxT1AMGusu4KTOOKoaW/hicxw== 7V5275CAU7VFPEDE07A3EKEVN199SM4G.com. 86400 IN NSEC3 1 1 0 - 7V52GSDL64931RDTID0MH4GADHIE5KFO NS DS RRSIG 7V5275CAU7VFPEDE07A3EKEVN199SM4G.com. 86400 IN RRSIG NSEC3 8 2 86400 20230614063850 20230607052850 46551 com. eIQbSkLiBDotVPgzUPS3LcLoydJH1f8UwBHZCiaMlmVOOQogY/KqhbIg 7oaCnD1gs/5iKh4kTn38ZqboYo1PBmB2+8FeOvYnKlkRotATeePAfQ8u fl6QW6CvRN7zej0HrwYYMwkiUDVPyX5GDk3uJYj3tSpmuN4XnZBPBBIJ AxWuC7KRrk2OAtOspPqLD7hVapz1F/hULpuF3TtasVvcXQ== ;; Received 735 bytes from 2001:502:1ca1::30#53(e.gtld-servers.net) in 32 ms advantechwifi.com. 10800 IN A 192.124.249.7 advantechwifi.com. 3600 IN NS ns70.domaincontrol.com. advantechwifi.com. 3600 IN NS ns69.domaincontrol.com. ;; Received 114 bytes from 97.74.104.45#53(ns69.domaincontrol.com) in 12 ms [23.05-RELEASE][admin@sg4860.local.lan]/root:if I had to guess why pfsense can look it up, is because you are falling back to what you get from dhcp or you have some other ns listed other than 127.0.0.1 in pfsense dns settings.
You can see from my trace - I got the auth ns for that domain from the gltd server
advantechwifi.com. 172800 IN NS ns69.domaincontrol.com. advantechwifi.com. 172800 IN NS ns70.domaincontrol.com. ;; Received 735 bytes from 2001:502:1ca1::30#53(e.gtld-servers.net) in 32 mssnipping out the dnssec stuff.
-
@johnpoz What are the chances this is broken because I'm blocking all IPv6 right now? lol
[23.05-RELEASE][admin@pfSense.ad.techzenit.com]/root: dig advantechwifi.com +trace ; <<>> DiG 9.18.13 <<>> advantechwifi.com +trace ;; global options: +cmd . 72262 IN NS l.root-servers.net. . 72262 IN NS i.root-servers.net. . 72262 IN NS a.root-servers.net. . 72262 IN NS d.root-servers.net. . 72262 IN NS c.root-servers.net. . 72262 IN NS b.root-servers.net. . 72262 IN NS j.root-servers.net. . 72262 IN NS k.root-servers.net. . 72262 IN NS g.root-servers.net. . 72262 IN NS m.root-servers.net. . 72262 IN NS f.root-servers.net. . 72262 IN NS e.root-servers.net. . 72262 IN NS h.root-servers.net. . 72262 IN RRSIG NS 8 0 518400 20230621210000 20230608200000 60955 . GS5d3Rro ajrrStR87RosuTPEMer2BFNGly0hqufyifG9WLE8EyqN8inf VNDuetHgilGiyqDBUXgUXWOhljV7WH7QuksvHWYDAOcEPX+slgLDY6qr WC 3Ljkb2GIfT0/fL+Q048z4SctzB6MoIgUc60EIMUR37NNzWV3J6j3wp AX22CJ3v8/Rdf2gMQtnCoxD+nmaZU3AMOVKht+kSvqWDOqckPUn/E psl 2sPdMqhJfEbvJ3R10htMZj38mlMa9QUa3/A7pTiszVhUSuhxrWivt7aK QktaUM0zmQ8IowKKTe7un4d6PDcVBlv4nhnvUExhg3OSC8M /sm/86wL6 jI9LiQ== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms **;; UDP setup with 2001:500:2d::d#53(2001:500:2d::d) for advantechwifi.com failed: host unreachable. ;; UDP setup with 2001:500:2d::d#53(2001:500:2d::d) for advantechwifi.com failed: host unreachable. ;; UDP setup with 2001:500:2d::d#53(2001:500:2d::d) for advantechwifi.com failed: host unreachable. ;; UDP setup with 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) for advantechwifi.com failed: host unreachable** . advantechwifi.com. 0 IN A 199.38.182.75 advantechwifi.com. 0 IN A 199.38.182.52 ;; Received 78 bytes from 199.9.14.201#53(b.root-servers.net) in 36 ms -
@lparker their NS are IPv4 - so blocking IPv6 would have zero to do with it..
Vs blocking - try turning off.. so pfsense has no ipv6.. here I turned off my ipv6 tunnel and can do a trace to it without any issues.
[23.05-RELEASE][admin@sg4860.local.lan]/root: dig advantechwifi.com +trace ; <<>> DiG 9.18.13 <<>> advantechwifi.com +trace ;; global options: +cmd . 62189 IN NS h.root-servers.net. . 62189 IN NS i.root-servers.net. . 62189 IN NS j.root-servers.net. . 62189 IN NS k.root-servers.net. . 62189 IN NS l.root-servers.net. . 62189 IN NS m.root-servers.net. . 62189 IN NS a.root-servers.net. . 62189 IN NS b.root-servers.net. . 62189 IN NS c.root-servers.net. . 62189 IN NS d.root-servers.net. . 62189 IN NS e.root-servers.net. . 62189 IN NS f.root-servers.net. . 62189 IN NS g.root-servers.net. . 62189 IN RRSIG NS 8 0 518400 20230622050000 20230609040000 60955 . XWAhVJyWxEZ3FhUBdiUyWs0G+xUNdbqfG/b+OiMs43cBQfxs+waRqAwV T5FSWBEraNrSJkEyFV3pnTgTE9xIVL+vwKVePLh9wTGsBaqHBqT2PeYk /kXi0Dog4YlGPx6wFqoSZMBDhtpwBernpFVcB6BbYVfxoPQpwTISRwEd lphtTnAlMvZ0Rcn322MTAbl6thD37Fxyy6xsXuvHXX4KslOGTCX+CTvV 1aZ8sQwo2hz//+uqv05n6cfMt7XGQ8ktRysLxptunhuGnuI0TCitqMN0 tuvAwfmKFhjPsSUuG4ps7153HwfYA4Sw1AqzIBy4v+U1Y8laP4T4VuLE AwX+ew== ;; Received 1097 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 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20230622050000 20230609040000 60955 . DHwyxGz3WHQd+E6QEijOKPKUPJrEUHnSGMhcr9HMImQ7U/mIsPP9sn7a LZs02sjKDa9nUtMjNsOCCEkF/VmlGPKa0AyPlIKr4hwtxqVslF2TSzI1 fzkCe4NOrDLn7J62XsMsNea4Lb4VjmXUejNjqe+o5/x18knpCKbB7TNz c361waQN8Y//Nnyut229ruvRfjKMCOyJa4e44Pg0/VrLLgWDs/efvH09 RwTJV/ssNx20lgeW9c6fe4yyH3fW91VQUHpVNg8j8FP/ULrsPOoMzjUB WGgKwu7i38sM+wiCUo7/VtK/8pUdVj1RZwJ/VhEglQPTKd4HHy4hcFWX SqxUOw== ;; Received 1177 bytes from 199.7.91.13#53(d.root-servers.net) in 11 ms ;; UDP setup with 2001:503:83eb::30#53(2001:503:83eb::30) for advantechwifi.com failed: host unreachable. ;; UDP setup with 2001:503:83eb::30#53(2001:503:83eb::30) for advantechwifi.com failed: host unreachable. ;; UDP setup with 2001:503:83eb::30#53(2001:503:83eb::30) for advantechwifi.com failed: host unreachable. ;; UDP setup with 2001:503:a83e::2:30#53(2001:503:a83e::2:30) for advantechwifi.com failed: host unreachable. advantechwifi.com. 172800 IN NS ns69.domaincontrol.com. advantechwifi.com. 172800 IN NS ns70.domaincontrol.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20230615042524 20230608031524 46551 com. opW1EZF0WaMz+df3vPSEQppiJ1Lj//YDFV/jDliPAJW+mSiYmFbJVQrq aNXtOgLzSD9VGKZ1ct/giCaP4pMt6RCCFaIKgpf7VwTCKtvOfV2IImZ5 y9iV8EQqx3oSFAD4BrchjjgsVzo+6k9pp1tyLdlbfO83DUibCyFuRNAc Tnsahwk274qiOF40DtdAXdxT1AMGusu4KTOOKoaW/hicxw== 7V5275CAU7VFPEDE07A3EKEVN199SM4G.com. 86400 IN NSEC3 1 1 0 - 7V52GSDL64931RDTID0MH4GADHIE5KFO NS DS RRSIG 7V5275CAU7VFPEDE07A3EKEVN199SM4G.com. 86400 IN RRSIG NSEC3 8 2 86400 20230614063850 20230607052850 46551 com. eIQbSkLiBDotVPgzUPS3LcLoydJH1f8UwBHZCiaMlmVOOQogY/KqhbIg 7oaCnD1gs/5iKh4kTn38ZqboYo1PBmB2+8FeOvYnKlkRotATeePAfQ8u fl6QW6CvRN7zej0HrwYYMwkiUDVPyX5GDk3uJYj3tSpmuN4XnZBPBBIJ AxWuC7KRrk2OAtOspPqLD7hVapz1F/hULpuF3TtasVvcXQ== ;; Received 735 bytes from 192.43.172.30#53(i.gtld-servers.net) in 49 ms advantechwifi.com. 10800 IN A 192.124.249.7 advantechwifi.com. 3600 IN NS ns70.domaincontrol.com. advantechwifi.com. 3600 IN NS ns69.domaincontrol.com. ;; Received 114 bytes from 97.74.104.45#53(ns69.domaincontrol.com) in 27 ms [23.05-RELEASE][admin@sg4860.local.lan]/root:I'm seeing the same thing with that udp failure with IPv6 address
As a temp work around you could prob setup a domain override for the advantechwifi.com NS.. Can you query them directly?
example
[23.05-RELEASE][admin@sg4860.local.lan]/root: dig @173.201.72.45 advantechwifi.com ; <<>> DiG 9.18.13 <<>> @173.201.72.45 advantechwifi.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54575 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;advantechwifi.com. IN A ;; ANSWER SECTION: advantechwifi.com. 10800 IN A 192.124.249.7 ;; AUTHORITY SECTION: advantechwifi.com. 3600 IN NS ns70.domaincontrol.com. advantechwifi.com. 3600 IN NS ns69.domaincontrol.com. ;; Query time: 9 msec ;; SERVER: 173.201.72.45#53(173.201.72.45) (UDP) ;; WHEN: Fri Jun 09 13:11:09 CDT 2023 ;; MSG SIZE rcvd: 114 [23.05-RELEASE][admin@sg4860.local.lan]/root: -
@johnpoz You're right, I just saw the UDP setup failure with those IPv6 addresses but re-enabling it didn't change anything. Any other thoughts on what I could try?
-
@lparker see my edit, can you directly query one of their NS and get an answer?
Their other ns is 97.74.104.45
-
@johnpoz I get the following when running dig queries from Ubuntu WSL virtual client behind my pfSense router:
XXXXX@XXXXX-DESKTOP:~$ dig @173.201.72.45 advantechwifi.com ; <<>> DiG 9.16.1-Ubuntu <<>> @173.201.72.45 advantechwifi.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31211 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;advantechwifi.com. IN A ;; ANSWER SECTION: advantechwifi.com. 0 IN A 199.38.182.75 advantechwifi.com. 0 IN A 199.38.182.52 ;; Query time: 40 msec ;; SERVER: 173.201.72.45#53(173.201.72.45) ;; WHEN: Mon Jun 12 10:08:18 EDT 2023 ;; MSG SIZE rcvd: 78 -
@lparker said in Single website won't resolve for clients - resolves fine for pfSense itself:
dig @173.201.72.45 advantechwifi.com
that doesn't seem right.. Why are you getting back a 0 ttl?
When you directly query an auth ns for a domain, you should always get the full ttl they have set on the record.
your not doing any redirection of dns are you?
edit: you should be seeing a aa flag in your response as well - since your directly talking to auth ns, that would seem like your dns is being intercepted.
see mine, just did another one
ser@i9-win:~$ dig @173.201.72.45 advantechwifi.com ; <<>> DiG 9.18.15-1+ubuntu22.04.1+isc+1-Ubuntu <<>> @173.201.72.45 advantechwifi.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15175 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;advantechwifi.com. IN A ;; ANSWER SECTION: advantechwifi.com. 10800 IN A 192.124.249.7 ;; AUTHORITY SECTION: advantechwifi.com. 3600 IN NS ns70.domaincontrol.com. advantechwifi.com. 3600 IN NS ns69.domaincontrol.com. ;; Query time: 20 msec ;; SERVER: 173.201.72.45#53(173.201.72.45) (UDP) ;; WHEN: Mon Jun 12 09:26:41 CDT 2023 ;; MSG SIZE rcvd: 114 user@i9-win:~$Notice the aa flag.. See when ask say google for that, you don't see the aa flag
user@i9-win:~$ dig @8.8.8.8 advantechwifi.com ; <<>> DiG 9.18.15-1+ubuntu22.04.1+isc+1-Ubuntu <<>> @8.8.8.8 advantechwifi.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12805 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;advantechwifi.com. IN A ;; ANSWER SECTION: advantechwifi.com. 10800 IN A 192.124.249.7 ;; Query time: 79 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) ;; WHEN: Mon Jun 12 09:30:05 CDT 2023 ;; MSG SIZE rcvd: 62 user@i9-win:~$And if you continue to check it - you notice that the ttl starts to drop depending on which google server answered you - you never know which one will answer you since anycast, etc. That mine shows the full ttl 10800, would tell me that it had to resolve it vs cache - but no aa in the flags, so tells me that came from a non authoritative ns, ie I asked google..
;; ANSWER SECTION: advantechwifi.com. 10518 IN A 192.124.249.7no aa flag, and that 0 ttl screams dns redirection to me.
-
@johnpoz Originally had DNS redirection of anything using UDP/TCP 53 back to 127.0.0.1 but that's been removed. DNS forwarding is disabled, only have on DNS Resolver. DHCP isn't declaring any special DNS servers and I can see on my clients that DHCP is handing out the default LAN address of the pfsense as the DNS server for clients.
In System > General > DNS Resolution Behavior - that is set to Use local DNS, fall back to remote DNS Servers (Default). I'm pretty new with pfSense (as you probably guessed) but it sounds like the pfSense can resort to using my WAN declared DNS servers if 127.0.0.1 fails for itself but when a client requests from the pfSense to lookup this domain, it's not requesting from these public DNS servers. I'm using 1.1.1.1 and 8.8.4.4
Edit: When I query other domains, I do receive TTL values
-
@lparker yeah if you don't have forwarders setup in unbound, then no clients can not use those listed in pfsense dns settings, only pfsense itself could do that..
Clearly you are not actually talking to that NS.. you should see aa in the flags if you were, and you should see the full ttl on every query 10800 is what they have set.
I would say you have serve zero set in unbound, but that would only come into play if you were redirecting dns to unbound since in your dig your calling out to directly talk to that ns IP..
You sure you have redirection turned off in pfsense? So what should happen even if redirected, you wouldn't see the aa but say your first query could be 0 ttl, but if you queried again that ttl should go up to the full when unbound actually resolved it. and then start counting down.. That is staying 0 tells me unbound isn't actually able to talk to that auth ns for some reason.
If you do that query on pfsense what happens - that shouldn't be redirected..
[23.05-RELEASE][admin@sg4860.local.lan]/root: dig @173.201.72.45 advantechwifi.com ; <<>> DiG 9.18.13 <<>> @173.201.72.45 advantechwifi.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31830 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;advantechwifi.com. IN A ;; ANSWER SECTION: advantechwifi.com. 10800 IN A 192.124.249.7 ;; AUTHORITY SECTION: advantechwifi.com. 3600 IN NS ns70.domaincontrol.com. advantechwifi.com. 3600 IN NS ns69.domaincontrol.com. ;; Query time: 10 msec ;; SERVER: 173.201.72.45#53(173.201.72.45) (UDP) ;; WHEN: Mon Jun 12 09:46:16 CDT 2023 ;; MSG SIZE rcvd: 114 [23.05-RELEASE][admin@sg4860.local.lan]/root:Your serve zero response is also different IP than I am seeing talking to the auth ns - so that could explain why the site isn't actually working, because your IP getting back are not valid any more.
-
@johnpoz Here's from the pfSense below. I would say maybe Comcast is interfering, but I still have my Wi-Fi running over a different firewall using a public IP in the same /29 and clients behind that can resolve it just fine.
[23.05-RELEASE][admin@pfSense.ad.techzenit.com]/root: dig @173.201.72.45 advantechwifi.com ; <<>> DiG 9.18.13 <<>> @173.201.72.45 advantechwifi.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42458 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;advantechwifi.com. IN A ;; ANSWER SECTION: advantechwifi.com. 0 IN A 199.38.182.52 advantechwifi.com. 0 IN A 199.38.182.75 ;; Query time: 35 msec ;; SERVER: 173.201.72.45#53(173.201.72.45) (UDP) ;; WHEN: Mon Jun 12 10:49:13 EDT 2023 ;; MSG SIZE rcvd: 78 -
@lparker that points to redirection being done upstream of pfsense.. What if you query say a different authoritative ns? Say the one for netgate.com
;; ADDITIONAL SECTION: ns1.netgate.com. 1241 IN A 208.123.73.80 ns2.netgate.com. 1241 IN A 208.123.73.90 ns3.netgate.com. 1241 IN A 34.197.184.523.05-RELEASE][admin@sg4860.local.lan]/root: dig @208.123.73.80 netgate.com ; <<>> DiG 9.18.13 <<>> @208.123.73.80 netgate.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19153 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 90de2fc3f45ad07a01000000648731f2c23be620901f7f07 (good) ;; QUESTION SECTION: ;netgate.com. IN A ;; ANSWER SECTION: netgate.com. 60 IN A 199.60.103.104 netgate.com. 60 IN A 199.60.103.4 ;; Query time: 33 msec ;; SERVER: 208.123.73.80#53(208.123.73.80) (UDP) ;; WHEN: Mon Jun 12 09:55:46 CDT 2023 ;; MSG SIZE rcvd: 100 [23.05-RELEASE][admin@sg4860.local.lan]/root:Notice the aa flag, and the ttl - 60 is insanely low if you ask me, but that is what they have set..
edit: another test you can do about redirection.. if you query an IP that you know is not serving dns - you know for a fact your being redirect ;)
[23.05-RELEASE][admin@sg4860.local.lan]/root: dig @1.2.3.4 www.google.com ;; communications error to 1.2.3.4#53: timed outBut if I check it from box behind pfsense that I am doing dns redirection on ;)
$ dig @1.2.3.4 www.google.com ; <<>> DiG 9.16.41 <<>> @1.2.3.4 www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37495 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 2616 IN A 142.250.190.132 ;; Query time: 0 msec ;; SERVER: 1.2.3.4#53(1.2.3.4) ;; WHEN: Mon Jun 12 10:00:51 Central Daylight Time 2023 ;; MSG SIZE rcvd: 59if I remove the redirection, then my client times out as it should
$ dig @1.2.3.4 www.google.com ; <<>> DiG 9.16.41 <<>> @1.2.3.4 www.google.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached1.2.3.4 isn't doing dns - so clearly yeah I shouldn't get an answer if I ask it directly ;) That is a smoking gun that your dns is being messed with..
-
@johnpoz I've actually just started getting more widespread DNS issues so for now I've moved clients to using public DNS and I'll probably do a config restore later on and check from there but it will be too disruptive for me to work on it now. Thanks for all your help!
-
@lparker on pfsense do that query check for me, do a query to 1.2.3.4 - do you get a response? If so then your dns is being messed with upstream that is for damn sure!
But a query to an auth NS not seeing aa in flags also screams dns being messed with.
-
@johnpoz Hah, yeah, I'm still getting responses from 1.2.3.4 even. Is there a way to flush unbound cache or what settings can I look for where this redirection would be enabled? The only rule I previously had was to redirect traffic targeting port 53 to use 127.0.0.1 via NAT rule but this has been removed for awhile now. DNS Resolver service restart didn't make a difference and neither did rebooting the entire firewall.
-
@lparker said in Single website won't resolve for clients - resolves fine for pfSense itself:
getting responses from 1.2.3.4 even
That is not an unound cache thing.. Your doing a directed query.. Your dns is being intercept at some point between where your sending traffic and were your trying to go..
I don't see how you could be doing a redirect on pfsense for that? Do you have some outbound rule in floating to do redirection?? That would be the only thing that you could of setup that would possible to do that, if that was the case then yeah dns is just going to utterly fail.. I don't even see how your directed queries to something like 8.8.8.8 from a client could work if you were doing such a thing.
Would seem to me your isp, or do you have some other device like another router in front of pfsense is redirecting your dns.. Creating a redirection of dns on your lan wouldn't have anything to do with pfsense doing a directed query.. The only way it would even be possible to redirect pfsense doing dns would be on some outbound rule in floating.
your not routing traffic through a vpn are you?
-
@johnpoz Yeah its extremely weird to say the least. Clients are working fine when using alternate DNS servers, but it seems all DNS requests sent to resolver are failing. I'm going to try doing a restore after hours today and see where that gets me.
-
Just as a further note - if I disable Resolver and instead turn on DNS Forwarder - clients can now use send DNS requests to the pfSense and it forwards it out and clients get the response back as expected - even when reaching out to the previously mentioned advantechwifi.com
-
@lparker tell you right now this is NOT a pfsense issue...
How would redirect its own traffic to itself and resolve something when you asked 1.2.3.4 for something?
You have restarted unbound I am sure right? how would you be getting back that zero ttl? since once you restart unbound there is no way for that to be in the cache, etc.
