DNS lookup fails only on specific sites while using Arch Linux

2

1

The title gets to the core of the problem. I will provide more information though.

I am running an install of Arch Linux on my laptop, and up until recently everything was going fine. I am was using netctl to connect to wifi, which went smoothly. Recently I started a job and my workplace's network uses WPA2 Enterprise, so I found it easier to directly use wpa_supplicant to connect to the network there. Once I did so however, I started to run into DNS issues. Most sites would load fine, but some like archlinux.org and wikipedia would fail to load in chromium, returning DNS_PROBE_FINISHED_NXDOMAIN errors. I was also unable to ping these by hostname, but I could by IP.

This of course made me think there was an issue with the DNS server provided by my router at work, so I created a /etc/resolv.conf.head in order to include Google's public DNS server into my /etc/resolv.conf file. I then ran sudo nscd -i hosts and restarted and things improved a bit. I was then able to at least access these pages, but the lookup time was terrible for each site (~5 seconds). Needing to get work done, I settled with that.

Now at home I am running into the same issues, which is perplexing. I am connected to my home wifi using the same netctl profile that I used to use without problem. I thought that maybe somehow Google's DNS was now causing an issue, so I removed the .head file I had created to fix the problem at work. I am still unable to load the same webpages, like wikipedia. I included Google's DNS in a tail file. Here is my resolv.conf file:

#Generated by resolvconf
domain hsdl.il.comcast.net
nameserver 75.75.75.75
nameserver 75.75.76.76
nameserver 8.8.8.8
nameserver 8.8.4.4

What is confusing me even further is that dig returns no error when I force a DNS lookup for one of the problem sites:

; <<>> DiG 9.13.3 <<>> en.wikipedia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 164
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;en.wikipedia.org.      IN  A

;; ANSWER SECTION:
en.wikipedia.org.   292 IN  A   208.80.154.224

;; Query time: 33 msec
;; SERVER: 75.75.75.75#53(75.75.75.75)
;; WHEN: Thu Oct 11 17:22:03 CDT 2018
;; MSG SIZE  rcvd: 61

I have an imperfect understanding of this stuff, but this suggest to me that I was able to actually resolve the hostname when using dig, but it still doesn't work when pinging or in browser.

Any pointers here would be greatly appreciated. I am aware of similar questions here, but the ones I have read have not helped the issue much.

Thanks

gabe

Posted 2018-10-12T03:24:14.553

Reputation: 121

2Are you perhaps using systemd-resolved? It behaves slightly differently than dig (random nameserver, DNSSEC usage whenever possible). Check its system logs especially for DNSSEC errors. – user1686 – 2018-10-12T03:27:31.377

First thing I’d try is dumping Comcast DNS. Try 1.1.1.1 and 1.0.0.1 (cloudflare) with google for backup, and no Comcast. – Tyson – 2018-10-12T03:28:18.467

Answers

1

Short answer: Most likely it's a timezone or system time issue. Set your computer to the correct time and timezone and it will probably go away.

Long answer: I had this exact same problem today. When I checked out my systemd-resolved.service logs via

journalctl -u systemd-resolved.service

it spit out a bunch of errors of the form:

DNSSEC validation failed for question en.wikipedia.org IN A: signature-expired

for example. This means that DNS failed due to a security issue arising from an expired signature. Since wikipedia.org probably does not use expired signatures, this is a hint that the system thinks that it's expired when it's not, and therefore, it must be a system clock issue.

I am not sure whether this was triggered by me being in a different time zone than where I normally work or because of the known windows-linux time conflict causing my linux partition to use the wrong time, but regardless, the fix worked.

Hope this helps anyone else who stumbles across this!

sicklybeans

Posted 2018-10-12T03:24:14.553

Reputation: 11