Author: Paul Cobbaut
Published Date: May 24, 2015
Translation: A. Panin
Date of transfer: July 11, 2015

Chapter 4. Introduction to DNS Servers

4.3. DNS caching servers

A DNS server that does not serve the DNS zone but is connected to other name servers to cache queries is called a caching DNS server. DNS caching servers do not work with DNS zone databases that contain resource records. Instead, they connect to other name servers and cache related information.

There are two types of caching DNS servers. These are DNS servers that use DNS forwarding servers, and DNS servers that use DNS root servers.

4.3.1. A caching DNS server that does not use a forwarding server

A caching DNS server that does not use a forwarding server must get the information elsewhere. At the moment of receiving a request from a client, it contacts one of the root servers. The root server sends the caching server information about the server serving the target top-level domain, which in turn will route it to another DNS server. The latter server can either have information to answer the request, or pass information about another DNS server that can have this information. Eventually, our DNS server will get the information it needs to answer the request and send a response back to the client.

The illustration below shows the process of a client sending a request for IP address information for the linux-training.be domain name. Our caching server will connect to the root server and be redirected to the server serving the top-level domain .be. It will then connect to the server serving the top-level domain .be and will be redirected to one of the name servers in the Openminds organization. One of these nameservers (in this case, nsq.openminds.be) will respond to the request with the IP address of the server with the domain name linux-training.be. After our caching server transmits this information to the client, the client can connect to the website in question.

If you use the tcpdump sniffer to resolve this domain name, you get the following output (the first 20 characters of each line have been removed).

192.168.1.103.41251> M.ROOT-SERVERS.NET.domain: 37279% A? linux-tr \ aining.be. (46) M.ROOT-SERVERS.NET.domain> 192.168.1.103.41251: 37279- 0/11/13 (740) 192.168.1.103.65268> d.ns.dns.be.domain: 38555% A? linux-training. \ be. (46) d.ns.dns.be.domain> 192.168.1.103.65268: 38555- 0/7/5 (737) 192.168.1.103.7514> ns2.openminds.be.domain: 60888% A? linux-train \ ing.be. (46) ns2.openminds.be.domain> 192.168.1.103.7514: 60888 * - 1/0/1 A 188.93.155. \ 87 (62)

4.3.2. DNS caching server using a redirect server

A caching DNS server using a forwarding server is a DNS server that gets all the information it needs from the forwarding server (forwarder). For example, the DNS server of an Internet service provider can act as a forwarding DNS server.

The illustration above shows a DNS server on a company's local network that uses an ISP-provided DNS server as its forwarding DNS server. If the IP address of the DNS server provided by the Internet provider is 212.71.8.10, the following lines should be present in the named.conf configuration file of the company's DNS server:

Forwarders (212.71.8.10;);

In addition, you can also configure your DNS server to work with conditional forwarders. The description of a conditionally redirecting DNS server in the configuration file looks like this:

Zone "someotherdomain.local" (type forward; forward only; forwarders (10.104.42.1;););

4.3.3. Iterative or recursive query

A recursive query is a DNS query after which the client waits for a final response from the DNS server (in the illustration above, it is depicted by the bold red arrow pointing from the MacBook to the DNS server). An iterative query is a DNS query, after which the client does not expect to receive a final response from the DNS server (in the illustration above, it is depicted using three black arrows pointing from the DNS server). Iterative queries are most often done between name servers. Root name servers do not respond to recursive queries.

The DNS server that manages a DNS zone is called the authoritative DNS server for that zone. Remember that a DNS zone is just a collection of resource records.

The first authoritative DNS server for a DNS zone is called the primary DNS server. This server will operate with a read and write copy of the DNS zone database. If you need to improve data integrity in the event of failures, improve server performance, or load balancing, you can deploy another DNS server that will also manage this DNS zone. This server will be referred to as the secondary DNS server.

The secondary server obtains a copy of the DNS zone database from the primary server during a zone transfer. DNS zone data transfers are requested by secondary servers at specified time intervals. The lengths of these time slots are set as part of the SOA resource record.

