Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
dig -6 works but dig -4 does not
I can't get a response from IPv4 dig on my server but I can get one from IPv6 dig.
See the below output:
$ dig +short myip.opendns.com a @resolver1.opendns.com
# Doesn't return anything, this used to work!
$ dig +short -4 myip.opendns.com a @resolver1.opendns.com
;; connection timed out; no servers could be reached
$ dig TXT +short o-o.myaddr.l.google.com @ns1.google.com
"2600:1700:846b:c8d0:98e5:2279:72f4:xxxx"
$ dig -4 TXT +short o-o.myaddr.l.google.com @ns1.google.com
;; connection timed out; no servers could be reached
$ dig -6 TXT +short o-o.myaddr.l.google.com @ns1.google.com
"2600:1700:846b:c8d0:98e5:2279:72f4:xxxx"
$ dig +short @8.8.8.8 google.com
;; connection timed out; no servers could be reached
$ dig +short @2001:4860:4860::8888 google.com
172.217.4.46
What the heck is going on?
I did just switched ISPs, Comcast cable => AT&T fiber and from a cable modem + router to AT&T bundled modem & router. I've never used IPv6 before this and all the IPv4 stuff worked previously for my dynamic DNS scripts from the computer I'm running this on. I'm not sure where to start looking.
EDIT:
It looks like resolv.conf has the old default gateway (192.168.0.1) as the IPv4 DNS server.
$ systemd-resolve --status
# ...
Link 3 (wlp2s0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 2600:1700:846b:c8d0::1
DNS Domain: attlocal.net
Link 2 (enp0s31f6)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.0.1
2600:1700:846b:c8d0::1
DNS Domain: ~.
attlocal.net
Using dig @192.168.0.254 google.com returns the correct value. I have no idea why it didn't change by itself. I'm just not sure how to fix it without rebooting.
For the record, I've never touched anything to do with resolv.conf and everything should be Linux Mint default. I've never manually changed the nameservers.
Also here's the output of ip -4 route
$ ip -4 route
default via 192.168.0.1 dev enp0s31f6 proto dhcp metric 20100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-7268d2f28da2 proto kernel scope link src 172.18.0.1
172.19.0.0/16 dev br-efe27a1d50a1 proto kernel scope link src 172.19.0.1
172.20.0.0/16 dev br-31f1b3063ac5 proto kernel scope link src 172.20.0.1
172.21.0.0/16 dev br-6c1ef2342a51 proto kernel scope link src 172.21.0.1
172.22.0.0/16 dev br-fca56dd8a950 proto kernel scope link src 172.22.0.1
172.25.0.0/16 dev br-6ee15f69026c proto kernel scope link src 172.25.0.1
172.26.0.0/16 dev br-2894a4b9fb39 proto kernel scope link src 172.26.0.1
192.168.0.0/24 dev enp0s31f6 proto kernel scope link src 192.168.0.230 metric 10
0
192.168.240.0/20 dev br-92e43c867623 proto kernel scope link src 192.168.240.1
$ traceroute -4n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.0.230 3061.133 ms !H 3061.064 ms !H 3061.023 ms !H
1 answer
From the further details you added, it does indeed sound like you have some stale connection state on your system. The fact that you can get DNS replies when you query a DNS server by IPv4 address, but not by host name, strongly suggests a resolver configuration issue, and from what you say, your /etc/resolv.conf is indeed out of date. It's worth remembering that dig uses the standard system resolver to resolve the name of the DNS server given as @ns.example.com on the command line. To work around that, you need to use a DNS server IP address, such as for example Google's public resolvers 8.8.8.8 and 8.8.4.4, Cloudflare's 1.1.1.1, or your ISP's resolver as provided by DHCP.
The easy fix for this is usually just to reboot, but as is often the case on *nix systems, there are ways to get the same result without the reboot.
I'm not familiar with Mint specifically, but since it's a Debian/Ubuntu derivative, it should be reasonably similar to modern Debian (which I am more familiar with). In that case, you should be able to use the NetworkManager tools to view and modify network state. A dead giveaway that your system uses NetworkManager to, well, manage the network, is if your /etc/resolv.conf (or whatever that is a symlink pointing to; in my case, /run/NetworkManager/resolv.conf which is another strong hint) has a comment near the top similar to
# Generated by NetworkManager
If so, you should be able to see your current network connection state by running:
$ nmcli connection show
This will print a list of your connections. Assuming that your terminal environment is set up correctly, one of them (your currently active connection) should be displayed in green, indicating that it is currently up. If you're having trouble identifying the connection to manipulate, you can do nmcli connection show id "<name>" for each, which will show additional details. Note the value in the "name" column or the connection.id field, then:
$ sudo nmcli connection down id "<name>"
$ sudo nmcli connection up id "<name>"
For example:
$ sudo nmcli connection down id "Wired connection 1"
$ sudo nmcli connection up id "Wired connection 1"
This should restart your network connection and update /etc/resolv.conf with the new values, without affecting anything other than the network connection you are manipulating and any traffic currently flowing through it. Confirm this by running nmcli connection show again; it should look very similar to how it did before.
Note that this will break any existing network connections, so don't do this over a remote connection like a SSH session without taking special precautions first.
With the connection back up, check your /etc/resolv.conf to see if it has been updated. If it has, name resolution should now work as expected.
(Yes, you can probably do all of this through a fancy GUI. No, I don't know where it's hidden.)
1 comment thread