Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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.

Post History

66%
+2 −0
Q&A dig -6 works but dig -4 does not

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,...

posted 4y ago by Canina‭

Answer
#1: Initial revision by user avatar Canina‭ · 2020-10-07T18:46:44Z (about 4 years ago)
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.)