I have been trading email with several people recently, talking them through some webhosting stuff, and I just discovered how prevalent this practice was. I should have guessed it when I wrote a post about it earlier, but I didn’t know everybody was doing it this way. Most people I talked to didn’t realize there was any other way.

So it’s worth another look, I think.

Note that this post covers some basic fundamentals to start with. If you already grok DNS, you can skip ahead to the “How to Point a Domain at a Webhost” bit. For now, I’m going to use the word “server” a lot.

Why DNS is Important

So you bought a domain name for a few bucks. That’s great. What nobody told you: A domain name by itself is useless.

Really. Computers cannot connect to domain names. Computers on the internet can only connect to IP addresses. So you have to have a way to convert that domain name into an IP address. The way that happens is through DNS.

DNS? How does it work?

DNS works as a decentralized system. There’s thousands (millions?) of DNS servers in the world, all talking to each other all the time. One way to think of it is as a big tree, with connections coming from the root servers all the way up through to other servers. This is the traditional approach. But a better way to think of it is as a cloud, with connections branching every which way. DNS servers talk to other DNS servers and they don’t much care where they are on the “tree”, generally speaking.

When I make a request for my site, ottopress.com, then a few things happen.

First, my computer checks its memory to see if I’ve done this recently. I probably have, in my case, so it just uses that information if it’s pretty recent. This is known as DNS Caching, and all modern systems do it.

Next, if I don’t know the address, then I know who to ask. I ask my own DNS server. Pop open a command prompt and type ipconfig /all (or ifconfig -a) . You’ll get a big listing of your IP configuration info, and some of those are your DNS servers. Those are provided by whatever gave your computer an IP address. It might be your home router, or it might be your ISP, or maybe you entered them manually. The point is that that DNS IP is where the computer connects to in order to ask it “hey, where is ottopress.com?”.

Now, my DNS server may already know the answer because it has it in memory (DNS cache again). If not, then it knows how to find out.

Firstly, it looks at the name itself. In this case, the name ends in “.com”. That’s important. This is the “Top Level Domain” (TLD), and every TLD has its own set of servers dedicated to it. Actually, there’s a set of servers called the “root nameservers“. They live at root-servers.net. They are a set of 13 servers world wide which distribute the TLD information. (Actually, there’s a lot more computers than “servers”, since each server is separated geographically. The J server, for example, lives in 70 different places. You can see all about them at root-servers.org.)

They deliver a file called the “root zone” file. In fact, this file is rather small (it will even fit on an old-school single sided 5.25″ floppy!), but it contains some critical information that describes the functioning of the DNS system. Specifically, it specifies where things like .com and .org and all the other TLDs can be serviced from. Every DNS server on the planet needs this information, and usually has it cached for a long, long, long time. The thing rarely changes.

So, my DNS server looks at the root zone file and discovers that “.com” domains are handled by some other set of servers, so it goes to those and asks it “where can I get the info for ottopress.com?”

This is an opportune moment to talk about authority.

Authoritative Responses and What They Mean

Every domain name on the internet has to have somebody in control of it. This person is considered to be the “authority” on that domain. He in turn delegates that authority to some DNS server. That server is the only one on the whole internet who knows, for a fact, what IP addresses are connected to his names.

When I get something out of the cache of any server, the result is “non-authoritative”. That is, the DNS server gave me an answer, but it cannot guarantee that the answer is the right one. A non-authoritative answer is the fast one.

Those root servers I talked about are the authorities for the TLDs. They give out the root zone file, which says, among other things, who is the authority for all “com” domains. That server, in turn, doesn’t have the faintest clue what IP address connects to ottopress.com, but it does have information on what nameserver is the authority for ottopress.com.

So my DNS server goes and talks to this new server which the .com servers have told it is the authority. And finally, THAT server says “yes, I know for a fact that ottopress.com lives at 64.202.163.10”.

So, now that it has an answer, my DNS server relays this back to me. It also caches the information, because I’m probably going to ask it again soon, and it’s quicker if it doesn’t have to go through all that again.

How to Point a Domain at a Webhost

So, when you signed up for your webhost, if you got the domain somewhere else, then they very likely told you to “point your domain’s nameservers to X and Y”.  What does this mean, exactly?

Previously, I explained how my DNS lookup went to the .com authoritative nameservers to get the nameserver information. Well, when I change my domain’s nameservers, then what I’m actually doing is changing the information on those .com servers. I’m telling them that these new nameservers are the authorities for all DNS lookups involving ottopress.com. I’m delegating my authority to those nameservers. When I do that, what I’m saying is that those nameservers are now in control over all requests on the internet that involve my domain.

Now, this normally isn’t a bad thing. Running nameservers is difficult and tricky. The syntax is arcane and strange (albeit well worth learning for your toolbox). Plus, you’re probably not in possession of all the information. After all, you hired this web hosting company to host your website for you, and they might change IPs around and such. Better for them to manage it, yes?

