This DNS is well written.

Just think about it, how many ways can we humans identify ourselves? It can be identified by an ID card, a social security card number, or a driver's license. Although there are various identification methods, in certain circumstances, certain identification methods will be more suitable than others. Hosts on the Internet, like humans, can be identified in a number of ways. One way to identify a host on the Internet is to use its hostname, such as www.baidu.com, www.google.com, and so on. This is the way we humans are accustomed to remembering, but hosts on the Internet don't. They like fixed-length, hierarchical IP addresses.

So how does the router resolve the IP address to the web address we are familiar with? This is where DNS comes in.

<div align = "center">Figure 7-1</div>

The full name of DNS is Domain Name Systems , which is a distributed database implemented by a hierarchical DNS server (DNS server) ; it is also an application-layer protocol that enables hosts to query distributed databases. The DNS protocol runs over the UDP protocol and uses port 53.

DNS Basic Overview

Like HTTP, FTP and SMTP, the DNS protocol is also an application layer protocol. DNS uses the client-server mode to run between communicating end systems, and transmits DNS messages between communicating end systems through the UDP transport layer protocol. .

DNS is usually not a stand-alone protocol, it is often used by other application-layer protocols, including HTTP, SMTP, and FTP, to resolve user-supplied hostnames to IP addresses.

The following describes the DNS resolution process based on an example:

What happens when you type www.someschool.edu/index.html into your browser? In order for the user host to send an HTTP request message to the Web server www.someschool.edu, the following operations are performed:

A client for a DNS application running on the same user host.
The browser extracts the hostname www.someschool.edu from the above URL and passes this hostname to the client of the DNS application.
A DNS client sends a request containing a hostname to a DNS server, asking the DNS server to resolve the IP address for that hostname.
The DNS client will eventually receive a reply message containing the IP address of the target host.
Once the browser receives the IP address of the target host, it can initiate a TCP connection to the HTTP server process on port 80 of that IP address.

In addition to providing IP address to hostname translation, DNS also provides the following important services:

主机别名(host aliasing) , a host with a complex hostname can have one or more other aliases, for example a host called relay1.west-coast.enterprise.com will have both enterprise.com and www. Two host aliases for enterprise.com, in this case relay1.west-coast.enterprise.com also known as the canonical hostname , and the host alias is easier to remember than the canonical hostname. Applications can call DNS to obtain the canonical hostname corresponding to the host alias and the IP address of the host.
邮件服务器别名(mail server aliasing) , and similarly, an email application can also call DNS to resolve the provided hostname.
负载分配(load distribution) , DNS is also used for load distribution among redundant servers, which is also called internal load . Busy sites such as cn com are redundantly distributed across multiple servers, each running on a different end system, each with a different IP address. Because of these redundant Web servers, a set of IP addresses is therefore associated with the same canonical hostname. A collection of these IP addresses is stored in the DNS database. Since the client makes an HTTP request every time, DNS round-robin distributes the load among all these redundant web servers.
Another kind of load is the global load . The global load is generally deployed between multiple computer rooms. Each computer room will have its own IP address. When a user accesses a domain name, polling will be performed among these IPs. If the data center is down, the corresponding IP address will be deleted. For example, a DNS client will poll the computer rooms in Beijing and Shanghai. If one is down, the other will be used directly. This is the concept of global load.

How DNS works

Suppose that some application running on a user's host computer, such as a web browser or mail reader, needs to translate hostnames to IP addresses. These applications will call the DNS client and specify the hostname that needs to be translated. After the DSN client receives the DNS, it will use UDP to send a DNS query message to the network through port 53. After a period of time, the DNS client will receive a DNS response message corresponding to the host name. So, from the user's host's point of view, DNS is like a black box, you can't see what's going on inside it. But in fact, the black box that implements the DNS service is very complicated. It consists of a large number of DNS servers distributed around the world and the application layer protocol that defines the communication method between the DNS server and the query host.

DNS was originally designed to have only one DNS server. This server will contain all DNS mappings. This is a centralized single-point design, which is not suitable for today's Internet, because the Internet has a huge and growing number of hosts, this centralized design will have the following problems

