In my previous article, Getting to Know DNS! Part 1, I’ve gone over the very basics of DNS and why it was needed to help power the Internet of today. It is one of the most used network services around the globe on a daily basis. There are literally thousands upon thousands of DNS queries per second and it is the job of DNS name servers all over the world to fulfill this role. In this second article, I will actually get a little more technical on what comprises of a DNS name server. By now, you should have a much clearer picture of how the DNS hierarchy looks like as well as what a fully qualified domain name (FQDN) consists of. If you aren’t sure, I’d suggest you read my previous article prior to reading this one. Here, things get much more technical but you shouldn’t have to worry one bit. I will do my best to go over each piece of the puzzle in a manner that everyone can understand!
All this talk about DNS this and DNS that but I haven’t taken the time to actually go over on what makes DNS tick internally and externally. The better question is, what actually makes DNS function? You already understand the concept of the DNS hierarchy but that’s the view from way up top. To really understand the distributed nature of DNS and what makes it so scalable, we need to focus our attention on DNS servers, a.k.a. name servers. The good news is that name servers are the building blocks of DNS as a whole. If you understand and can master how a name server functions, you also can master DNS as well. However, it’s easier said than done because name servers can be very complex. How they work and behave leads to the very core of DNS itself. A name server is basically a physical computer or in most cases, a server class computer that hosts zones and resource records. When your computer needs to perform name resolution, for example when you need to look up the IP address for www.google.com, then it is these name servers that gets sent the query or request.
Zones are a specific portion of the domain name space. For example, the company Google is responsible for and has total control over the Google.com “zone” within the DNS hierarchy. They registered for it so it belongs to them. They manage it with their own DNS name servers at their corporate headquarters. When a name server responsible for the zone it is managing answers a query for a DNS request for a host within its own name space, it is said that the name server is “authoritative” for it. They are authoritative because those name servers actually hold the resource records for the hosts. For example, if I need to look up the address for www.google.com, the answer I get back will not in most cases be authoritative because the DNS server I was using for the lookup was not directly from Google’s own name servers themselves. My DNS server got the answer either by looking at its cache or by performing an iterative lookup. Don’t worry, I will go into more detail about these two functions in the final article. However, if I switch things up and ask for the IP address for www.google.com directly from one of Google’s own name servers that is responsible for that zone, then the answer I get back will definitely be authoritative. Why? Because the name server I used to issue the query to actually contains the resource record (detailed in the next section) for the host www within the google.com zone. The Google DNS name server didn’t have to look elsewhere to help me find the answer. It itself actually holds the answer!
Although Google is almighty and powerful, it cannot somehow manage other zones for which they have no business managing! For example, while Google has the “authority” to manage the Google.com zone, they have none whatsoever when it comes to managing the Microsoft.com or Yahoo.com zone. As you can easily see, the DNS structure allows companies and businesses all over the world to manage their own portion of the name space all without having to worry or even knowing anything about other zones within the DNS hierarchy! Definitely remember this point as the final piece of the puzzle will be put together in the final article.
Below, you can see what happens when I look up the IP address for www.google.com using OpenDNS as my DNS server of choice (which obviously doesn’t belong to Google). Although I got the answer I was looking for, the answer was not authoritative.
Below, you can see what happens when I issue the same query for www.google.com but this time, I’m explicitly using a name server from Google. As expected, I once again got the answer I was looking for but this time, the answer was authoritative. You can tell because the “Non-authoritative answer” part was omitted.In most cases, you as the user or DNS client don’t really have to pay much attention to all this authoritative and non-authoritative dilemma. The reason I am writing it here is because it can better help you understand DNS from a more technical perspective. Almost all of the queries a user will make on a daily basis will mostly consists of non-authoritative answers, which of course is perfectly fine. This issue only becomes a factor if you’re a DNS administrator.
Now it’s time to talk about what consists of the actual “data” portion of DNS. For any sort of DNS name server, they all have many things in common and one of those is the storage of resource records. For a lack of a better analogy, think of resource records as individual index cards with the physical name server itself as the library. When a user queries a name server or “library” for information, they return back resource records or “index cards” to the user which allows the user to easily find the correct server or “book” in our analogy. There are many types of resource records but only a couple of them see the most use on a daily basis. A single resource record usually contains a single piece of information about a given computer or host. A popular name server can contain literally thousands upon thousands of individual resource records! In the final article, you’ll get to see exactly why this is.
Because I personally am most familiar with Microsoft server technology, here I will use a DNS server in my test lab to give you an idea of what a resource record can look like. To get started, I will be briefly going over six of the most used resource record types stored on DNS name servers today. Again, think of each resource record I list here as an individual “index card”.I don’t want you to get the idea that every DNS server is a Microsoft DNS server! The DNS service within the Microsoft server operating system is just but one method of managing a name server. In the real world however, most companies actually use BIND as their DNS software of choice. BIND is actually free of charge but it takes much more skills to manage as compared to a Microsoft DNS server. However, on many small to mid-size organizations where a Microsoft network and infrastructure is in place, it makes much more sense to deploy their own DNS server service as well due to its integration with its other software and products.
Start of Authority Record = For every zone, there usually exist a single SOA record. Although there can be many, many name servers serving resource records for a given zone (for redundancy and backup purposes), there can however be only one primary or master name server. There are also numerous other pieces of information related to the zone itself contained in the SOA record such as the email address of the person responsible for managing the zone along and the default Time to Live (TTL). This last bit of information is what we are most interested in and I will be talking about it in the next article. The Time to Live information bit plays a large role in reducing the burden of DNS servers.
A or AAAA Record = This is the most popular resource record in the DNS universe. The main job of a name server is to map host names to IP addresses and this resource record does exactly that! The A record is for IPv4 addresses and the AAAA (quad A) record is for IPv6 addresses. Nonetheless, they both serve the same purpose. In the picture below, notice that a host on my network labeled 8client.contoso.com is mapped to the 10.0.0.20 IP address.
PTR Record = A pointer record is the exact opposite of an A or AAAA record. Rather than mapping a host name to IP address, a PTR record maps a given IP address to host name instead. If you think this record is irrelevant in the real world, think again. It can be equally important as an A or AAAA record depending on the scenario. Also, note that the FQDN’s IP address is backward in the picture below. This is correct, although the reasoning behind this largely something you don’t need to concern yourself with.
NS Record = A name server record gives information to clients about which servers in the zone are authoritative for it. For example, Google can have 5 different name servers that is authoritative for their zone. Therefore, there would be 5 NS records as well within that zone. In my example, I only have one name server in my zone and so that is why I only have one entry. If I had 4 or 5 name servers, they would be listed here as well.
Mail Exchange Record = An MX record allows clients to find the server responsible for the handling and delivering of email. In my example, the MX record being shown states that when someone in my zone needs to send an email message, use the server specified in this MX record, which in this case is a server with the host name of ‘exchange’ within the contoso.com domain.
CNAME Record = A canonical name record is also very important where DNS name servers are concerned. It is also this resource record type that makes DNS so flexible in nature. Basically, a CNAME resource record allows a single computer host to be accessed via multiple names or aliases. A popular example is with the www host label. Some companies don’t actually like to give their web server a host name of ‘www’. However, users are most familar with entering www.somecompanyname.com when trying to reach their home page. Therefore, a CNAME record could be created so that whenever someone is looking for a host name of ‘www’, then point them to this server instead. That actual server name could be labeled however the company sees fit. It could actually have a FQDN of toothfairy.contoso.com. The users will still be able to access it because of an awesome resource record type called CNAME!
So far, I’ve only been talking about the server piece of the DNS puzzle. However, DNS is a client/server technology. That client piece of the puzzle is very simple. You are it! Whenever you make a name resolution request, your computer acts as the client while the name server acts as the server. To be more precise, there is a software piece called the DNS resolver that actually does the work. All you need to be aware of is that whenever a request is made for name resolution, the query is handled by the DNS resolver service on your machine. It is the job of the resolver to get the answer you are looking for.
Coming Up Next…
- Understand what are name servers and why they are the building blocks around the entire DNS infrastructure.
- Understand what zones are and what are considered authoritative and non-authoritative answers to a DNS client query
- Understand what resource records are
- Understand the most used resource records in DNS servers today
- Understand the client piece of DNS
Once you’ve gotten this part down, it is time to move on to the next and final article in the series. It is time you finally read about how DNS name servers actually process a DNS request and the work that has to go into each and every time of this happening. By the end of the third article, I promise that the entire picture will become much more clear!