DNS domain name resolution

Related Tags：1.Alibaba Cloud DNS
2. Alibaba Cloud DNS PrivateZone

1. Domain Name System

1. Overview of the Domain Name System

Domain Name System DNS (Domain Name System) is a naming system used by the Internet to convert machine names that are easy for people to use into IP addresses. The Domain Name System is actually the name system. Why is it called "domain name" instead of "name"? This is because many "domains" are used in this Internet naming system, hence the term "domain name". The "Domain Name System" clearly indicates that such a system is used in the Internet.

We all know that IP addresses are composed of 32-bit binary numbers. When a user communicates with a host on the Internet, it is obviously unwilling to use a binary host address of up to 32 bits that is difficult to remember. Even dotted decimal IP addresses are not very easy to remember. Instead, people prefer to use host names that are easier to remember. However, when processing IP datagrams, machines do not use domain names but IP addresses. This is because the length of the IP address is fixed, while the length of the domain name is not fixed, which makes it more difficult for the machine to process.

Because of the size of the Internet, it is not feasible to use only one domain name server for the entire Internet. Therefore, as early as 1983, the Internet began to adopt the naming method of hierarchical tree structure and use the distributed domain name system DNS. And use the client-server approach. DNS enables most names to be resolved locally, and only a few resolutions need to be communicated over the Internet, so the DNS system is very efficient. Since DNS is a distributed system, even if a single computer fails, it will not hinder the normal operation of the entire DNS system.

The resolution of domain names to IP addresses is done by many domain name server programs distributed on the Internet. The domain name server program runs on a dedicated node, and people often refer to the machine running the domain name server program as a domain name server.

The main points of the domain name to IP address resolution process are as follows: when an application needs to resolve the host name to an IP address, the application process calls the resolver, and is called a client of DNS, and puts the domain name to be resolved in the DNS request. In the packet, it is sent to the local domain name server in the form of UDP user datagram. After the local domain name server searches for the domain name, it returns the corresponding IP address in the reply message. The application can communicate after obtaining the IP address of the destination host.

If the local domain name server cannot answer the request, the domain name server is temporarily called another client of DNS and sends a query request to other domain name servers. This process continues until a domain name server is found that can answer the request. This process is discussed further below.

2. Internet Domain Name Structure

Due to the large number of Internet users, the Internet adopts a hierarchical tree structure naming method. Any host or router connected to the Internet has a unique hierarchical name, the domain name. Here, a "domain" is a manageable division of the namespace.

Syntactically, each domain name consists of a sequence of labels, and each label is separated by a dot (decimal point).

As shown in the following example:

This is the domain name of the computer used by CCTV to manipulate e-mail. It consists of three labels. The label com is the top-level domain name, the label cctv is the second-level domain name, and the label mail is the third-level domain name.

DNS stipulates that the labels in the domain name are composed of English and numbers, and each label does not exceed 63 characters (for the convenience of memory, generally no more than 12 characters), and does not distinguish between uppercase and lowercase letters. No punctuation marks other than hyphens (-) can be used in labels. The lowest-level domain names are written on the far left, and the highest-level characters are written on the far right. A full domain name consisting of multiple labels should not exceed 255 characters in total. DNS neither specifies how many subordinate domain names a domain name needs to contain, nor does it specify what each level domain name means. Domain names at all levels are managed by their higher-level domain name management agencies, while the highest top-level domain names are managed by ICANN. In this way, each domain name can be unique across the Internet, and it is also easy to design a mechanism for finding domain names.

A domain name is only a logical concept and does not represent the physical location where a computer is located. According to statistics in December 2006, there are now 265 TLDs (Top Level Domains), which are divided into three categories:

(1) National top-level domain name nTLD: adopt the provisions of ISO3166. Such as: cn for China, us for the United States, uk for the United Kingdom, and so on. The country domain name is often recorded as ccTLD (cc means country code contry-code).

(2) Generic top-level domain name gTLD: There are 7 most common generic top-level domain names, namely: com (company), net (network service organization), org (non-profit organization), int (international organization), gov (United States of America) government departments), mil (military departments of the United States).

