Before you build a DNS server, you can know what situation you need to build a DNS server, and under what circumstances you don't need to build a DNS server. Before that, you need to understand the basic concepts of domain and zone in DNS and the types of DNS resource records. If you are not familiar with this, you can refer to my last article. "Caching only DNS Setting and Forward Function".
First, why do you need to build your own DNS server?
There are three main reasons for building DNS servers:
(1) Generally, companies have multiple servers that need to access the Internet and provide services. At this time, companies need to apply for a domain from ISP, and these servers are located in the company's domain.
(2) Generally speaking, when users access the server, they usually query the IP address according to FQDN. If FQDN or IP address is likely to change frequently, it is better to build DNS server management by themselves, which is convenient to modify.
(3) When the number of Servers needs to change frequently, if you build a DNS server, and the FQDN of Server and the corresponding relationship data of host name are stored on this DNS server, you only need to manually add a new corresponding relationship.
Of course, if only one Server needs to access the Internet and provide network services to other hosts, then you just need to apply and let the upper DNS Server administrator set up the corresponding relationship between hostname and IP address for you, and you don't need to build your own DNS Server.
2. Forward parsing library files and reverse parsing library files
As mentioned in the previous blog, for a domain, it manages its underlying subdomains and hosts. A domain may contain one or more forward parsing regions and reverse parsing regions, but a domain is a logical concept, and a region is defined for each domain to be parsed. This definition of region is mainly embodied in parsing library files, that is to say, a region represents a parsing library file. But a parsing library file can only be one of the forward parsing and the reverse parsing. In conclusion, DNS servers that provide DNS services to the Internet are usually only responsible for parsing a domain. Each DNS server can manage one or more regions, each region can be positive or negative.
Since each domain to be parsed needs to be defined by a parse library file, and each parse library file represents a region, it is necessary to know which domain to parse. Basically, the process of querying IP address according to host name is called forward parsing, which corresponds to a forward parsing library file; the process of querying host name according to IP address is called reverse parsing, which corresponds to a reverse parsing library file.
Next, we introduce the necessary resource records in the forward and reverse parsing library files.
2.1 How to apply for the right to set up positive and negative solutions of DNS?
Apply for the right to set up DNS positive solution:
Anyone can register with ISP for a domain name as long as the domain name has not been registered. As long as the domain name is registered, it can be used. It should be noted that because INTERNIC has defined TLD, the domain name you define must be within the domain of the upper DNS. For example, you can apply for itab.com, itab.org, itab.cn and other domain names, but you can not customize and apply for a domain name such as itab.hello. In general, customized and applied domain names must conform to the INTERNIC and ISP specifications.
The right to apply for DNS counter-settlement:
The above application for DNS forward setup right is to apply to ISP for adding NS records and A records of our DNS server in a domain managed by an upper DNS server. For example, to apply for itab.com domain name, you need to apply for adding NS records of itab.com domain and A records corresponding to NS records of this domain on the DNS server of.Com domain. What about the reverse solution? Similarly, if there is a need for counter-resolution, you need to apply to your immediate upper ISP. For example, to apply for the domain of 10.168.192.in-addr.arpa, you need to apply to the ISP of the DNS server that manages the domain of 168.192.in-addr.arpa. IP addresses are issued to ISPs by INTERNIC, and IP addresses can not be set arbitrarily (routing problems).
2.2 Necessary resource records in DNS forward parsing library files
Because it is forward parsing, the key point is to query the IP address according to FQDN. A region parsing library file is defined for a domain, so the mapping between FQDN and IP address of DNS server in this domain should also be clearly defined (otherwise no one can query the subdomain and host information managed by this domain). Generally speaking, forward parsing library files should have at least the following resource record types:
(1) SOA Recording
The initial authorization record defines the region name of the current region (or the primary DNS server FQDN of the current region name), the mailbox address of the current regional administrator, the definition of the master-slave service coordination attribute, and the cache time TTL of the negative answer.
(2) NS records
NS records define one or more DNS servers FQDN in the current region.
(3) A record or AAAA record
A record defines the corresponding relationship between FQDN and IPv4 address of each host in the current area, and AAAA record defines the corresponding relationship between FQDN and IPv6 address of each host in the current area. In the forward parsing library file, the value of MX, NS and other types of records is FQDN, which requires a corresponding A record or AAAA record.
2.3 Necessary resource records in DNS reverse parsing library files
The key point of reverse parsing is to query the IP address from FQDN, so the necessary resource record types in reverse parsing library files should have at least SOA,NS,PTR. The forward parsing of SOA and NS records is described above, and here's a brief description of PTR records.
PTR Records
PoinTeR is the abbreviation of PoinTeR. The FQDN is retrieved from the IP address.
3. Building a DNS Server
Now take itab.com as an example to build a DNS server in the LAN. This DNS service will monitor port 53. If other hosts on the Internet want to access the hosts managed by the local DNS server, they need to register with the ISP and let the DNS service listen on the port 53 of the IP address that can communicate with the external host. But this is only an experiment, so the DNS server built can only be used within the scope of the local area network.
Next, I build the DNS server with my host (192.168.10.140).
Configuration steps for parsing a forward region:
(1) Definition area
(2) Establishing regional database files (mainly A or AAAA records)
(3) Let the server overload configuration files and regional database files
Configure the steps for parsing a reverse region:
(1) Definition area
(2) Establishment of regional database files (mainly PTR records)
(3) Let the server overload configuration and regional database files
3.1 Configuration parses a forward region
(1) Definition area
The main configuration file (/etc/named.conf) or the auxiliary configuration file (/etc/named.rfc1912.zones) included in the main configuration file are implemented in the following format:
zone "ZONE_NAME" IN {
type {master|slave|hint|forward}; //Four choices.
file "ZONE_NAME.zone"; //The file name of the regional database can be customized.
}Regional type:
Master: The master DNS server can be used as the master DNS server in the master and slave services of DNS.
Slave: slave DNS server, is the slave DNS server in DNS master-slave service.
hint: The root domain server is the built-in area of the DNS server. After installing the bind, the root domain is defined in the configuration file, which is provided by the rpm package maker of the bind.
forward: forward DNS server, see previous blog for details "Caching only DNS Setting and Forward Function".
View the definition of the root domain:
[root@www ~]# vim /etc/named.conf
zone "." IN {
type hint; //Records. Types of zones in this domain.
file "named.ca"; //The positive region database file of the root domain is / var/named/named.ca.
};
# Other information is omitted.Basically, each DNS server needs to define at least two zones, one is hint, the other is the positive solution zone of its own domain, which is built-in by the DNS server. When DNS can not find the required information in its own database, it will start to iterate from the root domain, so the definition of the root domain can not be less.
It should be noted that in order to keep the main configuration file / etc/named.conf clean, the general custom area can be defined in the / etc/named.rfc1912.zones file.
Taking itab.com as an example, the following areas are defined in the auxiliary configuration file / etc/named.rfc1912.zones of the main configuration file:
zone "itab.com" IN {
type master;
file "itab.com.zone";
};Note: The domain name is the domain name.
(2) Establishing regional database files (mainly A or AAAA records)
Because in the global configuration section (options section) of the main configuration file, an item is defined:
directory "/var/named";
So, when defining the file parameter for zone, the file name that follows should be stored in / var/named / directory by default.
Therefore, in this step, you need to create the region parsing library file itab.com.zone under / var/named/directory:
[root@www ~]# vim /var/named/itab.com.zone $TTL 3600 //The TTL value is declared globally at the beginning and then inherited in each record without rewriting. $ORIGIN itab.com. //Define the domain name, where the definition overrides the default ORIGIN variable value. @ IN SOA ns1.itab.com. dnsadmin.itab.com. ( 2017032901 1H 10M 2H 1W ) IN NS ns1 IN MX 10 mx1 IN MX 20 mx2 ns1 IN A 192.168.10.140 mx1 IN A 192.168.10.3 mx2 IN A 192.168.10.4 www IN A 192.168.10.140 web IN CNAME www bbs IN A 192.168.10.140 bbs IN A 192.168.10.141
It should be noted that the same IP address can correspond to multiple FQDNs (the same host can provide multiple services), while the same FQDN can correspond to multiple IP addresses (load balancing).
In order to prevent other users from accessing regional database files, it is necessary to set other users to have no permissions, and also to set the subgroup to named. Therefore, after configuring the regional database files, you need to modify the membership groups and permissions.
[root@www ~]# Chgrp named/var/named/itab.com.zone//modify the genus group to named. [root@www ~]# Chmod o=/var/named/itab.com.zone// Set up other users without any privileges. [root@www ~]# Ll/var/named/itab.com.zone// View the file properties of the regional database. -rw-r-----. 1 root named 384 3 month 29 23:19 /var/named/itab.com.zone
The chgrp can also be used to modify the subgroup, as follows:
[root@www ~]# chown :named /var/named/itab.com.zone [root@www ~]# ll /var/named/itab.com.zone
So even if the name process is hijacked, the contents of the regional database file cannot be modified.
Next you need to check for grammatical errors.
The command to check whether the main configuration file/etc/named.conf and the auxiliary configuration file (including/etc/named.rfc1912.zones) include d in the main configuration file have syntax errors is named-checkconf, while the command to check whether the regional database file has syntax errors is named-checkzone, which uses the following format:
# named-checkzone ZONE_NAME ZONE_FILE Area Name: Area Database File Path
Examples:
[root@www ~]# named-checkconf //Check if there are any grammatical errors in the main configuration file, and if there are no displays, there are no grammatical errors. [root@www ~]# Named-checkzone itab.com/var/named/itab.com.zone// Check regional database files zone itab.com/IN: loaded serial 2017032901 OK //Displaying OK is error-free.
(3) Let the server overload configuration files and regional database files
If there are no grammatical errors, they can be overloaded directly.
[root@www ~]# rndc reload server reload successful # Or: [root@www ~]# systemctl reload named.service
DNS service status can be viewed with rndc:
[root@www ~]# rndc status version: 9.9.4-RedHat-9.9.4-37.el7 <id:8f9657aa> CPUs found: 2 worker threads: 2 //Number of DNS service threads. UDP listeners per interface: 2 //Represents the number of udp listeners started on each network interface. number of zones: 7 //Number of zone s currently loaded. debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/0/1000 //How many DNS clients are currently doing recursive queries, including being able to accept requests and do so //Number of DNS clients for recursive queries. tcp clients: 0/100 //Currently, the number of clients that have established tcp connections. server is up and running //Represents that the service is up and running.
Such a forward parsing library file is configured and tested here.
Before testing, make sure that the DNS configuration in the / etc/resolv.conf file points to 192.168.10.140, as follows:
[root@www ~]# cat /etc/resolv.conf # Generated by NetworkManager nameserver 192.168.10.140
The resources in the regional database file of itab.com are recorded as follows:
Testing NS records using dig tools:
[root@www ~]# dig -t NS itab.com ;; ANSWER SECTION: itab.com. 3600 IN NS ns1.itab.com.
Test A record:
[root@www ~]# dig -t A web.itab.com ;; ANSWER SECTION: web.itab.com. 3600 IN CNAME www.itab.com. www.itab.com. 3600 IN A 192.168.10.140
[root@www ~]# dig -t A bbs.itab.com ;; ANSWER SECTION: bbs.itab.com. 3600 IN A 192.168.10.140 bbs.itab.com. 3600 IN A 192.168.10.141
Test MX records:
[root@www ~]# dig -t MX itab.com ;; ANSWER SECTION: itab.com. 3600 IN MX 20 mx2.itab.com. itab.com. 3600 IN MX 10 mx1.itab.com.
Testing SOA records:
[root@www ~]# dig -t SOA itab.com ;; ANSWER SECTION: itab.com. 3600 IN SOA ns1.itab.com. dnsadmin.itab.com. 2017032901 3600 600 7200 604800
After testing, there is no problem with forward analysis.
3.2 Configuration parses a reverse region
(1) Definition area
This step is similar to the previous one. It is important to note that the region name of the reverse region follows a specific format (rewriting the segment address, adding a specific suffix). The format of the region name of the inverse region is as follows:
Reverse segment address. in-addr.arpa
For example, the IP segment to be inverted is 192.168.10.0/24, so the inversion region name needs to be written as 10.168.192.in-addr.arpa.
Here we take 192.168.10.0/24 as an example to define the area:
[root@www ~]# vim /etc/named.rfc1912.zones
//Add the following to the file.
zone "10.168.192.in-addr.arpa" IN {
type master;
file "10.168.192.zone";
};Check for grammatical errors in the main configuration file:
[root@www ~]# named-checkconf [root@www ~]#
No hints, no grammatical errors.
(2) Establishment of regional database files (mainly PTR records)
[root@www ~]# Vim/var/named/10.168.192.zone//filename needs to be consistent with the definition in the configuration file. $TTL 3600 $ORIGIN 10.168.192.in-addr.arpa. @ IN SOA ns1.itab.com. nsadmin.itab.com. ( 2017040101 1H 10M 10H 12H ) IN NS ns1.itab.com. 140 IN PTR ns1.itab.com. 32 IN PTR mx1.itab.com. 33 IN PTR mx2.itab.com. 34 IN PTR www.itab.com. 35 IN PTR bbs.itab.com. 34 IN PTR bbs.itab.com.
Note that no MX records need to be defined in the reverse region database. In addition, the same IP address can correspond to multiple FQDNs, and a FQDN can correspond to an IP address, just like a forward regional database.
Check for syntax errors in reverse parsing database files:
[root@www ~]# named-checkzone 10.168.192.in-addr.arpa /var/named/10.168.192.zone zone 10.168.192.in-addr.arpa/IN: loaded serial 2017040101 OK //The grammar is correct.
Modify membership groups and permissions:
[root@www ~]# chgrp named /var/named/10.168.192.zone [root@www ~]# chmod o= /var/named/10.168.192.zone [root@www ~]# ll /var/named/10.168.192.zone -rw-r-----. 1 root named 327 4 month 1 22:00 /var/named/10.168.192.zone
(3) Let the server overload configuration and regional database files
[root@www ~]# rndc reload server reload successful
Use rndc to view DNS service status:
[root@www ~]# rndc status version: 9.9.4-RedHat-9.9.4-37.el7 <id:8f9657aa> CPUs found: 2 worker threads: 2 UDP listeners per interface: 2 number of zones: 8 //Number of zone s + 1. debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/0/1000 tcp clients: 0/100 server is up and running
The contents of the reverse area database file are as follows:
test
FQDN is obtained by IP reverse parsing:
[root@www ~]# dig -x 192.168.10.32 ;; ANSWER SECTION: 32.10.168.192.in-addr.arpa. 3600 IN PTR mx1.itab.com.
After testing, there is no problem with reverse parsing.
IV. Master-slave DNS Server
In production environment, in order to achieve high availability, two or more servers are usually used to provide services, and DNS services are no exception. However, when there are multiple DNS servers, system administrators have to manually configure DNS services for multiple servers, which may also lead to configuration errors. Therefore, master-slave synchronization (or master-assistant synchronization) mechanism is needed. With master-slave synchronization, system administrators only need to configure and modify the master DNS server, while other DNS servers can automatically and dynamically copy the same data from the master DNS server to operate synchronously, which is very convenient.
Duties of master-slave DNS server:
Main DNS Server: The DNS server that maintains the domain database for parsing can be read and written. From a DNS server: Copy a database from a master DNS server or from another DNS server, but only read it.
So how does the slave server synchronize with the master DNS server? As mentioned in the previous article, the information in the SOA record includes the definition of the master-slave service coordination attribute, so SOA is also a synchronization mechanism. But this is not enough. According to the SOA record, if the data of the database is synchronized every 10 minutes from the DNS server to the main DNS server, the main DNS server will change immediately when a synchronization operation is completed, which will result in nearly 10 minutes from the DNS server without updating the database. Both the main DNS server and the slave DNS server provide parsing service to the outside world at the same time. The DNS client may not be able to query the result or the wrong result. In order to solve this problem, in addition to the parameters recorded by SOA as synchronization reference, another mechanism needs to be introduced: the master DNS server notifies the slave DNS server as soon as it has updated data. To sum up, the implementation of master-slave synchronization is as follows:
(a) Based on SOA records
Serial number: serial, that is, the version number of the database. When the content of the main DNS server database changes, the version number should be increased.
(2) Refresh interval: refresh, check the status of serial number updates from the DNS server to the main DNS server at regular intervals.
(3) retry interval: when synchronizing database from DNS server to master DNS server fails, define how long to initiate the attempt request again.
(4) The expire time: when the slave DNS server can not contact the master DNS server all the time, define how long to give up the slave DNS server to synchronize the database and stop providing services.
(5) The length of cache for negative answers.
(b) Once the data is updated, the primary DNS server immediately "notifies" to update the data from the DNS server
Next, we introduce the configuration of master-slave DNS server. Because a DNS server has been configured above, and the type is master, it can be directly used as the main DNS server, here only need to configure a slave DNS server. The hosts used by master-slave DNS servers are as follows:
Main DNS server: 192.168.10.140 CentOS 7 system, host name changed to master. From DNS server: 192.168.10.128 # CentOS 6 system, host name slave.
It is important to note that slave is a concept at the regional level from DNS server. A slave is defined on the main DNS server as one or more regions, rather than as slave for all regions on the whole DNS server at the beginning.
Therefore, the steps to configure a slave region are as follows (first, ensure that bind is installed from the DNS server):
On Slave:
(1) Define a slave region
zone "ZONE_NAME" IN {
type slave;
file "slaves/ZONE_NAME.zone"; //The database files should be synchronized to the / var/named/slaves directory.
masters { MASTER_IP; }; //Explain which main DNS server is.
};After configuring, check the syntax of the configuration file:
[root@slave ~]# named-checkconf
The database files from the slave region are stored in the / var/named/slaves directory because when synchronizing the database from the DNS server to the main DNS server, the synchronization operation is carried out by the named process, which is a daemon initiated by the named user. Therefore, the / var/named / directory does not have write permission, as follows:
[root@slave ~]# ps aux | grep named | grep -v 'grep' named 22451 1.5 2.6 236376 12724 ? Ssl 15:11 0:00 /usr/sbin/named -u named # As you can see, the name process is initiated by the name user. [root@slave ~]# ll -d /var/named/ drwxr-x--- 5 root named 4096 Mar 28 08:16 /var/named/ # The owner is root, the owner group is named, and the name user does not have write permission.
But bind has a / var/named/slaves directory built in for name synchronization, which has write permission for name:
[root@slave ~]# ll -d /var/named/slaves/ drwxrwx--- 2 named named 4096 Jan 17 21:04 /var/named/slaves/ # named user has write permission.
Therefore, when the / var/named/slaves directory is dedicated to synchronizing data files from the DNS server to the master DNS server, it is necessary to create data files dynamically and automatically.
It is important to note that if the owner of / var/named / is changed directly to named, although the data file can be created automatically from the DNS server, there is a risk that once the name process is hijacked, all the data files of name will be emptied.
(2) Overload configuration
[root@slave ~]# rndc reload //If it is the first time to start, then: [root@slave ~]# service named start //CentOS 6. [root@slave ~]# systemctl reload named.service //CentOS 7.
On Master:
Ensure that NS records are configured for each slave server in the regional database file, and that if it is a forward zone file, an A record is also required for each slave server's NS records; if it is a reverse zone file, a PTR record is required for each slave server's NS records.
Now do slave regions for the forward and reverse regions on the main DNS server configured above:
On Slave:
Modify the global configuration segment to listen on port 53 of any address and set it to allow anyone to query:
options {
... ...
listen-on port 53 { any; };
allow-query { any; };
dnssec-enable no;
dnssec-validation no;
... ...
};Define from the region:
[root@slave ~]# vim /etc/named.rfc1912.zones
# Add the following to the file.
zone "itab.com" IN { //Do the slave region for itab.com.
type slave;
file "slaves/itab.com.zone";
masters { 192.168.10.140; };
};
zone "10.168.192.in-addr.arpa" IN { //The slave region is 10.168.192.in-addr.arpa.
type slave;
file "slaves/10.168.192.zone";
masters { 192.168.10.140; };
};Check for grammatical errors:
[root@slave ~]# named-checkconf [root@slave ~]# // The grammar is correct.
On Master:
Add NS records from DNS servers and corresponding A records in / var/named/itab.com.zone:
[root@master ~]# vim /var/named/itab.com.zone $TTL 3600 $ORIGIN itab.com. @ IN SOA ns1.itab.com. dnsadmin.itab.com. ( 2017032901 1H 10M 2H 1W ) IN NS ns1 IN NS ns2 //NS Recording from DNS Server IN MX 10 mx1 IN MX 20 mx2 ns1 IN A 192.168.10.140 ns2 IN A 192.168.10.128 //A record corresponding to the NS record from the DNS server mx1 IN A 192.168.10.3 mx2 IN A 192.168.10.4 www IN A 192.168.10.140 web IN CNAME www bbs IN A 192.168.10.140 bbs IN A 192.168.10.141
Add NS records from DNS servers and corresponding A records in / var/named/10.168.192.zone:
[root@master ~]# vim /var/named/10.168.192.zone $TTL 3600 $ORIGIN 10.168.192.in-addr.arpa. @ IN SOA ns1.itab.com. nsadmin.itab.com. ( 2017040101 1H 10M 10H 12H ) IN NS ns1.itab.com. IN NS ns2.itab.com. //NS Recording from DNS Server 140 IN PTR ns1.itab.com. 128 IN PTR ns2.itab.com. //PTR records corresponding to NS records from DNS servers 32 IN PTR mx1.itab.com. 33 IN PTR mx2.itab.com. 34 IN PTR www.itab.com. 35 IN PTR bbs.itab.com. 34 IN PTR bbs.itab.com.
Comment out the forbidden forwarding in the global configuration section of the / etc/named.conf file:
[root@master ~]# vim /etc/named.conf
options {
... ...
// allow-transfer { none; };
... ...
};Two regional settings for itab.com and 10.168.192.in-addr.arpa allow 192.168.10.128 hosts (from DNS servers) to forward regions:
[root@master ~]# vim /etc/named.rfc1912.zones
# Other contents are omitted.
zone "itab.com" IN {
type master;
file "itab.com.zone";
allow-transfer { 192.168.10.128; }; //Only 192.168.10.128 hosts are allowed to carry out area forwarding.
};
zone "10.168.192.in-addr.arpa" IN {
type master;
file "10.168.192.zone";
allow-transfer { 192.168.10.128; }; //Only 192.168.10.128 hosts are allowed to carry out area forwarding.
};Check for grammatical errors:
[root@master ~]# named-checkconf [root@master ~]#
Reload master-slave DNS servers separately
On Master:
[root@master ~]# rndc reload server reload successful
On Slave:
[root@slave ~]# rndc reload server reload successful
If the name service has not been started before, it can be started directly.
[root@slave ~]# service named start Starting named: named: already running [ OK ]
View status information:
You can see the transferred area files from the server and parse them locally.
[root@slave ~]# ll /var/named/slaves/ total 8 -rw-r--r-- 1 named named 454 Mar 28 16:37 10.168.192.zone -rw-r--r-- 1 named named 521 Mar 28 16:37 itab.com.zone
Test:
[root@slave ~]# dig -t A web.itab.com @192.168.10.128 ;; ANSWER SECTION: web.itab.com. 3600 IN CNAME www.itab.com. www.itab.com. 3600 IN A 192.168.10.140
[root@slave ~]# dig -x 192.168.10.34 @192.168.10.128 ;; ANSWER SECTION: 34.10.168.192.in-addr.arpa. 3600 IN PTR bbs.itab.com. 34.10.168.192.in-addr.arpa. 3600 IN PTR www.itab.com.
After testing, no problem.
Now add an A record and a PTR record to the forward and reverse area database files on the main DNS server to test whether the slave DNS server can synchronize.
On Master:
[root@master ~]# vim /var/named/itab.com.zone # Add an A record to the forward regional database. $TTL 3600 $ORIGIN itab.com. @ IN SOA ns1.itab.com. dnsadmin.itab.com. ( 2017032902 //Remember to add version number after modification 1H 10M 2H 1W ) IN NS ns1 IN NS ns2 IN MX 10 mx1 IN MX 20 mx2 ns1 IN A 192.168.10.140 ns2 IN A 192.168.10.128 mx1 IN A 192.168.10.3 mx2 IN A 192.168.10.4 www IN A 192.168.10.140 web IN CNAME www bbs IN A 192.168.10.140 bbs IN A 192.168.10.141 pop3 IN A 192.168.10.103 //Add the A record
[root@master ~]# vim /var/named/10.168.192.zone # Add a PTR record to the reverse region database. $TTL 3600 $ORIGIN 10.168.192.in-addr.arpa. @ IN SOA ns1.itab.com. nsadmin.itab.com. ( 2017040102 //Remember to add version number after modification 1H 10M 10H 12H ) IN NS ns1.itab.com. IN NS ns2.itab.com. 140 IN PTR ns1.itab.com. 128 IN PTR ns2.itab.com. 32 IN PTR mx1.itab.com. 33 IN PTR mx2.itab.com. 34 IN PTR www.itab.com. 35 IN PTR bbs.itab.com. 34 IN PTR bbs.itab.com. 123 IN PTR pop3.itab.com. //Add the PTR record
Check for grammatical errors in regional database files:
[root@master ~]# named-checkzone itab.com /var/named/itab.com.zone zone itab.com/IN: loaded serial 2017032902 OK [root@master ~]# named-checkzone 10.168.192.in-addr.arpa /var/named/10.168.192.zone zone 10.168.192.in-addr.arpa/IN: loaded serial 2017040102 OK
Overload service:
[root@master ~]# rndc reload server reload successful
View logs:
On Slave:
Test with dig tools (or host, nslookup, etc.):
[root@slave ~]# dig -t A pop3.itab.com @192.168.10.128 ;; ANSWER SECTION: pop3.itab.com. 3600 IN A 192.168.10.103
[root@slave ~]# dig -x 192.168.10.123 @192.168.10.128 ;; ANSWER SECTION: 123.10.168.192.in-addr.arpa. 3600 IN PTR pop3.itab.com.
Synchronization success!
V. Time Synchronization
Any service that allows multiple servers to coordinate with each other based on a particular application in a distributed environment should configure time synchronization. For DNS services, if time synchronization is not configured, the slave server may not be able to synchronize the database of the primary server. But even if synchronized for a period of time, it may still lead to errors after a period of time, so periodic planning can be used to synchronize it every other period of time. The utpdate command is needed for time synchronization on Linux, where a time server on the Internet is used: cn.pool.ntp.org.
View the program file path of ntpdate command:
[root@master ~]# which ntpdate /usr/sbin/ntpdate
Configure periodic task plans:
[root@master ~]# crontab -e 0 0 * * * /usr/sbin/ntpdate cn.pool.ntp.org
It should be noted here that in order to synchronize with cn.pool.ntp.org, we must first parse the FQDN cn.pool.ntp.org, and parsing takes a certain amount of time, so if we want to save the time needed to parse FQDN, or worry that for some reason the parsing is not successful, so we can get cn.poo first. The IP address of l.ntp.org:
[root@master ~]# dig -t A cn.pool.ntp.org ;; ANSWER SECTION: cn.pool.ntp.org. 16 IN A 51.15.41.135 cn.pool.ntp.org. 16 IN A 163.172.177.158 cn.pool.ntp.org. 16 IN A 79.98.105.18 cn.pool.ntp.org. 16 IN A 213.239.204.119
Choose an IP address here at will. Choose 51.15.41.135 here.
Use IP addresses to configure periodic task plans:
[root@master ~]# crontab -e 0 0 * * * /usr/sbin/ntpdate 51.15.41.135
This eliminates the need to parse FQDN for time synchronization. Similarly, slave servers need to configure time synchronization in the same way as above.
VI. Regional Transport
When synchronizing master and slave DNS, you can notice that an entry is defined in the area of the master DNS server:
allow-transfer { IP; };It is generally recommended that the IP address of the main server after allow-transfer is the IP address of the DNS server (to ensure security).
There are two types of regional transmission:
(1) Full transmission: axfr, transferring the whole database. (2) Incremental transmission: ixfr, which transmits only changed data.
Full-volume transport can be simulated from a DNS server:
[root@slave ~]# Digital AXFR itab.com@192.168.10.140//Analog transport itab.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> axfr itab.com @192.168.10.140 ;; global options: +cmd itab.com. 3600 IN SOA ns1.itab.com. dnsadmin.itab.com. 2017032902 3600 600 7200 604800 itab.com. 3600 IN NS ns1.itab.com. itab.com. 3600 IN NS ns2.itab.com. itab.com. 3600 IN MX 10 mx1.itab.com. itab.com. 3600 IN MX 20 mx2.itab.com. bbs.itab.com. 3600 IN A 192.168.10.140 bbs.itab.com. 3600 IN A 192.168.10.141 mx1.itab.com. 3600 IN A 192.168.10.3 mx2.itab.com. 3600 IN A 192.168.10.4 ns1.itab.com. 3600 IN A 192.168.10.140 ns2.itab.com. 3600 IN A 192.168.10.128 pop3.itab.com. 3600 IN A 192.168.10.103 web.itab.com. 3600 IN CNAME www.itab.com. www.itab.com. 3600 IN A 192.168.10.140 itab.com. 3600 IN SOA ns1.itab.com. dnsadmin.itab.com. 2017032902 3600 600 7200 604800 ;; Query time: 8 msec ;; SERVER: 192.168.10.140#53(192.168.10.140) ;; WHEN: Sun Apr 2 13:45:28 2017 ;; XFR size: 15 records (messages 1, bytes 342)
Successful analog transmission indicates that data can be transmitted normally, that is, it can be synchronized normally.
[root@slave ~]# dig axfr 10.168.192.in-addr.arpa//analog transport itab.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> axfr 10.168.192.in-addr.arpa ;; global options: +cmd ; Transfer failed. [root@slave ~]# dig axfr 10.168.192.in-addr.arpa @192.168.10.140 ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> axfr 10.168.192.in-addr.arpa @192.168.10.140 ;; global options: +cmd 10.168.192.in-addr.arpa. 3600 IN SOA ns1.itab.com. nsadmin.itab.com. 2017040102 3600 600 36000 43200 10.168.192.in-addr.arpa. 3600 IN NS ns1.itab.com. 10.168.192.in-addr.arpa. 3600 IN NS ns2.itab.com. 123.10.168.192.in-addr.arpa. 3600 IN PTR pop3.itab.com. 128.10.168.192.in-addr.arpa. 3600 IN PTR ns2.itab.com. 140.10.168.192.in-addr.arpa. 3600 IN PTR ns1.itab.com. 32.10.168.192.in-addr.arpa. 3600 IN PTR mx1.itab.com. 33.10.168.192.in-addr.arpa. 3600 IN PTR mx2.itab.com. 34.10.168.192.in-addr.arpa. 3600 IN PTR www.itab.com. 34.10.168.192.in-addr.arpa. 3600 IN PTR bbs.itab.com. 35.10.168.192.in-addr.arpa. 3600 IN PTR bbs.itab.com. 10.168.192.in-addr.arpa. 3600 IN SOA ns1.itab.com. nsadmin.itab.com. 2017040102 3600 600 36000 43200 ;; Query time: 1 msec ;; SERVER: 192.168.10.140#53(192.168.10.140) ;; WHEN: Sun Apr 2 13:47:01 2017 ;; XFR size: 12 records (messages 1, bytes 322)
However, other hosts are unable to access the database of the area on the main DNS server:
[root@www ~]# ip a # Other information is omitted. 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 inet 192.168.10.110/24 brd 192.168.10.255 scope global eth0 # The IP address of this host is 192.168.10.110. [root@www ~]# [root@www ~]# [root@www ~]# dig axfr itab.com @192.168.10.140 ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> axfr itab.com @192.168.10.140 ;; global options: +cmd ; Transfer failed. //Failed to retrieve database.