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.
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.
One of the important services that ensure the functioning of the modern Internet is the service for converting a site name into an IP address. We will set up the implementation of the DNS service in this article using the example of setting up Bind 9 (named) on a server running CentOS 7. We will prepare the minimum necessary basic functionality and look a little deeper into the logging settings.
If you have a desire to learn how to work with Mikrotik routers and become a specialist in this field, I recommend following a program based on information from the official course. The course is worthwhile, read the link for all the details. There are free courses.
Bind- the most common implementation of a DNS server today, which ensures the conversion of IP addresses into DNS names and vice versa. It is also called named, for example in Freebsd. Judging by information from Wikipedia, now 10 out of 13 root DNS servers on the Internet run on bind. It is installed out of the box on almost all Linux distributions. I'll look into installing it on a CentOS 7 server.
Installing Bind 9 (named) on CentOS 7
First of all, let’s check whether we have a DNS server installed on the system:
# rpm -qa bind* bind-libs-lite-9.9.4-14.el7.x86_64 bind-license-9.9.4-14.el7.noarch
I don’t have it installed because I chose the minimum software package. Our name server will work in a chroot environment, so install the appropriate packages:
# yum - y install bind bind - utils bind - chrootOnce again, please note that we will use bind in chroot environment to increase security. This imposes certain features in setting up and managing the server. You need to be careful in these little things. So, let's run bind :
# systemctl start named-chroot# systemctl enable named-chroot ln -s "/usr/lib/systemd/system/named-chroot.service" "/etc/systemd/system/multi-user.target.wants/named-chroot.service"
Checking the contents of the chroot directory:
# ls -l /var/named/chroot/etc
Everything is in order, the server has started, the necessary files have been created, everything is ready for configuration. Let's take care of it.
Setting up a DNS server in CentOS 7
Our server configuration file is located at /var/named/chroot/etc/named.conf. We open it and bring it to the following form:
# mcedit /var/named/chroot/etc/named.conf options ( listen-on port 53 ( any; ); listen-on-v6 port 53 ( none; ); directory "/var/named"; dump-file " /var/named/data/cache_dump.db"; allow-query ( 127.0.0.1; 192.168.7.0/24; ); recursion yes; allow-recursion ( 127.0.0.1; 192.168.7.0/24; ); forwarders ( 8.8 .8.8; ); version "DNS Server"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session. key"; dnssec-enable no; dnssec-validation no; ); zone "." IN (type hint; file "named.ca"; ); include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; logging ( channel default_file ( file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; ); category default ( default_file; ); );
This configuration will ensure the operation of a regular caching server on a local network. Comments on some parameters:
Do not forget to edit the firewall rules for the correct operation of the DNS server - open UDP port 53 for the caching server, which we have now configured, and TCP port 53 for forwarding zones, which will be discussed later
Now let's create a folder for logs. Don't forget that we are working in a chroot environment:
# cd /var/named/chroot/var/log && mkdir named && chown named. named
Own zone support
Let's say we need to place our own zone site1.ru in our named. First of all, we create a zone file that will be served by the DNS server:
# mcedit /var/named/chroot/var/named/site1.ru.zone $TTL 86400 @ IN SOA site1.ru. site1.ru.local. (2015092502 43200 3600 3600000 2592000) IN NS ns1.site1.ru. IN NS ns2.site1.ru. IN A 192.168.7.254 IN MX 10 mx.site1.ru. gate IN A 192.168.7.254 mx IN A 192.168.7.250 ns1 IN A 192.168.7.235 ns2 IN A 192.168.7.231
The description of the syntax of zone files is quite well covered on the Internet; I don’t want to dwell on this in detail. If desired, everyone can see for themselves if they need to configure support for their own zone.
We set the necessary rights:
# chown root:named /var/named/chroot/var/named/site1.ru.zone # chmod 0640 /var/named/chroot/var/named/site1.ru.zone
Zone "site1.ru" ( type master; file "site1.ru.zone"; );
We reread the named configuration using rndc:
# rndc reconfig
Adding to bind slave zone
If you want to keep on your server a copy of a zone taken from another DNS server, then add the following settings to the config.
Zone "site.ru" IN ( type slave; masters ( 10.1.3.4; ); file "site.ru.zone"; );
10.1.3.4 - IP address of the DNS server from which we take the zone. Don't forget to allow zone transfer to your DNS server.
You need to add write permission to the named group so that it looks like this:
After this, you can restart bind and check that the slave zone file has been created. With the above settings, it will be located at /var/named/chroot/var/named/site.ru.zone. If bind does not have rights to create a file, you will receive an error in the log:
Dumping master file: tmp-7Swr6EZpcd: open: permission denied
It is much more interesting and useful to understand detailed logging of server operation. For a long time I superficially grabbed at all sorts of recommendations and pieces of sample configs on the Internet, until I decided to deal with this topic myself and looked into the original manual.
Bind provides extensive logging capabilities. You can record almost everything related to the operation of the server. I will now show you how this works using simple examples.
First of all, in the configuration we set the channel where logs for certain events will be stored. Here is an example of such a channel:
Channel general ( file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes;
The name of the channel is indicated here, which we come up with ourselves - general, the path to the file is indicated, it is said that we will store 3 versions of the log no more than 5 megabytes in size. Parameter severity can take the following values:
Parameter print-time indicates that the time of the event should be recorded in the log. In addition to the settings I specified, the following parameters can be added to the channel configuration:
- print-severity yes | no — specifies whether or not to write the severity parameter to the log
- print-category yes | no — specifies whether or not to write the name of the log category
I did not specify these parameters, since the default value is set to no, which suits me personally.
Category general ( general; );
| default | Events of all categories from this table will fall here if they are not defined separately, with the exception of the queries category, which must be included specifically. That is, if you designate only the default category, then events of all categories will pour into it. |
| general | This category is for all logs that are not included in any of the listed categories. |
| database | Messages related to zone storage and caching. |
| security | Confirmation and refusal of requests. |
| config | Everything related to reading and executing the configuration file. |
| resolver | Name resolution, including information about recursive queries performed on behalf of the client by the caching server. |
| xfer-in | Information about obtaining zones. |
| xfer-out | Information about transferring zones. |
| notify | Logging NOTIFY protocol operations. |
| client | Fulfilling client requests. |
| unmatched | Messages that named could not assign to any class or for which no mapping has been defined. |
| network | Logging of network operations. |
| update | Dynamic updates. |
| update-security | Confirmation or rejection of update requests. |
| queries | Logging requests to the DNS server. To enable this category, you must separately set the parameter in the server configuration. This is due to the fact that this category generates a lot of entries in the log file, which can affect server performance. |
| query-errors | Errors in requests to the server. |
| dispatch | Redirecting incoming packets to server modules for processing. |
| dnssec | Operation of the DNSSEC and TSIG protocols. |
| lame-servers | Fixed errors that bind receives when contacting remote servers in an attempt to perform a name resolution request. |
| delegation-only | Logging requests that returned NXDOMAIN. |
| edns-disabled | Requests that are forced to use plain DNS due to exceeding timeouts. |
| RPZ | All operations related to the implementation of the Response Policy Zone (RPZ). |
| rate-limit | Operations related to one or more rate-limit statements in options or view. |
Thus, in order to display all categories of logs in separate files, you need to add the following construction to the named config:
Logging ( channel default ( file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel general ( file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel database ( file "/var/log/named/database.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel security ( file " /var/log/named/security.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel config ( file "/var/log/named/config.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel resolver ( file "/var/log/named/resolver.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel xfer-in ( file "/var/log/ named/xfer-in.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel xfer-out ( file "/var/log/named/xfer-out.log" versions 3 size 5m; severity dynamic ; print-time yes; ); channel notify ( file "/var/log/named/notify.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel client ( file "/var/log/named /client.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel unmatched ( file "/var/log/named/unmatched.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel network ( file "/var/log/named/network.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel update ( file "/var/log/named/update.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel update-security ( file "/var/log/named/update-security.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel queries ( file "/var/log/named/queries.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel query-errors ( file "/var/log/named/query-errors.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel dispatch ( file "/var/log/named/dispatch.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel dnssec ( file "/var/log/named/dnssec.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel lame-servers ( file "/var/log/named/lame-servers.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel delegation-only ( file "/var/log/named/delegation-only.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel edns-disabled ( file "/var/log/named/edns-disabled.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel rpz ( file "/var/log/named/rpz.log" versions 3 size 5m; severity dynamic; print-time yes; ); channel rate-limit ( file "/var/log/named/rate-limit.log" versions 3 size 5m; severity dynamic; print-time yes; ); category default(default;); category general(general;); category database ( database; ); category security ( security; ); category config(config;); category resolver(resolver;); category xfer-in ( xfer-in; ); category xfer-out ( xfer-out; ); category notify (notify; ); category client ( client; ); category unmatched ( unmatched; ); category network ( network; ); category update(update;); category update-security ( update-security; ); category queries ( queries; ); category query-errors ( query-errors; ); category dispatch ( dispatch; ); category dnssec ( dnssec; ); category lame-servers ( lame-servers; ); category delegation-only ( delegation-only; ); category edns-disabled ( edns-disabled; ); category rpz ( rpz; ); category rate-limit ( rate-limit; ); );
If we want to collect all request logs from a category queries, then in the options section of the configuration file you need to add a parameter that allows this:
Querylog yes;
Restart bind:
# systemctl restart named-chroot.service
Checking the operation of the DNS Server
First of all, let's go to the directory with logs and check what we have there:
# cd /var/named/chroot/var/log/named # ls -l
All log files have been created and are starting to fill up. You can check one of them. For example, let's see how our centos server (192.168.7.246) logs user requests. Let's try to run nslookup yandex.ru from computer 192.168.7.254 (Windows) and see how it is reflected in the log file:
26-Sep-2015 19:25:30.923 client 192.168.7.254#56374 (yandex.ru): query: yandex.ru IN A + (192.168.7.246) 26-Sep-2015 19:25:31.013 client 192.168.7.254# 56375 (yandex.ru): query: yandex.ru IN AAAA + (192.168.7.246)
Now let’s ping site1.ru to check how the server supports our zone:
Let's see what's in the logs:
26-Sep-2015 19:28:01.660 client 192.168.7.254#49816 (site1.ru): query: site1.ru IN A + (192.168.7.246)
This makes it very convenient to track where the computer is going. For example, you can temporarily raise the DNS server and enable the query log. In the client, specify the only DNS server that we have configured. Then we can track, for example, where Windows goes after loading without our knowledge. Or where advertisements are loaded on Skype. All requests will be neatly compiled into a file, which can then be easily analyzed, and then, for example, .
That's all I wanted to tell you in this material. The topic of setting bind (named) is quite extensive. Maybe I'll come back to it again.
Online courses on Mikrotik
If you have a desire to learn how to work with Mikrotik routers and become a specialist in this field, I recommend taking courses according to the program based on information from the official course MikroTik Certified Network Associate. In addition to the official program, the courses will include laboratory work in which you will be able to test and consolidate your acquired knowledge in practice. All details are on the website. The cost of training is very affordable, a good opportunity to gain new knowledge in a subject area that is relevant today. Course Features:- Practice-oriented knowledge;
- Real situations and tasks;
- The best of international programs.
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:
# apt - get install bind9After completion, downloading and installation, we need to edit its configuration file:
#vim /etc/bind/named. conf. optionsWe 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:
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
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
and paste the following into it:
(Please pay close attention to the syntax of the configuration file, even the dots have meaning)
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 - Setting up a DHCP server
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
# vim / etc / resolv . confand enter there:
nameserver 127.0.0.1everything that was there can be commented out by putting #
server restarts
# reboot
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:
If we test from Linux:
ping devicename. orgname - c 4Pings should go to the IP that you specified instead of XXX.XXX.XXX.XXX
You can also check the speed of processing requests with the command dig
# dig @127.0.0.1 tut.by ;<<>> DiG 9.9.5-9+deb8u6-Debian<<>> @127.0.0.1 tut.by ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63893 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;tut.by. IN A ;; ANSWER SECTION: tut.by. 103 IN A 178.172.160.5 tut.by. 103 IN A 178.172.160.4 tut.by. 103 IN A 178.172.160.2 tut.by. 103 IN A 178.172.160.3 ;; AUTHORITY SECTION: . 6029 IN NS i.root-servers.net. . 6029 IN NS b.root-servers.net. . 6029 IN NS m.root-servers.net. . 6029 IN NS k.root-servers.net. . 6029 IN NS e.root-servers.net. . 6029 IN NS d.root-servers.net. . 6029 IN NS j.root-servers.net. . 6029 IN NS g.root-servers.net. . 6029 IN NS l.root-servers.net. . 6029 IN NS f.root-servers.net. . 6029 IN NS h.root-servers.net. . 6029 IN NS a.root-servers.net. . 6029 IN NS c.root-servers.net. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Mar 22 16:46:24 MSK 2016 ;; MSG SIZE rcvd: 310
Attention
To correctly install and configure dnsmasq, go to the superuser session:
When prompted for a password, enter the superuser or local administrator password.
DNS cache is designed to speed up the loading of website pages by storing their IP addresses in memory. To configure caching, use the utility dnsmasq.
Yum install dnsmasq
Using the text editor vi or nano, open the file located at /etc/dnsmasq.conf
Vi /etc/dnsmasq.conf
Nano /etc/dnsmasq.conf
Edit the following settings:
Resolv-file=/etc/resolv.dnsmasq no-poll listen-address=127.0.0.1 cache-size=150 conf-dir=/etc/dnsmasq.d,.rpmnew,.rpmsave,.rpmorig
And also add the following parameter:
All-servers
- resolv-file- file with IP addresses of dns servers
- no-poll- a parameter that prohibits automatic application of changes to files named resolv.
- listen-address- a parameter indicating which address to listen to.
- cache-size- cache size. The default value allows you to store 150 hosts.
- conf-dir- parameter responsible for the additional configuration file.
- all-servers- redirects the DNS request to all available DNS servers and returns a response from the first server that responds. The parameter must be written down manually.
You can also specify the following parameters:
- no-negcache- do not cache negative responses from servers.
- bind-interfaces- allows you to run copies of the process.
- dns-forward-max- maximum number of DNS requests. The default is 150. The parameter must be written down manually.
Now create a file resolv.dnsmasq using a text editor vi or nano and write down the addresses of the DNS servers there.
Vi /etc/resolv.dnsmasq
Nano /etc/resolv.dnsmasq
Then add the IP address 127.0.0.1 to file resolv.conf. To do this, use the utility "Network Connections", located in “Menu” → “Options” → “Network connections” in a graphical environment Cinnamon or “System” → “Settings” → “Network Connections” in a graphical environment Mate. Select your active connection, click the button "Change", go to the tab "IPv4 Settings", change "Method" on "Automatic (DHCP, address only)", and in the field “ Additional DNS servers" write the address 127.0.0.1 , click apply and restart NetworkManager.
Editing the resolv.conf file using text editors is not recommended. The file will be overwritten with the next system restart.
Systemctl restart NetworkManager.service
To ensure that the changes have taken effect, review the contents of the file resolv.conf:
Cat /etc/resolv.conf
The content should be like this:
# Generated by NetworkManager nameserver 127.0.0.1
The operations described above will allow you to redirect all DNS requests to the local machine.
Add a service dnsmasq to autorun and re-login to the session:
Systemctl enable dnsmasq.service --now
To reset the cache, simply restart the service:
Systemctl restart dnsmasq.service
Functionality check
Check if the service is enabled:
Systemctl status dnsmasq.service
Check port 53:
Netstat -ntlp | grep:53 tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 7319/dnsmasq tcp6 0 0:::53:::* LISTEN 7319/dnsmasq
Now try using the dig utility to access the site several times google.com
Dig google.com | grep "Query time" ;; Query time: 135 msec
If caching of DNS requests works, then in almost all the following requests the highlighted line query time will be equal to zero.
;; Query time: 0 msec
Otherwise, it will vary from 0 and higher with each new request.
As a result, the main DNS server on the network will experience much less load.
If you find an error, highlight the text and click Ctrl+Enter.