单点故障(a single point of failure) , there is usually only one DNS server on a single point. If the DNS server crashes, the entire network will be paralyzed.
通信容量(traaffic volume) , a single DNS server has to handle all DNS queries, which may be in the millions or tens of millions.
远距离集中式数据库(distant centralized database) , it is impossible for a single DNS server to be close to all users. Assuming that the DNS server in the United States cannot be close to the query in Australia, the query request is bound to pass through low-speed and congested links, causing serious time extension.
维护(maintenance) , the maintenance cost is huge, and it needs frequent updates.

Therefore, a centralized design of DNS is impossible, because the centralized design has no scalability at all, so a distributed design is adopted. The characteristics of this design are as follows.

Distributed, hierarchical database

The first problem to be solved by the distributed design is the scalability of the DNS server. Therefore DNS uses a large number of DNS servers, which are generally organized in a hierarchical manner and distributed around the world. No single DNS server can have a mapping of all hosts on the Internet . Instead, these mappings are distributed across all DNS servers.

Broadly speaking, there are three types of DNS servers: root DNS servers, Top-Level Domain (TLD) DNS servers, and authoritative DNS servers . The hierarchical model of these servers is shown in the figure below.

<div align = "center">Figure 7-2</div>

Suppose now that a DNS client wants to know the IP address of www.amazon.com, how does the above domain name server resolve it?

First, the client associates with one of the root servers, which returns the IP address of the TLD server for the top-level domain com. The client then contacts one of these TLD servers and it returns the IP address of the authoritative server for amazon.com. Finally, the client contacts one of the amazom.com authoritative servers, which returns its IP address for www.amazom.com.

DNS Hierarchy

Let's now discuss the hierarchy of the above domain name servers.

根 DNS 服务器 , there are more than 400 root name servers all over the world, these root name servers are managed by 13 different organizations. A list and organization of root nameservers can be found at https://root-servers.org/ , which provide the IP addresses of TLD servers.
顶级域 DNS 服务器 There are TLD servers or clusters of servers for each of the top-level domains such as com, org, net, edu and gov and for all country-level domains uk, fr, ca and jp. See https://tld-list.com/ for a list of all top-level domains. The TDL server provides the IP address of the authoritative DNS server.
权威 DNS 服务器 , which have publicly accessible hosts on the Internet, such as web servers and mail servers, whose organizations must provide accessible DNS records that map the names of these hosts to IP addresses . An organization's authoritative DNS server hosts these DNS records.

DNS query steps

Let's describe the DNS query steps, from DNS resolution IP to a series of processes of DNS packet return.

Note: Usually, DNS will cache the searched information in the browser or computer locally. If there is the same request, the DNS search will not be performed, but the result will be returned directly.

Under normal circumstances, DNS lookup will go through the following steps

After the user enters the URL www.example.com in the browser and hits enter, the query goes to the network and is received by the DNS resolver.
The DNS resolver will initiate a query request to the root domain name, requesting to return the address of the top-level domain name.
The root DNS server notices the prefix of the requested address and returns to the DNS resolver a list of IP addresses of the top-level domain name servers (TLDs) for com.
The DNS resolver then sends a query message to the TLD server.
After the TLD server receives the request, it will return the IP address of the authoritative DNS server to the DNS resolver according to the address of the domain name.
Finally, the DNS resolver sends the query directly to the authoritative DNS server.
Authoritative DNS servers return IP addresses to DNS resolvers.
The DNS resolver will respond to the web browser with the IP address.

Once the DNS lookup step returns the IP address of example.com, the browser can request the web page.

The whole process is shown in the figure below

<div align = "center">Figure 7-3</div>

DNS resolver

The host computer and software that makes DNS queries are called DNS resolvers , and both workstations and personal computers used by users belong to resolvers. A resolver must register at least one IP address of a domain name server. The DNS resolver is the first stop in a DNS lookup and is responsible for dealing with the client that made the initial request . The parser initiates a sequence of queries that ultimately translate the URL into the necessary IP address.

<div align = "center">Figure 7-4</div>

A DNS recursive query is different from a DNS recursive resolver in that it makes a request to a DNS resolver that needs to resolve the query. A DNS recursive resolver is a computer that accepts recursive queries and processes the responses by making the necessary requests.

DNS query type

There are three types of queries that occur in DNS lookups. By using a combination of these queries, an optimized DNS resolution process reduces transmission distances . Ideally, cached record data could be used, allowing DNS nameservers to use non-recursive queries directly.

