The NS record plays a vital role in the ZONE delegation. In the project, the NS record configuration error of the parent domain or the child domain is often encountered, causing various problems. In this issue, Cloud School analyzes the cause of the problem through scenario simulation, and gives specific suggestions and specifications for NS configuration. enjoy:
A real case
One day, the user asked the ZDNS expert team for help, and some of his group's domain names could not be resolved by some operators across the country, LDNS. After analysis, it was found that the final problem was caused by the irregular NS of the domain name. After the user performed DNS configuration according to the NS configuration recommendations, the related problems were completely solved. In the process of analyzing this case, we realized that: 1) NS specification configuration affects whether a DNS authority zone is legal, and NS configuration compliance should be paid attention to in daily operation and maintenance work; 2) How to regulate in various scenarios Configuring NS records is a common problem.
Scene simulation
Overview
The current network configuration is as follows (simulation environment), using three servers to simulate various roles in the DNS system:
1) Root + top-level domain server: 10.1.112.98
2) Secondary authoritative server: 10.1.112.54
3) Recursive server: 10.1.112.252 (root configuration points to 10.1.112.98)
On the recursive server: point the root server to 10.1.112.98 (the purpose is to make it not use the default 13 roots), so that the recursive server will start the request from our "test root + top-level domain".
Detailed configuration
The basic DNS configuration for each role is as follows:
1) Root + top-level domain server: 10.1.112.98 has the following records:
@Zone (root zone):
com ：
2) Secondary authoritative server: 10.1.112.54 has the following records:
Test.com authority area:
3) Recursive server: 10.1.112.252 has the following records:
Root configuration (pointing to root + top-level domain server):
Reminder: The basic configuration involves the creation of NS and A records. It is recommended to fully understand it before viewing.
Simulation analysis
The simulated client initiates the following parsing to the recursive server, creating parsing errors:
1)dig points to the recursive server: 10.1.112.252 requests www.test.com, normal response
2)dig points to the recursive server: 10.1.112.252 requests ns.test.com and responds to NXDOMAIN
3)dig points to the recursive server: 10.1.112.252 requests new1.test.com and responds to SERVFAIL
problem analysis
The following detailed analysis of the detailed logic of each request according to the diagram:
1) Normal response to request:
As can be seen from the above figure, the recursive server queries recursively according to the normal logic, and gets the final result to reply to the client.
2) Request ns.test.com, reply NXDOMAIN
The cache is the NS and NS_glue value of the top-level domain response, not the result of the authoritative server response. When the recursive server receives a request from ns.test.com., the recursive server will think that the NS_gule value of the top-level domain response cannot be responded to as an authoritative result. On the client side, the recursive server will again request the test.com authoritative server for the ns.test.com. domain name
3) Request new1.test.com and get a response from SERVFAIL
First understand the definition of SERVFAIL: "ServFail" is explained in [RFC 1035]:
The RCODE response code is 2: Server failure
The name server was unable to process this query due to a problem with the name server. (The name server was unable to process this query due to a problem with the name server.)
The Rcode field in the response in the data packet:
The most common thing is: DNS server resolution timeout response SERVFAIL, but the reason for this SERVFAIL is not due to resolution timeout. SERVFAIL reason analysis:
Request logic:
The specific reasons are:
1. In the third step of the second request, the result of the ns.test.com domain name request is NXDOMAIN, and the result of the test.com authoritative server has a higher priority than the top-level domain authoritative server. , This request caused the NS_gule of test.com on the recursive server to be set to NXDOMIAN state.
2. The recursive server can no longer initiate a new domain name to test.com during the period of time when NS_gule is set to the NXDOMIAN state (generally, this period is cached according to the minimum TTL in the SOA record in the authoritative zone of test.com) request! (Once such a problem occurs, the ability to quickly clear the error cache in the entire network is required to make the business quickly return to normal)
NS configuration recommendations and specifications
As above is a case sharing caused by non-standard NS, then there are the following configuration specification recommendations for NS configuration:
1) It is recommended that the parent domain and the child domain negotiate to configure the NS configuration, and the NS record should be consistent. The specification recommends the configuration:
Example: On the test.com authoritative DNS server, bjdc.test.com needs to be authorized to a third-party DNS server for authoritative resolution, then the following configuration is recommended:
Create the following records on the test.com authoritative DNS server:
bjdc.test.com NS ns.bjdc.test.com
ns.bjdc.test.com A <third-party DNS server>
Create the following records on the third-party authoritative server of ns.bjdc.test.com:
bjdc.test.com NS ns.bjdc.test.com
ns.bjdc.test.com A <third-party DNS server>
(That is to ensure: the domain name corresponding to NS can find the A record on the third-party authoritative server)
2) Due to special circumstances, the parent-child domain NS cannot be consistent, the specification recommends the configuration:
Example: On the test.com authoritative DNS server, bjdc.test.com needs to be authorized to a third-party DNS server for authoritative resolution, then the following configuration is recommended:
Create the following records on the test.com authoritative DNS server:
bjdc.test.com NS bjdcns.test.com
bjdcns.test.com A <third-party DNS server>
(That is to ensure: the domain name corresponding to NS can find the A record on the parent domain server)
3) As an Internet authority, fill in the public network address in the gule value corresponding to the NS record
