We’re all familiar with web addresses such as www.google.com and www.pcandtechauthority.com.au. You’re probably also aware that different forms of address indicate different types of organisation, and different countries – so, for example, you can see at a glance that www.amazon.com is a different sort of entity to www.harvard.edu.
This naming convention is ubiquitous across the internet, but the truth is it isn’t actually needed for the internet to work. The computers that run online sites and servers don’t use addresses like this: they communicate and route data using numeric IP addresses, such as 184.108.40.206. Those familiar website names are there purely to help us users recognise and remember web addresses.
Clearly, some sort of translation system is required, so your computer can work out that when you type www.abc.net.au you really want to connect to 220.127.116.11. This translation process is called the Domain Name System, or DNS. The addresses we’re familiar with are known as domain names, and the process of turning the text of a web address into numbers is called resolving a domain name.
Note that domain names are different to URLs: a URL can include not only the name of a server, but also the path of a file or folder on that server. When you enter a URL such as www.sample.com.au/reviews, it’s only the “www.sample.com.au” part that must be resolved. The computer then contacts this server and requests a resource called “reviews”.
DNS operates through a network of tens of thousands of servers dotted around the web, known logically enough as DNS servers or name servers. These servers store a massive distributed database of domain names, along with the numeric addresses to which each one translates. When you type a web address into your browser, the first thing the browser does is send a DNS resolution request to its closest DNS server, asking for the IP address of that domain. The DNS server returns the associated IP number, and its job is done – the browser can then connect to the server, using its numeric IP address, and fetch the requested page.
It’s a simple concept, but because of the vast number of domains on the internet, and the huge amount of traffic flowing across it, the way DNS is implemented is more complex than it might appear.
A simple DNS experiment
You can see the relationship between IP addresses and domain names by performing a simple, live experiment. In Windows Vista or Windows 7, hit the Start button and type “cmd” into the search box; then hit Enter, to bring up a command prompt. Type the following into the window and hit Enter:
The nslookup command attempts to resolve a domain name to an IP address, and after a very short pause – assuming the computer you’re using is connected to the internet – you should see a result something like this:
The “unknown” server address may be different for you: this is the address of your router, which handles DNS requests for your home network. It normally comes up as “unknown” because it doesn’t have a domain name of its own.
The second IP address, however – the internet address of our sister site Atomic – should appear the same for all.
The fact that this resolution is described as “non-authoritative” reflects a fundamental aspect of the workings of DNS. At the heart of the internet lies a cluster of 13 top-level name servers (see p81), which maintain an authoritative database of the hundreds of millions of registered domain names, and the numeric IP addresses to which they relate.
But powerful though they are, these top-level servers would be swamped if they had to process every one of the staggeringly vast number of DNS lookups that go on around the world every microsecond.
So instead ISPs run their own subsidiary name servers. These servers cache every DNS lookup that passes through them, meaning that most requests can be resolved without any need to contact the top-level servers. And when such servers receive a lookup request for a domain they don’t know, they start by trying to find it in the cache of a nearby DNS server. This keeps network congestion to a minimum, and speeds up responses – and since IP addresses don’t change very often, it’s a pretty safe thing to do. Nevertheless, because a cached resolution doesn’t come directly from a root DNS server, it’s considered non-authoritative.
The speed factor
Understanding DNS isn’t only of academic value: it can have a practical bearing on your day-to-day browsing. Remember that every time you type a web address into your browser, that address must be resolved into a numeric IP address – via a DNS request – before you can be connected to the site you want to visit. If the DNS lookup operation is slow and laggy, it will have a noticeable impact on your browsing. How many times have you found yourself staring at a message along the lines of “looking up host xyz.com” in your browser’s status bar? That message means you’re waiting for a DNS resolution request to be fulfilled.
A blessing and a curse
One of the many beauties of DNS is its hierarchical nature. Every time you make a DNS request, it goes first to your closest name server – ordinarily, the one operated by your ISP. If the address is in this server’s cache, the address can be resolved right there and then, without any need to waste time and resources connecting to other servers.
If your local server doesn’t know the IP address of your target website, it will escalate the request to a name server a little higher up the chain. And if that server doesn’t know the address, it will ask the next one up – and so on, all the way up to one of the internet’s root name servers if necessary.
Most of the time this escalation of a request up the server chain isn’t necessary. That’s just as well, as it means DNS requests that end up stretching right across the internet are rare, and the internet doesn’t grind to a halt amid a maelstrom of requests streaming to and from the top-tier name servers.
Unfortunately, passing DNS requests up through multiple levels of servers takes time, and after a while your PC will give up waiting, on the assumption that your local DNS server isn’t working. Google has estimated that up to 6% of DNS requests fail simply because they’ve timed out.
DNS resolution speed is a significant factor in browsing performance – more so, in some cases, than raw download speeds. In the UK the independent communications regulator Ofcom released a broadband speed report in early 2011 that said: “A slow DNS time does not affect download speed, but can severely affect the responsiveness of the internet while browsing.” Ofcom’s research looked at both DNS latency and failure rates, and found latency variations of up to 100% between popular broadband providers, with anything from 0.2% to almost 4% of DNS requests from ISPs failing completely.
The good news is that if your ISP’s DNS performance is adversely affecting your browsing, you don’t have to stick with your provider’s servers. By default, your router will automatically configure itself to use these servers when you hook it up to your cable or ADSL connection. But you can easily change these settings and use one of the alternative free, open DNS servers instead.
Making the change is a simple matter of typing two numbers into your router’s setup pages. In the majority of cases, you don’t even have to change any settings in Windows itself: Windows’ DNS settings simply point to the router, so the change is transparent to the operating system.
An alternative DNS
The global domain name server network. Click to enlarge.
If you want to experiment with an alternative DNS provider, the best place to start is probably Google’s Public DNS service. DNS needs hardware clout, a decent geographical spread and engineering smarts, and Google has all three in plentiful supply. That makes it a good choice for seeing if your browsing speed could benefit from a change, and if you wish you can rely on the service for regular use, without worrying that it might suddenly vanish.
You can find out more about the service by heading to http://tinyurl.com/yhkhfwm, but to try it out all you actually need is two beautifully simple numbers – the IP addresses of the primary and secondary (backup) DNS servers. These are 18.104.22.168 for the primary server, and 22.214.171.124 for the secondary server. Just pop those into the relevant box in your router’s setup pages, reboot the router to make sure they’re being used, and that’s it.
The only caveat is that if you do somehow mess up your router’s settings, you may find yourself unable to browse the internet looking for help – so make absolutely sure you write down the existing DNS addresses (and ideally the rest of your configuration too) before you make any changes. If you have problems you can then just roll back to the old settings.
Improving browsing speed isn’t the only reason to change your DNS provider. There are also security and privacy issues to consider. That’s because the DNS system is based partly on trust: when you send a DNS lookup request for particular domain, you have no way of verifying that the server is sending you the correct IP address. Normally you can safely assume that it is; but if someone were to deliberately program a DNS server to give out the wrong addresses, you could be in trouble.
For example, when you type your bank’s web address, your browser heads off and asks the DNS server for the IP address of the web server it needs to contact. A maliciously compromised DNS server, rather than giving the numerical IP address of the real “www.lovelyfriendlybank.com.au”, could return the address of a site that looks exactly the same but which is hosted by cybercriminals. Unaware of the deception, you’d enter your login details, enabling the criminals to visit the real site and empty your account.
This sort of attack is known as DNS hijacking, and the good news is that, thanks to the hierarchical way DNS servers pass requests around among themselves, it’s difficult for criminals to spread bad resolution information.
For ISPs, though, it’s a different story. ISPs can easily configure their DNS servers to falsely resolve certain domain names to different IP addresses, and most subscribers will be none the wiser. We’re not suggesting an ISP would steal your banking details, but ISPs have been known to use DNS hijacking to manipulate the content their customers see. For example, by redirecting one domain to another, an ISP could replace a competitor’s adverts with its own. Strictly speaking, interfering with your browsing in this way is illegal, but so far the Information Commissioner’s Office has refused to pursue such matters. So if you suspect your ISP is manipulating your traffic, your best bet is to change to an impartial DNS service.
Although DNS can in theory be used for cybercrime, it can also help to prevent it. Since every website needs to have an IP address, a DNS server is a logical place to store a blacklist of known phishing sites, or sites with illegal or non-child-friendly content. The server can then automatically block DNS requests that resolve to one of these IP addresses.
This idea of blocking dangerous sites at the DNS level is one of the key ideas behind OpenDNS – one of the biggest free public DNS services. OpenDNS also aims to speed up DNS requests, and can even correct typos: request an IP address for “wikipedia.og”, for example, and the OpenDNS servers will direct you to the correct address for wikipedia.org.
The OpenDNS free service is ad-supported, but it doesn’t force these ads on you; in general you only see adverts if you try to visit a page that’s been blocked. You can find out more, including instructions on how to switch to OpenDNS
The internet’s 13 top-level servers
In the grand scheme of the internet, DNS servers are fantastically important. If a computer server could ever be regarded as prestigious, then the servers at the top of the domain name server hierarchy are perhaps the most prestigious of all. They’re known by the humble title of the root name servers, and there are only 13 of them to serve the entire internet, worldwide.
For every single one of the billions of domain name resolution requests that happen every second around the world, the buck stops at one of these 13 servers. Every DNS query goes back to one of them, or to a server that has, at some point, queried them.
Going round in circles
The 13 root servers are referred to, in prosaic internet-standard fashion, simply by the letters A to M. Their internet addresses are a.rootservers.net, b.rootservers.net, and so on to m.rootservers.net.
Think about that for a second, though, and you’ll realise that naming these servers in this standard fashion actually makes little sense. Before a DNS server or computer can communicate with a rootservers.net server, it needs somehow to resolve that domain to an IP address. It’s a chicken and egg scenario.
In practice, what happens is that every router and internet-connected device that might need to resolve an address from scratch is shipped with a root server hints file. This is a list of the 13 root name servers, along with their numeric IP address numbers, which is somewhere to start. This hints file, and other vital low-level internet “bootstrap” data, is maintained by the Internet Assigned Numbers Authority
Point of failure
Since all DNS requests ultimately end up at one of these servers, they represent a potential point of failure for the entire internet. In reality, the chances of them failing are remote. We may talk about them as if they were 13 individual computers in a cupboard somewhere, but the amount of traffic being delivered to each one is way beyond the capacity of any single computer. In reality, each one is a virtual server distributed across almost 250 sites worldwide, consisting of a load-balanced cluster of physical computers.
Nonetheless, there are still only 13 actual addresses for each of these virtual servers, and if one of them stopped working or its data was somehow corrupted, it could cause massive disruption.
Try it out
If you’re tempted to try a new DNS provider then you can – there’s no cost and, so long as you’re careful not to mess up your settings, no risk. Before you do, though, it’s worth checking to see how your current one stacks up against Google DNS or OpenDNS. It’s often hard to pin down browsing problems, so before you blame DNS for slowness and high latency, follow the walkthrough below to get some concrete comparison numbers between old and new servers. If it looks like you’ll get consistently lower lag from your new candidate, don’t hesitate to make the switch.
WALKTHROUGH: Test your DNS speed
If your browsing seems a little sluggish, slow DNS lookups could be part of the problem. If so, it’s worth changing your DNS provider – for example, to use OpenDNS rather than your ISP’s own servers. You can find out whether this will help by testing your current DNS servers against potential replacement candidates.
It’s hard to test DNS performance in isolation, since other factors such as the speed of your connection tend to interfere. But if you head to http://www.codeproject.com/KB/IP/DNSTester.aspx you can download the free DNS Tester program. This tool sends simultaneous requests to two DNS servers and allows you to compare response times.
Click “Download Demo Project” to download the tool. You’ll need to register on www.codeproject.com, but once you’re in there’s nothing more to do. The download is tiny and inside the Zip file you’ll find a single executable file – no installation is required. Simply double-click on the icon to run DNS Tester.
To test your current DNS server you’ll need to know its address. You can get this from your router’s setup web page: the information is usually shown on the front page, as with the Belkin router we’re using here. The two addresses are the primary DNS and a secondary fall-back server.
Now you’re ready to carry out the comparison. In DNS Tester, pop the address of the DNS service you want to test into box 1. For Google DNS this is 126.96.36.199; for OpenDNS, use 188.8.131.52. Then enter the address of your current ISP’s DNS server into the other box and hit Test.
DNS Tester will now send a series of resolution queries to both servers. The IP addresses returned by each server will be shown, and you’ll also see how long (in seconds) each server took to send the response. If your current DNS is consistently slower than your replacement candidate, it’s probably time to switch.