递归查询 : In a recursive query, the DNS client asks that the DNS server (typically a DNS recursive resolver) will respond to the client with the requested resource record, or return an error if the resolver cannot find the record information.
<div align = "center">Figure 7-5</div>
迭代查询 : In an iterative query, if the DNS server queried does not match the queried name, it will return a reference to a DNS server that is authoritative for the lower-level namespace. The DNS client will then query the referring address. This process continues with other DNS servers in the query chain until an error or timeout occurs.
<div align = "center">Figure 7-6</div>
非递归查询 : This query is usually made when a DNS resolver client queries a DNS server for a record it has access to, either because it is authoritative for the record, or because the record exists in its cache. DNS servers usually cache DNS records and can return cached results directly when a query comes in to prevent further bandwidth consumption and load on upstream servers.

DNS cache

DNS caching, sometimes called DNS resolver cache , is a temporary database maintained by the operating system that contains access records for recent websites and other Internet domains . That is to say, DNS caching is just a technology and means that the computer caches the loaded resources in order to meet the fast response speed, and can be directly and quickly referenced when accessing again. So how does DNS caching work?

DNS Caching Workflow

Before the browser makes a request to the outside world, the computer intercepts each request and looks up the domain name in the DNS cache database, which contains a list of the most recent domain names and the addresses DNS calculated for them the first time the request was made.

DNS caching method

DNS data can be cached in a variety of different locations, each of which will store a DNS record whose time-to-live is determined by the TTL (DNS field).

browser cache

Today's web browsers are designed to cache DNS records for a period of time by default. Because the closer the web browser is to DNS caching, the fewer times a request is made to the IP address to check the cache. When a request for a DNS record is made, the browser cache is the first place that is checked for the requested record.

In the chrome browser, you can use chrome://net-internals/#dns to view the DNS cache records.

<div align = "center">Figure 7-7</div>

OS kernel cache

After the browser caches the query, the operating system-level DNS resolver is queried. The operating system-level DNS resolver is the second stop before the DNS query leaves your computer and the last step in the local query.

DNS message

All DNS servers that jointly implement the DNS distributed database store Resource Records (RR) , which provide the mapping of hostnames to IP addresses. Each DNS reply message will contain one or more resource records. RR records are used to reply to client queries.

A resource record is a 4-tuple containing the following fields.

 (Name, Value, Type, TTL)

There are different types of RRs. Below is a summary table of different types of RRs.

DNS RR type	explain
A record	IPv4 host records, used to map domain names to IPv4 addresses
AAAA records	IPv6 host records, used to map domain names to IPv6 addresses
CNAME record	Alias records, used to map aliases of DNS domain names
MX records	Mail exchanger for mapping DNS domain names to mail servers
PTR records	Pointer for reverse lookup (IP address to domain name resolution)
SRV records	SRV records to map available services.

<div align = "center">Table 7-1</div>

DNS has two kinds of messages, one is query message, the other is response message, and these two kinds of messages have the same format, the following is the message format of DNS.

<div align = "center">Figure 7-8</div>

Let's take a look at the detailed message fields.

segment header

The segment header is the basic structural part of the DNS message. Below we describe each byte in the segment header.

Transaction ID: TransactionID is set by the client and returned by the server. TransactionID occupies 2 bytes. It is the identifier of DNS. For the same request message and response message, the value of this field is the same, so as to distinguish the client request and response.
Flags: The flags field occupies 2 bytes. There are many flag fields, and they are also more important. Below I list all the flag fields for you.

<div align = "center">Figure 7-9</div>

The meaning of each field is as follows

