Linux DNS Tuning for Performance and Resilience

Optimal DNS Configuration on Linux

We often don’t realize the importance of DNS in our infrastructure. Yet the impact when things go (slightly) wrong is huge. Time to have a good look at improving our DNS configuration. The goal is simple: improve performance, and make it more resilient to issues and attacks.

How DNS Resolving Works

When your Linux system needs to know the IP address of a particular host, it will use gethostbyname(3) function. This will use the nsswitch configuration stored in /etc/nsswitch.conf. For the related hosts line, it will determine how to do resolving.

Screenshot of /etc/nsswitch.conf file for DNS resolving

The order specified, determines how resolving will tried for each lookup

It is common to find the usage of the word hosts, which refers to the /etc/hosts file, a static list to be configured by the system administrator. It is then often followed by the word dns, which specificies it can use DNS queries to get the answer. Here our journey begins to query nameservers. To know which nameservers should be used, the /etc/resolv.conf file is consulted. Each nameserver is prepended with the word nameserver, followed by the IPv4 or IPV6 address of a DNS resolver.

Users who use systemd, might actually have a “resolve” in their nsswitch.conf configuration, pointing to the systemd-resolved service. It performs cache and aggregation of DNS related settings.


Timeouts and Settings

Most Linux administrators have a bare configuration in /etc/resolv.conf. To counter the impact of an unreachable DNS system, we can do a few things:Define Multiple Name Servers

Define Multiple Name Servers

The easiest option is adding more name servers. If you have defined just one, you are fully relying on the availability of that particular system. Also when that particular name server has a higher load of queries to process, your services will be affected.

Note: Most Linux distributions use /etc/resolv.conf directly. Some use /etc/resolvconf.conf, or/etc/systemd/resolved.conf when using systemd-resolvd. So check carefully what your system is using before making adjustments.

Limit Timeout

In the resolving configuration we can change the timeout of DNS queries. If we don’t get an answer within a specified amount of time, we continue using the next system. By default this can be as long as 30 seconds! So change your configuration file and set it to a much lower time.

options timeout:1

Randomize Usage

It doesn’t always make sense if all systems use the same system. The resolver allows you to rotate over DNS systems.

options rotate

Note: DNS servers love caching and a lot of requests. The more they are used, the better they perform. So before enabling this option, perform some testing to see if it makes sense for your situation.


Local Caching for Speed

The quickest network packet is the one which does not need to travel the network. For most systems a lot of repetition is involved in the tasks it is doing. This also applies for DNS requests. Very often a request will be made for a host we recently already contacted. As Linux systems do not cache DNS requests by default, a lot of traffic is sent to the network, for nothing.

We can counter the repetition of requests towards our name servers, by using caching. These tools can run locally, and cache both positive and negative matches. In other words, it has a different timer for both types. If a name or IP address can’t be found, it may be caching that result shorter (or longer). This improves the caching table and hit rates on the cache, while limiting the bad impact of a “miss”.

Local Cacher: dnsmasq

One of the options to consider, is the tool dnsmasq. This set of tools helps for smaller networks, but is also a great candidate to run just a local DNS cacher. After installation, configure it so that it just does DNS resolving. Then provide it with some name servers, so it can externally request the answers. Last step is pointing your normal resolver configuration to, so dnsmasq will be the middle man to deal with DNS requests.



Related Packages

  • Arch Linux – pacman -Ss dnsutils


Related utilities

These utilities might be handy during configuration, testing, and troubleshooting.

  • drill
  • dig
  • host
Automate security audits with Lynis and Lynis Enterprise
Lynis Enterprise screenshot to help with system hardening

This blog post is part of our Linux security series to get Linux (and Unix-based) systems more secure.

Daily security checks

Want to go to the next level of security scanning and system hardening? Start with automated security scans for Linux: Lynis and Lynis Enterprise.

Automate Scanning »

One comment

  • In the absence of a local cache, DNS caching is done at the process level, but most linux distributions ship with nscd which provides a shared cache for all NS lookups – not just DNS. Note that both nscd and dnsmasq don’t play nicely with sssd (LDAP lookup caching).


Leave a Reply

Your email address will not be published. Required fields are marked *