The purpose of DNS is to translate domain names that are easy for humans to remember into IP addresses that computers can understand, a process called name resolution.
What will installing our own caching DNS server give us?!
This will speed up the response of sites a little + Linux does not take NetBios names very well, but sometimes you have to find computers or printers within a local network, but you want to do it by name.
Remembering IP addresses is not convenient, and constantly looking at the log of the DHCP server is also not our method. It is for such cases that you need DNS on the local network.
The installation of the bind9 package itself is not difficult; glitches usually arise at the stage of its configuration, because After easily readable system configuration files, a person is faced with an incomprehensible syntax, which, by the way, is very similar to the S programming language. the server will work inside the local network, it makes no sense to transfer it to a chroot environment and the entire setup takes very little time.
With this, the lyrical part can be completed, let’s move on to installation and configuration.
Let's install the Bind9 DNS server:
sudo apt-get install bind9
After completion, downloading and installation, we need to edit its configuration file:
sudo nano /etc/bind/named.conf.options
We find the section, it is located at the very beginning of the configuration file, except for it there is nothing else there...

Options ( directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http: //www.kb.cert.org/vuls/id/800113 // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0"s placeholder. // forwarders ( // 0.0.0.0; // ); auth-nxdomain no; # conform to RFC1035 listen-on-v6 ( any; ); );

The forwarders section is responsible for where the DNS request for name resolution will be sent if it is not in its own database. Lately I have not been happy at all, the work of these servers with the provider is why you can connect third-party ones, for example Google ones, it is very easy to remember the IP 8.8.8.8, I will use its example to configure it, but no one bothers you to use the ones you like best.

We edit the section, first you need to remove comments from it and add third-party DNS, if there is a need to add several servers, for example, in case the Google server cannot withstand your requests and breaks down :), then the IP of other servers can be written in a column, then you can achieve greater fault tolerance.
forwarders (8.8.8.8; 193.58.251.251; //Russian DNS service -SkyDNS);
In this section it is better to enter the IP of the server that you have specified in the file /etc/resolv.conf or enter it in the section nameserver this IP
Save the changes and exit
Restart the server and check
We type in the command line nslookup mail.ru
Should output:

Non-authoritative answer: Name: mail.ru Addresses: 94.100.191.202
This suggests that our server is not the main one in servicing this zone (mail.ru), but added requests to the cache!
Now we need to create a DNS zone for our network so that machines can find various network services - there could be, for example, network printers, they can be either independent or shared on other workstations.
Our zone can be called orgname – i.e. Name of the organization.
First of all, we create a zone, for this we will edit named.conf.local

Sudo nano /etc/bind/named.conf.local
and add the following to it:
zone "orgname" ( type master; file "/etc/bind/db.orgname"; );
Save and exit
Now we need to create a zone configuration file
sudo nano /etc/bind/db.orgname
and paste the following into it:
(Please pay close attention to the syntax of the configuration file, even the dots have meaning)

@ IN SOA orgname. root.orgname. (20101015 4h; update time -4 hours 1h; repeat every hour 1w; how long to store information -1 week 1d); TTL (time to live) of record - 1 day @ IN NS orgname. ; nameservername @ IN A 192.168.10.1 ; A - record - the IP address of our DNS server that serves this zone, @ means that this is the root zone. * IN CNAME @ printer IN A 192.168.10.25 ; You can create a DNS record for a network printer located at 192.168.10.25

Now, when adding a new network device, you need to do 2 things:
1) Reserve an IP address on a DHCP server, you can read about how to do this in the article -
2) Create a DNS zone for this IP, type devicename IN A XXX.XXX.XXX.XXX. Where: devicename is the network name of the device; XXX.XXX.XXX.XXX is its IP address which is reserved on the DHCP server.

Now we need to edit the resolv.conf file

Sudo nano /etc/resolv.conf

And enter there:

Nameserver 127.0.0.1

Everything that was there could be commented out by putting #

Restarting the server

This was done so that the server searches for everything in its own database, and only then BIND will redirect requests to the server 8.8.8.8 IP whose IP is included in the directive forwarders.

Now you can check the functionality:

If testing takes place under Windows:
ping devicename.orgname

If we test from Linux:
ping devicename.orgname -c 4
Pings should go to the IP that you specified instead of XXX.XXX.XXX.XXX

This completes the DNS server setup.

Author: Paul Cobbaut
Published date: May 24, 2015
Translation: A. Panin
Translation date: July 11, 2015