(3) Infrastructure domain: There is only one such top-level domain name, arpa, which is used for reverse domain name resolution, so it is called a reverse domain name.

3. Domain Name Server

If the above-mentioned tree structure is adopted, each node adopts a domain name server, which will make the number of domain name servers too large and reduce the operation efficiency of the domain name server system. Therefore, in DNS, the method of dividing the area is used to solve the problem.

The area in which a server is responsible (or has authority) is called a zone. Each unit divides the area under its jurisdiction according to the specific situation. But all nodes in a zone must be able to connect. Each zone is set with a corresponding authority domain name server, which is used to store the mapping from all hosts in the zone to the domain name IP address. In short, the jurisdiction of the DNS server is not in "domain", but in "zone". A zone is the actual jurisdiction of the DNS server. region <= domain.

The figure below is an example of the different division methods of districts. Suppose abc company has subordinate departments x and y, there are three distributions u, v, w under department x, and there is subordinate department t under y. Figure a shows that abc company has only one area abc.com. This is, the zone abc.com and the domain abc.com refer to the same thing. But Figure b shows that the abc company is divided into two areas: abc.com and y.abc.com. Both of these two zones belong to the domain abc.com, and each has its own authoritative domain name server. It is not difficult to see that regions are subsets of domains.

The following figure is an example of the two areas divided by abc company in the above figure b, and the tree structure diagram of the DNS domain name server is given. This DNS domain name server tree structure diagram can more accurately reflect the distributed structure of DNS. Each domain name server in the figure is capable of partial domain name to IP address resolution. When a DNS server cannot perform domain name to IP address translation, it will try to find other domain name servers on the Internet for resolution.

As can be seen from the figure below, DNS servers on the Internet are also arranged in layers. Each name server only has jurisdiction over a part of the domain name system. According to the role of the domain name server, the domain name server can be divided into the following four different types.

Root name server: The highest-level name server and the most important name server. All root nameservers know the domain names and IP addresses of all top-level nameservers. No matter which local domain name server it is, if you want to resolve any domain name on the Internet, as long as you cannot resolve it yourself, you must first turn to the root domain name server. So the root name server is the most important name server. Assuming all root nameservers are down, the entire DNS system cannot work. It should be noted that in many cases, the root domain name server does not directly resolve the IP address of the domain name to be queried, but tells the local domain name server which top-level domain name server should be queried next.

Top-level domain name server: Responsible for managing the second-level domain names registered with the top-level domain name server.

Authoritative nameservers: Nameservers responsible for a "zone".

Local Domain Name Servers: Local servers do not belong to the hierarchy of domain name servers shown in the figure below, but they are very important to the Domain Name System. When a host sends a DNS query request, the query request message is sent to the local domain name server.

4. Domain name resolution process

Notice:

1. The host's query to the local domain name server is generally a recursive query. The so-called recursive query is: if the local domain name server inquired by the host does not know the IP address of the queried domain name, then the local domain name server will continue to send query request messages to other root domain name servers as a DNS client (that is, continue for the host. query), rather than letting the host do the next query itself. Therefore, the query result returned by the recursive query is either the IP address to be queried, or an error is reported, indicating that the required IP address cannot be queried.

2. Iterative query of the query from the local domain name server to the root domain name server. Features of iterative query: When the root domain name server receives the iterative query request message from the local domain name server, it either gives the IP address to be queried, or tells the local server: "Which domain name server should you query next?" . Then let the local server do subsequent queries. The root domain name server usually tells the local domain name server the IP address of the top-level domain name server that it knows, so that the local domain name server can query the top-level domain name server. After receiving the query request from the local domain name server, the top-level domain name server either gives the IP address to be queried, or tells the local server which authoritative domain name server to query next. Finally, know the IP address to be resolved or report an error, and then return the result to the host that initiated the query.

The following figure shows the difference between the two queries

The following is an example to demonstrate the entire query process:

Suppose a host with the domain name m.xyz.com wants to know the IP address of another host, y.abc.com. For example, the host m.xyz.com intends to send mail to y.abc.com. At this point, you must know the IP address of the host y.abc.com. The following are several query steps in Figure a above:

1. The host m.abc.com first performs a recursive query to the local server dns.xyz.com.

2. The local server adopts iterative query. It first queries a root name server.

3. The root domain name server tells the local server the IP address of the top-level domain name server dns.com that should be queried next.

4. The local domain name server queries the top-level domain name server dns.com.

5. The top-level domain name server dns.com tells the local domain name server the IP address of the authority server dns.abc.com that should be queried next.

6. The local domain name server queries the authority domain name server dns.abc.com.

7. The authority domain name server dns.abc.com tells the local domain name server the IP address of the queried host.

8. The local domain name server finally tells m.xyz.com the query result.

The entire query process shares 8 UDP packets.

In order to improve the efficiency of DNS query, reduce the load of the server and reduce the number of DNS query packets on the Internet, a cache is widely used in the domain name server to store the recently queried domain names and records of where to obtain the domain name mapping information. .

For example, in the above query process, if a user on the host of m.xyz.com has already queried the IP address of y.abc.com not long ago, then the local domain name server does not need to re-query the root domain name server for y.abc .com IP address, but directly tell the user the result of the last query stored in the cache (that is, the IP address of y.abc.com).

Since name-to-address bindings do not change very often, to keep telling the cache what is correct, the nameserver should set a timer for each item and process items older than a reasonable amount of time (eg two days per item). When the domain name server has deleted a certain information from the cache and is requested to query the information, it must bind the information to the domain name server authorized to manage the item again. When the authority server answers a query request, the time value for which the binding is valid is indicated in the response. Increasing this time value can reduce network overhead, and reducing this time value can improve the correctness of domain name resolution.

Caching is required not only in the local nameserver, but also in the host. Many hosts download their entire database of names and addresses from a local server at startup, maintain a cache of their most recently used domain names, and use nameservers only if the name is not found in the cache. Hosts that maintain local nameserver databases should periodically check nameservers for new mapping information, and hosts must delete invalid entries from their caches. Since domain name changes are infrequent, most outlets can maintain database consistency without much effort.


Detailed explanation of DNS resolution process

Several basic concepts of DNS:

one. root domain

It is the so-called ".". In fact, our website www.baidu.com should be www.baidu.com. has become a habit.

We know there are 13 root domain servers, but that's the wrong idea.

The root domain server only has 13 IP addresses, but the number of machines is not 13. Because these IP addresses use anycast technology, we can set up mirror sites of these IPs around the world. The IP you visit is not the only one of that host.

The specific mirror distribution can refer to Wikipedia. The content of these hosts is the same


two. Domain division
The root domain is the top-level domain or first-level domain.
There are two ways of division. One is com., net., etc., which are divided according to the nature of the industry when the Internet is just emerging.

You can check the specific amount by yourself, we don't care here.

Each domain will have a domain name server, also known as an authoritative name server.

Baidu.com is a top-level domain name, but www.baidu.com is not a top-level domain name. It is a host called www in the domain of baidu.com.

After the first-level domain, there are second-level domains and third-level domains. As long as I buy a top-level domain, and I set up my own BIND server (or other software) to register it on the Internet, then I can add a few more in front of it at will. A domain (of course, the length is limited).

For example, a.www.baidu.com, in this URL, www.baidu.com has become a second-level domain instead of a host, and the host name is a.

three. domain name server
A server that can provide domain name resolution. The above record types can be A (address) record, NS record (name server), MX (mail), CNAME, etc.

(For details, please refer to the blog: Differences and connections between A records, CNAMEs, MX records, and NS records in domain name resolution)

What does A record mean? It is to record an IP address and a host name, such as the domain test.baidu.com where my domain name server is located. We know that this is a second-level domain name, and then I have an A record in it, Record the IP of the host as a, and return it to you when found.