QR(Response) : 1-bit QR identifies whether the message is a query message or a response message. QR = 0 for query messages and QR = 1 for response messages.
OpCode : The 4 bit OpCode represents the opcode, this value is usually 0, which represents the standard request and response. OpCode = 4 means this is a notification; OpCode = 5 means this is an update request. While other values (1-3) are deprecated.
AA(Authoritative) : 1-bit AA stands for Authorization Response, this AA is only valid in response packets, when the value is 1, it means the name server is the authoritative server; when the value is 0, it means it is not the authoritative server.
TC(Truncated) : truncation flag, when the value is 1, it indicates that the response has exceeded 512 bytes and has been truncated, and only the first 512 bytes are returned.
RD(Recursion Desired) : This field is the expected recursive field, which is set in the query and returned in the response. This flag tells the name server that this query must be processed in a way called a recursive query . If this bit is 0, and the requested name server does not have an authoritative answer, it will return a list of other name servers that can answer the query. This approach is called an iterative query .
RA(Recursion Available) : The recursive field is available, this field only appears in the response message. When the value is 1, it means that the server supports recursive queries.
Z : Reserved field, its value must be 0 in all request and response packets.
AD : This field indicates whether the information is authorized, and authorized is true.
CD : This field indicates whether the security check is disabled. Disable the check is true.
rcode（Reply code） : This field is the return code field, indicating the error status of the response. When the value is 0, it means that there is no error; when the value is 1, it means that the message format is wrong (Format error), and the server cannot understand the requested message; when the value is 2, it means that the domain name server fails (Server failure), because The server is unable to process the request; when the value is 3, it means that the name is wrong (Name Error), which is only meaningful to the authorized domain name resolution server, indicating that the parsed domain name does not exist; when the value is 4, it means that the query type does not exist. Supported (Not Implemented), that is, the domain name server does not support the query type; when the value is 5, it means Refused, generally the server refuses to give a response due to the set policy, such as the server does not want to give a response to some requesters .

I believe that readers are like me. It is meaningless to just look at these fields. Let's take a look at the specific DNS packets by capturing packets.

<div align = "center">Figure 7-10</div>

Now we can look at the specific DNS message, through query we can see that this is a request message, the identifier of this message is 0xcd28 , and its sign is as follows.

QR = 0 This is a request.
Then comes the four-byte OpCode, which has a value of 0, indicating that this is a standard query.
Because this is a query request, no AA field is present.
Then there is the truncated flag bit Truncated, indicating that it has not been truncated.
RD = 1 immediately following it, indicating that a recursive answer is desired.
No RA field is present in the request message.
Then there is the reserved field Z.
A 0 immediately following it indicates that unauthenticated data is not acceptable.
There is no value for the RCODE field.

Then we look at the response message.

<div align = "center">Figure 7-11</div>

It can be seen that the flag bit is also 0xcd28 , which shows that this is the response of the above query request.

We will not explain the packets that have already been explained in the query request, and now only explain the content that is not in the request packet.

The AA field immediately following the OpCode is already present, and its value is 0, indicating that it is not a response from an authoritative DNS server.
The last is the response of the RCODE field, when the value is 0, it means there is no error.

query area

The query area usually refers to the query part of the message format. This section is used to display problems with DNS query requests, including query type and query class.

<div align = "center">Figure 7-12</div>

The meaning of each field in this section is as follows:

查询名（Query Name） : Specify the domain name to be queried, sometimes also the IP address, for reverse query.
查询类型（Query Type） : The resource type requested by DNS query, usually the query type is type A, which means that the corresponding IP address is obtained from the domain name.
查询类（Query Class） : address type, usually internet address, value 1. The values for this query class are usually 1, 254, and 255, representing Internet class, no class, and all classes, respectively.

Similarly, let's use wireshark to look at the query area.

<div align = "center">Figure 7-13</div>

It can be seen that this is a DNS query request initiated by mobile-gtalk.l.google.com, the query type is A (0x0001), then the response type obtained should also be A, A means IPv4 type, if Type is AAAA , then it represents the IPv6 type.

<div align = "center">Figure 7-14</div>

As shown in the image above, the response type is also A.

Resource Record Section

The resource record part is the last three fields of the DNS message, including the answer question area, the authoritative name server record, and the additional information area, all of which are in a format called a resource record, as shown in the figure below.

<div align = "center">Figure 7-15</div>

The fields in the resource record section have the following meanings

Name : The domain name of the DNS request.
Type : The type of resource record, which is the same as the query type in the query section.
Class : Address type, the same as the query class value in the question.
TTL : In seconds, it indicates the lifetime of the resource record.
RDLENGTH（资源数据长度） : The length of the resource data.
RDATA（资源数据） : Indicates the data of the related resource records returned by the query segment.

The resource record part only appears in DNS response packets. Let's take a look at specific field examples through the response message.

<div align = "center">Figure 7-16</div>

