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

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

; EDNS: version: 0, flags:; udp: 512
;en.wikipedia.org.      IN  A

en.wikipedia.org.   292 IN  A

;; Query time: 33 msec
;; 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.


  • 2
    Are 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. – grawity Oct 12 '18 at 3:27
  • First thing I’d try is dumping Comcast DNS. Try and (cloudflare) with google for backup, and no Comcast. – Tyson Oct 12 '18 at 3:28

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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.