You can initiate a forced update of DNS zone data using the rndc utility. The example below initiates a DNS transfer to fred.local and prints the corresponding portion of the / var / log / syslog log file.

[email protected]: / etc / bind # rndc refresh fred.local [email protected]: / etc / bind # grep fred / var / log / syslog | tail -7 | cut -c38- zone fred.local / IN: sending notifies (serial 1) received control channel command "refresh fred.local" zone fred.local / IN: Transfer started. transfer of "fred.local / IN" from 10.104.109.1 # 53: connected using 10.104.33.30 # 57367 zone fred.local / IN: transferred serial 2 transfer of "fred.local / IN" from 10.104.109.1 # 53: Transfer completed: 1 messages, 10 records, 264 bytes, 0.001 secs (264000 bytes / sec) zone fred.local / IN: sending notifies (serial 2) [email protected]: / etc / bind #

When adding a secondary DNS server to a DNS zone, you can configure that server to be the slave DNS server for the primary server. The primary DNS server will be the master DNS server in relation to the secondary server.

Most often, the primary DNS server is the master server that works with all the slave servers. Sometimes a slave server can also act as a master server for next-level slave servers. In the illustration below, the server named ns1 is the primary server, and the servers named ns2, ns3, and ns4 are secondary servers. Although ns1 is the master for ns2 and ns3, ns2 is the master for ns4.

The SOA resource record contains the refresh rate for the DNS zone named refresh. If this value is set to 30 minutes, the slave server will send requests to transfer a copy of the DNS zone data every 30 minutes. This record also contains a value for the length of the timeout period named retry. This value is used when the master server has not responded to the most recent DNS zone data transfer request. The value named expiry time sets the amount of time that the slave server can respond to requests from clients without updating the DNS zone data.

The following is an example of using the nslookup utility to read the SOA resource record data for a DNS zone (linux-training.be).

[email protected]:~# nslookup > set type = SOA > server ns1.openminds.be > linux-training.be Server: ns1.openminds.be Address: 195.47.215.14 # 53 linux-training.be origin = ns1.openminds.be mail addr = hostmaster.openminds.be serial = 2321001133 refresh = 14400 retry = 3600 expire = 604800 minimum = 3600

DNS zone data transfers are carried out only in cases of data changes in the DNS zone databases (that is, when one or more resource records are added, deleted or changed on the master server side). The slave server compares the serial number of its own copy of the SOA resource record with the version number of the SOA resource record of the corresponding master server. If the version numbers are the same, no data update is required (because no other resource records have been added, removed, or changed). In the same case, if the version number of the SOA resource record on the slave server side is less than the version number of the same record on the corresponding master server side, a DNS transfer request will be made.

Below is a snapshot of the Wireshark sniffer window with data intercepted during the DNS zone data transfer.

4.9. Full or partial transfers of DNS zones

DNS zone data transfers can be full or partial. The decision to use which mode depends on the amount of data that must be transferred to fully update the DNS zone database on the slave server. Partial transfer of zone data is preferred when the total amount of changed data is less than the size of the entire database. Full DNS zone transfers are done using the AXFR protocol, and partial DNS zone transfers are made using the IXFR protocol.

The release of WordPress 5.3 improves and expands the block editor introduced in WordPress 5.0 with a new block, more intuitive interactions, and improved accessibility. New features in the editor [...]

