Duckduckgo unreachable

According to this both have the same IP.

But when I run nc -v 443, it shows up in WireShark as ping also uses that address.

I’m thinking it might be a network error, but not on your part. Since that IP doesn’t work me either. You could put

in /etc/hosts as a workaround for now.

Or I could just use lite.
Here’s the full output of dig:

= dig

; <<>> DiG 9.16.6 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26810
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
; COOKIE: fbc7878fe0e990348f628ad55f5e68c7dbd0a691312c548b (good)
;            IN  A

;; ANSWER SECTION:     200 IN  A

;; Query time: 23 msec
;; WHEN: Sun Sep 13 20:45:27 MEST 2020
;; MSG SIZE  rcvd: 87 is my router, so maybe I need to clear the cache there. But then why is ping getting a different address?

This IP works. on the other hand doesn’t.

Aha! When I ping duckduckgo on my FreeBSD machine, it comes up with the 40. address. So it seems there’s some sort of DNS problem on this Linux box.
Can you nc the 79. address?

I did. It doesn’t work.

So maybe the problem is just that ping & Palemoon are somehow getting the wrong address. Dig, however, works fine.

Can you cat /etc/resolv.conf and /etc/nsswitch.conf?

= cat /etc/nsswitch.conf
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.

passwd: files mymachines systemd
group: files mymachines systemd
shadow: files

publickey: files

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

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

netgroup: files

= cat /etc/resolv.conf
# Generated by NetworkManager

Can you run dig @ ?

Ahhhh, I just found the problem. In /etc/hosts I have the 79. address for Apparently that address is obsolete. Sigh. :frowning:

:joy: Now still @pobrn deserves a medal for his engagement and support. You owe him a beer :stuck_out_tongue_winking_eye::beers:

Indeed, @pobrn, I do owe you a beer or six. :beer: :beer: :beer: :beer: :beer: :beer:

It’s amazing how such a simple problem can be so time-consuming to figure out.
It’s also interesting that dig doesn’t consult /etc/hosts. If it had done that, the problem would have been much more readily apparent.

I have some critical addresses hardwired into /etc/hosts in case the DNS goes down or gets subverted. Today we learned the downside of that emergency measure. Better would be to have a cron job which updates (or re-writes) the file using dig on the list of critical sites.

1 Like

As recompense for my stupidity, I offer the little script I developed to keep /etc/hosts up to date:

#!/bin/sh -f
# /root/bin/hosts       20200914        NHA
# Run this in a cron job to update /etc/hosts

type dig 2>/dev/null 1>&2  ||  exit 1

mv -f /etc/hosts /etc/hosts.bak

cat  <<__EOF__  >/etc/hosts
# /etc/hosts -- created by /root/bin/hosts using /etc/hosts.list
# $(date)   localhost   myhostnamehere
::1     localhost ip6-localhost ip6-loopback
ff02::1     ip6-allnodes
ff02::2     ip6-allrouters

for host in $(fgrep -v \# /etc/hosts.list) ;do
        echo "$(dig $host +short | tail -1) $host" >>/etc/hosts

Put the list of critical sites in /etc/hosts.list, and add an entry to crontab to invoke the script regularly, and Bob’s your uncle. If DNS goes wonky, you’ve still got access to the most critical sites.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.