If you have thought about having your own domain, then you have run across the term DNS. DNS is neither incomprehensibly complex nor is it “just like a phone book for the Internet.” Instead, it is like a group of phone books, but each phone book is kept in a different room. Thankfully, it is fairly easy to learn what you need to know, and many steps only need to be done once.
Perhaps five times in the past year I have been asked to explain the system of NS, A, CNAME, and MX records that make up Domain Name Service, or DNS. The bulk of Scott’s readers operate web sites of one form or another, and thus are probably interested in a tutorial on how to take their first steps in the world of DNS.
For the tyros, let me begin with the essential analogy: If you consider “calling me” that is probably how you might conceive of the task: “I want to call George at work.” The phone number is 804.286.4279, but most people think of the task as calling the person who answers, not calling the phone number. In a world of speed dials, skype ids, and voice dialing, phone numbers are generally entered into a directory and never thought of again.
DNS is Domain Name Service. Because DNS means Domain Name Service or Domain Name Server, it is as redundant to talk about a “DNS Server” as it is to speak of any other of my favorite pleonasms such as “hot water heaters,” “PIN numbers,” and “tuna fish sandwiches.”
But what is a “domain name?” A domain name is a string of characters divided into segments by dots. In fact, the names end in a dot, but no one ever writes it. When I worked at HP Labs in the mid-1990s, I got my mail from a machine named:
The “.com” part is called the top level domain, or TLD. There is a growing proliferation of TLDs, but in 2011 in the United States you are likely to have your domain within the well-known TLDs of .com, .org, .net, .info, or .biz.
In the example, the “hp” name is what you usually think of as the personalization element, and what you acquire is the right to use hp.com. Unfortunately, if you get the rights to myname.com, you do not automatically acquire the right to use myname.org.
Let’s say you want to have your own domain, georgeflanagin.com in my case. The first step is the registrar’s office, and in the United States a company named Network Solutions is the final authority on who registers which domain name. Network Solutions charges you money, $35 for the first year, so you should probably think of yourself as leasing rather than owning the domain name.
The first step does not do anything except allow you and you alone to use this name. You can subdomain it: www.georgeflanagin.com, blog.georgeflanagin.com, and so on. You can set yourself up to receive mail with your domain name as the part of the email address to the right of the @. However, acquiring the right to use the name does not create web sites, mailboxes, nor assign you a machine to call home.
The purchase does provide the owner with a smidgen of visibility, and Network Solutions provides an NS record that tells the world where to find the location of the machine that contains information about anything connected with georgeflanagin.com.
Perhaps this seems a tad indirect? Consider it to be a bit like a global meta-phone book that tells you only that you may find out the actual phone number of George Flanagin by looking in the “Richmond, Virginia, USA” phone book. While it is not the entire story, it is quite a helpful piece of information for callers in Turkey, India, and Argentina.
In the case of georgeflanagin.com (http://georgeflanagin NULL.com), the NS record says that the information may be found on either of the two machines whose names are:
These machines contain the A, CNAME, and MX records that tell the complete story of the georgeflanagin.com (http://georgeflanagin NULL.com) domain. But, what are these A, CNAME, and MX records?
(Aside: This article is not about the topic of “routing,” which is how my machine got the numeric address, and how the packets find their way to it.)
It both makes sense and is true that somewhere out in the Wasteland of the Internet there must be a facility that translates text so that when you type in “georgeflanagin.com” you are invisibly directed to the numeric address, 184.108.40.206, that is associated with a machine in “the room behind the garage” of my house.
In DNS-speak, the association of names and numeric addresses is called an “A record.” Part of what Network Solutions does for the $35 is allow you to create, edit, and maintain this association. After you have found a “host” for your websites or whatever else you plan to have under your newly acquired domain name, you can create an A record that associates your domain with a real machine that has a real address.
As an example, my A records are set up like this:
squeezebox.georgeflanagin.com 220.127.116.11 scarpia.georgeflanagin.com 18.104.22.168 beethoven.georgeflanagin.com 22.214.171.124 georgeflanagin.com 126.96.36.199 www.georgeflanagin.com 188.8.131.52 brahms.georgeflanagin.com 184.108.40.206 berlioz.georgeflanagin.com 220.127.116.11 boulez.georgeflanagin.com 18.104.22.168
and so on.
In the Internet world, it is traditional to assign the A record to the machine’s primary identity, but also note that several text addresses may refer to the same machine — and often do.
Getting mail is an entirely different operation from setting aside a little disc space to have a website. As you may have guessed, mail is a different “phone book” within DNS. These records are called MX (Mail eXchange) records.
The part of the population that is still sane wants nothing to do with setting up mail servers and mail routing. Doing so is a thankless and painful job akin to peeling shallots or removing the seeds from habanero peppers. If Dante had lived seven hundred years later, the traitors would have been configuring sendmail. email is best done by letting Google handle it, and they have a fine set of instructions for doing so.
The instructions conclude with a set of MX records that you need to provide to Network Solutions. Mail servers get overworked from spam and undergo frequent configuration changes, so no one with an intent to actually receive mail has only one MX record. The MX records associate a numeric “priority” with the text name of some machine that is set up to handle your mail.
My MX records look like this:
40 alspmx2.googlemail.com. 50 aspmx3.googlemail.com. 30 alt2.aspmx.l.google.com. 20 alt1.aspmx.l.google.com. 10 aspmx.l.google.com.
The priority is not really meaningful as an absolute value, but simply tells senders of mail to try the lower numbered records first, and only try the others if the lower numbered records have failed to deliver the message.
The final kind of DNS entry that concerns most people is the frequently misunderstood CNAME record. Suppose you are not someone with half a dozen servers; in fact, suppose you know me and you say “George, I just registered cletusvandamme.com and I wonder if you could host me on one of your machines? I don’t really want to buy one of my own, I just want to squat.” In this case, you need a CNAME record rather than an A record. The CNAME phonebook is a lookup table of aliases, and a CNAME record provides an initial translation of cletusvandamme.com to www.georgeflanagin.com before the replacement name is translated to 22.214.171.124.
“Why bother?” is a fair question to ask at this point. CNAMEs solve an important problem for you. Suppose that I change my Internet service and my machines get assigned a new address. If you are using a CNAME rather than an A record, you will not need to go back to Network Solutions and change your A record — I will change the A record for my domain, and your machine will still be (correctly) aliased to it. In fact, this is the way most cloud computing addresses work.
Cradle to grave / Soup to nuts:
From the preceding sections, it should be clear that the usefulness of any analogy is related to the precision that is required. When we say: “DNS translates the name of a website into its IP address, much as a phone book translates a name to a phone number,” the analogy is suitable for the use of a browser, but it not as helpful for putting together all the records that make a website work seamlessly.
Let us carefully consider what happened when you type in www.technify.me in order to read this article.
- Your request first went out to your Internet Service Provider (ISP), and the name of this site was looked up on the DNS that your ISP keeps handy for its customers. In other words, it is quite unlikely that your request went all the way to Network Solutions to be resolved.
- From this cache of information, your browser will be told that the IP address you are requesting is 126.96.36.199. The request is then sent to that address through a maze of machines, (I counted 18 machines between the computer where I do my work and the webserver that hosts www.technify.me) each of which is thought to be a bit closer to the destination than the last.
- The request arrives at the proper computer based on the IP address, but the webserver process (Apache) on this machine must be careful. Many machines host more than one website, i.e., they have a number of CNAMEs pointing to the same machine, so more information than the IP address is required to make a decision.
The webserver process decides that because you are requesting the text string www.technify.me, you must want to see the front page of this website and not some other website on the same machine.
The future of DNS:
DNS is changing because the Internet’s entire system of addressing machine with numeric addresses like 188.8.131.52 is changing. The existing system is called IPv4, and the new system is called IPv6. It isn’t really new — the IPv6 system was finalized in 1998, but there has not been a big push to proceed. The family of DNS records for IPv6 will perform the same function and work the same way, but there will be new elements that will allow IPv6 and IPv4 to (peacefully?) coexist. For example, there will be AAAA records for IPv6 that will perform the same function as A records perform in IPv4.
We will look into the changes in a future article on IPv6. For now, the upcoming changes sound like another argument for using CNAMEs if you can. After all, if you just alias some other machine, you can kick the can down the road and get on with the work you get paid to do.
About the Author
George Flanagin is a computer science professional with 30 years of experience in the design, delivery, and business positioning of software products. His Fortune 100 experience includes Hewlett Packard Labs (http://www NULL.hp NULL.com) and Boeing Defense and Space Group (http://www NULL.boeing NULL.com). George has served on the Board of Directors of Triton-Elics Inc. S.A. (http://www NULL.tritonimaginginc NULL.com/site/) of California and Paris, France.
He is the author of a dozen published magazine articles and conference papers, a former lecturer in Computer Science at the VCU School of Engineering (http://www NULL.egr NULL.vcu NULL.edu/Page NULL.aspx?id=138), and a former member of the Board of External Advisors for the School of Information Technology at University of Sydney (http://www NULL.usyd NULL.edu NULL.au/).
You can find George online at:
Digital Gaslight, Inc. (http://digitalgaslight NULL.com)
GeorgeFlanagin.com (http://georgeflanagin NULL.com)