DNS catching and Prefetching
DNS Catching and Prefetching.
A DNS cache is a temporary database, maintained by a computer's operating system, that contains records of all the recent visits and attempted visits to websites and other internet domains.
In other words, a DNS cache is just a memory of recent DNS lookups that your computer can quickly refer to when it's trying to figure out how to load a website.
Most people only hear the phrase "DNS cache" when it refers to flushing/clearing the DNS cache in order to help fix an internet connectivity issue.
The Purpose of a DNS Cache
The internet relies on the Domain Name System (DNS) to maintain an index of all public websites and their corresponding IP addresses. You can think of it like a phone book.
With a phone book, we don't have to memorize everyone's phone number, which is the only way phones can communicate: with a number. In the same way, DNS is used so we can avoid having to memorize every website's IP address, which is the only way network equipment can communicate with websites.
This is what happens behind the curtain when you ask your web browser to load a website...
You type in a URL like lifewire.com and your web browser asks your router for the IP address. The router has a DNS server address stored, so it asks the DNS server for the IP address of that hostname. The DNS server finds the IP address that belongs to lifewire.com and then is able to understand what website you're asking for, after which your browser can then load the appropriate page.
This happens for every website you want to visit. Every time a user visits a website by its hostname, the web browser initiates a request out to the internet, but this request cannot be completed until the site's name is "converted" into an IP address.
The problem is that even though there are tons of public DNS servers your network can use to try to speed up the conversion/resolution process, it's still quicker to have a local copy of the "phone book," which is where DNS caches come into play.
The DNS cache attempts to speed up the process even more by handling the name resolution of recently visited addresses before the request is sent out to the internet.
How a DNS Cache Works
Before a browser issues its requests to the outside network, the computer intercepts each one and looks up the domain name in the DNS cache database. The database contains a list of all recently accessed domain names and the addresses that DNS calculated for them the first time a request was made.
The contents of a local DNS cache can be viewed on Windows using the command ipconfig /displaydns, with results similar to this:
docs.google.com
-------------------------------------
Record Name . . .. : docs.google.com
Record Type . . . . .: 1
Time To Live . . . . : 21
Data Length . . . . .: 4
Section . . . . . . . : Answer
A (Host) Record . . . : 172.217.6.174
-------------------------------------
Record Name . . .. : docs.google.com
Record Type . . . . .: 1
Time To Live . . . . : 21
Data Length . . . . .: 4
Section . . . . . . . : Answer
A (Host) Record . . . : 172.217.6.174
In DNS, the "A" record is the portion of the DNS entry that contains the IP address for the given host name. The DNS cache stores this address, the requested website name, and several other parameters from the host DNS entry.
What Is DNS Cache Poisoning?
A DNS cache becomes poisoned or polluted when unauthorized domain names or IP addresses are inserted into it.
Occasionally a cache may become corrupted due to technical glitches or administrative accidents, but DNS cache poisoning is typically associated with computer viruses or other network attacks that insert invalid DNS entries into the cache.
Poisoning causes client requests to be redirected to the wrong destinations, usually malicious websites or pages full of advertisements.
For example, if the docs.google.com record from above had a different "A" record, then when you entered docs.google.com in your web browser, you'd be taken somewhere else.
This poses a massive problem for popular websites. If an attacker redirects your request for Gmail.com, for example, to a website that looks like Gmail but isn't, you might end up suffering from a phishing attack like whaling.
DNS Flushing: What It Does and How to Do It
When troubleshooting cache poisoning or other internet connectivity issues, a computer administrator may wish to flush (i.e. clear, reset, or erase) a DNS cache.
Since clearing the DNS cache removes all the entries, it deletes any invalid records too and forces your computer to repopulate those addresses the next time you try accessing those websites. These new addresses are taken from the DNS server your network is setup to use.
So, to use the example above, if the Gmail.com record was poisoned and redirecting you to a strange website, flushing the DNS is a good first step to getting the regular Gmail.com back again.
In Microsoft Windows, you can flush the local DNS cache using the ipconfig /flushdns command in a Command Prompt. You know it works when you see the Windows IP configuration successfully flushed the DNS Resolver Cache or Successfully flushed the DNS Resolver Cache message.
Linux users should enter the /etc/rc.d/init.d/nscd restart command.
A router can have a DNS cache as well, which is why rebooting a router is often a troubleshooting step. For the same reason you might flush the DNS cache on your computer, you can reboot your router to clear the DNS entries stored in its temporary memory.
DNS Prefetching: -
Pre-fetching is a way of hinting to the browser about resources that are definitely going to or might be used in the future, some hints apply to the current page, others to possible future pages.
DNS prefetching is an attempt to resolve domain names before a user tries to follow a link. This is done using the computer's normal DNS resolution mechanism; no connection to Google is used. Once a domain name has been resolved, if the user does navigate to that domain, there will be no effective delay due to DNS resolution time. The most obvious example where DNS prefetching can help is when a user is looking at a page with many links to various domains, such as a search results page. When we encounter hyperlinks in pages, we extract the domain name from each one and resolving each domain to an IP address. All this work is done in parallel with the user's reading of the page, using minimal CPU and network resources. When a user clicks on any of these pre-resolved names, they will on average save about 200 milliseconds in their navigation (assuming the user hadn't already visited the domain recently). More importantly than the average savings, users won't tend to experience the "worst case" delays for DNS resolution, which are regularly over 1 second.
Architecture
Chromium's implementation of DNS prefetching does not use the browser's network stack at all. Instead, it relies on external threads to resolve the names, thereby warming the DNS cache of the operating system (completely ignoring any cache in the application network stack). The advantage of this approach was that it was completely compatible with all network stacks (it is external), and prevented accidental regressions on the main network stack.
Since some DNS resolutions can take a long time, it is paramount that such delays in one resolution should not cause delays in other resolutions. Toward this end Chromium currently, employs 8 completely asynchronous worker threads to do nothing but perform DNS pre-fetch resolution. Each worker thread simply waits on a queue, gets the next requested domain name, and then blocks on a synchronous Windows resolution function.Eventually, the operating system responds with a DNS resolution, the thread then discards it (leaving the OS cache warmed!), and waits for the next prefetch request.
Manual Prefetch
Chromium uses the "href" attribute of hyperlinks to find host names to prefetch. However, some of those hyperlinks may be redirects, for example, if the site is trying to count how many times the link is clicked. In those situations, the "true" targeted domain is not necessarily discernible by examining the content of a web page, and so Chromium not able to prefetch the final targeted domain.
To improve the speed of redirects, content authors can add the following tag to their page:
<link rel="dns-prefetch" href="//host_name_to_prefetch.com">
The above "link rel" tag has no impact on the visual rendering of the page but causes Chromium to prefetch the DNS resolution of "host_name_to_prefetch.com" as though there was an actual href targeted at a path in that domain. The double slashes indicate that the URL starts with a host name. It is equivalent (but unnecessary) to use a full URL such as "http://host_name_to_prefetch.com/".
Comments
Post a Comment