1

I have a Rasberry Pi running Arch and i'm encountering some weird resolving behavior. Long story short, dig and nslookup can resolve hostnames, curl, wget, pacman can't. If i add a host in /etc/hosts everything works fine for that host.

Here is the output of some troubleshooting:

  1. resolv.conf exists and is readable:

    $ ls -l /etc/resolv.conf
    -rw-r--r-- 1 root root 19 Apr 28 10:45 /etc/resolv.conf
    
  2. I have a nameserver:

    $ cat /etc/resolv.conf
    nameserver 8.8.8.8
    
  3. nslookup works:

    $ nslookup google.com
    Server:         8.8.8.8
    Address:        8.8.8.8#53
    
    Non-authoritative answer:
    Name:   google.com
    Address: 92.87.11.30
    Name:   google.com
    Address: 92.87.11.54
    Name:   google.com
    Address: 92.87.11.49
    Name:   google.com
    Address: 92.87.11.45
    ...
    
  4. dig works:

    $ dig google.com
    
    ; <<>> DiG 9.11.0-P3 <<>> google.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20686
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;google.com.                    IN      A
    
    ;; ANSWER SECTION:
    google.com.             299     IN      A       92.87.175.49
    google.com.             299     IN      A       92.87.175.50
    google.com.             299     IN      A       92.87.175.48
    google.com.             299     IN      A       92.87.175.44
    google.com.             299     IN      A       92.87.175.42
    google.com.             299     IN      A       92.87.175.41
    google.com.             299     IN      A       92.87.175.51
    google.com.             299     IN      A       92.87.175.36
    google.com.             299     IN      A       92.87.175.39
    google.com.             299     IN      A       92.87.175.45
    google.com.             299     IN      A       92.87.175.37
    google.com.             299     IN      A       92.87.175.40
    google.com.             299     IN      A       92.87.175.38
    google.com.             299     IN      A       92.87.175.47
    google.com.             299     IN      A       92.87.175.43
    google.com.             299     IN      A       92.87.175.46
    
    ;; Query time: 40 msec
    ;; SERVER: 8.8.8.8#53(8.8.8.8)
    ;; WHEN: Fri Apr 28 11:37:32 EEST 2017
    ;; MSG SIZE  rcvd: 295
    
  5. I can ping one of the IPs:

    $ ping 92.87.175.49
    PING 92.87.175.49 (92.87.175.49) 56(84) bytes of data.
    64 bytes from 92.87.175.49: icmp_seq=1 ttl=54 time=3.75 ms
    64 bytes from 92.87.175.49: icmp_seq=2 ttl=54 time=3.71 ms
    
    --- 92.87.175.49 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1001ms
    rtt min/avg/max/mdev = 3.711/3.734/3.758/0.065 ms
    
  6. wget fails:

    $ wget https://google.com
    --2017-04-28 11:39:31--  https://google.com/
    Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
    Resolving google.com... failed: Name or service not known.
    wget: unable to resolve host address 'google.com'
    
  7. curl fails:

    $ curl https://google.com
    curl: (6) Could not resolve host: google.com
    

What am I missing?!...

Edit:

$ cat /etc/hosts
#
# /etc/hosts: static lookup table for host names
#

#<ip-address>   <hostname.domain.org>   <hostname>
127.0.0.1       localhost.localdomain   localhost
::1             localhost.localdomain   localhost

# End of file

$ cat /etc/nsswitch.conf
# Begin /etc/nsswitch.conf

passwd: compat mymachines systemd
group: compat mymachines systemd
shadow: compat

publickey: files

hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files

# End /etc/nsswitch.conf

It seems it has something to do with systemd-resolvd. If i stop it or remove resolve [!UNAVAIL=return] from /etc/nsswitch.conf, resolving works fine for every app, if i start it again or leave /etc/nsswitch.conf as is, resolving works only for nslookup & dig.

  • Does your network require you to use a HTTP proxy? – tripleee Apr 28 '17 at 12:14
  • @tripleee No proxy i required. – petry Apr 28 '17 at 12:18
  • Can you nc 92.87.175.49 80? What about openssl s_client -quiet -crlf -connect 92.87.175.49:443? – tripleee Apr 28 '17 at 12:19
  • 1
    You could try running strace wget https://google.com to see what the wget program does and where the name lookup goes wrong. The contents of /etc/host.conf and /etc/nsswitch.conf could also be of interest. – Johan Myréen Apr 28 '17 at 13:10
  • 1
    (@JohanMyréen) The specific programs host nslookup dig are part of the BIND package and ONLY use the DNS server (defaulted or specified), not the full name-resolution logic (typically in libc) used by most programs. Your DNS server (8.8.8.8) is fine and it's something else in name-resolution that's bad, apparently whatever nsswitch setting resolve invokes. – dave_thompson_085 Apr 28 '17 at 18:53
1

I have a similar problem after archlinuxarm updates: some sites works but most of them are unavailable and pacman cannot updates. In my case the problem is dnssec on system resolver. It may be detected by runing from console:

resolvectl query archlinuxarm.org (or any other unavailable site)

the answer was: ... DNSSEC validation failed: invalid

In my case helped addition DNSSEC=false to /etc/systemd/resolved.conf and reboot

  • This happened to me too just recently, also on archlinuxarm. However, I got archlinuxarm.org: resolve call failed: DNSSEC validation failed: signature-expired as a result of the command. But adding DNSSEC=false still fixed the issue. Thanks! – Rapti May 16 at 19:11

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.