Shulou(Shulou.com)11/24 Report--

Let's start today's topic.

Is DNS an application layer protocol based on UDP? When we execute dig www.baidu.com, the operating system will issue a dns request to ask how much IP corresponds to the domain name www.baidu.com.

$ dig www.baidu.com; DiG 9.10.6 www.baidu.com global options: +cmd Got answer: -HEADER- opcode: QUERY, status: NOERROR, id: 61559 flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4000 QUESTION SECTION:;www.baidu.com. IN A ANSWER SECTION:www.baidu.com. 298 IN CNAME www.a.shifen.com.www.a.shifen.com. 298 IN A 180.101.49.12www.a.shifen.com. 298 IN A 180.101.49.11 At this time, from the perspective of packet capture, DNS is an application layer protocol, and UDP protocol is indeed used at the transport layer.

The transport layer uses UDP protocol

It is mentioned in RFC 5966.

#https://www.rfc-editor.org/rfc/rfc5966 This document updates the requirements for the support of TCP as a transport protocol for DNS implementations.

When we add the + tcp option to the dig command, we can force DNS queries to use TCP for data transfer.

$ dig +tcp www.baidu.com; DiG 9.10.6 +tcp www.baidu.com global options: +cmd Got answer: -HEADER- opcode: QUERY, status: NOERROR, id: 28411 flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4000 QUESTION SECTION:;www.baidu.com. IN A ANSWER SECTION:www.baidu.com. 600 IN CNAME www.a.shifen.com.www.a.shifen.com. 600 IN A 180.101.49.11www.a.shifen.com. 600 IN A 180.101.49.12 At this point, the bag is caught again.

TCP can be found at the transport layer, and DNS uses TCP at the transport layer.

Then the question arises.

Why does UDP still need TCP? We know that network transmission is like transmitting data packets in a certain pipe. This pipe has a certain thickness, called MTU. Exceeding the MTU results in fragmentation at the network layer on the sending side and reassembly at the network layer on the receiving side. Reassembly requires a buffer, and the size of this buffer has a minimum value of 576 bytes.

IP layer fragmentation transmission will increase the probability of packet loss, and IP layer itself does not have the function of retransmission, so IP layer fragmentation needs to be avoided as much as possible.

If fragmentation does occur during transmission, try to ensure smooth reassembly at the receiving end, so in the most safe case, set MTU to 576. (A little too cautious, MTU=1500 in most scenarios now).

Based on this premise, this MTU length is about 512Byte after cutting IP header and UDP header.

RFC1035 states that DNS messages should not exceed 512 bytes in UDP.

More than that will be truncated. Then the data packet is incomplete, which may cause the downstream to be unable to parse the data properly.

But inevitably, there will always be scenarios where a lot of data needs to be transmitted.

What to do? Then switch to TCP.

Because TCP itself is segmented, the segmented length is exactly less than or equal to the MTU length. And after packet loss will be retransmitted, so it can ensure that the data transmission is normal.

So when the packet length is greater than 512, DNS needs to use TCP protocol for transmission.

If TCP is so good, why not use TCP? We can compare the two figures above for UDP and TCP, and we will find that in addition to the DNS request and response two packets, there are three more handshakes and four waves in the TCP scenario.

At first glance, it doesn't seem to be a lot.

Let's go back and look at the process of querying the IP corresponding to the domain name through the DNS protocol.

If the query process is subdivided, it can be divided into iterative queries and recursive queries.

What are iterative queries and recursive queries?

Iterative query means that after sending DNS, if the other party does not know what the IP of this domain name is, it will tell me the IP of the machine that may know this matter, and I will ask the machine that may know it myself, and repeat it until I get the result.

Recursive query means that after issuing DNS request, the other party is required to directly give the final result after checking.

Recursive queries may seem convenient, but they are actually offloading the query process to other DNS servers. So many times, both exist at the same time.

Take an example.

Iterative queries and recursive queries such as IP queries corresponding to www.baidu.com

When this machine sends out DNS requests, it will ask the nearest DNS server to check the results and then return them to this machine (step1), so this time it is a recursive query required.

The local machine is easy, but the nearest DNS server (probably your home router) needs to be busy. It needs to adopt an iterative query method. In the worst case, it needs:

Step 2: Query the root domain name server

Step3: Get the IP of the first-level domain name (com) server returned by the root domain name server.

Step4: Query the level 1 domain (com) server again

Step5: Get the IP of the secondary domain (baidu) server

Step6: Query the secondary domain (baidu) server

Step 7: Get IP of third-level domain (www) server

Step8: Query the third-level domain (www) server

Step9: Get the IP of the www.baidu.com server

At this point, the DNS server will cache the results and return them to the local server (step 10).

As you can see, iterative queries and recursive queries exist simultaneously in this scenario.

Message characteristics of iterative and recursive queries

This is also reflected in the DNS header.

DNS messages we need to pay attention to are the RD and RA fields in the Flags field.

RD (Resolution Desired) refers to the query method expected by the client.

0: Indicates iterative query

·1: Indicates recursive query

RA (Recursion Available) refers to the query method actually used by the server, which will only appear in the response packet.

0: Indicates iterative query

·1: Indicates recursive query

Impact of iterative and recursive queries

Back to the question of why DNS isn't all TCP.

We can see that DNS requests involve a lot of servers.

If TCP is used, it requires three handshakes to establish a connection and four waves to disconnect.

For the recursive query side, it's actually fine, because only one connection will be established, one request will be sent and one response will be received.

But for one side of the iterative query, there is a need to repeatedly establish and disconnect connections with many servers. Performance can have a big impact.

At this time, I guess everyone will also want to ask.

Does that mean that TCP connections are constantly opened and the next multiplexing will be fine?

