The concept and mechanism of domain name (3)

3.3.2. Algorithm

The algorithm used by the name server is related to the local operating system and the data structure, and the following algorithm assumes that the RR is organized in several tree structures, one is the area, and one tree is used for buffering:

1. is not the support loop query to see the server, if support, and need to loop query, go to step 5th;

2. Query the area closest to the QName ancestor's node, and if it is not found, move to step 4th;

3. Starting from top to bottom in the zone, the matching process ends with the following conditions:

• If the whole QName match, we'll find it. If the result of the data is Cname,qtype mismatch cname, the replication CNAME RR to the response area, the QName is changed to the standard form in the CNAME RR, then the 1th step is replicated, otherwise all matching Qtype RRs are copied to the response area and then 6th;

• If the result of the match allows us to leave the certification authority, we'll get a reference (referral), where we'll run into a node with an NS RR, replicate the NS RR to the response's authentication area, put whatever address in the other area, and if you don't get an address from the authentication data or buffer, You can use an associated RR. Then go to step 4th;

• If there is no match on some tags, see if there is a "*" tag exists, if the "*" tag does not exist, check the name we are looking for is not QName, if the name is the original QName, in the response set the error, otherwise quit. If "*" exists, match RR and Qtype, and if the match succeeds, copy them into the response, but set the owner of the RR (owner) as QName, not the node with "*", then go to step 6th;

1. To match in a buffer, if the QName is found in the buffer, copy all the associated and matching Qtype RRs to the response area, and if there is no authorization from the authentication authority, you can find the best one in the buffer, place it in the authentication area, and then go to step 6th;

2. Use local resolver to respond to requests. Save the results, including the middle CNAME, into the answer.

3. Using only local data, try adding other useful rrs to the additional part of the query. And then exit.

3.3.3. Wildcard

In the previous algorithm, we had special treatment for the RR that the owner started with *, which is called wildcards. The wildcard RR can be viewed as a synthetic RR, and the server creates a RR when the appropriate conditions are available, and the name of the RR is the same as the name of the query, and the content is obtained from the wildcard RR. This mechanism is often used to create a zone that can be used to forward messages from one messaging system to another on the network. In this case, the usual assumption is that all the names in the zone exist, as long as they do not say they do not exist.

The contents of the wildcard RR conform to the usual RR format, and the wildcard in the zone has a name of the owner that the controller can match. The owner of the wildcard RR is in the following form: "*.", which is any domain name, should not include other * tags, and it should be in the zone's authentication data. We can think of wildcard as wildcard characters. Wildcard RR does not apply in the following situations:

• The query should be in another area;

• If a domain already exists in the zone that it represents. For example, if the wildcard RR has "*. X ", the area includes the b.x, then the wildcard does not represent b.x,a.b.x or x, and can only represent z.x.

The * in the query name has no special effect, it is only used to detect wildcard in the authentication authority, such a query is only able to obtain a query request in the response including * in the owner name, and no response from the other request can contain *. The results of this query cannot be buffered. The contents of the wildcard RR should not be changed while the RR is being synthesized.

Here is an example where we assume that a large company has a large non-TCP/IP network to create a mail gateway. If the company is x.com and the TCP/IP gateway is a.x.com, the following RR may be in the COM zone:

X.com	Mx	10	A.x.com
*. X.com	Mx	10	A.x.com
A.x.com	A	1.2.3.4
A.x.com	Mx	10	A.x.com
*. A.x.com	Mx	10	A.x.com

For MX queries in all x.com, you will get a.x.com. The existence of two wildcard RR is necessary, because there is a.x.com, must have *. A.x.com, otherwise w.a.x.com will not be available for enquiries, for reasons please find in this section where the wildcard RR does not apply.

3.3.4. Negative response buffer (optional)

DNS can allow a server to provide a negative response buffer service in which the server returns a negative response and a ttl,resolver can assume that the same query will receive a negative response within the TTL time. Similarly, resolver can perform a query that configures multiple types and buffers nonexistent types.

The method is implemented when the server joins an SOA RR into the additional region of the response when the data is authenticated, and the SOA must be that zone, and the zone must be in the authentication authority of the data in the response, and the minimum domain of the SOA controls the time that the negative response is buffered. In some cases, the response data may include multiple owner names, and the SOA mechanism should be used to match QName data, which is the only authenticated data. Servers and Resovler should not attempt to add SOA to an additional area of the non-authenticated response, nor should there be any speculation.

This feature is optional, although it is now becoming more and more likely to be standard, but the server does not have to add SOA RR to all authentication responses, and resolver does not necessarily have to buffer negative results. All resolver and servers that support circular queries should be able to ignore SOA RRs.

Maintenance and transmission of 3.3.5. Area

Part of the job of the district administrator is to maintain the zone data on all servers. When modifications must be made, modifications must be made known to all name servers. This process can be done via FTP or some other process, and the recommended method is the method indicated by the zone Transfer section of the DNS protocol. The usual automatic update mode is a server that is the primary server for the zone, the administrator modifies the domain name file (master file), the administrator notifies the master server to load the new data, and the other non-primary servers synchronize with the primary server on a regular basis.

In order to know if any changes have occurred, the serial server must check the SOA domain, as long as there is a change, the serial domain will change, this change may be plus one, it may be some other algorithm, anyway changed on the line. Because the size of the field we are changing has a range, there must theoretically be a modified interval, and basically, the old copy must disappear when the serial number (that is, that field) finishes using half its space. In fact, as long as the comparison of the correctness of the operation can be.

