When I started writing this article I was confident that I had the right route to get you to your destination. When I retraced my steps to be sure I understood, I ended way off course. As much as I was embarrassed by this gap in knowledge, I found that the exercise helped me produce the type of article I like to write: one where I can learn just as much as the reader, if I’m not more.
Given how widely the subject of this article varies between Linux distributions — and has varied over time — I shouldn’t have been surprised I took a wrong turn. With computers, knowledge goes stale — and fast.
Oh, where is my manners? This week’s topic concerns configuring the DNS settings on desktop Linux. This is a simple concept that can provide privacy, security and availability benefits. It’s not intuitive to customize your device DNS, even though it used to be simple.
Master Your Computer’s Domains
Why bother with DNS at all? DNS configuration is a great way to regain some control of your digital life. Here is a quick overview of DNS to help you understand why.
It is often referred to as the “phonebook” of the Internet. Internet Protocol (IP) is the only internet connection that understands IP addresses and not domain names. linuxinsider.com. When you enter an URL containing a specific domain, your PC asks the DNS server the IP associated with that domain. When the DNS server replies with an answer, your computer dials the IP address to connect.
This is a classic chicken-and-egg scenario. How can your computer locate a DNS server, if it requires an answer from the DNS server in order to connect? You can store a few DNS servers so that your computer knows who to ask for domains.
Where do these DNS server addresses come from? These IPs can be sourced from several places, but they are usually generated by the network that you’re on.
Access point administrators can configure IP addresses or, in the case of home or small-business networks, the ISP can automatically assign them. ISP-provided servers of DNS are usually owned by the ISP. The AP does not care who sets its DNS servers. It pushes the addresses of those servers to clients.
What’s the reason you might want to use a different DNS server from the one that your AP provides?
First, the AP could use DNS to prevent you from accessing certain domains. It is easy to keep devices from visiting a website by not providing the “correct” DNS response. This rudimentary filtering can be avoided by choosing a DNS server you trust to answer your queries.
You may also want to continue using the internet in case your ISP’s DNS crashes. Few years ago, the DNS of your ISP was often down. DDoS attack against DNS provider Dyn Effectively prevented millions of internet users from using it.
Was the Internet down today? No, it wasn’t. Users’ devices couldn’t access the Dyn DNS server their ISP gave them. Those who set up their devices so that they go straight to the alternative DNS servers were able to continue surfing as normal.
It’s not easy to keep your resolutions.
It’s not something I remember, despite my admiration for DNS You can find out more about it here. How to configure. This article is a part of my efforts to get the message across. It’s unlikely I will forget it.
DNS configuration used to be easy in the Linux days. The system would write the DNS server addresses directly to your device when it received them from the AP. /etc/resolv.conf. Just disable the service that overwrote that file — for desktop Linux, usually NetworkManager — write in whatever DNS servers you want, and you are good to go.
Systemd’s DNS customization is complicated. We will stick to the bare essentials. The systemd software is both an init application and daemon controller. We’re only interested in daemons which are background services.
One of these daemons handles DNS. Systemd-resolved is used differently by different Linux desktop distros, making it difficult to describe how DNS resolution works in every case. It’s systemd-resolved that prevents us simply replacing. /etc/resolv.conf. The service runs on your computer a “stub-listener” with IP address 127.0.0.53. (All 127.0.0.x addresses are reserved to a device referring to itself).
The stub server is a “DNS Server” that only a. forwards DNS requests to real DNS servers b. caches the returned responses. To make sure it receives the DNS requests from your system, systemd resolved controls /etc/resolv.confThe stub is the only listener that can be contained in this device.
This isn’t systemd-resolved’s only method of catching all DNS requests from your computer; it’s the last resort. All systemd resolve’s manual pages warn that you should not disable it. So, to configure DNS we need to use systemd resolve.
Let’s make our Query and Split!
I knew that going in. The explanation given is not incorrect but it’s incomplete. I was naive to think that systemd-resolved could be tweaked by simply adding the servers of my choice into its configuration files. /etc/systemd/resolved.conf. What I didn’t understand was the “split-DNS” architecture of systemd resolved.
Each network interface (e.g. wireless card, Ethernet adapter etc.) has its own DNS settings under systemd-resolved. Each “link” or network interface has its own link-specific settings. This is a sensible approach: you may need to use different DNS servers for different situations. This is a good example of this. blog post The Gnome Foundation provides an overview of split-DNS functionality and gives examples on how to configure DNS per link.
This article reveals that in order to control the DNS queries we send on our desktop Linux, it is essential to:
- Configure DNS servers to which a link should be forwarded, You can also find out more about the following:
- Indicate the conditions under which systemd-resolved will forward that link or global.
There are several ways systemd-resolved can determine which links to route queries. This Fedora Magazine article It was also crucial to understand how all of these determinations worked.
The important detail for our purposes is that, by using a special “~.” We can use the route-only domain to tell systemd-resolved that all queries should default to one link/global configuration, unless they match a more specific link’s domain.
Remarks are needed to explain the nuances of what is or is not routed via this “default DNS” configuration. There’s so much to cover in this article that making these comments is not very useful. To preserve all of the knowledge I’ve accumulated, I will release “Part 2,” a DNS investigation, which will take up the pieces that I’m about to drop.
The Matter is Finally Solved
Instructive as they were, my one critique on the two articles cited above — and why I saw value in writing my own — is that neither goes into much detail on how to put the concepts they elucidate into practice. Let’s discuss that.
It is important to decide first whether we will use a global or singular DNS configuration. Global configuration makes sense if you, like myself, want DNS resolutions to be more resilient. This way, if we plug an Ethernet cable into our device, DNS queries will still go to our desired servers — but over the Ethernet cable.
Instead, we can set the Wireless link as the default route-only domain, our computer would try to use the wireless card to resolve DNS even if then it would actually connect to the site via the Ethernet cable — or any other interface. It’s even worse if your wireless card isn’t connected to any network. DNS queries will fail, and the links we haven’t customized may be used instead.
This article’s follow-up is the perfect place for per-link settings.
By selecting the “global link” in our DNS settings, we can easily change our DNS settings. You can also find out more about the following: Edit the text only /etc/systemd/resolved.conf (with superuser rights) but with one important addition.
1. Remove the comment from the line “DNS=” and enter up to three DNS addresses separated by spaces after the “=”.
2. Add “~.” After the “=”., add “” (without quotes).
3. Save the file.
4. Start systemd-resolved running systemctl restart systemd-resolved Superuser.
Run Configuration to check your configuration. resolvectl. You’ll find the DNS servers that your AP has pushed onto your computer in the output under your global configuration.
It’s vital to check the servers involved in split DNS. You can fulfill DNS requests.
1. Run resolvectl to set the log level to “debug”. resolvectl log-level debug Superuser.
2. By running, flush the cache to force new DNS requests. resolvectl flush-caches.
3. Do a DNS lookup via resolvectl query domain Domains can be any domain.
4. Open the logs using Run Journalctl –u systemd-resolved.
If you are reading the logs and want to find out where systemd resolved forwarded the request, simply type in “Using DNS server”, without quotes, into the search box, and then hit “Enter”.
If you see only the servers that you have set up in your global configuration, and not the per-link server output from resolvectl, then it is working.
In my next article, I’ll walk you through the systemd-resolved DNS routing process. Also covered will be per-link DNS settings. I will conclude by debriefing my exploratory mission, and discussing why it is so difficult to find information on this seemingly basic task.
Suggestions for Topics
Would you like to see a particular tutorial featured?
Email your ideas to me, And I’ll take them into consideration for a future article.
You can also use the Reader Comments section below to give your feedback!