After nine months of development, the FFmpeg 4.2 multimedia package is available, which includes a set of applications and a collection of libraries for operations on various multimedia formats (recording, converting and [...]

New features in Linux Mint 19.2 Cinnamon

Linux Mint 19.2 is a Long Term Support release that will be supported until 2023. It comes with updated software and contains improvements and many new [...]

Linux Mint 19.2 distribution released

The release of the Linux Mint 19.2 distribution kit, the second update of the Linux Mint 19.x branch, formed on the Ubuntu 18.04 LTS package base and supported until 2023, is presented. The distribution is fully compatible [...]

New BIND service releases are available that include bug fixes and feature enhancements. New releases can be downloaded from the downloads page on the developer's site: [...]

Exim is a Message Transfer Agent (MTA) developed at the University of Cambridge for use on Unix systems connected to the Internet. It is freely available in accordance with [...]

After nearly two years of development, ZFS on Linux 0.8.0 has been released, an implementation of the ZFS file system packaged as a module for the Linux kernel. The module has been tested with Linux kernels 2.6.32 to [...]

WordPress 5.1.1 fixes site control vulnerability

The Internet Engineering Task Force (IETF), which is engaged in the development of Internet protocols and architecture, has completed the formation of an RFC for the Automatic Certificate Management Environment (ACME) protocol [...]

The non-profit certification center Let’s Encrypt, controlled by the community and providing certificates free of charge to everyone, summed up the results of the past year and spoke about plans for 2019. […]

A new version of Libreoffice has been released - Libreoffice 6.2

DNS (Domain Name System) is an important and rather difficult to configure component necessary for the operation of websites and servers. Many users turn to DNS servers provided by their hosting provider, however, having their own DNS servers has some advantages.

In this tutorial, you will learn how to install Bind9 and configure it as a caching or forwarding DNS server on an Ubuntu 14.04 server.

Requirements

• Understanding the basic types of DNS servers. For details, see.
• Two machines, of which at least one is running Ubuntu 14.04. The first machine will be configured as a client (IP address 192.0.2.100) and the second as a DNS server (192.0.2.1).

You will learn how to configure a client machine to send queries through a DNS server.

Caching DNS Server

Servers of this type are also called qualifiers because they process recursive queries and, in general, can perform DNS lookups on other servers.

When the caching DNS server monitors the response to the client's request, it returns the response to the client and also stores it in the cache for the time allowed by the TTL of the corresponding DNS records. The cache can then be used as a source of responses to subsequent requests to speed up the overall request processing time.

Almost all DNS servers in your network configuration will be caching. A caching DNS server is a good choice for many situations. If you don't want to rely on your hosting provider's DNS servers or other public DNS servers, set up your own caching DNS server. The shorter the distance from the DNS server to the client machines, the shorter the service time for DNS queries.

Forwarding DNS Server

From a client's perspective, a redirecting DNS server will look almost identical to a caching server, but the mechanisms and workload are completely different.

A redirecting DNS server has the same benefits as a caching server. However, it doesn't actually execute any recursive query. Instead, it redirects all requests to an external permissive server and then caches the results for subsequent requests.

This allows the redirect server to serve requests from its cache without processing recursive requests. Thus, this server only handles single requests (redirected client requests) and not the entire recursion procedure. This can be advantageous in environments where external bandwidth is limited, where caching servers need to be changed frequently, and in situations where local requests need to be redirected to one server and external requests to another.

Step 1 - Installing Bind on a DNS Server

The Bind package can be found in the official Ubuntu repository. Update package index and install Bind using apt manager. You also need to install a couple of dependencies.

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

After that, you can start configuring the server. You can use the caching server configuration as a template for configuring a forwarding server, so you need to configure a caching DNS server first.

Step 2 - configuring a caching DNS server

First, you need to configure Bind as a caching DNS server. This configuration will cause the server to recursively look for answers to client queries on other DNS servers. It will sequentially poll all relevant DNS servers until it finds an answer.

Bind configuration files are stored in the / etc / bind directory.

Most of the files do not need to be edited. The main configuration file is named named.conf (named and bind are two names for the same application). This file refers to the named.conf.options, named.conf.local and named.conf.default-zones files.

To configure a caching DNS server, you only need to edit named.conf.options.

sudo nano named.conf.options

This file looks like this (comments omitted for simplicity):

options (
directory "/ var / cache / bind";
dnssec-validation auto;

listen-on-v6 (any;);
};

To set up a caching server, you need to create an access control list, or ACL.

You need to protect the DNS server that processes recursive queries from attackers. DNS amplification attacks are especially dangerous because they can involve the server in distributed denial of service attacks.

DNS amplification attacks are one way to shut down servers and sites. To do this, attackers try to find public DNS servers that process recursive queries. They spoof the victim's IP address and send a request that will return a very voluminous response to the DNS server. In this case, the DNS server returns too much data to the victim's server in response to a small request, increasing the attacker's available bandwidth.

Hosting a public recursive DNS server requires careful configuration and administration. To prevent the server from being compromised, configure a list of IP addresses or network ranges that the server can trust.

Before the options block, add an acl block. Create a label for the ACL group (in this tutorial, the group is called goodclients).

acl goodclients (
};
options (
. . .

In this block, list the IP addresses or networks that will have access to this DNS server. Since the server and client are running on a / 24 subnet, you can restrict access to that subnet. You also need to unblock localhost and localnets, which connect automatically.

acl goodclients (
192.0.2.0/24;
localhost;
localnets;
};
options (
. . .

You now have a secure client ACL. You can start configuring request resolution in the options block. Add the following lines to it:

options (
directory "/ var / cache / bind";
recursion yes;

. . .

The options block explicitly enables recursion and then configures the allow-query parameter to use the ACL. You can also use another parameter to reference an ACL group, such as allow-recursion. With recursion enabled, allow-recursion will define a list of clients that can use recursive services.

However, if the allow-recursion parameter is not set, Bind falls back to the allow-query-cache list, then to the allow-query list, and finally to the default localnets and localhost lists. Since we are only configuring the caching server (it does not have its own zones and does not forward requests), the allow-query list will always only apply to recursion. This is the most common way to define ACLs.

Save and close the file.

These are all the settings that need to be added to the caching DNS server configuration file.

Note: If you only want to use this type of DNS, go to check the configurations, restart the service and configure your client.

Step 3 - Setting Up a Forward DNS Server

If a DNS forwarding server is more appropriate for your infrastructure, you may want to tweak the setting slightly.

At the moment the named.conf.options file looks like this:

acl goodclients (
192.0.2.0/24;
localhost;
localnets;
};
options (
directory "/ var / cache / bind";
recursion yes;
allow-query (goodclients;);
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 (any;);
};

You can use the same ACL to restrict the DNS server to a specific list of clients. However, this requires some configuration changes so that the server no longer tries to execute recursive queries.

Do not change recursion to no. The redirect server does support recursive services. To set up a redirect server, you need to create a list of caching servers to which it will forward requests.

This is done in the options () block. First, you need to create a new forwarders block in it, which will store the IP addresses of the recursive name servers to which you want to redirect requests. In this case, these will be Google's DNS servers (8.8.8.8 and 8.8.4.4):

. . .
options (
directory "/ var / cache / bind";
recursion yes;
allow-query (goodclients;);
forwarders (

8.8.8.8;

8.8.4.4;

};
. . .

As a result, the configuration looks like this:

acl goodclients (
192.0.2.0/24;
localhost;
localnets;
};
options (
directory "/ var / cache / bind";
recursion yes;
allow-query (goodclients;);
forwarders (
8.8.8.8;
8.8.4.4;
};
forward only;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 (any;);
};

The last change concerns the dnssec parameter. With the current configuration and depending on the settings of the DNS servers to which requests are redirected, the following errors may appear in the logs:

Jun 25 15:03:29 cache named: error (chase DS servers) resolving "in-addr.arpa/DS/IN": 8.8.8.8 # 53
Jun 25 15:03:29 cache named: error (no valid DS) resolving "111.111.111.111.in-addr.arpa/PTR/IN": 8.8.4.4 # 53

To avoid them, change the dnssec-validation parameter to yes and explicitly enable dnssec.

. . .
forward only;
dnssec-enable yes;
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
. . .

Save and close the file. The forwarding DNS server is now configured.

Step 4: Checking the Settings and Restarting Bind

Now you need to make sure that the settings are working as expected.

To check the syntax of the config files, enter:

sudo named-checkconf

If there are no errors in the files, the command line will not display any output.

If you receive an error, correct it and check again.

You can then restart the Bind daemon to update the settings.

sudo service bind9 restart

Then you need to check the server logs. Run the command on the server:

sudo tail -f / var / log / syslog

Now open a new terminal and proceed with configuring the client machine.

5: client setup

Log in to the client machine. Make sure the client was listed in the ACL group of the configured DNS server. Otherwise, the DNS server will refuse to serve this client's requests.

Edit the /etc/resolv.conf file to point the server to the nameserver.

Changes made here will only persist until reboot, which is great for testing. If you are satisfied with the results of the test setup, you can make these settings permanent.

Open the file with sudo in a text editor:

sudo nano /etc/resolv.conf

The file should list the DNS servers that will be used to resolve requests. To do this, use the nameserver directive. Comment out all the current entries and add a nameserver line pointing to your DNS server:

nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

Save and close the file.

You can now send a test request to verify that it resolves correctly.

You can use ping to do this:

ping -c 1 google.com
PING google.com (173.194.33.1) 56 (84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq = 1 ttl = 55 time = 63.8 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min / avg / max / mdev = 63.807 / 63.807 / 63.807 / 0.000 ms

Every year the speed of the Internet - both the last mile and the main channels - is getting higher. Only one thing is invariable - latency has already run up against physical limitations: the speed of light in fiber is about 200 thousand kilometers per second, and, accordingly, faster than ~ 150ms a response from the server across the Atlantic Ocean will not be received in the foreseeable future (although of course there are delights, like fiber with air core or radio relay communication, but this is hardly available to mere mortals).

When we try, for example, from Russia to open a website located in the USA (its NS servers are probably in the same place), and the domain was not found in the DNS cache of your provider, then we will have to wait a long time even on a gigabit Internet, perhaps even a whole second: while we across the ocean we will receive the names of the NS servers of the domain, while we cut their IP, while we will send and receive the actual DNS request itself ...

A couple of years ago, Google started its own public DNS servers, and to agitate the transition to them, they developed the NameBench utility, which runs DNS tests on your surfing history and shows how much Google DNS is faster than your ISP's DNS server.

But I managed to make my own DNS server, which works faster than Google Public DNS, and in this short note I want to share the results.

PDNSD

pdnsd- caching DNS proxy. In addition to the banal caching of DNS requests (with the ability to rigidly set the minimum TTL - it may be necessary on a very bad Internet), he is able to send a request simultaneously to several "parent" DNS servers, and give the client the first response returned.

It is the inclusion of parallel polling that gives us the main advantage in speed. since when the result is found in the cache of any of the providers, we get the result very quickly, and we do not expect full and slow resolution if the first provider does not have a response in the cache.

It is installed in Ubuntu - the banal apt-get.

A couple of points in the config

global (perm_cache = 10240; // Maximum cache size in kilobytes. // By default it was 1024, all records were not interfered with me. cache_dir = "/ var / cache / pdnsd"; [...] min_ttl = 60m; // The minimum time to save an entry in the cache. // Even if the TTL arrives less than 60 minutes, it will be 60 minutes max_ttl = 1w; // The maximum time to save an entry in the cache neg_ttl = 5m; // Time to cache negative responses (i.e. if the domain is not found) [..] par_queries = 3; // The number of simultaneously polled "parent" DNS servers) server (label = "main"; ip = 85.21.192.5 // There are 4 servers, if the first 3 do not respond, a request will be sent to 4 -th, 213.234.192.7 // The first 2 servers are the server of your provider, and of some neighboring one, 8.8.4.4 // This is Google Public DNS - they have everything rare cached and they resolve quickly, 8.8.8.8; [.. ])

In principle, caching can be made less aggressive (min_ttl = 1m for example), but during the year of work there were no special problems. In case of problems - if you wish, you can wipe one entry from the cache:
sudo pdnsd-ctl record 3.14.by delete or all at once:
sudo pdnsd-ctl empty-cache

Test results in NameBench

We see that for 50% of requests, we get a response in less than 10ms, for 85% faster than Google Public DNS, and then the results naturally coincide with Google.

Based on the test results, NameBench happily informs us:

8.8.8.8 Slower replica of SYS-192.167.0.98 8.8.4.4 Slower replica of SYS-192.167.0.98

Thus, a smart caching DNS proxy with parallel requests can speed up even 100-megabit Internet. And for slow (radio) links with high latency and packet loss, the difference can be like between heaven and earth.