DNS, or Domain Name Servers, are a group of servers which provide a distributed management of domain names on the Internet. This allows computer addresses to be easier to remember by allowing you to use names (e.g. www.example.com) instead of numbers (such as 192.0.34.166).

As it is one of the most important parts of the Internet, it has been setup in such a way that different servers (or groups of servers) have different responsibilities depending on what information you are looking for. This makes it much faster and safer than just one (or a few) servers taking full control over all parts of DNS.

You don't normally notice this process as it is very fast (usually less than one-quarter of a second to complete all the requests) and is handled away from your computer at your local DNS server (all networks and ISP's keep their own DNS servers to make this process much quicker and to make sure that servers don't get overloaded).

To convert a domain name, such as example.com, to an computer address, such as 192.0.34.166, there needs to be a series of requests. The following text is taken from the Wikipedia article about DNS and provides a good example of the steps taken to get the name of the computer. When you make the request, the request is sent to the recursor which deals with the query.

The Queries

• Before starting, the recursor has to know where to find the root servers; DNS Server administrators must manually specify (and periodically update) a file called the root hints which contains recently known IP addresses of these servers.
• The process starts by the recursor asking one of these root servers - for example, the server with the IP address "198.41.0.4" - the question "what is the IP address for www.wikipedia.org?"
• The root server replies with a delegation, meaning roughly: "I don't know the IP address of www.wikipedia.org, but I do know that the DNS server at 204.74.112.1 has information on the .org domain."
• The local DNS recursor then asks that DNS server (i.e. 204.74.112.1) the same question it had previously put to the root server, i.e. "what is the IP address for www.wikipedia.org?". It gets a similar reply - essentially, "I don't know the address of www.wikipedia.org, but I do know that the DNS server at 207.142.131.234 has information on the wikipedia.org domain."
• Finally the request goes to this third DNS server (207.142.131.234), which replies with the required IP address.

Caching

As you can appreciate, this is a lot of work to do by your computer and all the DNS servers when you visit each page (or download each image on the page, etc.). Therefore, when creating the DNS system, it was built in with the ability to store (or cache) the data from each request in memory for a short period of time.

Therefore, if you, or another person, makes the same request within a specified period of time, the local (recursor) server would be allowed to return the same data from memory. This period of time is governed by a valid known as the TTL value (or Time To Live) and is set in seconds (by default to 86,400 seconds or 24 hours). So, any query from another server can be kept on a local server for up to 24 hours before it has to make another request to see if any change have been made.

For example, if you logged onto example.com at 14:54, and the TTL was set to 86400 (24 hours), then any further requests for that data will be returned with the data from memory until 14:53 the next day. If someone then made another request at 14:57 the next day, as it's 240 seconds past the TTL value, the server will have to make a new request and update it's records, returning the newly-fetched value.

Negative Caching

What happens when you make a request for an entry that doesn't exist? For example, Plesk has a known bug (see Why can't I access www.(example.com)) which doesn't add the www. entry into the DNS configuration when it first creates the domain. Therefore, any requests to www.example.com will fail with the 'Server Not Found' error.

In theory, this is still a valid response, so it doesn't need to throw it away. But how does it know how long to keep it for if nothing was returned?

In this case another server will use a general value called 'Negative TTL' from the domain's master settings to decide how long to hold onto 'bad' data. For all our servers, has been set to 3600 (1 hour). So, if any request is made to a non-existant entry, it will only be allowed to be kept for 1 hour before having to try again.

Changing DNS

Therefore, when you change any DNS value, and it doesn't matter what you change, any server that has previously made a request for that information and still has it in it's cache (i.e. the data is less than TTL seconds old), it can carry on re-issuing that data to it's clients until the TTL expires.

However, for any server that doesn't have a copy of this old data (i.e. they haven't made a request yet), the will have to pick up the new data, and therefore will start serving the new data until the TTL expires.

It is this difference in times, and hence difference in what some servers know, that causes the effect known as propagation - we must wait for all the DNS servers around the Internet who hold an old record of our DNS to have it's cache expire and pick up the new data. Only then can we say that the new settings take place have fully taken over.