The Domain Name System, DNS, makes the Interweb go around. It’s the White Pages of the internet, translating names to numbers, a forward lookup, and numbers to names, a reverse lookup. Having a handle on DNS can help you with basic troubleshooting as a user and is essential for managing and maintaining servers as a Systems Engineer. Without getting any more preachy, let’s move on. There are three primary record types in forward looks ups. An “A” record maps a name directly to an IP. “CNAME” is an alias record. It maps one name to another. “MX” defines mail exchangers responsible for a domain and the associated priority. The lower the number, the higher the priority, i.e. closer to final mail delivery. On the reverse DNS side of the coin, there’s the “PTR” record that maps an IP to a name. Generally speaking, unless you’re doing DNS admin, you don’t need to sweat other records like SOA and NS. Now let’s take a look at the services that actually makes up the Domain Name System. First there’s something called a resolver that lives on your computer. It, well, resolves the query, “What is the IP address of a specific host?” The resolver asks the DNS Servers in the Network System Preferences that you’ve probably pulled down via Dynamic Host Configuration Protocol, DHCP. If one of those Name Servers has previously looked up the IP address of the host in question it hands over the IP. If it doesn’t have that information cached then it needs to go to the Root Name Servers. These guys are the top of the food chain in DNS land and are responsible for the Top Level Domains, TLDs, both the generic (com, net, edu, etc.) and country codes (us, au, ca, etc.). Think of them as the phone company. They have a critical piece of information for resolution to take place. That being which Name Servers are authoritative for a particular domain, or which phone book contains the information we seek. Once the Name Servers (phone book user) that our resolver is querying has retrieved those authoritative Name Servers (phone book) from the Root Name Servers (phone company), they query those Name Servers (phone book), directly for the IP of the host in question and return that to our resolver which hands it off to the requesting application. Whew.
OK so we’ve identified the critical players, let’s put it into action. You fire up Safari and type in www.mac-fusion.com, because that site is rad. Moments later you’re there. We take it for granted but how do it know? Think about it. How did Safari know where all the HTML files were stored for rending the web page you’re checking out? The entire process is pretty fascinating. For now we’ll leave out a whole lot and focus on the big picture. So when you type in the address and hit Enter in Safari, all kinds of stuff happens behind the scenes. And here’s the high altitude, conversational, view of it all:
So if DNS really is the White Pages of the Internet let’s see how hard we can flog this phone book analogy. After hitting Enter, Safari says, “Hey, can you put me in touch with www.mac-fusion.com?” The Network System Preference checks the DNS servers it has, and sends the resolver off on it’s mission. The resolver then asks the DNS servers from Network System Preferences, “I’m looking for www.mac-fusion.com. Do you know which phone book they’re in?” To which, they reply, “I don’t have that cached, let me check with the phone company.” After being asked, the phone company replies, “Ok, mac-fusion.com, you’ll want to check in the following phone books.” And the Root Name Servers pass along the Name Servers authoritative for the domain, in our case, ns2.mac-fusion.com, ns2.mydyndns.org and ns3.mydyndns.org. Network System Preferences says, “Sweet!” and cracks open the phone book, querying those Name Servers. At this point the DNS server from Network System Preferences has looked up the .com and .mac-fusion parts (name resolution takes place from right to left) of the fully qualified domain name, FQDN, now it needs the specific host, www. But a hah! When asking the phone book for www, the DNS server finds www is an alias, a CNAME, for the actual server, hemi.mac-fusion.com. “So where’s hemi at?” demands the DNS server. “hemi’s at 72.26.106.202.”, replies the phone book. The DNS server replies to resolver which turns to Safari and says, “Blow up www.mac-fusion.com at 72.26.106.202.” And Safari does. And you’ve got a kick ass website in front of you.
The End.
Except for the Open Directory and the http and the arp and a million other crazy things that go on behind the scenes. I feel a sequel coming.
The Domain Name System, DNS, makes the Interweb go around. It’s the White Pages of the internet, translating names to numbers, a forward lookup, and numbers to names, a reverse lookup. Having a handle on DNS can help you with basic troubleshooting as a user and is essential for managing and maintaining servers as a Systems Engineer. Without getting any more preachy, let’s move on. There are three primary record types in forward looks ups. An “A” record maps a name directly to an IP. “CNAME” is an alias record. It maps one name to another. “MX” defines mail exchangers responsible for a domain and the associated priority. The lower the number, the higher the priority, i.e. closer to final mail delivery. On the reverse DNS side of the coin, there’s the “PTR” record that maps an IP to a name. Generally speaking, unless you’re doing DNS admin, you don’t need to sweat other records like SOA and NS. Now let’s take a look at the services that actually makes up the Domain Name System. First there’s something called a resolver that lives on your computer. It, well, resolves the query, “What is the IP address of a specific host?” The resolver issues a recursive query to the DNS Servers in the Network System Preferences that you’ve probably pulled down via Dynamic Host Configuration Protocol, DHCP. If one of those Name Servers has previously looked up the IP address of the host in question, it hands it over. If it doesn’t have that information cached then it needs to go to the Root Name Servers. These guys are the top of the food chain in DNS land and are responsible for the Top Level Domains, TLDs, both the generic (com, net, edu, etc.) and country codes (us, au, ca, etc.). Think of them as the phone company. They have a critical piece of information for resolution to take place. That being which Name Servers are authoritative for a particular domain, or which phone book contains the information we seek. Once the Name Servers (phone book user) that our resolver is querying has retrieved those authoritative Name Servers (phone book) from the Root Name Servers (phone company), they query those Name Servers (phone book), directly for the IP of the host in question and return that to our resolver which hands it off to the requesting application. Whew.
OK so we’ve identified the critical players, let’s put it into action. You fire up Safari and type in www.mac-fusion.com, because that site is rad. Moments later you’re there. We take it for granted but how do it know? Think about it. How did Safari know where all the HTML files were stored for rending the web page you’re checking out? The entire process is pretty fascinating. For now we’ll leave out a whole lot and focus on the big picture. So when you type in the address and hit Enter in Safari, all kinds of stuff happens behind the scenes. And here’s the high altitude, conversational, view of it all:
So if DNS really is the White Pages of the Internet let’s see how hard we can flog this phone book analogy. After hitting Enter, Safari says, “Hey, can you put me in touch with www.mac-fusion.com?” The Network System Preference checks the DNS servers it has, and sends the resolver off on it’s mission. The resolver then asks the DNS servers from Network System Preferences, “I’m looking for www.mac-fusion.com. Do you know which phone book they’re in?” To which, they reply, “I don’t have that cached, let me check with the phone company.” After being asked, the phone company replies, “Ok, mac-fusion.com, you’ll want to check in the following phone books.” And the Root Name Servers pass along the Name Servers authoritative for the domain, in our case, ns2.mac-fusion.com, ns2.mydyndns.org and ns3.mydyndns.org. Network System Preferences says, “Sweet!” and cracks open the phone book, querying those Name Servers. At this point the DNS server from Network System Preferences has looked up the .com and .mac-fusion parts (name resolution takes place from right to left) of the fully qualified domain name, FQDN, now it needs the specific host, www. But a hah! When asking the phone book for www, the DNS server finds www is an alias, a CNAME, for the actual server, hemi.mac-fusion.com. “So where’s hemi at?” demands the DNS server. “hemi’s at 72.26.106.202.”, replies the phone book. The DNS server replies to resolver which turns to Safari and says, “Blow up www.mac-fusion.com at 72.26.106.202.” And Safari does. And you’ve got a kick ass website in front of you.
The End.
Except for the Open Directory and the http and the arp and a million other crazy things that go on behind the scenes. I feel a sequel coming.
trying to sort this out. As is typical for Apple when simplifying the GUI side (abstracting things Apple from the Open Source goodies) they kind of complicate what’s happening behind the scenes. In trying to resolve this problem, here are the notes I’ve taken thus far.