If I now want to query a.test.baidu.com from the domain name server baidu.com, then the top-level domain name server will find that the URL you requested is in the domain of test.baidu.com, and I have recorded this secondary level here. The IP of the NS of the domain name server test.baidu.com. I will return this address to you, and then you can check the host whose host is a.

The domain name servers in these domains are called authoritative servers and directly provide DNS query services. (These servers don't do recursion)

Four. parsing process
So how does our DNS resolve a domain name?

1. Now I have a computer that is connected to the Internet through an ISP, then the ISP will assign me a DNS server. This DNS server is not an authoritative server, but a dns resolution server equivalent to a proxy. It will help you iterate authoritative The response returned by the server, and then return the IP finally found to you.

2. Now my computer is going to send a request to this ISPDNS to query the domain name www.baidu.com, (remind by netizens: This is actually not ISPDNS, but should be the DNS in the user's own computer network settings, not It must be ISPDNS. For example, it is possible that you manually set 8.8.8.8)

3. After ISPDNS gets the request, first check whether there is this address in its cache, and return it directly if there is. The IP address obtained at this time will be marked as a response from a non-authoritative server.

4. If there is no cache, ISPDNS will read the addresses of 13 root domain name servers from the configuration file (these addresses are unchanged, directly in the BIND configuration file),

5. Then make a request like one of them.

6. After the root server gets the request, it knows that it is under the top-level domain name com., so it will return the NS records in the com domain, generally 13 host names and IPs.

7. Then ISPDNS makes a request to one of them again. The server of the com domain finds that your request is from the domain baidu.com. Once I find the NS of this domain, I will return it to you, and you can check it again.

(Baidu currently has 4 top-level domain name servers for baidu.com).

8. ISPDNS takes the trouble to initiate a request to the authoritative server of the domain baidu.com again. After receiving it, baidu.com checks the host with www and returns the IP to you.

9. Then ISPDNS gets it, returns it to the client, and saves this in the cache.

Let's use the nslookup tool to explain the parsing steps in detail:


From the image above we can see:

The first line of Server is: the hostname of the DNS server -- 210.32.32.1

The second line Address is: its IP address -- 210.32.32.1#53

The following Name is: parsed URL-- www.jsjzx.com

Address is: parsed IP--112.121.162.168


But there are also more complex DNS resolutions like Baidu:

You will find that Baidu has an alias with cname = www.a.shifen.com.

What kind of process is this?

Let's use the dig tool to track it (the linux system comes with it)

The Dig tool will iterate on the local computer and record the query process.


The first step is to obtain the 13 IPs and hostnames [b-j].root-servers.net. of the root domain service area from the ISPDNS of my machine.

The second step is to send a query request for www.baidu.com to one of the root domain servers (Servername is in the parentheses in the last line), which returns the server IP (not shown) and name of the com. top-level domain,

The third step is to request a server 192.33.4.12 in the com. domain, www.baidu.com, and he returns the server IP (not shown) and name of the baidu.com domain. Baidu has four top-level domain servers.

[You can use dig @192.33.4.12 www.baidu.com to view the returned Baidu TLD server IP address].


The fourth step is to request www.baidu.com from Baidu's top-level domain server (202.108.22.220). He finds that www has an alias instead of a host, and the alias is www.a.shifen.com.


According to general logic, when dns requests to an alias, the query will be terminated, but the request to query the alias will be re-initiated, so what should be returned here is just www.a.shifen.com.

But why return the NS of this domain of a.shifen.com?

We can try this command: dig +trace shifen.com and see what happens. . . . . . . .


You will find that in the third step, the domain name server of the top-level domain of shifen.com and the domain name server of the domain of baidu.com are the same host (ie: dns.baidu.com)!

When I got the alias www.a.shifen.com of www.baidu.com, I originally needed to go to the com domain to find the NS of the shifen.com domain, but because these two domains are on the same NS, I directly initiated to the machine,

The shifen.com domain finds that the requested www.a.shifen.com belongs to the a.shifen.com domain.



So I returned the NS and IP of a.shifen.com, and let me query www.a.shifen.com on the domain name server of a.shifen.com.

So I got an A record from one of ns X .a.shifen.com, and finally the IP address of www.baidu.com. [You can also use dig +trace www.a. shifen.com] Follow it

Use a picture to illustrate (only 13 units in the world in the third step in the picture are wrong)

The following content is the experimental data obtained by building a local dns server in a virtual machine to correct the above conclusions

In the above analysis, we tracked with the dig tool, but dig did not continue to track things after we got the cname and the IP of ns2.a.shifen.com from baidu.com.

That's why we came to the conclusion that local dns will request www.a.shifenc.om from ns2.a.shifen.com.

In fact, this idea is wrong. Build a local dns in your own local area, grab all the packages in the whole parsing process, and you will understand when you look at it.

The actual result is that although dns.baidu.com returns the server address and IP of the a.shifen.com domain,

However, local dns does not directly request www.a.shifen.com from the returned IP, but requests the com domain again, and gets the servers of the shifen.com domain (that is, the four baidu.com servers),

Then request www.a.shifen.com, return to the server of the domain of a.shifen.com, and finally request www.a.shifen.com,

Although the IP has been returned above, the result of the experiment is to go through the query of the shifen.com domain again.


The above picture is the whole process of localdns parsing www.baidu.com to capture packets. The blue one is to continue to request shifen.com from the com domain after receiving the cname and the IP address of the domain name server of the responding a.shifen.com.

This figure fully illustrates that the IP of ns2.a.shifen.com is also returned when cname is returned.

So to sum up it is

① This machine requests www.baidu.com from local dns

②local dns requests www.baidu.com from the root domain, and the root domain returns the server IP of the com. domain

③Request www.baidu.com from the com. domain, and the com. domain returns the server IP of the baidu.com domain

④Request www.baidu.com from baidu.com, and return the server IP of cname www.a.shifen.com and a.shifen.com domains

⑤ Request www.a.shifen.com from the root domain

⑥ Request www.a.shife.com from the com. domain

⑦Request to shifen.com

⑧ Request to a.shifen.com domain

⑨ Get the IP of www.a.shifen.com

⑩localdns returns the local www.baidu.com cname www.a.shifen.com and the IP of www.a.shifen.com

In the eyes of many people, DNS is only to provide DNS resolution services for the outside world (I used to think so, until I hit an arrow in the knee), but as the infrastructure of the Internet, DNS is far from being as simple as imagined. If you haven't heard of DNS query, reverse resolution, zone transfer, dynamic update, DNS security, then you can get the most concise explanation about them from this article.

1. DNS protocol
DNS listens for requests on port 53 and provides responses. For performance reasons, DNS query requests are exchanged using the UDP protocol and the size of each request is less than 512 bytes, but if the size of the returned request is greater than 512 bytes, both parties will negotiate to use the TCP protocol.

2. DNS query
The main function of the domain name server in DNS is to respond to the query request of the domain name resolver (this domain name resolver may be the resolver on the PC side, or it may be another domain name server with resolution function). The domain name resolver is software installed on the PC, which is responsible for initiating domain name resolution requests to the local DNS (local DNS).

There are three types of queries in the DNS system:

1. Recursive query
The domain name server will perform domain name query on behalf of the requesting client (lower-level DNS server). If the domain name server cannot answer directly, the domain name server will perform recursive query on the top and bottom of each branch of each tree species in the domain, and finally return the query result to the client. During a domain name lookup, the client is always in a wait state. The process of recursive parsing is shown in the following figure:

It should be noted in the above figure that many authoritative name servers do not provide the function of recursive query (why?), such as the root name server. and the secondary name server. com do not provide the function of recursive query, so in the true sense Recursive query is done by Local DNS.

In general, the following three possible return results are received when recursive query is performed:

1), one or several A records, or an A record with a CNAME chain. The A record is the IP address of the domain name to be requested. The A record with the CNAME chain is like the previous blog "Detailed explanation of the minimum configuration of DNS open source server BIND". When requesting ftp.cobb.com, the ftp.cobb.com CNAME will be first Go to ljx.cobb.com, then go back to the A record for ljx.cobb.com.

2), an error message indicating that the domain or host does not exist. Note that this error message may also contain CNAME records. For example, I want to request ftp.cobb.com, and my domain name server CNAMEs ftp.cobb.com to ljx.cobb.com, but the host of ljx.cobb.com does not exist, at this time, the CNAME record and error message are returned.

