5. Using NDS reverse name resolution with the IN-ADDR.APRA domain

1 DNS Resolver Functionality and General Operation

On the whole, name servers are undoubtedly the most important part of the DNS system. After all, they store all the data on the system, and when names are submitted to them, they actually provide the addresses we need. Without these servers, there would be no DNS, of course, and what is the use of servers if no one requests services? The clients in the system, known as resolvers, are also very important because they initiate the process of name resolution.

1.1 Name Resolution Service

The main task of a DNS resolver is to resolve. Although most people think that name resolution is just the process of converting names to IP addresses, this is only one of several resolution services. Below are several of the most typical DNS resolution types.

Standard Name ResolutionIt accepts a DNS name as input and determines its corresponding IP address.

Reverse Name ResolutionAccept an IP address and determine the associated name.

Email ResolutionAccepting the email address used in the message to determine where to send the email message.

1.2 Functions of Name Resolvers

Although there are other types of resolution activities, most name resolutions still use the standard type, which is our primary focus of discussion. To complete this task, name resolution needs to perform many related functions:

Providing User InterfaceUnder normal circumstances, name resolution generally does not require the explicit operation of a resolution software. When you enter a website in a web browser, name resolution is naturally executed. There is nothing magical about it. It is just an implicit call to the resolver. The web browser sees that you enter a name instead of an IP address, so it sends this name to the resolver and tells it: 'I want to resolve this name.' (Well, after all, etiquette is not a bad thing.) The resolver is responsible for performing the resolution and providing the IP address connected to that website to the web browser (here it doesn't seem to be transmitting the IP to the browser). Therefore, the resolver is an interface between the user (including human users and software users such as browsers) and the DNS system.

Generating and Sending QueryGiven a name to be resolved, the DNS resolver must use the DNS message transmission system to create an appropriate query, determine what type of resolution to perform, and then send the query to the appropriate name server.

Handling ResponseThe resolver must accept the response returned by the DNS server to which it sends the query and decide how to handle the information contained in the response. You will see that it may be necessary to contact multiple name servers to perform a specific name resolution.

The main clients in DNS are software modules called DNS name resolvers, which are responsible for accepting names from client software. They generate resolution requests to DNS servers, then process and return responses.

2. DNS Name Resolution Technology: Iterative Resolution and Recursive Resolution

Conventional name resolution converts a DNS name into an IP address, and at the highest level, this process can be considered to consist of two stages. In the first stage, we locate a server that contains the information we need, that is, the IP address corresponding to a specific name. In the second stage, we send a request to this server containing the name we want to resolve, and then this server returns the requested address.

The second stage is quite simple, but finding the appropriate server in the first stage may be more difficult because the name information of DNS servers is not centrally stored.

Because DNS name information is stored in the form of a distributed database on many servers, a single request/response communication is usually not sufficient to complete name resolution. Firstly, it is necessary to find the server that contains the information needed by the resolver, which often requires a series of message exchanges, starting from a root server and extending down to the specific server that contains the client's required resource records (RR).

2.1, Iterative Resolution

When a client sends an iterative request to a name server, this server will either respond to the request (i.e., the corresponding IP address) or respond with the name of another server that contains the required information or is closer to the information. The original client must then send a new request to this recommended server, (repeatedly) iterate the above process, and this process will continue until the correct server is found. As shown in the diagram below.

2.2, Recursive Resolution

When a client sends a recursive request to a name server, if the server contains the information it is looking for, it will return the actual answer as a response. If the server does not have the required information, it will take over the responsibility of finding the answer, becoming a client and representing the original client to send new requests to other servers, ultimately obtaining the information it wants (if the information is not available, it will send an error message), as shown in the diagram below.

There are two methods for name resolution in DNS: iterative resolution and recursive resolution. In iterative resolution, if a client sends a request to a server that does not contain the information it needs, the server will return a pointer to another name server, and then the client will send a new request to this server. In recursive resolution, if a client sends a request to a server that does not contain the required information, the server will take over the responsibility of sending requests to other servers to find the required records and return these records to the client. The server performing these operations acts as a client when sending its own requests to other servers.

3, Improving the Efficiency of DNS Name Resolution: Caching and Local Resolution

Iterative and recursive queries can both help us find the correct server, but they will take a lot of time. Since parsing is often required, it is beneficial to make some improvements to the basic parsing process to maximize efficiency as much as possible.

3.1, Motivation for High-Speed Query: Query Localization

There is a computer science principle called access locality that describes two common phenomena related to the use of computers (and networks). The first phenomenon, also known as spatial locality of access, observes that if a resource is close to another resource that was recently accessed, then it is likely to be accessed. The second phenomenon, known as temporal locality of access, refers to the fact that if a resource was recently accessed, it is likely to be accessed again.

Generally, these two phenomena are based on the theoretical foundation of caching in the computer field, and they are also the theoretical foundation for caching in DNS servers. The benefits brought by caching are also applicable to parsers, and many parsers also adopt a similar caching method to servers for execution.

3.2, Name resolver caching

Once a specific name is resolved on a specific client computer, it is cached and kept for use when needed next, which also eliminates the traffic and load on the DNS server (but it should be noted that not all resolvers perform caching). The duration a resource record (RR) is saved in the cache is specified by its Time to Live (TTL) value. In addition, the resolver does not cache certain results, such as reverse queries, and they may also not cache resolution results if the resolver suspects (for any reason) that the returned data is corrupted or unreliable.

3.3, Local resolution

It is very meaningful to submit the resolver's query request to the server and let this server first check if it can answer the query before querying the root server, because this not only provides a faster response to the client but also reduces the traffic on the Internet. This practice is called local resolution. For example, the hosts method on our own computers.

4, DNS name resolution process

4.1, A simple example of DNS name resolution

Assuming XYZ industries runs its own DNS server for the xyzindustries.com region, with the primary name server named ns1.xyzindustries.com and the secondary name server as ns2.xyzindustirs.com, Googleplex University runs its own DNS server for the google.edu domain, which has three subdomains: finerats.googleples.com, compscis.googleplex.com, and admin.googleplex.com. The compscis.googleplex.com subdomain is located in a separate area with a dedicated server, while the other two subdomains are located in the .googleplex.edu region.

Assuming you are an employee of XYZ industries and your client is responsible for managing the network department of Googleplex University. Now enter the web service address of this department in your own browser as www.net.compsic.googleplex.edu. This process will involve the following steps.

4.2, Modify resolution to handle aliases (CNAME records)

The CNAME record can be used to present a fixed and unchanging name of a device to the outside world, while also allowing the actual device corresponding to that name to change within the organization. When using a CAME, it is necessary to modify the process of name resolution by adding an additional step: first, resolve the alias to a canonical name, and then resolve the canonical name.

5. Using NDS reverse name resolution with the IN-ADDR.APRA domain

5.1. Initial method: reverse query

For reverse queries, the resolver sends a query, where it does not fill in a name and leave space for the server to fill in the IP address, but fills in an IP address and leaves space for the server to fill in the name. The server will check its RR and return the name to the resolver. When the scale of the Internet was relatively small, this method was also good, but now the scale of the network is very large, so this method is not feasible.

So, how should we perform a reverse query? Well, the problem is that servers are organized by name rather than by IP address. Therefore, the solution is as simple as that, organize servers by IP address. This does not mean that we want to delete the name hierarchy or copy all the servers, or any foolish ideas of that kind. On the contrary, we create an additional digital hierarchy that coexists with the name hierarchy, and then, using this hierarchy, we use a process usually called reverse name resolution to find names from numbers.

5.2. IN-ADDR.ARPA name structure for reverse resolution

The digital hierarchy of the Internet is implemented by a special domain located in the reserved .ARPA TLD, called IN-ADDR.APRA (IN-ADDR stands for Internet ADDRess). Previous articles have mentioned that .APRA was originally used for the transition of Internet hosts to DNS, and now it is used by Internet operators for various purposes.

In IN-ADDR.APRA, a special digital hierarchy covering the entire IP address space has been created

5.3. RR settings for reverse resolution

In this structure, we can now associate each record in the actual DNS namespace with a record in this namespace. We complete this work by using the pointer (PTR) RR type. For example, if the IP address of www.xyzindustries.com is 192.168.2.34, then the DNS server in the area will have an address (A) RR record to explain this situation. In the text file format, it may display information similar to the following:

www.xyzindustries.com  A  192.168.2.34

But within the IN-ADDR.ARPA domain, it will also have records like the following:

34.2.168.192 IN-ADDR.ARPA PTR www.xyzindustries.com

Note: DNS is case-insensitive.

6. DNS email support and mail exchange (MX) resource records

There is an application that has always been using DNS, but when we think of DNS, we often forget about it, that is email. In fact, email is more dependent on DNS than any other TCP/IP application. Consider that sometimes you may also enter an IP address in commands like tracerroute, or even enter an address in a browser, but you may never enter an email client like joe@192.168.23.25 to send anyone an email. You enter something like joe@qq.com, and DNS is responsible for figuring out where the email should be sent.

6.1, Special Requirements for Email Name Resolution

The email address resolution differs from other DNS applications for the following three reasons:

We may not want to send email to the machine specified by the address exactly.

We need to be able to change the server name without modifying the personal email address.

We need to be able to support multiple servers handling email.

To provide flexibility for all these places, a special DNS RR type called Mail Exchange (MX) records is defined.

6.2, Mail Exchange Records and Their Use

Each MX record specifies a particular mail server to handle incoming email for a specific domain. Once this record is established, the email resolution becomes very similar to the conventional resolution. Assuming you want to send a message to joe@qq.com, the basic process is as follows.

(1) Your email client program calls the resolver on the local machine to perform email resolution for joe@qq.com.

(2) Your local resolver and local DNS resolver follow the process introduced earlier in this chapter to find the authoritative server for joe@qq.com.

(3) The authoritative server finds the MX record for qq.com and responds indicating that mail.qq.com should be used for email.

Email cannot send any content to mail.qq.com yet; it still needs to obtain its IP address. Therefore, it also needs to resolve the domain name. The request is very likely to have arrived at the DNS name server that just handled the MX request. To eliminate the inefficiency of executing twice separately, the DNS name server can combine the information and can also specify multiple MX records for a specific domain, with each record pointing to the name of a different mail server. This provides redundancy; if one server fails, another can take over its work. DNS also supports assigning a priority value to each mail server, so that it can clearly specify which server is the primary mail server, which is the first backup server, which is the second backup server, and so on. DNS will choose the mail server with the highest priority.