The value of the domain name is mobile-gtalk.l.google.com, the type is A, the class is 1, the lifetime is 5 seconds, the data length is 4 bytes, and the address represented by the resource data is 63.233.189.188.

CNAME record

CNAME is a record type of DNS, its full name is Canonical Name Record , this type can map certain DNS aliases to the DNS naming system.

A very simple example is shown below

 www.cxuanblog.edu  
IN  
CNAME  
www.cxuanblog.com

What does this mean?

This means that if the user enters the domain name www.cxuanblog.edu in the browser, it is actually the domain name www.cxuanblog.com. If you plan to move your blog, the old domain name you enter will actually jump directly. Go under the web page for the new domain name.

Another common practice of CNAME is to access it as a public domain name .

Reverse DNS lookup

What we have been discussing above is the conversion method of DNS -> IP, which is also the essence of DNS. But if you look at Figure 7-1 carefully, you will find that there is also a way of IP -> DNS conversion. This reverse conversion is also called reverse DNS query . The relationship between them is much like ARP and RARP.

The reverse DNS query queries the DNS server for a PTR (Pointer Record) record . If the server does not have a PTR record, the reverse lookup process cannot be resolved. PTR is also a RR resource record, see Table 7-1.

The PTR record will store the IP address. When reverse query, the IP address stored in the PTR will be reversed, and the .in-addr.arpa field will be attached. For example, if the IP address of the domain is 192.137.8.22, then when reverse query, The PTR record is 22.8.137.192.in-addr.arpa.

Reverse DNS lookups are often used in email protocols, email servers check if email messages in an email box are from a real and valid server, spammers often use hijacked machines, and these emails will not come after they come PTR records. Email servers will reject mail from servers that do not support reverse lookups or that are not very legitimate.

SOA records

If the response is from an authoritative DNS server, the record stores important information about the zone, which is the SOA record. All DNS zones require an SOA record to be IETF compliant. SOA records are also important for zone transfers.

SOA records have some additional fields in addition to the fields of the DNS resolver response, as follows

<div align = "center">Figure 7-17</div>

Meaning of specific fields

PNAME : The Primary Name Server, which is the name of the primary name server for the zone.
RNAME : That is, Responsible authority's mailbox, RNAME represents the administrator's email address, @ is represented by ., that is, admin.example.com is equivalent to admin@example.com .
序列号 : Namely Serial Number, the area serial number is the unique identifier of the area.
刷新间隔 : Refresh Interval, the time (in seconds) that the secondary server should wait before requesting the primary server for an SOA record to see if it has been updated.
重试间隔 : The Retry Interval, the time the server should wait for an unresponsive primary name server to request an update again.
过期限制 : the Expire limit, if the secondary server does not receive a response from the primary server within this period, it should stop responding to queries in this area.

The primary and secondary name servers are mentioned above, and the relationship between them is as follows.

<div align = "center">Figure 7-18</div>

In this section, we mainly explain the records of RR type A (IPv4) and SOA. In addition, there are many other types. This article will not be introduced in detail. Readers and friends can read "TCP/IP Volume 1 Protocol" Check with cloudflare's official website https://www.cloudflare.com/learning/dns/dns-records/ . It is worth mentioning that cloudflare is a very good website for learning network protocols.

Zone transfers and DNS NOTIFY

Zone transfer usually refers to the update of RR resources in a DNS server in a zone. The purpose of this is to ensure that multiple servers ensure content synchronization. If one server in the zone fails, other servers can temporarily step up and act as a temporary DNS server. Zone transfer is usually enabled after polling . During polling, the slave server will periodically check the master server to see if the zone has been updated. Zone transfer needs to be enabled.

Once a zone transfer is initiated, there are two modes of transfer:

Full transmission: that is, the message of the entire area is transmitted, and the full transmission will transmit the message of the entire area (using AXFR).
Incremental transfer: Incremental transfer is the transfer of a portion of the message, and the incremental transfer uses (using DNS IXFR) the message.

But using polling has some drawbacks, because the slave server will periodically check whether the content on the master server is updated, which is a waste of resources, because in most cases it is an invalid check, so in order to improve this situation, DNS has designed the DNS NOTIFY mechanism. DNS NOTIFY allows the master server to notify the slave server that the content needs to be updated after the content of the zone is modified, and the zone transfer should be started.

DNS network troubleshooter

