DNS Resolver Not Resolving Some Requests
-
Well...now I'm embarrassed, just spent the last couple of hours tearing my network apart and putting it back together into a rack and now when I try the site again it loads. Before in Firefox I was getting connection timed out errors and Chrome would give the err_connection_refused page. Honestly half the time those dig logs were giving me results so I have no idea why the page wouldn't load but now it does so I guess the problem is solved. Thanks for your help and sorry for wasting your time.
-
@jaskerx sure firefox and chrome weren't using doh?
-
@johnpoz No, DNS over HTTPS is off for both Firefox and Chrome.
-
@jaskerx said in DNS Resolver Not Resolving Some Requests:
DNS over HTTPS is off for both Firefox and Chrome.
Says you - but what about what they were doing for your own good? I mean your just a stupid user, what do you know about dns? As the smart company providing your browser we know better and trying to protect you from bad shit, oh you will get ads - but they are safe (trust us) and blah blah blah ;)
I mean really - why would you want/need to resolve anything locally - we will just ask ourselves for shit you will want to go to ;)
-
Plz no smart browser company. -
Sigh, now it happening again. Here is dig +trace from both the pfSense box and client:
pfSense box
Shell Output - dig www.upsbatterycenter.ca +trace ; <<>> DiG 9.18.14 <<>> www.upsbatterycenter.ca +trace ;; global options: +cmd . 12319 IN NS j.root-servers.net. . 12319 IN NS k.root-servers.net. . 12319 IN NS l.root-servers.net. . 12319 IN NS m.root-servers.net. . 12319 IN NS a.root-servers.net. . 12319 IN NS b.root-servers.net. . 12319 IN NS c.root-servers.net. . 12319 IN NS d.root-servers.net. . 12319 IN NS e.root-servers.net. . 12319 IN NS f.root-servers.net. . 12319 IN NS g.root-servers.net. . 12319 IN NS h.root-servers.net. . 12319 IN NS i.root-servers.net. . 12319 IN RRSIG NS 8 0 518400 20230720170000 20230707160000 11019 . R1l/Pnc5g7u9rNzJyoeqVRVUvslpimDfvtPSJo4oYdns63SUuLQCrboI 31O+JbHjAx4cw0asHadaq+rcVZxgI6/M2UaHpe+k5h5myyFLxirpLjL3 LqaoXYz8FYDjE2tfZM5ZMzdXHsfZkwPrQNMJPLe+w/iJfQfdPri+grhB nCrOddYSlyyzSA1dn1bjIE8duUCJejCtUDroamLck1sFl7snX2VGgna9 scSW6XMrJqWJLHJx+KvElmRo7wn2nqCDnDu0//HI+/sQKmAVwvYqtQ2M ItmLKct9Gxt8n8+B1/ThmbxnIP4kLpCvjiKgJK9Q6GbVY40uLhoBQLFM E842Ww== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms ;; UDP setup with 2001:7fe::53#53(2001:7fe::53) for www.upsbatterycenter.ca failed: host unreachable. ;; UDP setup with 2001:7fe::53#53(2001:7fe::53) for www.upsbatterycenter.ca failed: host unreachable. ;; UDP setup with 2001:7fe::53#53(2001:7fe::53) for www.upsbatterycenter.ca failed: host unreachable. ca. 172800 IN NS c.ca-servers.ca. ca. 172800 IN NS j.ca-servers.ca. ca. 172800 IN NS x.ca-servers.ca. ca. 172800 IN NS any.ca-servers.ca. ca. 86400 IN DS 43787 8 2 2AF70B49C542B7DACEC2D4754651598B740EF1D79E7A839B32BC7F7E 96039A2C ca. 86400 IN RRSIG DS 8 1 86400 20230721050000 20230708040000 11019 . XNRHu6PSTbX/MM8JJo+yyaCRNG5FfOYq5GhxWMYITzJk/kEaj3sOOnjV uWDaX8BcXqL3jr+lBsm59QLyARd+PrSr4qe4WKMNsczQBUh7139lRKoC gVXTI9sERizj8gXW9L2goSxdd3uYdPiMgal+C1b1nwsOaGg951WsuEgs ObB8Qe7DN5/osZgCo3U7if2E1Mq51gsUTmSTMdsUS82O0bS9uVq3+Qhx Zrjow+CNZS1Ru1pmnnfsi/vBMMABsXhKV1cn+eekfRY/vkpa4pV9XMoc zcsoncKcfVCoO/b2xCax4SwWAk8TTjb7sO02n8ilwHXMCPSc/4B8ENR/ tVRCtQ== ;; Received 640 bytes from 198.97.190.53#53(h.root-servers.net) in 108 ms ;; UDP setup with 2001:500:a7::2#53(2001:500:a7::2) for www.upsbatterycenter.ca failed: host unreachable. ;; UDP setup with 2001:500:83::1#53(2001:500:83::1) for www.upsbatterycenter.ca failed: host unreachable. ;; UDP setup with 2620:10a:8053::2#53(2620:10a:8053::2) for www.upsbatterycenter.ca failed: host unreachable. upsbatterycenter.ca. 86400 IN NS dns702-1.nexcess.net. upsbatterycenter.ca. 86400 IN NS dns702-2.nexcess.net. r66k981mhm0vmpsgv1djat7janroai95.ca. 3600 IN NSEC3 1 1 0 - R66PG9PTTIK20OKT0J69V3IS2M57VEK9 NS SOA RRSIG DNSKEY NSEC3PARAM r66k981mhm0vmpsgv1djat7janroai95.ca. 3600 IN RRSIG NSEC3 8 2 3600 20230711170339 20230704080817 49461 ca. jR98b8IzgVz4JGSEZyWl8EpXHq/RX8Ad+D+R9/PyPJAY9clu4yXhLjee TZ58Hkd49lzGJjzWZLXQo6WtUl4g/97h4C+y45BUTUk0a1HsU7o2Z5At y79OzKLPYGspT7EZB9ifk2/gX573ILXaOpPgJhWW0PcoTpMwGXhwlS/P RI8= 8je5iun30cs8v8ofuutn6t4jjq32iv0m.ca. 3600 IN NSEC3 1 1 0 - 8JEACDPOASEME0D4HMNEQU711GTPHJU5 NS DS RRSIG 8je5iun30cs8v8ofuutn6t4jjq32iv0m.ca. 3600 IN RRSIG NSEC3 8 2 3600 20230712095705 20230705023829 49461 ca. mwXxADUHb52mEGnr0RQVV8EzPTSftHsBqf4IqG8zkoP2DtWJk1pqrmPU 3jdKsKiYUGRjvPHC+97undY0DF70qMKBaHtzEwillZDosjzMIN1G1s2y GuR6ruYyhAkce2A09QhFO8LPaezUsMoz/HmDLGMQGAw2yJx2lkyqKfLd Fe4= ;; Received 594 bytes from 185.159.196.2#53(c.ca-servers.ca) in 52 ms www.upsbatterycenter.ca. 43200 IN CNAME upsbatterycenter.ca. upsbatterycenter.ca. 43200 IN NS dns702-1.nexcess.net. upsbatterycenter.ca. 43200 IN NS dns702-2.nexcess.net. ;; Received 112 bytes from 192.240.174.186#53(dns702-1.nexcess.net) in 65 msFedora client
dig www.upsbatterycenter.ca +trace ; <<>> DiG 9.18.16 <<>> www.upsbatterycenter.ca +trace ;; global options: +cmd . 12370 IN NS b.root-servers.net. . 12370 IN NS c.root-servers.net. . 12370 IN NS d.root-servers.net. . 12370 IN NS e.root-servers.net. . 12370 IN NS f.root-servers.net. . 12370 IN NS g.root-servers.net. . 12370 IN NS h.root-servers.net. . 12370 IN NS i.root-servers.net. . 12370 IN NS j.root-servers.net. . 12370 IN NS k.root-servers.net. . 12370 IN NS l.root-servers.net. . 12370 IN NS m.root-servers.net. . 12370 IN NS a.root-servers.net. ;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 11 ms ;; Received 52 bytes from 192.58.128.30#53(j.root-servers.net) in 0 msI'm starting to think this might be on the client side, and might not be a pfSense problem at all. I'm still getting the address resolved but the browser will not lead the page as it keeps timing out. Bizarre.
-
Hmmm not working on phone connected to wifi either.
-
@jaskerx that fedora client trace is not valid, its just the roots.
Also that trace isn't a good test, because it just ends at the cname, to know if you can actually get there you need to resolve what the cname points to
www.upsbatterycenter.ca. 43200 IN CNAME upsbatterycenter.ca.
I mean you end up asking the same NS, but to validate that the actual fqdn your wanting to go to resolves, you need to query or trace to that not he cname pointing to it.
-
@johnpoz Phone (Android) gives same output of that command and Fedora. This would have to be a DNS misconfiguration problem would it not? Although everything else seems to work fine.
-
@jaskerx yeah that trace is not valid.. It didn't follow through - it just got the roots, from itself - see that 127.0.0.53 that is some caching dns software prob dnsmasq.. But from that you really have zero idea where that client is getting its actual dns from.. Its pointing to a local service. That is going to forward somewhere - where? is the question.
So for example I do a dig on my PC, and it gets the roots from the dns its pointing to 192.168.3.10
<<>> DiG 9.16.42 <<>> upsbatterycenter.ca +trace ;; global options: +cmd . 4690 IN NS k.root-servers.net. . 4690 IN NS l.root-servers.net. . 4690 IN NS m.root-servers.net. . 4690 IN NS a.root-servers.net. . 4690 IN NS b.root-servers.net. . 4690 IN NS c.root-servers.net. . 4690 IN NS d.root-servers.net. . 4690 IN NS e.root-servers.net. . 4690 IN NS f.root-servers.net. . 4690 IN NS g.root-servers.net. . 4690 IN NS h.root-servers.net. . 4690 IN NS i.root-servers.net. . 4690 IN NS j.root-servers.net. . 4690 IN RRSIG NS 8 0 518400 20230721050000 20230708040000 11019 . l03NbbJFtKo3X8r5f3s/tMjWa7LSeflFy2gVmuxAs+KOjtk0B6bMv8VF SpHVduEiOwxNEm2yq5BFdHETuyoqQEcBmMLPWz293/J21rbjfPFMXJHT WSVCUEI37MF58Bkpr2MTBXQOE8XsXF1ykdBD1gwi9qTERsr8htwt1K8O G17HAGHJuqB8SaMC4St/VZGQmKsi+vKn6r63jrcBMXtDA2hgtjaOE3EE 8iFd43x+dM+9JawJeI78FglgZyYnHYF4VfS1NQcu6oX2L99YYyfeD1pH p0JFXJAqVcYgvXfXKNhI7k6aoVeqoq6RLvecNz5GfWxG7AAPLv23UWnl 0/e5NA== ;; Received 525 bytes from 192.168.3.10#53(192.168.3.10) in 8 ms -
@johnpoz As far as I know 127.0.0.53 is the stub address network-manager sends DNS requests, I'm also sure that this is default. In fact I can go to another default config Fedora machine and try the site and it will timeout just like it does on my PC.
-
@jaskerx yeah I know that is default on many linux boxes, the problem is you don't actually know where the query went..
your trace from pfsense shows it can resolve, do a directed query to pfsense. Do you get a reply? if so then its not pfsense having an issue..
Pfsense can not make your client ask it for dns, all it can do is respond when asked or not.. But clearly looks like it is responding. Shoot the ttl on that is 12 hours.. So once it looks it up once - it wouldn't have to look it up again for 12 hours, unless unbound is being restarted.
Why don't you look to sniff if your client is even asking dns, and if so what - and if that is answering or not? Doing a +trace isn't going to tell you were the problem is, only that is not in network connectivity on how that is resolved.
If pfsense was unable to resolve it, then a trace would be a good test to see where in the resolve process its failing, etc.. But if pfsense can resolve it.. Then clearly that is not your problem - and traces from any other machine really are not going to help.. What is helpful is just a simple dig or nslookup or host what what your looking for.. Does the client get an IP in answer?
$ dig www.upsbatterycenter.ca ; <<>> DiG 9.16.42 <<>> www.upsbatterycenter.ca ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53798 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;www.upsbatterycenter.ca. IN A ;; ANSWER SECTION: www.upsbatterycenter.ca. 41202 IN CNAME upsbatterycenter.ca. upsbatterycenter.ca. 41202 IN A 192.240.174.188 ;; Query time: 11 msec ;; SERVER: 192.168.3.10#53(192.168.3.10) ;; WHEN: Sat Jul 08 10:01:42 Central Daylight Time 2023 ;; MSG SIZE rcvd: 82 -
@johnpoz Maybe this could possibly be a browser problem after all I managed to get the site to load in Firefox but when I went to Chrome it wouldn't load, I then went back to Firefox and tried to navigate the site further and it timed out again. Here is output of dig on Fedora:
dig www.upsbatterycenter.ca ; <<>> DiG 9.18.16 <<>> www.upsbatterycenter.ca ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4765 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;www.upsbatterycenter.ca. IN A ;; ANSWER SECTION: www.upsbatterycenter.ca. 3914 IN CNAME upsbatterycenter.ca. upsbatterycenter.ca. 3914 IN A 192.240.174.188 ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) ;; WHEN: Sat Jul 08 09:07:52 CST 2023 ;; MSG SIZE rcvd: 82It's resolving so why are the browsers timing out?
-
Now it's working again on both browsers, I'm ready to throw up my hands and walk away from this one.
-
Reviewing; why do think this is a DNS issue at all?
You initally stated those sites would not resolve but then you said you seeing timeout and connection refused errors, neither of which I'd associate with a DNS issue.
-
@stephenw10 I originally assumed it was DNS because the site would fail to load on multiple Fedora pc's as well as Android phones but now I'm getting combinations of err_connection_refused, err_connection_aborted and connection has timed out errors. Got more research to do I guess.
-
Are you running pfBlocker or Snort/Suricata? Anything logged as blocked there?
-
@stephenw10 That was the second place I looked but I'm not getting the pfBlocker page or the 1x1 pixel dot, and I don't see upsbatterycenter in the Reports - Alerts page. Also wouldn't explain the intermittent nature of what I have been experiencing today with this site it would just be blocked period.
-
I'd try running a pcap for 192.240.174.188 when you're trying to access it. It could just be refused at the server.
-
@jaskerx I would look to your client to why its failing.. DNS is just the first step in connecting to it.. But if you get that IP answer from pfsense then its not a pfsense dns issue.
Now it could be your client not asking pfsense? It could be as mentioned a rst from the server, could be the server just not answering?
I have not seen any issues loading up that site on my devices..
In firefox load up the dev tools when you try and access it - you should get some more details of what exactly is failing. or look at firefox actual dns cache, etc..
about:networking#dns
In firefox will show you its cache, and info on where it got it from if its using doh, etc.
