Introduction
Now is the world of the Internet. Everyone obtains various resources and information from various websites. Usually, we only need to remember a website address. As for the location of the server behind the website, we do not need to care. When our request points to this URL, we only need to wait for the request to be forwarded to the back-end server of the URL and get the returned processing result.
The service that resolves the website name into the service IP address is the DNS service, and its full name is Domain Name System, which is the domain name resolution service.
So how exactly does DNS work?
Some smart friends may say, it is not easy, build a unified server, save the IP corresponding to all domain names in the world, and get it from this service every time it needs to be resolved. Indeed, this was done in the early days of the Internet, when there were not many websites, the cost of domain name maintenance was not high, and there was no domain name system in the beginning.
ARPANET (The Advanced Research Projects Agency Network), which is the technical foundation of the Internet, is the first wide-area packet-switched network with distributed control, and it is also the earliest network facility to apply the TCP/IP protocol.
In the ARPANET network, each host has a numerical address, but this numerical address is obviously against the human memory model, so scientists hope to give these hosts some easy-to-remember names, so it is necessary to maintain the relationship between these names and the host. At this time, the Stanford Research Institute (now known as SRI International) took over the task, and they maintained a HOSTS.TXT text file, which describes the relationship between host addresses and host names. Mapping relations.
If someone wants to update this HOST file, they need to call the SRI Network Information Center during business hours, and the information center staff will add the hostname and address to the HOSTS.TXT file. Of course, such an operation is ok for a small amount of data update, but if the amount of data is too large, there will be problems.
The latter person named Elizabeth Feinler built the WHOIS directory on the basis of the SRI Network Information Center to retrieve information about resources, contacts and entities, and proposed the concept of domain names.
The initial maintenance is centralized management on a single server, but this maintenance method can no longer meet the growing network demand, so in 1983 Paul Mockapetris created the DNS system at the University of Southern California, and in 1983 The relevant original specifications were published in RFC 882 and RFC 883 in November 2009.
After a series of development of DNS, in November 1987, RFC 1034 and RFC 1035 replaced the 1983 DNS specification.
Function of DNS
As we mentioned earlier, the most basic function of DNS is to convert the domain name provided by the user into the address of the server.
For example, we now have a domain name called www.flydean.com, its corresponding server IPv4 address is 42.138.111.201, and the corresponding IPv6 address is fe40::1024:ff:fe10:123f. The work of DNS is to convert www.flydean .com is quickly converted to an IPv4 or IPv6 address as needed. This is the first and most important function of DNS: providing domain name resolution services.
In addition, in specific application scenarios, the corresponding server IP behind the domain name may change, so the DNS needs to have the function of rapid update, which can quickly reflect the changes of the network without affecting the access of specific users.
This operation is user-friendly, because users do not need to know the changes of the underlying server, they only need to know the domain name to be accessed.
Finally, modern network applications are generally distributed, there may be multiple worker nodes, and different worker nodes may be deployed in different places. When a user accesses a domain name, in order to improve the access speed, he should give priority to the node closest to the user. At this time, DNS assumes the task of optimizing network access. It is responsible for providing users with the nearest server node. Therefore, in modern network architecture, DNS plays an increasingly important role.
Composition of DNS
After explaining the functions of DNS, let's take a look at the composition of DNS. As a domain name service, DNS is composed of two parts: domain name space and Name servers.
The domain name space describes the structure and command rules of the domain name, and the name servers are the services that resolve the domain name. Next, we will explain them separately.
Domain name space
Domain name space, also called Domain name space, is a collection of all domain names. Here is a diagram of the domain name space on Wikipedia:
<img src="https://img-blog.csdnimg.cn/a4ada5191a6d4889aa54edb5a3a2e148.png" style="zoom:67%;" />
As can be seen from the above figure, the domain name space is actually a tree structure, each node or leaf node has a label and RR (esource records record useful information related to the domain name), the domain name itself is composed of labels, and the right side is its The names of the parent nodes, separated by dots.
The domain name space can be divided into multiple subspaces, and each subspace can be managed independently. Such a subspace is called a zone.
Each DNS domain can in turn be subdivided into a domain, or it may contain many domains and subdomains, depending on the management choices of the domain manager.
Everyone is familiar with domain names, but you may not understand the structure of domain names very well.
In fact, the domain name is composed of labels, and each label is connected by dots, such as: www.flydean.com.
Each label can be regarded as a level of the domain. The rightmost is the top-level domain name com, and the left is the subdomain of the right domain name. For example, flydean is the subdomain of com, www is the subdomain of flydean.com, and so on. There can be a total of 127 hierarchies.
Each label can contain 0 to 63 characters, and the total length of the domain name cannot exceed 253 characters. Why 253 characters instead of 255? That's because 2 characters are used to store the length value.
Generally speaking, the labels of domain names are represented by ASCII characters, usually az, AZ, 0-9 and hyphens. This rule is referred to as LDH (letters, digits, hyphen) rule.
In domain names, strings are case-insensitive, which means that www.flydean.com and WWW.FLYDEAN.COM are equivalent.
Note that tags cannot start or end with a hyphen, and TLDs cannot be all numbers.
Some friends may ask, no, why have I heard of Chinese domain names?
This is because in order to solve the problem that domain names can only be encoded in ASCII, ICANN passed a system called IDNA Internationalized Domain Names, through which user applications (such as web browsers) can use Punycode to map Unicode strings to valid DNS character set.
What is Punycode? Punycode is an encoding method that uses the ASCII character set to represent Unicode. Interested students can explore on their own, and I won't go into details here.
Name servers
Name servers, also known as name servers, are servers used to resolve domain names. A name server is a client-server architecture, each of which is used to publish information about that domain and to manage the name servers of any domains subordinate to it.
Such name managers form a hierarchy. In order to improve the efficiency of domain name resolution, it is usually necessary to use a cache to store the correspondence between domain names and server addresses, but sometimes we need more time-sensitive scenarios and services, so a special name server appears, which is called Authoritative name server.
Why is it called an authoritative name server? This is because an authoritative name server only gives answers to DNS queries from data configured by the original source, not from a query to another name server. It is the last stop in a nameserver query, and if the authoritative nameserver holds the requested record, it returns the IP address of the requested hostname to the DNS resolver that made the initial request.
DNS workflow
With so many conceptual things mentioned above, you may be a little confused. It doesn't matter, here we give a specific example to observe the whole process of DNS query.
If the user enters www.flydean.com in the browser and wants to visit this website, because the user enters a domain name, the domain name needs to be resolved into an IP address, so as to send subsequent data request packets.
Because DNS itself is a name service, a client is required to request DNS, and this client is called a DNS resolver.
Generally speaking, the DNS resolver is embedded in the browser. When the user enters a URL to access network resources, the browser will automatically call the DNS resolver to resolve the URL.
So where is the first stop for domain name resolution? The first stop for domain name resolution is the root server, also known as the root server.
The request for domain name resolution is first responded by the root server, but the root server does not directly return the domain name address to be resolved by the user, but returns the address of the top-level domain name server (TLD) according to the top-level domain name in the domain name accessed by the user.
For example, the defined domain name we want to visit here is .com, then the root server will return the address of the top-level domain name server of .com.
How many root servers are there? There are only 13 root server IP addresses in the world, this is due to the limitation of early technical reasons. Among the IP addresses of these 13 root servers, 1 is the main root address, which is managed by ICANN, and 9 of the other 12 addresses are in the United States, 2 in Europe, and 1 in Japan.
Although the root root server has only 13 IP addresses, a server cluster is constructed based on these 13 IP addresses, which can effectively ensure the running stability of the root server. Thereby, there will be no large-scale network errors caused by the inaccessibility of the root server.
Going back to our resolution process, the root server returns the address of the .com top-level domain name server to the DNS resolver, and the DNS resolution will initiate a resolution query to the .com TLD again.
The .com TLD will again return flydean.com's domain name server address to the DNS resolver.
The DNS resolver sends a request to the domain name server of flydean.com again. The domain name server here is an authoritative domain name server, because this is the last stop of domain name resolution, which stores the real IP address of the domain name. The authoritative domain name server obtains www. The real IP address of flydean.com and returned to the DNS resolver.
Finally, the DNS resolver returns this IP address to the browser for subsequent browsing requests.
It can be seen that DNS resolution is a process of continuous recursive resolution, so such a resolver is also called a DNS recursive resolver.
As can be seen from the above process, each domain name request needs to go through the root domain name server, so the pressure on the root domain name server will be great. In order to solve this problem, we actually introduced DNS cache in the process of use.
The purpose of the cache is to put the DNS data in the place closest to you, so as to prompt the processing speed and display efficiency of the data.
Common DNS caches include browser cache and operating system DNS cache.
The browser cache is the DNS cache maintained by the browser, and the operating system DNS cache is the operating system-level DNS cache.
If neither of these two caches exist, then the local DNS client will make DNS queries to the DNS recursive resolver inside the ISP (Internet Service Provider), and for the ISP, it will also have a DNS cache, so if Adding a domain name or changing an IP address does not take effect immediately, but requires a certain period of time to invalidate the cache or refresh the cache.
DNS resource records
We mentioned earlier that each node in the DNS namespace is composed of label and resource records (RR). RR stores resource description information and will return it after receiving a DNS query.
DNS RR is composed of records. The following is the structure of a record:
field name | describe | length [octets] |
---|---|---|
NAME | The name of the node to which this record belongs | variable |
TYPE | RR type | 2 |
CLASS | Class code | 2 |
TTL | Seconds to keep RR active | 4 |
RDLENGTH | length of the RDATA field | 2 |
RDATA | Additional data fields | variable |
where NAME is the fully qualified domain name of the node in the tree.
TYPE is the record type. It indicates the format and purpose of the data, such as A for converting domain names to IPv4 addresses, NS for listing which name servers can respond to DNS domain lookups, and MX for specifying the mail server used to handle mail for the specified domain in e-mail in the email address.
RDATA is data related to a specific type, such as the IP address of an address record, or the priority and hostname of an MX record.
Structure of DNS Messages
Since there is a DNS query, there will be a DNS query message structure. DNS messages can be divided into two types, namely query messages and reply messages.
Each message contains a message header and four other parts: question, answer, authority and extra space.
The header is responsible for controlling the other four parts. The header contains the following fields: Identification, Flags, Number of questions, Number of answers, Number of authority resource records (RRs) and Number of additional RRs, as shown in the following table:
field name | describe | length [bits] |
---|---|---|
QR | Whether the message is query (0) or reply (1) | 1 |
OPCODE | The type of query QUERY (standard query, 0), IQUERY (recursive query, 1), or STATUS (server status request, 2) | 4 |
AA | Is it an authoritative server response | 1 |
TC | Indicates that the message was truncated because it was too long | 1 |
RD | Whether to query recursively | 1 |
RA | Does the DNS server support recursion? | 1 |
Z | reserved text | 3 |
RCODE | Response code, can be NOERROR (0), FORMERR (1, format error), SERVFAIL (2), NXDOMAIN (3, non-existing domain name) | 4 |
The length of the tag field of the entire header is 16bits, followed by 4 16bits, which respectively represent the length of 4 other parts.
Summarize
The above is the structure of DNS and the basic flow of DNS work.
This article has been included in http://www.flydean.com/19-domain-name-service/
The most popular interpretation, the most profound dry goods, the most concise tutorials, and many tricks you don't know are waiting for you to discover!
Welcome to pay attention to my official account: "Program those things", understand technology, understand you better!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。