Chapter 4: Introduction to DNS Servers

4.3. Caching DNS servers

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

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

4.3.1. Caching DNS server that does not use a forwarder

A caching DNS server that does not use a forwarder must obtain information from somewhere else. When a request is received from a client, it contacts one of the root servers. The root server passes information about the server serving the target top-level domain to the caching server, which in turn will route it to another DNS server. The last server may either have the information to respond to the request, or it may pass on information about another DNS server that may have that information. Eventually our DNS server will receive the information it needs to answer the request and send a response to the client.

The illustration below shows the process of a client sending a request for IP address information for the domain name linux-training.be. Our caching server will connect to the root server and will be redirected to the server serving the .be top-level domain. It will then connect to the server serving the .be top-level domain and be redirected to one of the Openminds organization's name servers. 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. Once our caching server passes this information to the client, the client will be able to connect to the website in question.

When using the tcpdump sniffer to resolve a given domain name, you can 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. Caching DNS server using a forwarder server

A caching DNS server that uses a forwarder is a DNS server that gets all the necessary information from the forwarder. For example, the DNS server of an Internet service provider can act as a redirecting DNS server.

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

Forwarders ( 212.71.8.10; );

Additionally, you can also configure your DNS server to work with conditional forwarders. The description of the conditional forwarder DNS server in the configuration file is as follows:

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

4.3.3. Iterative or recursive query

A recursive request is a DNS request, after sending which the client expects to receive a final response from the DNS server (in the illustration above, it is depicted with a bold red arrow directed from the MacBook to the DNS server). An iterative request is a DNS request, after sending which the client does not expect to receive a final response from the DNS server (in the illustration above it is depicted with three black arrows directed from the DNS server). Iterative queries are most often carried out between name servers. Root nameservers 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 copy of the DNS zone database that is both readable and writable. If you need to increase data security in case of failures, improve server performance or load balancing, you can commission another DNS server, which will also manage this DNS zone. This server will be called the secondary DNS server.

The secondary server receives a copy of the DNS zone database from the primary server during the DNS zone transfer process. Requests for DNS zone data transfers are sent by secondary servers at certain time intervals. The duration of these time intervals is set within the SOA resource record.

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

root@debian7:/etc/bind# rndc refresh fred.local root@debian7:/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) root@debian7:/etc/bind#

When adding a secondary DNS server to a DNS zone, you can configure the server to be a slave DNS server to 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 communicates with all the slave servers. Sometimes a slave server can also be the master server for slave servers at the next level. In the illustration below, the server named ns1 is the primary server, and the servers named ns2, ns3 and ns4 are the secondary servers. Although the master server for servers named ns2 and ns3 is ns1, the master server for ns4 is ns2.

The SOA resource record contains a DNS zone data refresh rate value 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 entry also contains a value for the length of the timeout period named retry . This value is used if the master server does not respond to the last DNS zone data transfer request. A value named expiry time sets the period of time that the slave server can respond to requests from clients without updating DNS zone data.

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

Root@debian6:~# 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 occur only when data in the DNS zone databases changes (that is, when one or more master server-side resource records are added, deleted, or modified). The slave server compares the version 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 match, 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 side of the slave server is less than the version number of the same record on the side of the corresponding master server, a DNS zone data 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 zone data

The transfer of DNS zone data can be either complete or partial. The decision to use one mode or another 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 preferable when the total amount of changed data is less than the size of the entire database. Full DNS zone data transfers are carried out using the AXFR protocol, and partial DNS zone data transfers are carried out 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 interaction, 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

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

New BIND service releases are available that contain bug fixes and feature improvements. New releases can be downloaded from the downloads page on the developer's website: […]

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 almost two years of development, the release of ZFS on Linux 0.8.0 is presented, an implementation of the ZFS file system, designed as a module for the Linux kernel. The module has been tested with Linux kernels from 2.6.32 to […]

WordPress 5.1.1 fixes a vulnerability that allows you to take control of your site

The IETF (Internet Engineering Task Force), which develops Internet protocols and architecture, has completed an RFC for the ACME (Automatic Certificate Management Environment) protocol […]

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

A new version of Libreoffice has been released – Libreoffice 6.2

To speed up web browsing, the Windows operating system caches DNS server responses. Immediately after the response to determine the number from the DNS server arrives, Windows automatically places this address in local storage. When a browser requests a URL, Windows first looks for it in storage, and if it finds it, it immediately returns the result without contacting the ISP's DNS servers. Local cache increases speed and saves traffic.

