Training Note _ch13_Use Bind to Provide Domain Name Resolution Service
At the end of the article, you will post your notebook photos.
The main contents of the article are as follows:
- DNS domain name resolution service
- Install and deploy the Bind service program
- Deployment of slave servers
- Secure Encrypted Transmission
- Deployment of Cache Server
- Separation and Analysis Technology
- Book Notes
DNS domain name resolution service
Domain names are easier to understand and remember than IP addresses made up of numbers, so people are more accustomed to accessing resources in the network through domain names. However, computers in the network can only identify each other based on IP address, and in order to transmit data in the Internet, they must also be based on the IP address of the external network.
DNS (Domain Name System) is a technology used to manage and parse the relationship between domain name and IP address. It can accept the domain name or IP address input by users, and then automatically find the matching (or mapping) IP address or domain name.
- Forward Resolution: Domain Name - > IP Address
- Reverse Resolution: IP Address - > Domain Name
DNS domain name resolution service adopts directory tree hierarchy structure:
Domain name suffixes are generally divided into international domain names and domestic domain names. In principle, domain name suffixes are strictly defined, but they can be used without strict compliance. At present, the most common suffixes of domain names are. com (commercial organization),. org (non-profit organization),. gov (government department),. net (network service provider),. edu (teaching and research institute),. pub (public), and. cn (China's top national domain name).
DNS provides three types of servers:
- Main server: It has uniqueness in a specific area and is responsible for maintaining the corresponding relationship between domain name and IP address in that area. (There are currently 13 real servers around the world for managing the correspondence between domain names and IP addresses)
- Slave server: Obtain the corresponding relationship between domain name and IP address from the master server and maintain it in case of downtime of the master server. (Dispersed deployment in various countries, provinces, cities or regions to allow users to query domain names nearby. Synchronize the corresponding relationship between domain name and IP address in the main server, reduce the pressure of the main server and speed up user requests.
- Cache Server: By querying other domain name resolution servers to obtain the corresponding relationship between domain name and IP address, and save frequently queried domain name information to the local server, in order to improve the efficiency of repeated queries. (Not commonly used, usually deployed in the enterprise intranet gateway location, used to speed up user domain name query requests)
Specific information on 13 root DNS servers: (there is only one root DNS server in Japan in Asia)
| Name | Management Unit | geographical position | IP address |
| A | INTERNIC.NET | USA-Virginia | 198.41.0.4 |
| B | American Institute of Information Science | USA-California | 128.9.0.107 |
| C | PSINet Company | USA-Virginia | 192.33.4.12 |
| D | University of Maryland | Maryland, USA | 128.8.10.90 |
| E | NASA | California, USA | 192.203.230.10 |
| F | Internet Software Alliance | California, USA | 192.5.5.241 |
| G | DOD Network Information Center | Virginia | 192.112.36.4 |
| H | United States Army Research Laboratory | Maryland, USA | 128.63.2.53 |
| I | Autonomica Corporation | Sweden-Stockholm | 192.36.148.17 |
| J | VeriSign Corporation | USA-Virginia | 192.58.128.30 |
| K | RIPE NCC | UK-London | 193.0.14.129 |
| L | IANA | USA-Virginia | 199.7.83.42 |
| M | WIDE Project | Japan-Tokyo | 202.12.27.33 |
Install and deploy the Bind service program
BIND (Berkeley Internet Name Domain) service is the most widely used, secure, reliable and efficient domain name resolution service program in the world. It is suggested to add chroot extension package when deploying bind service program in production environment, so as to effectively restrict the bind service program to operate only on its own configuration file, so as to ensure the security of the whole server.
Install the bind service program: Yum install-y bind-chroot
There are three key files in the bind service program:
- Main configuration file (/etc/named.conf): The parameters inside are used to define the operation of the bind service program.
- Zone Profile (/etc/named.rfc1912.zones): The location where the domain name and IP address correspond. Corresponding to the specific location of each domain and corresponding IP address, when it needs to be viewed or modified, relevant files can be found according to this location.
- Data Profile Directory (/ var/named): This directory is used to save the data profile that corresponds to the real relationship between domain name and IP address.
The name of the bind service program is named. Before deploying the bind service, the main configuration file/etc/named.conf of the bind service program should be modified so that all IP addresses on the server can provide DNS domain name resolution service and allow everyone to send DNS query requests to the server.
vim /etc/named.conf #In lines 11 and 17, the address is changed to any ... 11 listen-on port 53 { any; }; #All IP addresses on the server can provide DNS domain name resolution services. The original value is 127.0.01. ... 17 allow-query { any; }; #Allow everyone to send DNS query requests to this server. The original value is localhost ...
If you encounter a failure to start the bind service program, you can execute the following commands:
- The named-checkconf command: Check for grammar or parameter errors in the bind service program master configuration file/etc/named.conf.
- The named-checkzone command: Check for syntax or parameter errors in the bind service program data configuration file / var / named / xxx.
Experiments on forward and backward analytical configuration
Forward (domain name / host name - > IP), reverse (IP - > domain name).
Configuration forward and backward parsing requires editing area profiles and data profiles.
Step 1: Edit the area profile (/etc/named.rfc1912.zones).
The area profile is used to store the location of the corresponding relationship between domain name and IP address. In this file, the location of the file and the type of service saved by the rules of domain name and IP address resolution are defined, but no specific information such as domain name and IP address correspondence is included. There are three types of services, hint (root region), master (main region), slave (auxiliary region), in which master and slave refer to the master server and slave server.
vim /etc/named.rfc1912.zones zone "linuxprobe.com" IN { #Forward analytical parameters type master; #Service Type as Master Server file "linuxprobe.com.zone"; #Domain name and IP File location saved by address resolution rules(/var/named/linuxprobe.com.zone) allow-update {none;}; #Which clients are allowed to dynamically update the parsing information (no one is allowed here) }; zone "10.168.192.in-addr.arpa" IN { #Reverse analytic parameters,Representation 192.168.10.0./24 Reverse Analytical Region of Network Segments type master; file "192.168.10.arpa"; };
Step 2: Edit the data configuration file (var/named/xxx). (File names have been customized when editing regional profiles)
Copy a forward parsed template file (named.localhost) from the / var / name directory and a reverse parsed template file (named.loopback). Then the corresponding data of domain name and IP address are filled in the data configuration file and saved. When copying with the cp command, we must add - a parameter to keep the information of the original file's owner, affiliated group, permission attributes and so on. The permission here is very important! In order to make the bind service program read the file content smoothly.
Note that the last "..." of the domain name is usually omitted for convenience when entering the web address, but it cannot be omitted when configuring dns.
cd /var/named/ cp -a named.localhost linuxprobe.com.zone cp -a named.loopback 192.168.10.arpa vim linuxprobe.com.zone #Edit forward parsing data profile $TTL 1D #The life cycle is1 day @ IN SOA linuxprobe.com. root.linuxprobe.com. ( #Start Of Authority Domain Name Administrator Mailbox 0 ; serial #Update Sequence Number (which serves as the basis for slave and master updates and is usually set by date) 1D ; refresh #Update time (how often does the command slave actively update) 1H ; retry #Retry delay (the interval between retries when refresh time is reached but slave cannot connect to master) 1W ; expire #Failure time (command after expire time when slave has been unable to connect to master) 3H); minimum #Cache time of invalid parsing records (time saved in the database and TTL without specified lifetime data) NS ns.linuxprobe.com. #Name Server (NS must be followed by the host name) ns IN A 192.168.10.10 #Address record (A denotes a forward parsing tag in [hostname] IN A [IP]) IN MX 10 mail.linuxprobe.com. #Mailbox Exchange Record (MX is related to Mail Server for mail forwarding. The smaller the value after MX, the higher the priority. The host name must have an A record after MX) mail IN A 192.168.10.10 www IN A 192.168.10.10 bbs IN A 192.168.10.20 vim 192.168.10.arpa #Edit reverse parsing data configuration file $TTL 1D @ IN SOA linuxprobe.com. root.linuxprobe.com.( 0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H); minimum NS ns.linuxprobe.com. ns A 192.168.10.10 10 PTR ns.linuxprobe.com. #PTR is a pointer record and is only used for reverse parsing (format: [IP] IN PTR [host name]) 10 PTR mail.linuxprobe.com. 10 PTR www.linuxprobe.com. 20 PTR bbs.linuxprobe.com.
Step 3: Modify the DNS address of the network card to the IP address of the machine, restart the network card service and name service, and check the forward and backward parsing results with the nslookup command.
The nslookup command is used to detect whether the parsed records of domain names and IP addresses can be queried from the DNS server, and then to more accurately verify whether the DNS server has been able to provide services for users.
vim /etc/sysconfig/network-scripts/ifcfg-eno16777728 #Modifying Network Card Parameters ... DNS=192.168.10.10 #hold DNS Change address to local machine ip address ... systemctl restart network #Restart Network Card Service systemctl restart named #Restart the name service nslookup >www.linuxprobe.com #It shows that the server providing forward parsing is 192.168.10.10, and the IP is 192.168.10.10. >bbs.linuxprobe.com #Resolve IP: 192.168.10.20 >mail.linuxprobe.com #Resolve IP: 192.168.10.10 >192.168.10.10 #The server that provides reverse parsing is 192.168.10.10, and the domain name is resolved: ns/www/mail.linuxprobe.com. >192.168.10.20 #Resolve the domain name: bbs.linuxprobe.com.
Deployment of slave servers
Based on the experiment in the previous section, the client 192.168.10.20 is used as the slave server to synchronize the data configuration files from the master server 192.168.10.10.
Changes to be made to the main server 192.168.10.10:
- Change the zone profile of the primary server to allow it to specify update requests from the slave server, and then restart the DNS service program.
- If the slave server is well configured and the DNS service is restarted many times, but it is still unable to synchronize the data configuration file from the master server, the iptables firewall of the master server is cleared.
vim /etc/named.rfc1912.zones #Change the zone profile of the primary server to allow it to specify update requests from the slave server zone "linuxprobe.com" IN { type master; file "linuxprobe.com.zone"; allow-update { 192.168.10.20; }; #Allow update requests from 192.168.10.20 }; zone "10.168.192.in-addr.arpa" IN { type master; file "192.168.10.arpa"; allow-update { 192.168.10.20; }; }; systemctl restart named #Restart the name service iptables -F #Clear the iptables firewall service iptables save
Work to be done from the server:
- Install the bind service program;
- Edit the master configuration file so that all IP addresses on the server can provide DNS domain name resolution service and allow everyone to send DNS query requests to the server.
- Edit the area profile and fill in the IP address of the main server and the area information to be grabbed.
- Modify the network card DNS to local IP, restart the network card service and DNS service.
yum install -y bind-chroot vim /etc/named.conf ... 11 listen-on port 53 { any; }; ... 17 allow-query { any; }; ... vim /etc/named.rfc1912.zones #Editing Area Profile zone "linuxprobe.com" IN { type slave; #slave Server Type masters { 192.168.10.10; }; #Specify the ip address of the primary server file "slaves/linuxprobe.com.zone"; #Specify where to store synchronized data profiles }; zone "10.168.192.in-addr.arpa" IN { type slave; masters { 192.168.10.10; }; file "slaves/192.168.10.arpa"; }; vim /etc/sysconfig/network-scripts/ifcfg-eno16777728 #Modify Network Card DNS Parameters ... DNS=192.168.10.20 ... systemctl restart network #Restart Network Card Service systemctl restart named #Restart the name service cd /var/named/slaves #Enter the storage location of the synchronous data profile / var/named/slaves ls #See the corresponding data configuration file (the content is encrypted), indicating that the synchronization is successful. nslookup #Verify that the DNS parsing service is provided by the local machine itself? >192.168.10.10 >www.linuxprobe.com #It shows that DNS parsing is provided by 192.168.10.20, and the corresponding IP is 192.168.10.10.
Secure Encrypted Transmission
In order to provide secure parsing services, the bind service program has provided support for TSIG (RFC 2845) encryption mechanism. TSIG mainly uses cryptographic encoding to protect the transmission of domain information (Zone Transfer), that is, TSIG encryption mechanism ensures the security of domain name area information transmission between DNS servers.
On the basis of the experiment in the previous section, TSIG encryption transmission function is configured so that only the slave server with the same key authentication file as the master server can update DNS information from the master server.
Dnssec-keygen command: Used to generate secure DNS service key, format: dnssec-keygen [parameter].
Common parameters of the dnssec-keygen command:
| parameter | Effect |
| -a | Specified encryption algorithms, including RSAMD5 (RSA), RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA, etc. |
| -b | Key length (HMAC-MD5 key length is between 1 and 512 bits) |
| -n | Types of keys (HOST denotes host-related) |
What the main server should do:
- Generate DNS service key (public key + private key), view the generated private key file, and copy key parameter values;
- Enter the bind service program to save the configuration file directory / var/named/chroot/etc/, and create the key authentication file tansfer.key. Make a hard link to the / etc directory. For the sake of security, change the file group to named to reduce file permissions.
- Turn on and load the key authentication function of Bind service. First load the key verification file in the master configuration file of the master server, then set it up so that only DNS servers with master-slave key authentication can synchronize the data configuration file and restart the name service.
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST master-slave #Generate a 128-bit HMAC-MD5 key file with master-slave name (public key + private key) ls -al Kmaster-slave.+157+46845.* #Using wildcards to view the generated key file, there will be a private key file (suffix private) and a public key file (suffix key) cat Kmaster-slave.+157+46845.private #View the private key file and copy the key parameter values ... Key: 1XEEL3tG5DNLOw+1WHfE3Q== ... cd /var/named/chroot/etc/ #Get into bind The directory used by the service program to save configuration files vim transfer.key #Create a key authentication file key "master-slave" { #Key name algorithm hmac-md5; #encryption algorithm secret "1XEEL3tG5DNLOw+1WHfE3Q=="; #Private key encrypted string }; chown root:named transfer.key #Change the file group to named chmod 640 transfer.key #Reduce file permissions ln transfer.key /etc/transfer.key #Create a hard link to a key authentication file/etc Catalogue(When configuring the master configuration file, the key authentication file must be/etc Catalog) vim /etc/named.conf #Edit the master configuration file of the bind service to open and load the key authentication function of the Bind service ... 9 include "/etc/transfer.key"; #Key authentication files must be in / etc directory 18 allow-transfer { key master-slave; }; #Only those who own the key authentication file are allowed to synchronize ... systemctl restart named #Restart the bind service program
Then, empty the data configuration file synchronized from the primary server in the server / var/named/slaves directory, and restart the bind service, and find that the data configuration file can no longer be retrieved from the primary server.
rm -rf /var/named/slaves/* #Empty all data profiles in the directory systemctl restart named #Restart the bind service ls /var/named/slaves #Looking at the slaves directory again, we found that it was still empty, at which point the data configuration file could no longer be retrieved from the primary server from the server.
Work to be done from the server:
- Create a key authentication file in the configuration file directory of the bind service program (the steps and parameters are the same as those in the master server), set the corresponding permissions, and then make a hard link to the / etc directory.
- Turn on and load the key validation function of the slave server (slightly different from the settings in the master server). Load the key authentication file in the main configuration file, then write the IP address and key name of the main server in the specified format, and restart the bind service.
cd /var/named/chroot/etc #Enter the configuration file directory of the bind service program vim transfer.key #Create a key authentication file (the same parameters as the primary server's key authentication file) key "master-slave" { algorithm hmac-md5; secret "1XEEL3tG5DNLOw+1WHfE3Q=="; }; chown root:named transfer.key chmod 640 transfer.key ln transfer.key /etc/transfer.key #Create hard links to key authentication files vim /etc/named.conf ... 9 include "/etc/transfer.key"; ... 43 server 192.168.10.10 #Specifies the IP address and key name of the primary server 44 { 45 keys { master-slave; }; 46 }; ... systemctl restart named ls /var/named/slaves/ #After restarting the bind service, look at the slaves directory and synchronize from the primary server to the data configuration file
Deployment of Cache Server (Understanding only, unsuccessful experiments are common)
DNS Caching DNS Server is a DNS server that is not responsible for domain name data maintenance. Cache servers store parsing records of domain names and IP addresses frequently used by users locally in order to improve the efficiency of the next parsing (at most millisecond level, not significant). DNS caching servers are generally used in enterprise intranets where some fixed sites are frequently accessed and the speed of accessing these sites is high, but the actual application is not extensive.
This experiment is very simple, the configuration is not bad, but as to why the client can not parse dns, it may be that the superior DNS server does not allow synchronization of DNS information. The upper DNS server address refers to the server that gets the data profile.
The cache server prepares two network cards, one for bridging (access to the external network), one for host mode only (communication between hosts only), and one for client mode only. As long as the client can resolve the DNS of the external network, it means that the domain name resolution service must be provided by the cache server.
What the cache server needs to do: configure the main configuration file of the bind service program, add cache forwarding parameters, and restart the bind service.
vim /etc/named.conf ... 17 forwarders { 8.8.8.8; }; #The address of the superior DNS server is best ping test, ping reuse ... systemctl restart named #Restart the bind service
What the client needs to do: modify the parameters of the network card, change the DNS address to the IP of the cache server, and restart the network card.
vim /etc/sysconfig/network-scripts/ifcfg-eno16777728 ... DNS=192.168.10.10 ...
systemctl restart network
Subsequently, the client uses nslookup to test the extranet website to verify whether DNS can be parsed.
Separation and Analysis Technology
When a website becomes more and more popular and has users both at home and abroad, only deploying the website in one place will inevitably cause some users to visit very slowly. Therefore, highly well-known websites usually need to deploy servers all over the world. Through the separation and parsing function of DNS services, readers located in different geographical areas can access the same website, but never. The same server gets the same data.
Illustration:
What DNS servers need to do:
- Two network cards are equipped with only host mode, addresses are 122.71.115.10 (Beijing) and 106.185.25.10 (USA), respectively.
- Configure the main configuration file for the bind service. Delete 51-54 rows of root domain information (DNS separation parsing function and DNS root server configuration parameters conflict);
- Edit area profile;
- Establish the data configuration file (forward parsing) and restart the bind service.
vim /etc/named.conf #Configure the master configuration file for the bind service ... 11 listen-on port 53 { any; }; ... 17 allow-query { any; }; ... 51 # zone "." IN { #Annotations are equivalent to deleting, deleting the root domain information 52 # type hint; 53 # file "named.ca"; 54 # }; vim /etc/named.rfc1912.zones #Editing Area Profile 1 acl "china" { 122.71.115.0/24; }; #Use acl Parameters define two variable names, respectively( china and american)，Follow-up parameterschina=122.71.115.0/24 2 acl "american" { 106.185.25.0/24; }; 3 view "china"{ #By determining which segment the user's IP address belongs to, then load different data profiles (linuxprobe.com.china or linuxprobe.com.american) separately. 4 match-clients { "china"; }; 5 zone "linuxprobe.com" { #Conventional definition of zone parameters 6 type master; 7 file "linuxprobe.com.china"; 8 }; 9 }; 10 view "american" { 11 match-clients { "american"; }; 12 zone "linuxprobe.com" { 13 type master; 14 file "linuxprobe.com.american"; 15 }; 16 }; cd /var/named #Enter the directory where the data configuration files are stored cp -a named.localhost linuxprobe.com.china #Duplicate two forward parsing templates cp -a named.localhost linuxprobe.com.american vim linuxprobe.com.china $TTL 1D @ IN SOA linuxprobe.com. root.linuxprobe.com. ( 0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ;) minimum NS ns.linuxprobe.com. ns IN A 122.71.115.10 www IN A 122.71.115.15 vim linuxprobe.com.american $TTL 1D @ IN SOA linuxprobe.com. root.linuxprobe.com. ( 0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ;) minimum NS ns.linuxprobe.com. ns IN A 106.185.25.10 www IN A 106.185.25.15 systemctl restart named #Restart bind Payment
What the client needs to do:
The network card addresses are 122.71.115.1 (Beijing) and 106.185.25.1 (USA), respectively. The DNS addresses are set as two IP addresses of the server host: 122.71.115.10 (Beijing) and 106.185.25.10 (USA), and the nslookup test is carried out.
Book Notes