There are two commonly used troubleshooting tools for DNS, one is nslookup , which is the recommended troubleshooting tool in general books. Let us first introduce the use of this tool, and then we will introduce another tool.

nslookup

nslookup is a tool for troubleshooting DNS related problems.

It is mainly divided into two modes, one is interactive mode and the other is non-interactive mode . The interactive mode is a question-and-answer format, while the non-interactive mode is a one-time execution.

For example, if you want to use interactive, enter nslookup directly on the command line.

<div align = "center">Figure 7-19</div>

This will start an nslookup command prompt, and then you can enter the domain name you want to query, as shown below:

<div align = "center">Figure 7-20</div>

Non-interactive is to directly enter the content you want to query in nslookup. For example, we also take baidu as an example.

<div align = "center">Figure 7-21</div>

In fact, the content of the query is the same, and the way of use is actually quite different.

nslookup is generally used to query the following common scenarios:

nslookup can query the IP address of the host;
nslookup can query the domain name of the IP address;
nslookup is able to query mail servers for domain names.

You can query the mail server of the domain name through nslookup -querytype, as follows

<div align = "center">Figure 7-22</div>

There will be two query results, one is Non-authoritative answer , which indicates that the URL we want to query is queried from the local DNS cache, that is, the DNS cache, rather than the real one obtained from the local DNS after DNS query. domain name.

There is another kind of Authoritative answers , which is the real domain name obtained by the local DNS after DNS query.

The above figure also shows some parameters of the netease.com mail server, origin represents the source address, mail addr represents the address of the mail server, serial represents the serial number, refresh represents the refresh interval, retry represents the retry interval, expire represents the expiration time, and the minum represents the The maximum length.

dig

There are multiple network connections on our computer, each network connection will have a different DNS, and DNS is also divided into primary DNS and backup DNS, nslookup will use the primary DNS connection by default, if your primary DNS is not configured, use may be The following situation exists.

<div align = "center">Figure 7-23</div>

Different from nslookup, dig is also a DNS network troubleshooting tool. It will select an available connection from your network connection for analysis and use. However, the use of the dig command tool is not supported by default under Windows 10, but it is supported by mac.

Below is the dig command under mac.

<div align = "center">Figure 7-24</div>

