DNS Resolver Not Resolving Some Requests
-
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.
-
@jaskerx how do you turn of DoH on Chrome???