No.

There’s a lot of good reasons to manage your DNS yourself. For one thing, you have total control. If you want to do some tricky DNS stuff, or set up email to the domain with MX records, or things like that, then you can do so yourself. Just the ability to edit your own CNAMEs and TXT records easily is well worth it. Heck, maybe you want to get Jabber working on your domain. Who knows?

On the other hand, you have total control, and that includes total freedom to screw it up. And anyway, most web hosts have some kind of easy interface to let you add and remove specific entries yourself, so you still have some control over it.

But now we get back to the main problem, which I was talking about in that previous post. Vendor lock-in.

DNS Propagation Delay and TTL

Remember what I mentioned earlier, when your webhost said to “point your domain’s nameservers to X and Y”? That’s the root of the problem.

DNS lives and dies by a setting called “Time-To-Live” (TTL). The time-to-live is the caching factor I mentioned several times before. When a DNS server gets some new information and stores it in its memory, it also stores the TTL, which it also receives from the other server. The TTL is a time limit on how long it can cache that information. Most DNS servers obey this value extremely well. If the TTL says to cache it for 2 hours, then it caches it for 2 hours and not a second longer.

Well, that nameserver lookup from the .com servers has a TTL too, only it’s a very LONG one. See, those second-level servers are way overloaded. Think about it, every lookup of every .com domain name goes through one server (which is actually a whole bunch of computers geographically spread out too). There’s millions, probably billions, of these lookups a day. So they offload a lot of the information. Where to? Why into everybody else’s caches, of course. The nameserver results tend to have a very long TTL, on the order of a day to a week or so (mean time is about 48 hours). Even then, many DNS servers are configured, by default, to hold these results even longer. Sometimes weeks.

This is because while the IP address corresponding to a domain name might change a lot, the nameservers for one actually rarely change. You don’t switch hosts every week, for example. But your IP might change a lot, if you’re using dynamic addressing or something along those lines.

So what happens when I change that information? Well, basically, all the other servers on the internet that have my information cached will be wrong for some period of time. That period of time is call the propagation delay, because it takes that long for my change to propagate out to the rest of the world. Those caches have to expire and all the DNS systems out there then have to ask me for the new information, assuming somebody asks them for it.

So if I change my IP, it takes a couple of hours for it to get out there, because my TTL is 2 hours. The downside to this is that when your nameserver changes, it takes a friggin’ long time to take effect.

Solving the Problem

The solution is simple: Never change your nameservers.

By that, I mean to keep your nameserver in the same place for as long as you possibly can. And this means, if at all possible, don’t delegate your authority to your web host. Instead, a better option is delegate it to your domain name provider.

I use GoDaddy for my domain names. With purchase of domain, they offer free DNS. It’s not the best interface in the world (actually it’s downright clumsy), but it works well enough. I can point my A record (that’s an “address” record, which connects names to IP addresses) to anywhere I want with relative ease. I can set my own TTL on that lookup (currently it’s 2 hours). If I were to change web hosts, my outage time would be 2 hours instead of 2 days. Why? Because all I have to do is to point my domain name at my new host, after they told me what IP address to point it to. If I instead tried to change my nameservers to theirs, then my outage would be 2 days, at least, because it usually takes at least that long for a change to the .com servers to take effect everywhere. And in some parts of the internet, that outage would be a week, at least. Minimum.

There’s also other options for owning your DNS. ZoneEdit offers both free and paid services for DNS, allowing you to point your domain to them and then controlling it all you like. This allows you to take your domain with you from one registrar to another, without having to worry about your registrar not providing DNS anymore.

Or you can even run your own DNS. That’s a super advanced topic though. Even I wouldn’t attempt that without some serious resources.

Summing up

But the point is that you want your DNS to be somewhere that it’s never going to move. Or, at least, that it’s going to move so rarely that you never have to worry about it. If I changed web hosts, it’s complex, but a simple enough matter that I could do it myself. But seriously, when am I going to move my domain names between registrars? How often does that really happen? Most people pick their registrar and stick with them forever. Unless they seriously raised the rates or something, it’s unlikely I’d ever switch them off GoDaddy.

Also, you want your DNS somewhere that you have a reasonable assurance that nobody’s going to screw with it. You own your domain, but the DNS controls where your domain goes. He who controls the DNS controls the domain, and that’s what ownership is, really. Control. Owning your DNS is the ability to control your own domains. It takes some learning, but seriously, it’s way easier than you think. More interesting too.

Shortlink:

22 Comments

  1. TL; DR 🙂

  2. A lot of talk in the news about DNS, thanks for the very clear explanation Otto. I noticed in my GoDaddy panel recently that they are about to release ‘Premium’ DNS (screen shot here: http://domainnoob.com/media/premiumDnsGodaddy20101112.jpg ). Have you any idea what that is or what we’d use it for?
    Thanks!

    • Word via the Googles says that they’re going to limit the number of zone file entries for non-premium DNS to some number (between 40-60). This is not particularly bad, as most people rarely go above 10-20 entries.

      They’re also adding other DNS related stuff to it. DNSSEC, Templating (to create “templates” for multiple domains, thus allowing you to manage DNS for all of them at once), vanity nameservers, reporting (presumably stats on DNS queries and such). Probably nothing special that most people need, unless you’re managing lots of domains.

  3. […] Here is a very detailed article from @ottodestruct, a WordPress Developer, about DNS. – Why You Should Own Your Nameservers […]

  4. Definitely a huge topic. Something that most people often overlook. A space I’ve been watching for a long time.

    We recently purchased a yearly credit over at Zoneedit, and we’ve been happy there. I also have accounts over at Everydns.

    Recently Amazon started offering Route53, which looks very interesting as well.

    DynDNS has their Dynect (ultra) DNS platform for the enterprise.

    I’d really love to see a feature by feature comparison across the board and see how well the different companies stack up to each other, to really see who has the most effective, lowest-latency, resilient network available.

  5. […] Possédez et contrôlez vos DNS, car ça compte vraiment : via @citizenk […]

  6. Nice write up Otto, thanks. Quick question; if your hosting provider is upgrading servers or is required to make an emergency move, wouldn’t your IP address change and cause your site to get knocked offline with this configuration?

    Perhaps this is simply the trade-off we need to make in order to have full control over our DNS zone records, but I’m cautious because what I describe has happened to me before (even though I paid extra for a static IP on my shared host).

    If you’ve got a solution to this problem or know of a host that offers one, I’d love to hear about it. Thanks again!

    • Yes, yes it would. You may not have noticed, but my IP changed this weekend. I did an upgrade/server move with GoDaddy, and my IP changed. Twas a pain, but it’s dealt with now and I had to make some changes to deal with it.

      The important point of this post is to avoid changing your nameservers. Changing your IP is fine, and relatively quick and painless. Changing nameservers sucks.

      • Good thing that I bookmarked your post, it’s a really good DNS refresher. Am actually a bit worried about having to manually switch A records, so wanted to follow up on this.

        Have you ever used a dynamic DNS setup? If your hosting service/DNS provider allows, this could be a good way to avoid having to manually edit your zone when your machine’s IP changes. Any thoughts on this?

  7. Hi Otto,

    Thanks for the great article. I used to have the DNS for all my domains set up this way but I got complacent recently and just left the name servers at whichever cheapo shared hosting provider I signed up for. That’s all fixed now.

    If you happened to be thinking about writing another article on DNS about why you might want to (or not want to) use a DNS provider such as DynDNS instead of just using your domain registrar’s DNS services, then that article would certainly be much appreciated. I for one don’t understand the benefits of a paid DNS provider, or, really, what they provide that my domain registrar doesn’t.

    Regards,
    John

  8. hey, is what is the unit we use in TTL’s in order to provide the status?

  9. […] Here is a very detailed article from @ottodestruct, a WordPress Developer, about DNS. – Why You Should Own Your Nameservers […]

  10. Thanks for a great article. Very useful for someone who has to deal with domain name configuration, but only very rarely.

    Have you any experience of using CloudFlare? They provide name servers as well as content caching and security. Basic accounts are free.

    • I actually won’t use CloudFlare specifically because they require me to point my nameservers at their systems. Don’t trust them enough to host my DNS, frankly.

      • I changed my name servers into cloudflare and my website stop working.. but it seems normal to wait 24 hours to get back to work.. but after more than 2 days, I decided to communicate with my domain server and they told me to change the old nameservers.. What do you think is the problem with CF?? My domain server is Godaddy.. Please, I’ll be grateful if you could give your opinion.

  11. Thanks for such a neat explanation, have a few question,
    what protocol do DNS servers use to talk to each other ?
    If my browser need is looking for say, some.example.co.net, then would the resolution start from TLD or how would it get it resolved?

    Thanks,
    Nikhil

    • Your browser doesn’t need to know – it will ask the stub resolver of the operating system it runs on. Only there arises the need of a decision what server to query – if necessary – to resolve a hostname.

  12. I was on a shared host using a different pair of nameservers. Even though I had no trouble getting their IP (A record) they changed it during a “network maintenance” causing massive downtime as my domain pointed to their old IP address which now had no HTTP service running on it.

    What can one do about this? Use No-IP’s nameservers and ask web hosts to install DDNS clients on their web servers 😀

    • Use a hosting service that will give you adequate warning before changing your IP address. That is a sufficiently rare event that there should not be any reason for them to not tell you about it.

  13. executing “ifconfig -a” on a (unixoid) computer is useless for obtaining information about nameservers. Instead, you probably want look into /etc/resolv.conf file, or run “nslookup .” and ignore the last lines about “NXDOMAIN”

Leave a Reply to Otto Cancel reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Need to post PHP code? Wrap it in [php] and [/php] tags.