DNS Caching
Introduction
In the
previous pages I 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 in
charge of the domain the client is after.
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.
The Big Picture
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 the problem !
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.
I 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
!
|
