According to this both have the same IP.
But when I run nc -v duckduckgo.com 443
, it shows up in WireShark as 79.125.108.55. 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
40.114.177.156 duckduckgo.com
in /etc/hosts
as a workaround for now.
Or I could just use lite.
Here’s the full output of dig:
= dig duckduckgo.com
; <<>> DiG 9.16.6 <<>> duckduckgo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26810
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: fbc7878fe0e990348f628ad55f5e68c7dbd0a691312c548b (good)
;; QUESTION SECTION:
;duckduckgo.com. IN A
;; ANSWER SECTION:
duckduckgo.com. 200 IN A 40.114.177.156
;; Query time: 23 msec
;; SERVER: 192.168.3.3#53(192.168.3.3)
;; WHEN: Sun Sep 13 20:45:27 MEST 2020
;; MSG SIZE rcvd: 87
192.168.3.3 is my router, so maybe I need to clear the cache there. But then why is ping getting a different address?
This IP works. 79.125.108.55
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
nameserver 192.168.3.101
nameserver 192.168.3.3
Can you run dig duckduckgo.com @192.168.3.101
?
Ahhhh, I just found the problem. In /etc/hosts I have the 79. address for duckduckgo.com. Apparently that address is obsolete. Sigh.
Indeed, @pobrn, I do owe you a beer or six.
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.
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)
127.0.0.1 localhost
127.0.1.1 myhostnamehere
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
__EOF__
for host in $(fgrep -v \# /etc/hosts.list) ;do
echo "$(dig $host +short | tail -1) $host" >>/etc/hosts
done
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.