However, kindly, I have sorted out the installation and configuration of dig under windows10 for you ( https://www.csdn.net/tags/Mtjacg0sMjU1ODQtYmxvZwO0O0OO0O0O.html )

Once installed, you can use dig under Windows 10.

<div align = "center">Figure 7-25</div>

Let's introduce the usage of dig tool and the meaning of each parameter. We will use dig baidu.com to explain

<div align = "center">Figure 7-26</div>

As shown above, the top

; <<>> DiG 9.16.23 <<>> www.baidu.com Indicates the dig version and the domain information to be queried.

;; global options: +cmd indicates global options, dig can query multiple domain information, here shows the options applied to all queries, the default is +cmd.

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63799 This line represents the header information, where the opcode QUERY represents query, IQUERY represents reverse query, STATUS represents monitoring status, etc.

NOERROR indicates that the request was resolved normally, and the id is a random number used to bind the request and response together.

;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 These lines are all flag bits, where

qr = query , rd = recursion desired , ra = recursion avaliable Here, DNS is actually playing a word game with us, because rd translation requires recursion, there is nothing to say about this, the default is to use recursive query; and ra translation is recursive available , I need to think about it, should I use recursion or not? Of course, you can use it or not. If you don't use recursion, then the DNS query method is iterative query.
QUERY represents the number of queries, ANSWER represents the number of results
AUTHORITY indicates the number of results from the authoritative name server, 0 means it is returned from the local DNS, because there is no return information from the authoritative server.
ADDITIONAL indicates additional information, and the additional information is only seen when its value is greater than 1.

Below is the problem area

;; QUESTION SECTION:
;www.baidu.com. IN A

In order is the domain name being queried, IN we mentioned above it means internet query, A means domain name is mapped to IPv4 address.

Below is the answer section

;; ANSWER SECTION:
www.baidu.com. 183 IN CNAME www.a.shifen.com.
www.a.shifen.com. 57 IN A 220.181.38.150
www.a.shifen.com. 57 IN A 220.181.38.149

The number in the middle indicates the TTL, the time interval for which records can be cached.

Finally, there is the statistics part, there is not much to say about this.

In addition, dig has some other query methods.

-x do reverse DNS lookup

We know that DNS can convert domain names to IP, and at the same time, IP can be converted to the corresponding domain name, where -x is to perform reverse DNS query, as shown below:

<div align = "center">Figure 7-27</div>

It can be seen that both QUESTION SECTION and ANSWER SECTION are PTR, which means reverse DNS query, and the domain name behind shows that this is a google DNS. In the reverse DNS query, the IP address should be added with in-addr.arpa .

Similarly, we can also add in-addr.arpa to the query, and the result is the same.

<div align = "center">Figure 7-28</div>

We usually like to use -x because it reduces the amount of typing work.

+noall +answer

This tells dig to only print the ANSWER part of the DNS response, as shown below

<div align = "center">Figure 7-29</div>

+short

dig +short is like a castrated version of dig +noall +answer, it only shows very little.

<div align = "center">Figure 7-30</div>

+trace

dig +trace is able to mimic what a DNS resolver does when looking up a domain name, that is, it starts the query from the root server and goes all the way to the authoritative DNS server. It is equivalent to a function of link tracking.

<div align = "center">Figure 7-31</div>

In addition to the nslookup and dig we introduced above, there are other DNS detection tools, such as dog and drill, which are all very useful DNS network troubleshooting tools. You can check the relevant information for use. I will not go into details here. introduced.

DNS Security

Nearly all network requests go through DNS queries, and like many other Internet protocols, DNS was not designed with security in mind and has some design limitations that create opportunities for DNS attacks.

DNS attacks mainly include the following methods:

The first is Dos attack, the main form of which is to overload important DNS servers such as TLD servers or root domain name servers, so that they cannot respond to requests from authoritative servers, making DNS queries ineffective.
The second form of attack is DNS spoofing, by altering the contents of a DNS resource, such as masquerading as an official DNS server, and replying to a fake resource record, causing a host to connect to the wrong IP address when trying to connect to another machine.
A third form of attack is DNS tunneling, which uses other network protocols to tunnel through DNS queries and responses. Attackers can use SSH, TCP, or HTTP to pass malware or stolen information into DNS queries in a way that makes the firewall undetectable, resulting in a DNS attack.
A fourth form of attack is DNS hijacking, in which an attacker redirects queries to other name servers. This can be done through malware or unauthorized DNS server modification. Although the result is similar to DNS spoofing, this is a completely different attack because it targets the website's DNS records on the name server, not the resolver's cache.
Chapter 5 The attack form is DDoS attack, also known as distributed denial of service bandwidth flooding attack. This attack form is equivalent to an upgraded version of Dos attack.

So how to defend against DNS attacks?

One of the most well-known ways to defend against DNS threats is to use the DNSSEC protocol.

DNSSEC

DNSSEC, also known as DNS Security Extensions, protects the validity of data by digitally signing it, thus preventing it from being attacked. It is a series of DNS security authentication mechanisms provided by the IETF. DNSSEC doesn't encrypt data, it just verifies that the address of the site you're visiting is valid.

DNS firewall

Some attacks are carried out against the server, which requires the appearance of the DNS firewall, which is a tool that can provide many security and performance services for the DNS server. A DNS firewall sits between a user's DNS resolver and the authoritative name server for the website or service they are trying to access. Firewalls provide rate-limited access to shut down attackers trying to overwhelm the server. If a server does go down due to an attack or any other reason, a DNS firewall can keep the operator's site or service up and running by serving DNS responses from the cache.

In addition to the above two defenses, operators of their own DNS zones will take further steps to protect DNS servers, such as configuring DNS infrastructure to prevent DDoS attacks.

Summarize

In this article, I used a lot of words to introduce you to the basic overview of DNS, the working mechanism of DNS, the query method of DNS, the caching mechanism of DNS, and we also used WireShark to capture packets to show you the packets of DNS, and finally I have introduced DNS attack methods and defense methods for you.

This is a relatively comprehensive article on introductory DNS. It took me more than a week to write this article. After understanding this article, you should be able to answer most of the DNS questions, and I think the interview is stable. .

Original link: DNS, I have arranged for you to understand!

I have a public account myself: programmer cxuan, you can search on WeChat, everyone is welcome to join us.