3), a temporary error message. It is mainly because the host is unreachable from the network, which does not necessarily mean that the host does not exist.

2. Iterative query
The domain name server returns some guidelines or host IP addresses for the next query. After receiving the guidelines, the domain name resolver will initiate a query request to these guidelines again until the host IP address is received. The process of iterative parsing is shown in the following figure:

​​

In general, the following three possible return results are received when recursive query is performed:

1), an A record or an A record with a CNAME chain.

2), an error message indicating that the domain or host does not exist.

3), a temporary error. Possibly because the network is unreachable.

4), a list of domain name servers (including its IP address) for the next domain name resolution can be given. Tell the parser where to go for further parsing.

3. Reverse query
A reverse lookup is to look up a domain name based on a resource record. This resource record may be an A record, a CNAME record or an MX record (see "Detailed minimum configuration of DNS open source server BIND").

In order to realize reverse query, there is a special domain name IN-ADDR.ARPA in DNS to define reverse query. See RFC3425 for details.

3. Domain Maintenance
Domain maintenance refers to maintaining the same zone file between the primary domain name server and the secondary domain name server through the DNS protocol.

There are two domain maintenance methods in DNS, one is full transfer AXFR (full zone transfer), and the other is incremental transfer IXFR (incremental zone transfer).

1. Full transmission of AXFR
During full transmission, the slave domain name server requests the zone file from the primary domain name server, and the poll interval is defined by the refresh tag in the SOA record. The process of requesting the zone file is realized by sending a query from the domain name server to the main domain name server. If the serial number (serial number tag definition) in the SOA record of the main domain name server is greater than the serial number of the SOA record of the secondary domain name server, the secondary domain name server will Send a full transfer request to the primary nameserver. So once the main name server changes the zone file, it needs to increase its serial number in the zone. The complete format of the entire SOA record is shown in the following figure:



Normally, the serial number sn follows the format of "year+month+day+number". The 2003080803 in the figure indicates that the zone is the third update on August 8, 2003.

The full transmission is performed on TCP port 53.

2. Incremental transfer (IXFR)
Passing a very large zone file is very resource-intensive (time, bandwidth, etc.), especially when only one record in the zone changes, there is no need to pass the entire zone file. Incremental transfer allows the master name server and the slave name server to communicate Only those records that have changed are transferred.

It should be noted that not all domain name servers support incremental transfer. When incremental transfer is not supported, full transfer is used between master and slave.

3. Notice (NOTIFY)
It can be seen from the above analysis that the slave server sends requests to the master server every refresh time, and only the serial number in the SOA of the master server is greater than the serial number of the slave server, but if the time interval is relatively large (for example, 12 hours), a rapidly changing network environment may not allow such a large time difference.

So in the DNS cluster that implements the notification message, after the zone file of the DNS master server changes, it immediately sends a NOTIFY message to the slave server, telling the slave server that my zone file has changed, and then the slave server immediately compares the two Serial number, and then use the full transfer or incremental transfer method described above to request the zone file.

BIND itself supports notification. The configuration of notification is configured in the option of zone in named.conf. The configuration instructions are notify, also-notify and notify-source, see here for details.

4. Dynamic update
Every time you need to update the zone file, you need to stop the domain name server and restart it, so when there are many zone files, it takes a lot of time to load the zone file when the domain name server restarts. Therefore, there needs to be a local mechanism that does not stop the query service and quickly updates the zone file. There are two main mechanisms:

One is to allow external processes to update the zone file while the server is running;

The other is to store the resource record RR in the zone in the database, and read it dynamically every time the record in the zone is searched;

