Saturday, May 21, 2016

Linux DNS Tuning for Performance and Resilience

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 127.0.0.1, so dnsmasq will be the middle man to deal with DNS requests.

No comments:

Post a Comment