According to this both have the same IP.
But when I run
nc -v duckduckgo.com 443, it shows up in WireShark as 184.108.40.206. 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
/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 220.127.116.11 ;; 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.
18.104.22.168 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.
= 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.
Now still @pobrn deserves a medal for his engagement and support. You owe him a beer
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.