Linux BIND DNS - Part 6: Linux BIND - DNS Caching

In the previous articles, we spoke about the Internet Domain Hierarchy and explained how the ROOT servers are the DNS servers, which contain all the information about authoritative DNS servers the domains immediately below e.g firewall.cx, microsoft.com. In fact, when a request is passed to any of the ROOT DNS servers, they will redirect the client to the appropriate authoritative DNS server, that is, the DNS server in charge of the domain.

For example, if you're trying to resolve firewall.cx and your machine contacts a ROOT DNS server, the server will point your computer to the DNS server in charge of the .CX domain, which in turn will point your computer to the DNS server in charge of firewall.cx, currently server with IP 74.200.90.5.

Understanding DNS Caching and its Implications

As you can see, a simple DNS request can become quite a task in order to successfully resolve the domain. This also means that there's a fair bit of traffic generated in order to complete the procedure. Whether you're paying a flat rate to your ISP or your company has a permanent connection to the Internet, the truth is that someone ends up paying for all these DNS requests ! The above example was only for one computer trying to resolve one domain. Try to imagine a company that has 500 computers connected to the Internet or an ISP with 150,000 subscribers - Now you're starting to get the big picture!

All that traffic is going to end up on the Internet if something isn't done about it, not to mention who will be paying for it!

This is where DNS Caching comes in. If we're able to cache all these requests, then we don't need to ask the ROOT DNS or any other external DNS server as long as we are trying to resolve previously visited sites or domains, because our caching system would "remember" all the previous domains we visited (and therefore resolved) and would be able to give us the IP Address we're looking for!

Note: You should keep in mind that when you install BIND, by default it's setup to be a DNS Caching server, so all you need to do it startup the service, which is called 'named'.

Almost all Internet name servers use name caching to optimise search costs. Each of these servers maintains a cache which contains all recently used names as well as a record of where the mapping information for that name was obtained. When a client (e.g your computer) asks the server to resolve a domain, the server will first check to see whether it has authority (meaning if it is in charge) for that domain. If not, the server checks its cache to see if the domain is in there and it will find it if it's been recently resolved.

Assuming that the server does find it in the cache, it will take the information and pass it on to the client but also mark the information as a nonauthoritative binding, which means the server tells the client "Here is the information you required, but keep in mind, I am not in charge of this domain".

The information can be out of date and, if it is critical for the client that it does not receive such information, it will then try to contact the authoritative DNS server for the domain and obtain the up to date information it requires.

DNS Caching Does Come with its Problems!

As you can clearly see, DNS caching can save you a lot of money, but it comes with its problems !

Caching does work well in the domain name system because name to address binding changes infrequently. However, it does change. If the servers cached the information the first time it was requested and never change that information, the entries in the cache could become incorrect.

The Solution To DNS Caching Problems

Fortunately there is a solution that will prevent DNS servers from giving out incorrect information. To ensure that the information in the cache is correct, every DNS server will time each entry and dispose of the ones that have exceeded a reasonable time. When a DNS server is asked for the information after it has removed the entry from its cache, it must go back to the authoritative source and obtain it again.

Whenever an authoritative DNS server responds to a request, it includes a Time To Live (TTL) value in the response. This TTL value is set in the zone files as you've probably already seen in the previous pages.

If you manage DNS server an are planning to introduce changes like redelegate (move) your domain to some other hosting company or if the IP Address your website currently has or changing mail servers, in the next couple weeks, then it's a good idea to get your TTL changes to a very small value well before the scheduled changes. Reason for this is because any dns server that will query your domain, website or any resource record that belongs to your domain, will cache the data for the amount of time the TTL is set.

By decreasing the $TTL value to e.g 1 hour, this will ensure that all dns data from your domain will expire in the requesters cache 1 hour after it was received. If you didn't do this, then the servers and clients (simple home users) who access your site or domain, will cache the dns data for the currently set time, which is normaly around 3 days. Not a good thing when you make a big change :)

So keep in mind all the above when your about the perform a change in the DNS server zone files. a couple of days before making the change, decrease the $TTL value to a reasonable value, not more than a few hours, and then once you complete the change, be sure you set it back to what it was.

We hope this has given you an insight on how you can save yourself, or company money and problems which occur when changing field and values in the DNS zone files!