Clearing the local DNS cache

If, when storing the address in local storage, the information is damaged or the IP address changes, the browser will not be able to open the site. This doesn't happen very often. Luckily, there is a way to clear your local cache to instantly resolve the issue.

Windows OS has a tool ipconfig, which has the option /flushdns to clear all cached entries. If you need to clear the local cache, then in the command line window ( Start — Programs(All programs) - Standard — Command line) you should enter the command ipconfig /flushdns and press the Enter key.

To view all DNS records in local storage, you can use the option /displaydns teams ipconfig. To do this, enter the command in the command line window ipconfig / displaydns and press the Enter key. All cached DNS response records will appear in the window.

Setting cache retention time

Typically, Windows stores addresses for no more than 86,400 seconds (1 day), but the storage time can be limited to another limit. To do this, you need to open the registry editor (in the command line, enter the regedit command and press Enter). In the left pane of the editor there is a tree of registry keys, which is similar to folders on a hard drive. In this tree, by clicking on the corresponding folder expansion icons (plus sign), you should open the path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters, then place the cursor on the folder in this tree Parameters. The contents of this key (folder) will appear in the right pane of the registry editor.

DWORD value of the parameter MaxCacheTtl specifies the time limits for storing responses in seconds. It can be changed to any other. If the parameter MaxCacheTtl no, that means the standard limit is set to 86400 seconds. To change it, you need to create a parameter MaxCacheTtl type DWORD with a value equal to the required limit. Parameter MaxCacheTtl It limits only the storage time of positive responses, i.e. when it was possible to determine the IP address from the domain name.

If the provider's DNS server returned a negative response (it could not determine the address), it is also stored in local storage. Typically, this response is stored for 15 minutes. This means that if, while visiting a site, it was not possible to determine its IP address, the site will be impossible to visit within 15 minutes, even if it becomes available during this time. To avoid this, you should reduce the storage time of negative responses or completely disable their storage. To set the storage time, you must adjust (or create, if missing) the DWORD parameter MaxNegativeCacheTtl, which limits the maximum storage time for negative responses. To disable their storage, just set the storage time to zero.

Temporarily disable DNS response caching

If you need to temporarily disable address caching in local storage, you must enter the command on the command line net stop dnscache(or sc stop dnscache) and press Enter. To turn it back on, enter the command on the command line net start dnscache(or scstart dnscache) and press Enter, or restart the computer.

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

When we try, for example, from Russia to open a website located in the USA (its NS servers are probably there), and the domain is not found in the DNS cache of your provider, 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 will resolve their IP, while we will send and receive the DNS request itself...

A couple of years ago, Google launched its public DNS servers, and to promote the transition to them, they developed a utility called NameBench, which runs DNS tests on your surfing history and shows how much faster Google DNS is than your provider’s DNS server.

But I managed to make my own DNS server that 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 strictly set the minimum TTL - this may be necessary on a very poor Internet), it can send a request simultaneously to several “parent” DNS servers, and give the client the first returned response.

It is the inclusion of parallel polling that gives us the main advantage in speed, because when a result is found in the cache of any of the providers, we get the result very quickly, and do not wait for a complete and slow resolution if the first provider does not have an answer in the cache.

Installed in Ubuntu using 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 my records didn’t fit. cache_dir="/var/cache/pdnsd"; [...] min_ttl=60m; // Minimum time for storing an entry in the cache. //Even if the TTL arrives less than 60 minutes, it will be 60 minutes max_ttl=1w; // Maximum time for saving an entry in the cache neg_ttl=5m; //Time for caching negative responses (i.e. if the domain is not found) [..] par_queries=3; //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, then a request will be sent to 4 th, 213.234.192.7 //The first 2 servers are the server of your provider, and some neighboring one, 8.8.4.4 //This is Google Public DNS - they cache everything rare and they resolve quickly, 8.8.8.8 ; [.. ] )

In principle, caching can be made less aggressive (min_ttl=1m for example), but over the course of a year of operation no special problems have arisen. In case of problems, you can optionally erase 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 receive a response in less than 10ms, for 85% Google Public DNS is faster, and then the results naturally coincide with Google.

Based on the test results, NameBench happily reports to 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 queries allows you to speed up even a 100-megabit Internet. And for slow (radio) links with high latency and packet loss, the difference can be like heaven and earth.