Periodic synchronization of a non-primary server is determined by the parameters of the SOA RR in the Zone refresh,retry and expire. When a non-primary server is loaded into the new zone, it queries the primary server for a newer sequence number after the refresh second, and if the query fails to complete, it restarts every retry seconds. If the query gets the same serial number as the original serial number, you do not need to change it. Start again after the refresh interval. If a non-primary server cannot query after the expire interval, it must discard the existing zone data.

When the query knows that the data in the zone has changed, the non-primary server must request the primary server transfer data through the AXFR request. AXFR may be rejected to produce an error, but usually a series of response information is obtained. The first and last information must include the data for the zone's top authentication node. The information in the middle includes information about other RRs in the area, both certified and not certified. This data allows a non-primary server to obtain a copy of the zone data, because the data must be accurate and we must use a connection based protocol. The above query operations can be performed not only between the primary server and not the primary server, but also between the non-primary servers. This can improve the overall operational efficiency.

4. resolvers

4.1. Introduce

Resolver is the interface between the user program and the domain name server, in the simplest case, the resolver receives the request from the user, returns the query result which conforms to the local data format. Resolver and requesting the DNS service are on the same machine, but the DNS server is on the other machine, because resolver may query multiple name servers, all of which require a local buffer, and the time of the query may vary greatly depending on the specific query. An important function of resolver is that it has a buffer that multiple programs can share, and there are some query results that can be used to reduce repeated queries to the server.

4.2. Customer-resolver Interface

4.2.1. Typical functions

This interface varies by host, but there are three functions that everyone must have:

1. Host name to host address translation, which is commonly defined to simulate a function that was originally based on HOSTS.TXT. Given a string, returns a 32-bit IP address, which, under DNS, is converted to a RR request of type A. Because DNS does not preserve the order of RRS, functions are sorted to return one of the many addresses returned to the user. Please note: It is best to return multiple addresses, but a single address is a simulation of the original HOSTS.TXT service.

2. Host address to hostname conversion, given a 32-bit IP address, returns a string. Query using PRT query, host name plus "IN-ADDR." ARPA "suffix for query, such as IP address 1.2.3.4, then PTR RR query domain name" 4.3.2.1.in-addr. ARPA ".

3. Universal query function, the caller provides Qname,qtype and Qclass, and expects all matching RRS to return the query results using the DNS format rather than the native format, which includes the contents of all RRs.

When resolver executes the above function, the following results are returned to the customer:

• One or more RRs for the given request data, at which point Resovler returns the result in the appropriate format

• Name error (NE), which does not exist in the queried name is to return NE

• No data error found, query name exists, but the appropriate type of data does not exist when this error occurs, such as the use of the host address for the mailbox address will return an error

It should be noted that sometimes some functions can be merged into a different type of error when the name error and the data are not found in the query, but usually the function does not. One reason is that a program usually queries a first name (including type information), then another type of the same name, and if two errors are combined, the opposite will slow down the query.

4.2.2. Alias

When trying to parse a special name query, resolver may find that this is an alias, and if so, it will be returned to the customer. But often, when resolver encounters a CNAME, it starts a query again. However, resolver should not alias when performing normal functions and CNAME RR configuration query type. There are several special cases when aliases are available. Multiple-level names should be avoided because they are too inefficient, but they should not be returned to the customer as errors. For alias loops and aliases pointing to nonexistent names, the error should be returned to the customer.

4.2.3. Temporary error

Sometimes resolver may not be able to complete a request because of network and other reasons, and should not return without a name or query to such an error. This kind of mistake is a worry to the human user. The request can be blocked at some point, but this is not a good solution, especially when the server is ready to move on to other tasks. The recommended method is to return an error indicating that a temporary error is now occurring.

4.3. Resolver internal

The implementation of each resolver is different, there are complex logic to handle various errors, and this article only discusses a program.

4.3.1. Root (Stub) resolvers

One way to realize resolver is to implement on the server that supports circular query, which can save the resources on PC, and also can manage the query result buffer centrally. The other thing is to have a file that supports circular query server address on PC, PC has limited resources, so it may not be realistic to support a domain name database. The user must determine that the listed name server supports circular queries and that the server can refuse to make any client's circular query requests, so the user must check with the administrator. This type of service has some deficiencies, because the cyclic query is more time-consuming, the root of the UDP time to choose more difficult to determine, the server will be repeated due to the root of the crash. It might be nice to use TCP, but this can be a serious CPU time, and using TCP is equivalent to implementing a real-time query system.

4.3.2. Resources

In addition to its own resources, resolver can access the zone data that is saved by the local server. This speeds up the resolver, but it also allows the buffer data to flush out the area data. The local information in this article is the buffer and shared area data, and the authentication data should be used as a priority in the case of authenticated data and buffered data. The following algorithm assumes that all functions are converted to a common query function, using the following data structure to represent the status of the In-progress request:

Sname	The domain name to query
Stype	Qtype of Query requests
Sclass	Qclass of Query requests
Slist	Represents the name server and zone being queried, which holds resolver predictions, predicts where data is expected to be queried, and data in this structure changes as data is received. It includes a server address, a known server in the Zone, a history, and a tag indicating how far the query is from the target (the query starts down from the top of the tree until the target).
Sbelt	It comes in handy when resolver cannot know from local information which server should be queried.
CACHE	Save the results of the previous response because resolver discards the TTL-time RR, and most resolver implementations convert the time received for RRs to absolute time and then save them in a buffer, resolver can discard expired RRs as they are queried, or maintain them on a regular basis.