Understand DNS cache
Produced by learning scum, technical/English learning records, it is inevitable that there will be understanding/translation flaws or even errors, please correct me.
It is recommended to read the original text: Understanding DNS cache
When I first learned DNS resolution , I was surprised by this long and complicated process. Imagine how many websites you visit every day, and then think about how many times you visit every day. Now imagine that every time you visit, the ISP DNS server on the other end must repeat the entire recursive process and query all domain name servers in the recursive chain.
With this as a background, imagine your cell phone. When you want to make a phone call with a friend you regularly contact, you can easily find their name in the recent call and call. However, if the information is not ready, you have to call 114 to get their number, and then dial out manually. Does it seem cumbersome?
In fact, it takes a lot of steps and a lot of time to convert a domain name into a IP Fortunately, DNS considered how to speed up DNS and implemented the cache. DNS cache enables DNS Server or the client to store the DNS records locally and reuse them later, reducing the query requirements DNS
The domain name system implements the survival time ( TTL ) DNS TTL specifies the number of seconds that a DNS record DNS server and client. DNS record exists in the cache, its survival time will also be saved. The server will continue to update TTL in the cache, counting down in seconds. When it becomes 0 , the record will be deleted or cleared from the cache. At this time, if the request for the record is received again after the cache expires, the DNS server must start the resolution process.
To understand caching, let's look at the example in the previous article, parsing www.google.com . When you enter www.google.com in the browser, the browser asks the operating system for the address of IP The operating system has stub resolver or DNS client (reference: what is DNS Server , resolver and stub resolver ), an operating system responds to all DNS query parser. The DNS resolver will send a DNS request (and turn on the recursive query flag) to a specific recursive resolver (domain name server) and store its DNS record in the cache TTL
When Stub Resolver receives a request from an application, it will first check its cache, and if there is the record in the cache, it will directly return the information in the cache to the application. If there is no cache, sending DNS request (recursive marker and open) recursive parser ( ISP the DNS server).
When Recursive Resolver receives a request, it will first check which information of www.google.com If there is a A cache, the record is sent to Stub Server . If there is no A record, but there is an authoritative name server's NS record, it will request these authoritative name servers (bypassing the root server and com gTLD server).
If there is no authoritative name server, it will request the com gTLD server.
Note: The chart is added by the translator according to his own understanding (corrections are welcome)
If there is no authoritative name server, the .com gTLD server will be requested (because their TTL is very high, they generally exist in the cache, and they are suitable for any .com domain name). Only when they do not exist in the cache, Recursive Resolver gTLDs from the root server, which is very rare (usually refers to the purge ).
In order to avoid propagating the expired DNS record, the DNS server will correct a requested TTL instead of the original TTL value of this record. For example, assume a www.google.com record TTL is 4 hours, and in the morning it 8 points are Recursive Resolver stored in the cache. If there is a new user, in this parser in the morning 9 request the same domain name point, resolver will send a 3 hours TTL record.
Now we have covered the DNS in OS and DNS servers, and then there is the last layer of cache: application. All applications can choose to cache DNS data, even if they cannot follow the DNS standard. The application relies on the operating system function getaddrinfo() to resolve the domain name (all operating systems use the same function name). This function returns the IP -but it does not return the DNS record, so the application does not have TTL available.
Therefore, different applications have different time for caching data. IE10+ will store up to 256 domain names in its cache, the fixed time is 30 minutes . 256 domain names seem to be a lot, but in fact they are not-a large number of web pages on the Internet will consume 50 domain names, thanks to third-party tagging and redirection. On the other hand, Chrome will cache DNS information one minute and store 1000 records. You can access Chrome: // NET-Internals # dns view and clean up Chrome of DNS cache.
NS cache trap
DNS cache traps that people often fall into is the authoritative name server record. As we mentioned before, the authoritative name server is specified NS NS records TTL . But it does not provide the IP address of the name server. IP information is in the additional A or AAAA record response.
Therefore, a Recursive Resolver depends on both the NS and A records to reach the name server. Ideally, two recording types TTL should be the same, but occasionally someone misconfigured DNS zones , they will DNS request incoming new A or AAAA record. The new record overwrites the old record, causing discrepancies.
When all the records are in the cache, Recursive Resolver IP address of one of the domain name servers. If Recursive Resolver cache only NS record, no A or AAAA record, it must resolve the domain name server, such as ns1.google.com , get its IP address. This is not good, because it increases the time to resolve the domain. And, if it has a A or AAAA domain name server but no NS , it will forcefully initiate a DNS query of the www.google.com
Set TTL: balance behavior
So, TTL be longer or shorter? If appropriate, use a longer TTL because it will resolvers longer and OSS - means better performance for end users, and it will reduce traffic to your name server, Because there will be fewer requests. In any case, it will also reduce your changes to DNS , make you more vulnerable to DNS hijacking attacks, and fail to set offline error pages when your data center is inaccessible.
In other words, TTL more people will spend time downloading pages or resources, and increase the pressure on your name server. And make you change the DNS configuration faster.
DNS parsing is a multi-stage process involving a large number of Internet servers. The built-in caching mechanism of the protocol accelerates the process DNS DNS server and / or client TTL follow the on DNS specification, but the application such as the browser does not follow the norm - so they can be saved at any time of the cache.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。