We are sometimes told that it can take “24-48 hours” for DNS changes to propagate across the Internet. There’s a bit more to the story than that. Here, we explain all you need to know about DNS from a user perspective.
What is DNS?
The networking protocols that the Internet is built on are based on each device, such as a web server, having a unique IP (“Internet Protocol”) address. The most common form of an IP address is four numbers separated by dots, such as 212.58.244.69.
Those addresses aren’t very convenient for humans to use for a number of reasons:
- They are hard to remember. Most of us would find it easier to remember “bbc.co.uk” than “212.58.244.69”.
- They’re tied at any one time to one specific system. If that system isn’t working right now, that address will be unreachable until either the system comes back or another system takes on that address.
- They’re not constant. If a web server moves from one data centre to another, it’s very likely that the IP address will change.
- Typically, mail for an organisation needs to be sent to one system and their website will reside on another, so we need different IP addresses depending on what we’re trying to achieve.
DNS solves all of those problems, and more. The Domain Name System (DNS) provides a mapping between the human-readable names and the corresponding IP addresses (and the reverse, too).
How DNS Works
The correct operation of DNS is critical to the Internet, and under the covers DNS is a sophisticated and relatively complex technology. This overview of how DNS works is simplified, but the principles described are sound.
DNS names are hierarchical, with the higher levels being on the right of the name. The root of the hierarchy is simply named “.” (period), but for convenience this trailing period is usually omitted. The technically correct name of the BBC’s website is thus “www.bbc.co.uk.” (note the trailing period).
DNS records are maintained on DNS servers, and, like the names, the servers are organised hierarchically. The PC on your desk, your tablet, your phone, they all need to know how to find a DNS server, and they are typically told that as part of the network configuration of the device.
When you try to view the BBC’s web page on your phone, your phone talks to its designated DNS server and asks it for the IP address of www.bbc.co.uk. If we ignore, for the moment, something called “caching” (which we’ll get to), that DNS server will start from the right-hand end of that name (the “.”), and will contact the Internet DNS “root” servers. They understand the top level domains, such as “com.”, “net.” and “uk.”, and can tell your local DNS server who to talk to about the next level down, in this case the “uk.” domain.
The process now repeats: your local DNS server contacts one of the DNS servers that knows about “uk.” and asks about “co.uk.”, and is given a list of DNS servers that understand that part of the hierarchy. Eventually we are able to locate a DNS server that knows about “www.bbc.co.uk.” and can tell us the corresponding IP address. But there’s a catch…
DNS Record Types
If we want to send email to the BBC, we need the address of the BBC’s email server (more accurately, the address of a server that will accept email for bbc.co.uk). If we want to visit their website, we (usually) don’t want to contact the mail server.
DNS solves this “multiple use” problem with record types. When your phone asks for the address of bbc.co.uk, it also states which record type is wants. For looking up the IP address, as in the case of trying to reach the web server, an “A” record is requested. Originally, mail too was handled by the server with the corresponding A record address, but as time went on it became desirable to separate out mail handling.
MX Records
Enter the MX (Mail Exchanger) record. The MX record for a domain holds the name (not IP address) of one or more servers that will accept mail on behalf of that domain. So, the DNS records for the bbc.co.uk domain might look like, in part:
A 212.58.244.23 MX cluster1.eu.messagelabs.com.
We can see here that the BBC’s mail is initially handled by another organisation, in this case Message Labs (who provide a spam and virus filtering service). As the MX record is required to hold a name rather than an IP address, we need a second DNS lookup to find the IP address to send the mail to. The A record for cluster1.eu.messagelabs.com. has multiple IP addresses, any of which should be happy to accept mail addressed to the bbc.co.uk domain.
As well as A records and MX records, there are records that point to DNS servers (NS, or NameServer, records). So the initial DNS lookups we did, to find a DNS server that knows about the .uk. domain, requested the NS records for uk.
That’s probably enough detail about the hierarchical nature of DNS names and DNS servers, but it does lead to a problem.
Caching
There will be a lot of lookups for ‘bbc.co.uk.’ in a day, but there will be even more for all the “.co.uk.” names – and by the time we get to the root servers, the number of lookups is in the multiple billions per day.
Although the root DNS servers are, in reality, server farms distributed geographically for redundancy, it isn’t scalable to have every DNS lookup in the world go via the root servers, and therefore the intermediate servers will “cache”, or remember, the results for a given time. Once your local DNS server knows where to go to find out about the uk. domain, it doesn’t need to go to the root servers when someone asks for tiger-computing.co.uk: it can go straight to the uk. servers. And, when your colleague also wants to look at the BBC website, the local DNS server doesn’t need to go anywhere at all: it already knows the IP address.
But there’s still a problem.
Time To Live
Things change. Web servers change IP addresses, mail is moved from in-house to an external filtering company, even nameservers change IP addresses from time to time. That means that, if we cache the results of the lookup of bbc.co.uk, eventually they may be incorrect.
To combat this, each DNS domain has a concept of “Time To Live”, or TTL, which is a duration defined in seconds. A typical, but by no means universal, value is 86400, which is the number of seconds in 24 hours. That is used to determine how long it is safe for other DNS servers to cache the result of the lookup. If you go to the BBC website at 07:30, and if the bbc.co.uk domain TTL was 86400, then your local DNS server will not re-check the address of bbc.co.uk again until the first query after 07:30 tomorrow.
“Please Allow 24-48 Hours For Your Changes To Propagate”
We’re getting closer to understanding this message now. If the TTL is set to 86400, then the DNS servers around the planet may take up to 24 hours to reflect any changes to DNS for your domain.
But that’s not very convenient. If you move your website from one server to another, you don’t want to your visitors to be sent to the “old” server for up to a day.
How To (Mostly) Avoid the Problem
The TTL value for a domain is arbitrary, and can range from 0 (not recommended) to something in excess of 60 years (also not recommended). This TTL value can be changed, typically by editing values in a DNS control panel or, if you run your own DNS servers, by editing the zone records.
Let’s assume you have a TTL of 86400, and that you plan to move your web server to a new IP address in a week’s time. What you should do a couple of days in advance is reduce the TTL value, perhaps to 300. At that point in time, any existing cached records are sill valid for 24 hours, but any new lookups will only be valid for 5 minutes. 24 hours after making the change, all records for your domain cached worldwide should only be valid for 5 minutes.
This will cause more DNS lookups on your DNS servers, but it does help avoid the “24-48 hours” problem. Once your web server has moved to its new IP address, the DNS record (the “A” record) is updated to point to the new IP address, and the TTL can be changed back to 86400.
But there’s still a (minor) problem. Some ISPs configure their DNS servers to cache for long periods regardless of the TTL value. There’s not much you can do about that; even if you don’t use those ISPs yourself, you web visitors may do.
Wrap Up
This is very much a simplification of how DNS works, but, despite the real complexity, the DNS system mostly works very well indeed.