随着 Linux 的不断发展壮大，涌现出了各种各样的 DNS 自动管理程序，它们都想要直接获得 /etc/resolv.conf 的控制权，有些人欣然接受，有些人则无法接受。如果你是无法接受的那一方，那么请继续往下看，我会教你如何识别出是哪些程序在控制你的 /etc/resolv.conf 文件，以及如何夺回控制权。
Resolve the battle for control over your DNS settings in Debian/Ubuntu
There are a few daemons all wanting to control your DNS in Debian and Ubuntu. However, it’s better to resolve the conflict and leave one daemon in charge instead of having them battle it out on their own.
The Debian 8.0 “Jessie” network installer installs some packages that leave you with broken domain name resolution in some situations. Ubuntu 15.04 “Vivid Vervet” also does some strange things out of the box. Both leaving Network Manager with a hard time controlling the systems’ DNS settings. Let us correct this by putting Network Manager back in control.
Update (): This article still applies if you’ve updated from an older version of Debian or Ubuntu. However, I’ve since published How to take back control of /etc/resolv.conf on Linux which provides more up to date advice and help in more similar situations. I recommend you read that article instead.
One assumption before leaving all of your system’s networking in Network Manager’s capable hands: You want your network to always configure itself automatically with minimal hassle at any location/Wi-Fi network. Read on if this sounds like your use case.
Some symptoms indicating that you may have DNS resolution problems:
Frequent unreliable and slow domain name resolution in browsers and other programs that seemingly correct themselves after some seconds
It takes a long time for DNS to start working after connecting to a new network
Only IPv6 resolution working when IPv4 resolution isn’t working, and visa-versa
/etc/resolv.conf is rewritten every few seconds
/etc/resolv.conf is missing the “# Generated by NetworkManager” header at the top
Check that you’re using Network Manager. In most situations on most distributions this will be the case:
Run service NetworkManager status to confirm that Network Manager is running
Run head /etc/resolv.conf and look for:
# Generated by NetworkManager
If the header is missing, continue with the below instructions. If it’s there then this post doesn’t hold a solution to your network problem answer. Sorry, but you need to do more research elsewhere to identify your problem.
Run service rdnssd status to see if rdnssd is also running
Run service resolvconf status to see if resolvconf is also running
If two or more services are running we may have successfully identified the problem. Network Manager already covers the functionality provided by rdnssd and resolvconf, so you can go ahead and remove rdnssd and resolvconf.
Run apt-get purge rdnssd to remove it from your system
Run apt-get purge resolvconf to remove it from your system
Run service NetworkManager restart to stop and start the Network Manager daemon so it can find the changes
Wait a minute – or disconnect and reconnect your network – and then repeat step 2 to verify that Network Manager is back in control over your name resolution.
How did this problem arise in the first place? According to Debian bug #740998, the Debian network installer (for Debian 8.0 “Jessie”) will install the troublesome rdnssd program if the network installer sees an IPv6 environment. The package isn’t required on systems managed by Network Manager. Debian 9.0 “Sketch” – currently in the testing release channel – has resolved the problem by making the two packages conflict with each other, preventing them from being installed at the same time.
As for resolvconf, it’s a bit harder to track down how that gets installed. I suspect it’s the network installer again but haven’t confirmed it. Although resolvconf alone can almost manage your /etc/resolv.conf file, it will interfere with Network Manager. resolvconf will not setup IPv6 name servers in all situations
Ubuntu extra
Ubuntu always installs resolvconf. If you’re running Network Manager (see step 2), you can remove it. In addition to resolvconf, you also have to deal with dnsmasq in the mix on Ubuntu. dnsmasq is a caching system meant for situations when DNS is broken. As a side effect, it interferes with DNS and gets in the way of IPv6 DNS servers. Assuming you aren’t on the Moon or the International Space Station, you don’t need a separate system-level DNS caching daemon and can remove it:
Remove (or comment out) the below line from /etc/NetworkManager/NetworkManager.conf:
dns=dnsmasq
Run service NetworkManager restart
Wait a minute – or disconnect and reconnect your network – and then repeat step 2 to verify that Network Manager is back in control over your name resolution.
If your DNS still is broken, you can start blaming your router or internet service provider at this point. Check to see if you also have issues with other machines on the same network. Debian and Ubuntu’s conflicting oddities should have been neutralized, at least.
from https://www.ctrl.blog/entry/how-to-debian-dns-resolv.html
----------------------------
How to take back control of /etc/resolv.conf on Linux
Several DNS-related programs want to automatically manage the DNS name server and resolution configuration file at /etc/resolv.conf. In some situations, you may want to manage this file yourself. Here is how you identify which programs are automatically managing this file on your Linux distribution, and how you can take back manual control of the file.
There are quite a few different tools that fight to control a Linux system’s DNS resolution configuration file /etc/resolv.conf including netconfig, NetworkManager, resolvconf, rdnssd, and systemd-resolved.
Except for NetworkManager, most of these tools are oblivious to each other’s presence which can cause DNS resolution problems. If you simply try to make changes to the file without disabling the managing program, it may overwrite your changes after a few minutes or revert them when you reboot the system.
Identifying which utility currently controls your /etc/resolv.conf
The following command will read the first few lines the resolv.conf file, which should include a comment identifying any programs that have automatically taken over management over the file.
head /etc/resolv.conf
Some utilities don’t include a comment in the resolv.conf file, but you can identify these programs by checking for symbolic links with the following command:
ls -l /etc/resolv.conf
As a last resort, you can check your init system to see if any of the programs mentioned in this article are running. If you can’t identify any management programs using these methods, chances are you should be in control over the resolv.conf file and your system’s DNS resolution.
The next sections will teach you how to disable various programs that automatically manage resolv.conf.
Opting-out of NetworkManager
NetworkManager is by far the most common auto-configuration tool for the entire networking stack including DNS resolution. It’s responsible for /etc/resolv.conf on many popular Linux distributions including Debian and Fedora.
After you’ve disabled all other programs that try to manage resolv.conf, you may also discover that NetworkManager will jump in to fill the job — as happens on Ubuntu 16.10 and later.
Set the dns option in the main configuration section to none to disable DNS handling in NetworkManager. The below commands sets this option in a new conf.d/no-dns.conf configuration file, restarts the NetworkManager service, and deletes the NetworkManager-generated resolv.conf file.
If you discover that NetworkManager is still managing your resolv.conf, then you may have a configuration conflict (usually caused by dnsmasq). Recursively search through your NetworkManager configuration to discover any conflicts.
grep -ir /etc/NetworkManager/
Refer to the last section of this article for instructions on recreating a /etc/resolv.conf file with manual configuration
Opting-out of netconfig
You’ll encounter netconfig on openSUSE, SUSE, and derivative distributions.
You can disable netconfig’s handling of /etc/resolv.conf by disabling the NETCONFIG_DNS_POLICY option in /etc/sysconfig/network/config to an empty string as shown below.
NETCONFIG_DNS_POLICY=""
Afterward, you should delete the netconfig-generated resolv.conf file, and reboot the system.
rm /etc/resolv.conf
reboot
Refer to the last section of this article for instructions on recreating a /etc/resolv.conf file with manual configuration.
Disabling resolvconf and rdnssd
If you installed Debian 8.0 or Ubuntu 15.04 with an active IPv6 connection and have upgraded your system, you may end up with both resolvconf and rdnssd fighting each other for control over resolv.conf. Both services want to control the file, which may lead to intermittent DNS resolution outages as the two services overwrite each other’s changes every few milliseconds.
You can disable both services with the following commands. You can just go ahead and run both commands, as nothing unexpected should happen if disable an already disabled service.
You may also need to follow the instructions in the section on NetworkManager, as it may step in automatically to handle the resolv.conf file after you remove it.
Disabling systemd-resolved
If you’re running Ubuntu 16.10 or later, your DNS resolution will be managed by the systemd-resolved service. You can disable this service without any further ado using the following commands.
You may also need to follow the instructions in the section on NetworkManager, as it may step in automatically to handle the resolv.conf file after you remove it.
Recreating /etc/resolv.conf
By this point, you shouldn’t have anything automatically creating the /etc/resolv.conf file anymore. Please begin again from the top of this article to troubleshoot if the file still exists on your system. You now need to create a world-readable (permission 644) resolv.conf and add some nameservers to it.
The below shows two examples that set IPv4 and IPv6 nameservers. The first example uses the free security-hardened public DNS service from Quad9, and the second example assumes there’s a DNS server like Knot Resolver or dnsmasq running on your local device. Both examples are set up for dual-stack IPv4/6 routing for improved reliance and compatibility.
You generally don’t need to restart any network management services for the changes to take effect. However, some system services or programs may have entered a failed state while DNS resolution was disabled. Do a quick reboot to kick-start them unless you want to manually double-check that all running services and programs have recovered.
You may want to configure additional parameters for the resolv.conf file. See the man 5 resolv.conf manual for details on other domain resolution configuration options.
This article is meant to dispel an internet myth that says systemd-resolved is pointless and isn’t doing you any good. systemd-resolved is almost guaranteed to be useful for any Linux device that accesses the internet and can optionally be configured to boost your privacy and security.
First things first:
How to tell if your system is already using systemd-resolved?
Ubuntu 16.04 and later as well as any derivative Linux distributions use systemd-resolved by default. If you’re not sure whether you’re using systemd-resolved or not then we can quickly establish that by running the following command:
systemctl -n0 status systemd-resolved && \
head -n1 /etc/resolv.conf
The command should return: “# This file is managed by man:systemd-resolved(8). Do not edit.” This means that your system is indeed using systemd-resolved.
If you do want to edit this file, then the configuration example in the bottom of this article will show you how to set the DNS server to something else. You can also read How to take back control of /etc/resolv.conf if you want to configure this file manually.
Improving DNS responsiveness with caching
systemd-resolved caches DNS query responses by default. This means that it can quickly respond to repeated queries for the same domains even when they come from different programs on your system. But is this useful to you on your system?
Before performing the next step, either let your system do its thing for a little while or otherwise use the system as normal for some minutes. Afterward, you can run the following command to determine whether systemd-resolved’s DNS cache is doing you any good:
resolvectl statistics
This will return some statistics that should help prove the worth of systemd-resolved. The cache can store up to 4096 DNS responses for up to 2 hours, so don’t expect to see a massive number listed as the current cache size. You need not be afraid that the cache will bog down your system memory either. A quick calculation shows that the DNS cache can’t grow to more than 420 kB when used to its fullest.
What is more interesting is the next two numbers: cache hits and cache misses. The last number is the number of DNS queries that had to be forwarded to an external recursive DNS server, whereas the first number is the number of queries that were resolved immediately without the need to reach out to an external server. Every cache hit is an instance where systemd-resolved made your system just a little faster.
Your cache hit ratio will vary greatly depending on how you use your system and the software you use. E.g. you’re more likely to see a higher cache hit if you use GNOME Web or Chrome and less likely when using Firefox.
Firefox’s has its own internal one–two minutes DNS cache that means its cache will handle a lot of queries that would be handled by systemd-resolved if you’re using a browser with a shorter internal DNS cache (anything built on Chromium) or no internal DNS cache (anything built on WebKit).
Enhancing DNS privacy and security
DNS queries and responses have traditionally been unencrypted, but more and more resolvers now support DNS over an encrypted TLS connection (DNS over TLS). TLS can help ensure that no parties between the DNS server and the resolver can see or modify the DNS responses.
This means that someone on the same public network at a café can’t see what you’re doing through your DNS request, and also means that your internet service provider nor your local government can see into your traffic either.
systemd-resolved only supports opportunistic DNS over an encrypted channel. Opportunistic here means that it will reach out and connect over TLS when available, but it won’t verify that it’s connecting to the correct server; make it susceptible to the attacker-in-the-middle interception as described in Actually secure DNS over TLS in Unbound. Attempting to use encryption is still a step up from no encryption at all, however!
You can enable this option (make sure you use a DNS provider that supports DNS over TLS and DNSSEC) by adding the following options to the /etc/systemd/resolved.conf file:
[Resolve]
# Use Quad9.net DNS, and Cloudflare DNS.
# Both supports DNS over TLS and DNSSEC,
# and promises not to log DNS queries.
DNS=2620:fe::fe 9.9.9.9 \
2606:4700:4700::1111 1.1.1.1
FallbackDNS=2620:fe::9 149.112.112.112 \
2606:4700:4700::1001 1.0.0.1
# Attempt to use DNS over TLS.
DNSOverTLS=opportunistic
# Enforce DNSSEC validation.
DNSSEC=true
You must restart the systemd-resolved service (the command is systemctl restart systemd-resolved.service) for these options to take effect. You can learn more details about the available configuration options in the resolved.conf manual.
The statistics command, shown above, also output some statistics over the effects of DNSSEC enforcement. DNSSEC helps prevent a potential attacker from modifying your DNS responses, but systemd-resolved doesn’t enforce this by default. The intricacies of DNSSEC is out of scope for this article, however.
When you need strong security and privacy, then you’ll need to set up a more capable DNS resolver than systemd-resolved such as Knot Resolver or Unbound. These more fully features resolvers also support caching more DNS query responses and for much longer than systemd-resolved.
No comments:
Post a Comment