4. DNS Security
Like any other public service, DNS is subject to various security threats. This section looks at what kind of security threats DNS servers are subject to? How smart people deal with these threats.

In order to understand the security threats to DNS and the corresponding countermeasures, it is first necessary to understand the normal data flow of DNS. As shown below:

​​

Each data flow in the above diagram is subject to a security threat in response:

1) Threats to zone files may include: files are tampered or deleted unintentionally or intentionally. This kind of threat is easy to deal with. The main method is to develop a good system management strategy. The zone file and other configuration files require strict and safe read and write permissions.

2) 3) Threats to dynamic update and domain transfer may include: unauthorized update, tampering of zone files during transfer (often tampering with domain names to other IPs). The usual response to this threat is the TSIG (Transaction SIGnature) strategy (this strategy is defined in RFC2845). A key is calculated in the TSIG policy. This key is calculated by one-way hashing (the value can be easily derived from the input, but it is difficult to guess the input from the value), and then both parties transmitting the zone file are in the transmission process. Bring this key, if the key is incorrect, the transmission will be refused.

4) 5) Threats to remote queries may include: cache pollution (IP spoofing, data interception or wrong master host address). Cache pollution is when content in the cache may redirect your domain name to a wrong server. The usual response to this threat is Domain Name System Security Extensions (DNSSEC), which is a source of DNS data provided to DNS clients (resolvers), data integrity verification, but no provision or confidentiality An extension set exists for denying and authentication. Information on DNSSEC can be found here. About this part, I will introduce it in a follow-up blog

DNS, the abbreviation of Domain Name System, translated as Domain Name System, is a distributed database on the Internet that maps domain names and IP addresses to each other. DNS can make it easier for users to access the Internet without having to remember IP strings that can be directly read by machines. The process of obtaining the IP address corresponding to the domain name through the domain name is called domain name resolution (or host name resolution).

The following picture details the whole process of DNS domain name resolution:

The following is a detailed explanation of the process of DNS domain name resolution:

The network client is the computer we usually use, open the browser and enter a domain name. For example, enter www.163.com, then the computer you are using will send a DNS request to the local DNS server. The local DNS server is generally provided by your network access server provider, such as China Telecom and China Mobile.

After the DNS request for querying www.163.com reaches the local DNS server, the local DNS server will first query its cache record. If there is such a record in the cache, it can directly return the result. If not, the local DNS server will also query the DNS root server.

The root DNS server does not record the corresponding relationship between the specific domain name and IP address, but tells the local DNS server that you can go to the domain server to continue the query and give the address of the domain server.

The local DNS server continues to make requests to the domain server, in this case the .com domain server. After the .com domain server receives the request, it will not directly return the correspondence between the domain name and the IP address, but will tell the local DNS server the address of the resolution server for your domain name.

Finally, the local DNS server sends a request to the resolution server of the domain name, and then a corresponding relationship between the domain name and the IP address can be received. The local DNS server not only returns the IP address to the user's computer, but also saves the corresponding relationship in the cache. , so that when another user queries next time, the result can be returned directly to speed up network access.



Regarding the TTL parameter for DNS resolution:

When we configure DNS resolution, there is a parameter that is often ignored, which is the TTL parameter of DNS resolution, Time To Live. The TTL parameter tells the local DNS server the maximum time the domain name will be cached. Taking Alibaba Cloud DNS as an example, the default TTL of Alibaba Cloud DNS is 10 minutes. The meaning of 10 minutes is that the local DNS server caches the domain name for 10 minutes. After 10 minutes, the local DNS server will delete this record. After that, if a user accesses the domain name, the above complicated process is repeated.

In fact, if the website has entered a state of stable development and will not easily change the IP address, we can completely set the TTL to the maximum value of the protocol, that is, 24 hours. The benefit is that the domain name resolution records can be stored in the local DNS server for a longer time to speed up the access of all users. Setting it to 24 hours, in fact, also solves the problems that may be caused by the servers deployed by Googlebot around the world to crawl websites. Mai Xinjie has a blog post on this problem.