Linux should learn this way-DNS configuration

DNS domain name resolution service

Compared with IP addresses composed of numbers, domain names are easier to understand and remember, so we are usually more accustomed to accessing resources on the network through domain names. However, computers in the network can only identify each other's identities based on IP addresses, and if you want to transmit data on the Internet, you must also complete them based on the IP address of the external network.

In order to lower the threshold for users to access network resources, DNS (Domain Name System, Domain Name System) technology came into being. This is a technology used to manage and resolve the corresponding relationship between domain names and IP addresses. In simple terms, it is able to accept the domain name or IP address entered by the user, and then automatically find the matching (or mapping) IP address or Domain name, that is, resolve a domain name to an IP address (forward resolution), or resolve an IP address to a domain name (reverse resolution). In this way, we only need to enter the domain name in the browser to open the website we want to visit. The forward resolution of DNS domain name resolution technology is also one of our most commonly used working modes.

In view of the large database of the correspondence between domain names and IP addresses in the Internet, DNS domain name resolution service uses a hierarchical structure similar to a directory tree to record the correspondence between domain names and IP addresses, thus forming a distributed database system, such as As shown in Figure 13-1.

Chapter 13 uses Bind to provide domain name resolution services.  Chapter 13 uses Bind to provide domain name resolution services.