Not so good.

Because most URLs involve different domain name servers, for example, www.baidu.com and www.xiaobaidebug.top involve different first, second and third level domain name servers, so there is no need to maintain TCP long links for multiplexing.

So in contrast, in smaller data scenarios, UDP can save the cost of shaking hands, so UDP is a better solution.

Is there only 13 IPV4 root domains in DNS? It is true.

Here comes the problem again.

Why 13 IPs? Can't you add more? This is purely for historical reasons. It is mentioned above that UDP-based DNS messages should not exceed 512Byte, and if you remove the header information of DNS itself, you can probably put 13 IPs (IPV4).

The exact calculation process is not important, so I will omit it. If you are interested in the calculation process, you can see the references at the bottom of this article.

Although most machines now have MTU=1500, there may still be machines with MTU=576 that need forward compatibility, so it is not recommended to adjust them at will.

But here comes the problem.

Even if the MTU of all the machines reached 1500, would there be no such limit?

Well, from that perspective, it can be added, but it's unnecessary.

We need to think about why?

Is it because 13 IPs correspond to 13 servers, and the pressure is too great?

Or is it due to other unspoken considerations?

For example, when watching TV a long time ago, a brickist mentioned that "there are only 13 DNS root servers in the world, of which x are deployed in beautiful countries. As long as they cut off access, our network will be affected balabala".

But 13 IPs doesn't mean there are only 13 servers. To be precise, it should be said that there are 13 groups of servers, each group can expand the number of servers indefinitely, and multiple servers share the same IP.

This actually involves a technology called anycast.

Anycast is what we know. In the process of transmission, one machine sends a message to another machine. This is called unicast.

Unicast a machine, send a message to all the machines in the local network segment, that is called broadcast.

Both are very common and should be fine.

A machine sends a message to one of all eligible destination machines, which is called anycast.

Anycast We know that network devices all over the world are put together to form a mesh structure, which is also the origin of the name network.

Let's assume that there is a router that wants to access a machine with an IP. There are many paths from the router to the destination machine, and the router can calculate the cost of each path through information such as hop count to obtain the optimal path. The optimal path is collected into a table, which is often referred to as a routing table.

For example, in the diagram below, both the green and red lines can reach the same destination, but obviously the green route is shorter, so the routing table records the green route at a lower cost.

The routing table records shorter paths So now suppose we set the network IP to the same for two points in this mesh, the router doesn't know that these are two different machines, and for it, these are just two different paths, but both lead to the same IP.

Different paths arrive at the same IP address. Both paths can reach the same IP address, so any service can get the desired information, thus realizing anycast.

Now let's add another condition. The router and one of the machines are both in China, and the other machine is abroad. For the router, because the domestic machine is close, the transmission cost is low, while the foreign machine is far away and the transmission cost is high, so the optimal route generated by the router is to hit the domestic machine.

Based on this idea, we only need to mirror a foreign DNS domain name server information to the domestic computer room. We won't have to request foreign servers anymore.

Therefore, even if the root domain name server of other countries hangs, it will not have any impact on us. In fact, there are already many mirror servers in China, which are very stable.

That slightly expanded, assuming that the same IP mirror service is set up in Shanghai and Guangdong, then for users in Shanghai, their routers will give priority to the mirror service in Shanghai. Guangdong users will give priority to Guangdong machines, thus achieving nearby access.

If the mirror service in Shanghai hangs up, the routing table in the corresponding Shanghai user router will update the path to the mirror machine in Guangdong. Shanghai users 'requests will be sent to Guangdong's mirror service. To achieve high availability (or disaster preparedness).

It seems that anycast can achieve both Load Balancer and High Availability, which is very similar to nginx.

Then, the problem arose.

If there is anycast technology, why use nginx? nginx as a common reverse proxy server, behind which N servers can be connected. When the client wants to request the backend, the client doesn't need to know which server is serving it, just take the last result returned by nginx. Such proxy methods that block out specific servers are called reverse proxies.

Because the reverse proxy does not know which servers are behind it, it can expand indefinitely. If one server is hung, others can also top it. Therefore, it realizes Load Balancer and high availability.

I wrote an article entitled "Why HTTP Protocol and Websocket Protocol?" It was mentioned that for online game scenarios, there needs to be a server that actively pushes data to the client. Because nginx establishes a TCP long link between the client and the server, the client can respond to the server along this connection after receiving the message from the server.

If nginx is not used at this time and anycast is simply used, then after the server actively pushes the message to the client, when the client responds, the message is not guaranteed to be returned to the original server. After all,"anycast" means that as long as you can access any server.

So anycast is not a substitute for nginx.

Of course, these two things are not the same dimension, so it is not appropriate to compare them. I just gave a counterexample to help you smooth out the differences between the two.

DNS can use both UDP and TCP protocols at the transport layer. UDP is used when the amount of data transmitted is less than 512 bytes, otherwise TCP is used.

Although there are only 13 IPs in the root domain, it does not mean that there are only 13 servers. To be precise, there should be 13 groups of servers. Each group of servers shares the same IP. There are already many mirror servers in China. With anycast technology, as long as you can access one of them nearby, it will be fine.

If there are destination machines with the same IP at home and abroad, then for routers, there are nothing more than two paths to reach the same destination, one farther and one closer. Closer paths are placed in the routing table based on cost.

Although Anycast technology can also achieve Load Balancer and high availability to a certain extent, it is not a dimensional thing with nginx and cannot replace nginx.

resources

《Why 13 DNS root servers?》

https://miek.nl/2013/november/10/why-13-dns-root-servers/

This article comes from Weixin Official Accounts: Xiaobai debug (ID: xiaobaidebug), author: Xiaobai

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.