Domain name suffixes are generally divided into international domain names and domestic domain names. In principle, domain name suffixes have strict definitions, but they do not need to be strictly followed in actual use. At present, the most common domain name suffixes are .com (commercial organization), .org (non-profit organization), .gov (government department), .net (network service provider), .edu (teaching and research institution), .pub (public public) , .Cn (China's top-level domain name), etc.

DNS technology is an important part of the Internet infrastructure. In order to provide netizens with uninterrupted, stable and fast domain name query services and ensure the normal operation of the Internet, the following three types of servers are provided.

Main server : It is unique in a specific area and is responsible for maintaining the correspondence between domain names and IP addresses in that area.

Slave server : Obtain and maintain the correspondence between domain names and IP addresses from the master server to prevent downtime of the master server.

Cache server : Obtain the correspondence between domain names and IP addresses by querying other domain name resolution servers, and save frequently queried domain name information locally to the server to improve the efficiency of repeated queries.

To put it simply, the master server is the real server used to manage the correspondence between domain names and IP addresses. The slave servers help the master server to "lay hands" and are deployed in various countries, provinces, cities, or regions so that users can query domain names nearby, thereby reducing the need for the master server. The load pressure of the server. Cache servers are not commonly used, and are generally deployed at the gateway of the corporate intranet to speed up users' domain name query requests.

The DNS domain name resolution service adopts a distributed data structure to store a large amount of "regional data" information. When executing a domain name query request initiated by a user, it has two methods: recursive query and iterative query. The so-called recursive query means that when the DNS server receives a request initiated by the user, it must return an accurate query result to the user. If the DNS server does not store the corresponding information locally, the server needs to query other servers and submit the returned query results to the user. The iterative query means that when the DNS server receives the request initiated by the user, it does not directly reply to the query result, but tells the address of another DNS server, and the user submits the request to this DNS server. This is repeated in turn. Until the query result is returned.

It can be seen that after a user initiates a query request for a certain domain name to a nearby DNS server (here, www.linuxprobe.com is taken as an example), the query process is roughly as shown in Figure 13-2.

Chapter 13 uses Bind to provide domain name resolution services.  Chapter 13 uses Bind to provide domain name resolution services.

When a user initiates a domain name request to a DNS server designated by the network, usually the local DNS server sends an iterative query request to the higher-level DNS server; if the DNS server does not have the information to query, it will go further to the higher-level DNS The server sends iterative query requests until accurate query results are obtained

Install Bind service program

BIND (Berkeley Internet Name Domain) service is the most widely used, safest, reliable and efficient domain name resolution service program in the world. DNS domain name resolution service, as an Internet infrastructure service, has a heavy responsibility. Therefore, it is recommended that you add the chroot (commonly known as the cage mechanism) extension package when installing and deploying the bind service program in a production environment to effectively limit the bind service program. Can only operate on its own configuration file to ensure the security of the entire server

[root@myserver ~]# yum install bind-chroot
Installing:
bash: [root@my-server: command not found...
 bind-chroot                  x86_64                  32:9.11.4-16.P2.el8                   AppStream                   99 k
Installing dependencies:
 bind                         x86_64                  32:9.11.4-16.P2.el8                   AppStream                  2.1 M

Transaction Summary
=============================================================================================================================
Install  2 Packages

Total size: 2.2 M
Installed size: 4.7 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                     1/1
  Running scriptlet: bind-32:9.11.4-16.P2.el8.x86_64                                                                     1/2
  Installing       : bind-32:9.11.4-16.P2.el8.x86_64                                                                     1/2
  Running scriptlet: bind-32:9.11.4-16.P2.el8.x86_64                                                                     1/2
  Installing       : bind-chroot-32:9.11.4-16.P2.el8.x86_64                                                              2/2
  Running scriptlet: bind-chroot-32:9.11.4-16.P2.el8.x86_64                                                              2/2
/sbin/ldconfig: File /lib64/libdcerpc-samr.so.0.0.1 is empty, not checked.
/sbin/ldconfig: File /lib64/libdcerpc-samr.so.0 is empty, not checked.

  Verifying        : bind-32:9.11.4-16.P2.el8.x86_64                                                                     1/2
  Verifying        : bind-chroot-32:9.11.4-16.P2.el8.x86_64                                                              2/2
Installed products updated.

Installed:
  bind-chroot-32:9.11.4-16.P2.el8.x86_64                           bind-32:9.11.4-16.P2.el8.x86_64

Complete!
[root@myserver ~]#

The configuration of the bind service program is not simple, because if you want to provide users with a sound DNS query service, you must save the relevant domain name database locally, and if you write the correspondence between all domain names and IP addresses into a configuration file , It is estimated that there are tens of millions of parameters, which is not conducive to the efficiency of program execution, nor is it convenient for future modification and maintenance. Therefore, there are the following three more critical files in the bind service program.

Main configuration file (/etc/named.conf)

Zone configuration file (/etc/named.rfc1912.zones): the location used to save the correspondence between domain names and IP addresses.

Data configuration file directory (/var/named): The data configuration file used to save the real correspondence between domain names and IP addresses.

 In the Linux system , the name of the bind service program is named. First, you need to find the main configuration file of the service program in the /etc directory, and then modify the addresses on lines 11 and 19 to any, which means that all IP addresses on the server can provide DNS domain name resolution services, and allow Everyone sends a DNS query request to this server. These two places must be modified accurately.

The zone configuration file (/etc/named.rfc1912.zones) of the bind service program is used to save the location of the correspondence between the domain name and the IP address.

[root@myserver etc]# cat /etc/named
named/               named-chroot.files   named.conf           named.rfc1912.zon
[root@my-server etc]# cat /etc/named.rfc1912.zones
zone "localhost.localdomain" IN {
        type master;
        file "named.localhost";
        allow-update { none; };
};

zone "localhost" IN {
        type master;
        file "named.localhost";
        allow-update { none; };
};

zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
        type master;
        file "named.loopback";
        allow-update { none; };
};

zone "1.0.0.127.in-addr.arpa" IN {
        type master;
        file "named.loopback";
        allow-update { none; };
};

zone "0.in-addr.arpa" IN {
        type master;
        file "named.empty";
        allow-update { none; };
};

In this file, the file location and service type saved by the domain name and IP address resolution rules are defined, but it does not contain information such as the correspondence between the specific domain name and IP address. There are three types of services, namely hint (root zone), master (primary zone), slave (auxiliary zone), among which the commonly used master and slave refer to the master server and the slave server.

Forward resolution parameters that resolve domain names to IP addresses

Chapter 13 uses Bind to provide domain name resolution services.  Chapter 13 uses Bind to provide domain name resolution services.

Reverse resolution parameter to resolve IP address to domain name

Chapter 13 uses Bind to provide domain name resolution services.  Chapter 13 uses Bind to provide domain name resolution services.

In the following experiments, the main configuration file, area configuration file and data configuration file of the bind service program will be modified respectively. If you encounter a failure to start the bind service program in the experiment, you can execute the named-checkconf command and the named-checkzone command to check the syntax or parameter errors in the main configuration file and the data configuration file, respectively.

Forward analysis experiment

---DNS改为本地ip,否则优先级会变
[root@myserver named]# cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.1.88

In the DNS domain name resolution service, forward resolution refers to finding the corresponding IP address based on the domain name (host name).

Step 1 : Edit the zone configuration file . There are already some irrelevant parsing parameters in this file by default, which are intended to give users a reference. We can add the following parameters to the bottom of the zone configuration file. Of course, we can also clear all the original information in the file, and only keep our own domain name resolution information:

[root@myserver etc]# vi /etc/named.rfc1912.zones
zone "yhd.com" IN {
        type master;
        file "yhd.com.zone";
        allow-update { none; };
};

 Step 2 : Edit the data configuration file . We can copy a forward-analyzed template file (named.localhost) from the /var/named directory, and then fill in the corresponding data of the domain name and IP address in the data configuration file and save it. Remember to add the -a parameter when copying, which can retain the original file's owner, group, permission attributes and other information, so that the bind service program can read the file content smoothly:

[root@myserver named]# vim yhd.com.zone
$TTL 1D
@       IN SOA  yhd.com. root.yhd.com. (
                                        0       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
        NS      ns.yhd.com.
ns      IN  A   192.168.1.88
bbs     IN  A   192.168.1.88
www     IN  A   192.168.1.88

Step 3 : Check the analytical results. In order to verify the analysis results, you must first modify the DNS address parameters in the Linux system network card to the local IP address, so that you can use the DNS query service provided by this machine. The nslookup command is used to detect whether the DNS server can query the resolution records of the domain name and IP address, and then more accurately verify whether the DNS server has been able to provide services to users

[root@myserver named]# nslookup
> www.yhd.com
Server:		192.168.1.88
Address:	192.168.1.88#53

Name:	www.yhd.com
Address: 192.168.1.88

Reverse analysis experiment

In the DNS domain name resolution service, the role of reverse resolution is to resolve the IP address submitted by the user into the corresponding domain name information. It is generally used to shield all domain names bound to an IP address as a whole, and shield certain domain names. Spam sent. It can also perform reverse analysis for an IP address to roughly determine how many websites are running on it. When buying a virtual host, you can use this feature to verify whether the virtual host provider has a serious oversell problem.

Step 1 : Edit the zone configuration file . When editing the file, in addition to not writing the wrong format, you also need to remember the name of the data configuration file defined here, because you will need to create a file with the same name in the /var/named directory for a while. Reverse resolution is to resolve the IP address into the domain name format, so when defining the zone (zone), the IP address should be reversed, for example, it was originally 192.168.1.0, and the reverse should be 1.168.192, and only the IP should be written. The network bit of the address is fine. Add the following parameters to the back of the forward analysis parameters.


zone "yhd.com" IN {
type master;
file "yhd.com.zone";
allow-update { none; };
};

zone "1.168.192.in-addr.arpa" IN {
type master;
file "192.168.1.arpa";
allow-update { none; };
};

Step 2 : Edit the data configuration file . First copy a reverse-analyzed template file (named.loopback) from the /var/named directory, and then fill in the following parameters into the file. Among them, the IP address only needs to write the host bit.

[root@myserver named]# vim 192.168.1.arpa
$TTL 1D
@       IN SOA  yhd.com. root.yhd.com. (
                                        0       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
        NS      ns.yhd.com.
ns      A       192.168.1.88
88      PTR     www.yhd.com.

Step 3 : Check the analytical results. In the previous forward resolution experiment, the DNS address parameters in the system network card have been modified to the local IP address, so you can directly use the nslookup command to check the resolution results, and you can query the corresponding domain name information by entering the IP address.

[root@myserver ~]# nslookup
> www.yhd.com
Server:		192.168.1.88
Address:	192.168.1.88#53

Name:	www.yhd.com
Address: 192.168.1.88
> 192.168.1.88
88.1.168.192.in-addr.arpa	name = www.yhd.com.
> 

 Deploy from the server

As an important Internet infrastructure service, it is essential to ensure the normal operation of DNS domain name resolution services. Only in this way can a stable, fast and uninterrupted domain name query service be provided. In the DNS domain name resolution service, the slave server can obtain the specified zone data file from the master server, thus playing the role of backup resolution records and load balancing. Therefore, by deploying the slave server, the load pressure of the master server can be reduced, and users can also be improved. The query efficiency.

In this experiment, the operating systems and IP addresses used by the master server and the slave server are shown in Table 13-2.

Table 13-2 Operating system and IP address information used by the master server and the slave server respectively

Host name operating system IP address
Main server RHEL 8 192.168.1.88
Slave server RHEL 8 192.168.1.78

 

Step 1 : Allow the update request of the slave server in the zone configuration file of the master server, that is, modify the allow-update {host address allowed to update zone information;}; parameters, and then restart the DNS service program of the master server.

Install bind-chroot on the main server

root@slave1 ~]# yum install -y bind-chroot

Edit the main configuration file

options {
        listen-on port 53 { any; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        secroots-file   "/var/named/data/named.secroots";
        recursing-file  "/var/named/data/named.recursing";
        allow-query     { any; };

Zone profile

[root@myserver ~]# vim /etc/named.rfc1912.zones

zone "yhd.com" IN {
type master;
file "yhd.com.zone";
allow-update { 192.168.1.78; };
};

zone "1.168.192.in-addr.arpa" IN {
type master;
file "192.168.1.arpa";
allow-update { 192.168.1.78; };
};

Step 2 : Fill in the IP address of the master server and the area information to be captured in the slave server, and then restart the service. Note that the service type at this time should be slave (slave) instead of master (master). The masters parameter should be the IP address of the master server, and the file parameter defines the location to save the data configuration file after synchronizing the data. You can see the synchronized file in this directory later.

Install bind-chroot on the slave server

root@slave1 ~]# yum install -y bind-chroot

Edit the main configuration file

options {
        listen-on port 53 { any; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        secroots-file   "/var/named/data/named.secroots";
        recursing-file  "/var/named/data/named.recursing";
        allow-query     { any; };

Zone profile

[root@slave1 ~]# vim /etc/named.rfc1912.zones 

zone "yhd.com" IN {
type slave;
masters {192.168.1.88;};
file "slaves/yhd.com.zone";
};

zone "1.168.192.in-addr.arpa" IN {
type slave;
masters {192.168.1.88;};
file "slave/192.168.1.arpa";
};

Step 3 : Check the analytical results. When the DNS service program of the slave server is restarted, the data configuration file is generally automatically synchronized from the master server, and the file will be placed in the directory location defined in the zone configuration file by default. Then modify the network parameters of the slave server and modify the DNS address parameter to 192.168.1.78, so that the DNS domain name resolution service provided by the slave server itself can be used. Finally, you can use the nslookup command to see the analysis results smoothly ( don't forget to turn on the firewall for the main server )

[root@slave1 ~]# cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.1.78
[root@slave1 slaves]# systemctl restart named
[root@slave1 slaves]# ll
total 8
-rw-r--r--. 1 named named 286 Feb  7 00:41 192.168.1.arpa
-rw-r--r--. 1 named named 297 Feb  7 00:41 yhd.com.zone
[root@slave1 slaves]# 
[root@slave1 slaves]# nslookup 
> www.yhd.com
Server:		192.168.1.78
Address:	192.168.1.78#53

Name:	www.yhd.com
Address: 192.168.1.78
> 192.168.1.78
78.1.168.192.in-addr.arpa	name = www.yhd.com.
> 

 

Guess you like

Origin blog.csdn.net/yanghuadong_1992/article/details/113710359