Getting to Know DNS! Part 3

Alright folks! It’s time to finally wrap things up with the final article in my “Getting to Know DNS!” series. In this last article, I will be putting together everything you have read so far in the past two articles and giving you the ultimate look at how name resolution functions on an every day basis. Of course, I will also introduce new terms and functionality as well but by now, you should have a pretty good idea of how DNS looks not only from way up top but also as to what actually comprises of a DNS infrastructure as well. To recap just a bit, at the very least you should have a good understanding of what and how the DNS hierarchy looks like, what a FQDN is and how it relates to the hierarchy, what name servers are and equally important, the basic types of resource records that a DNS server can return to a client. If you have no idea on what I’m talking about at this point and have stumbled upon this article believing that reading the last article in the series is always more fun than reading the first, then yes, you’re right! While you can definitely continue to read on, many of the terms I will be using here will be unfamiliar and to really get a good grasp at how DNS works, its important to get all the details down. So, I highly urge you to read my two prior articles before continuing to get the most out of this one! With that out of the way, let’s begin!

Getting to Know DNS! Part 1

Getting to Know DNS! Part 2

Delegation

The delegation factor is very important where DNS is concerned and I’ve talked about this in the first article. However, I need to go over it again here because not much else will make sense until you get how delegation works. Well, at the very least the concept of it. You already know the DNS hierarchy and the levels within it. Well, how does a name server on the top level of the hierarchy know how to find a name server on the level below it? Simple. By delegating authority of that lower domain to someone else. In other words, allow another organization to maintain and administer it. By adding Name Server (NS) and A/AAAA resource records for the name servers that are authoritative for that specific domain portion, the upper tier name servers know exactly where to direct requests when the request is for a host within that specific domain.

For example, at the very root, there are around 13 root name servers spread across the world. The administrators maintaining these root name servers add NS and A/AAAA records for name servers of the various top level domains, which is the level right below it in the hierarchy. So, it has NS and A/AAAA records for the name servers authoritative for the .com, .net, .org, .edu and a myriad of other top level domains. That’s it.

I actually remember talking to an individual who believed that the IP addresses for these root name servers are somehow a secret and that only privileged DNS servers have access to them! This couldn’t be any farther from the truth. The IP addresses for these root name servers can be located here in this text file which is maintained by InterNIC.

Within the .com name space, the administrators add NS and A/AAAA records for name servers authoritative for the level below it. This includes the name servers for Google, Microsoft, Yahoo and a thousand others that use the .com top level domain. Similarly, the other top level domains add similar records for any second level domains that register their name under it. That’s it.

The name servers responsible for Google, Microsoft, Yahoo are then responsible for managing their actual zone and hosts within it. Again, this includes adding the appropriate NS and A/AAAA for their hosts. That’s it.

DNS Delegation

DNS Delegation

Ask Someone Else!

The good news when learning about how name resolution works is that there is just one major thing you need to keep in mind and that is DNS servers don’t really like to be bothered all that much! There is a very simple process that truly makes DNS so scalable and when you think about it, it’s so simple that you’re probably going to laugh yet admire the person who came up with this strategy. Here is the single thought you must keep in mind at all times: “If I don’t have the answer, then go ask someone else!”

That’s right folks. This one simple statement is what makes DNS so magical. Again, if you think about it, it makes perfect sense. The DNS infrastructure has many different levels. Each level or “tier” is managed by some organization. Therefore, it can be considered decentralized. However, all name servers need to coexist on the Internet (if they want a truly public presence) and so the major factor that ties DNS servers together no matter where they are in the world is that statement I just made. If a DNS server receives a request that it doesn’t have an answer for, then it simply asks another server who does! Eventually, the DNS server will get the right answer and return it to the client. How is this possible? Well, it goes back to directly what I’ve just said earlier. Although DNS servers all over the globe can be managed independently by different organizations, each level of the DNS hierarchy have name servers that are responsible for its own name space. Therefore, there must be some DNS name servers that are authoritative  for that portion of the DNS name space. When you make a name resolution request, it starts from way up top of the DNS hierarchy and continues to trickle down each tier until the name request can finally be solved.

Name Resolution Request Process

To demonstrate the point above, let’s now take a look at how a simple name resolution request that users perform on a daily basis, including yourself, look like. The most simplest of example is to see what happens when you enter in a URL address within your favorite browser. In this case, we want to reach www.microsoft.com. Immediately when you hit the Enter key on your keyboard, name resolution takes place and this is what happens:

  1. The client DNS resolver on the local computer intercepts the name resolution request and first checks to see if the request can be answered locally. If not, then the request will be sent to the DNS server configured on the local computer as a “recursive” query. For most home users, this will be the DNS server located at their ISP headquarters.
  2. The DNS server at ISP headquarters will then check to see if the request can be answered locally by the name server itself either via an authoritative answer or cache lookup. If not, then it will proceed to send an “iterative” query for www.microsoft.com to one of the 13 possible root name servers spread across the world.
  3. At the root name server, it will not be able to give the IP address for www.microsoft.com BUT it will return an address for one of the top level domains (which is directly beneath it in the DNS hierarchy). Basically, this is the root name server’s way of telling the DNS server at ISP headquarter to go bother someone else!
  4. The DNS server at ISP headquarter will now send another iterative request for www.microsoft.com to the IP address it has just gotten from the root name server. This IP address is for one of the DNS name servers in the .com name space.
  5. At the name server over at .com, it will not be able to give the IP address for www.microsoft.com BUT it will return an address for a name server responsible for managing the microsoft.com zone. Basically, this is the .com’s name server way of telling the DNS server at ISP headquarter to go bother someone else!
  6. The DNS server at ISP headquarter will now send another iterative request for www.microsoft.com to the IP address it has just gotten from the .com name server.
  7. At the name server over at microsoft.com, IT WILL be able to fully answer the request because it knows the exact IP address for the host of www within its own microsoft.com zone. This name server is said to be “authoritative” for the microsoft.com zone. The IP address gets sent back to the DNS server over at ISP headquarters.
  8. Upon receiving the answer, the DNS server at ISP headquarter will then return the request to our client resolver which it will then pass back to the application that made the request (the browser in our case).
  9. The client computer can now communicate with www.microsoft.com. via the IP address it has just been given to by the DNS server at ISP headquarters!
DNS Name Resolution Process

Name Resolution Process

This ladies and gentleman, is how DNS name resolution works! You can easily see how each DNS server at each tier of the DNS hierarchy passes off the request it cannot give an authoritative answer for to another DNS server at a lower tier. This simple process continues until the answer can be found. However, after learning about this process, you may have a few questions or two and that is not surprising. Imagine this process happening thousands to even millions of times per second all over the world! While this process does indeed work to help clients find the IP address for a given host, it’s not that efficient. So, let’s continue on in the journey!

Clients Have it Good

By now, you’re probably wondering just what the heck a recursive and iterative query is. However, if you look carefully at the picture above, you can get some sort of idea as to what they are about. Basically, it’s simple.

The client portion performs a recursive query. What this means is that it tells the DNS server at ISP headquarters that hey, look buddy. I gave you a request. The answer that you give me back better be either the answer I’m looking for (the IP address) or an error message itself (if no such host or domain exists)! Looking at it from another perspective, the client, once it has sent its request, is able to just sit back and relax while the DNS server does all the work. Yups, clients have it good!

The DNS server at ISP headquarter, however, needs to perform the bulk of the work and this relates to the iterative requests that it sends out to other DNS name servers. What this means is that for a single iterative request, the DNS server that receives the request knows that it doesn’t have to provide the exact answer to the query. What it only has to do is give the “best answer possible”. This best answer can be known as a referral and it makes a lot of sense. If the DNS server doesn’t have the exact answer for a request, then what it should do is point the DNS server that made the request one step closer to the final destination.

Most public DNS servers perform iterative queries out of respect of not over burdening the root name servers. Can you imagine if the root name servers actually had to perform the bulk of the work instead?! However, DNS servers can definitely refuse to answer recursive queries and I’m sure that is just what the root and .com name servers are doing. In fact, most top level domain name servers should discard recursive queries by default.

Caching

Earlier, I mentioned that the name resolution process is not very efficient. However, in reality, that’s not actually true due to an incredible and simple feature called caching. Once I explain how caching works, you’ll be able to see that for a given name resolution request, it usually just involves steps 1 and 2 in the process I’ve described above and the rest of the other steps are unnecessary.

Caching is not new to DNS but it can definitely have a big impact. A cache is just a temporary location on your hard disk where it can store resource records that it has received from a DNS server. Think about this for a second. If I just made a request for www.microsoft.com and have gotten the correct answer from my DNS server, wouldn’t it make sense that I might make another request to www.microsoft.com in the near future? If yes, then doesn’t it also make sense that instead of repeating the whole DNS name resolution process again, the DNS resolver on my computer can just look in the cache to find the answer to speed things up? Well, of course it does! That’s the whole point with caching and it is a very important feature, especially where DNS servers all around the world are concerned.

In step one, the DNS resolver looks at your local cache to see if it can find the answer to the name request. If it can, then obviously the question has been answered and no query will be sent to an external DNS server. This not only allows your browser to get to the destination faster, but it also allows your DNS server to relax a little since that is one less request it has to perform!

With today’s high speed Internet, receiving an answer either from the local cache itself or via a normal name resolution process doesn’t really matter much and you’re most likely looking at milliseconds of a difference. Also, properly configured DNS servers can withstand pretty big workloads. Nonetheless, it is still important to not skip this step when talking about DNS technology.

Below, you can see a partial display of my DNS cache. You can see that I successfully navigated to Yahoo.com and in the process, cached its A record. Now, if I go back to Yahoo.com, then the DNS resolver would use this cached record to point my browser to the correct destination all without having to get any DNS servers involved.

DNS Cache

DNS Cache

In most cases, your DNS provider will provide the answer to name requests via its own cache look up, which is step 2 in the process. A popular name server such as the one at your ISP headquarter will no doubt have thousands upon thousands of users making requests every minute. It is very likely that someone before you have already made a request for www.yahoo.com. Therefore, the resource record will have been cached at the DNS server as well and the server will be able to use it to answer your request of www.yahoo.com without having to bother the root name servers.

Time to Live

Now you’re probably wondering is that if the cache is all that powerful, can’t we just pre-populate the cache with all types of records pointing to Internet locations we visit often and not have to worry about DNS queries? Essentially, yes, you can do this with the HOST file but it might not be a good idea to do so and there is a good reason why.

As you browse the Internet, you’d no doubt cache all types of resource records. However, what happens if your resolver used a resource record in your local cache but the company actually changed the IP address for that host? The answer is you probably won’t be able to contact that host as long as your resolver keeps using the cached record. To combat this problem, there is a setting on each resource record that specifies how long each DNS server or client can keep that record in its cache. Once that time interval has passed, than the client or server must purge it from its cache. When the client needs to query that name again for its IP address, the entire name resolution process begins anew. This setting for controlling the resource record’s lifetime in the cache is called the Time-to-Live, a.k.a. TTL.

For many companies that have a strong presence on the Internet, they would want to lower the TTL value on their resource records to mere minutes because they want their customers to be always able to locate their web servers after a change. The disadvantage of having a low TTL setting is putting a bigger burden on their name servers. Why? Well because if the resource record in a client’s cache gets purged quickly, then the clients (in most cases this will be DNS servers) will have to manually ask for the IP address again and that means the name servers at the company headquarters will need to do more work in answering those queries.

For many smaller companies and blog sites, they don’t necessarily have to worry much about name or IP address changes within their zone. Therefore, they can afford to set a higher TTL value, such as one hour. There is no right or wrong answer where the TTL setting is concerned. It just needs to make sense for the company. If a company is confident enough that hardly any hosts change on a daily basis within their zone, they could even set their TTL value to a week or more if they so wish.

Below, you can see the TTL value for Yahoo’s resource records being set to 10 minutes:

Time to Live

Time to Live

HOST File

Yes folks, as I’ve mentioned in the first article of the series, the HOST file continues to live on till this very day! During step 1 of the process, the DNS resolver actually consults the HOST file to see if it can also find an answer there for a DNS query. Entries in the HOST file are all statically created, which was one of the reason it lead to its downfall.

If the DNS resolver actually finds the answer to a name request within the HOST file, it will return that answer to the application. It doesn’t matter if the entry is right or wrong. The actual IP address for that host could have changed between the time you made the entry in the HOST file to the resolver actually returning it as an answer. If that is the case, then your browser will not be able to communicate with the destination host. Also, the resolver doesn’t perform any checks whatsoever. This often leads to users playing a prank on other novice computer users where they would make a entry in the HOST file pointing a specific host to a different IP address. Confusion would ensue once the user realizes that heading to www.facebook.com brings them to the www.myspace.com homepage! The HOST file can also be the target for malware. If they are allowed to make changes to your HOST file, they could use this same method to direct your browser to a fraudulent web page. Using the same example above, the attackers could setup a website that closely resembles that of www.facebook.com. Because you are at the fraudulent website, any credentials you enter will be captured by the attackers.

HOST File Prank

HOST File Prank

The HOST file has very limited uses when we compare it to the DNS infrastructure but it still have some uses, especially in limited test environments. The biggest purpose I see in a HOST file is using it as a advertisement blocker. There is actually a group of people out there than maintains and updates a HOST file that you can download and use that is filled with hundreds upon hundreds of entries that direct some of the most popular advertising networks on the Internet back to the IP address of 127.0.0.1. You can learn more about this special HOST file from here.

So Where Do I Fit in the Food Chain?!

Probably the biggest question you have at this point is just where the heck do you, an average user, fit in? Better yet, how do you own a piece of the Internet? Mere mortals like us obviously don’t own or have the know-how to manage a personal DNS name server. Also, we don’t know any of the awesome people who manages the upper level domains! How on earth are we gonna get noticed on the Internet?! The answer? Well, although we don’t have the resources ourselves, we know of people who do!

I’m going to use myself as an example. I wanted to create a blog and in order to do that, I needed two things. First, I needed to register the domain name that I want people to reach me at. Secondly, I needed a web host provider to actually host the data and files needed. Like I said above, I obviously can’t register a domain name by myself. But there are many registrars out there that can help me get this done. For a small fee, of course. Personally, I choose GoDaddy to help me register the anotherwindowsblog.com domain. GoDaddy has special relationships with the organization that do run the .com top level domain so they can help me in this regard. That solves one part of the problem.

For my web host provider, I chose not to go with GoDaddy but instead with HostGator. So now we have a small problem. GoDaddy is responsible for helping me register my name but my hosting is not provided through them. How to solve this problem? Well, it’s actually very simple. HostGator themselves have name servers that they manage for their hosts. Because my hosting is provided through them, then it’s obvious that when someone is looking for the IP address of www.anotherwindowsblog.com, then that answer should come from HostGator’s DNS servers instead and not from GoDaddy’s. How to we make this happen? Again, very simple! I just tell GoDaddy which DNS servers I want to register under my domain name! GoDaddy in turn will help me get that information propagated to the .com name servers. Within a few hours to a day of making that change, the entire world can then reach me at the correct location. If I decide to change my web host to another company, I perform the same procedure. I let GoDaddy know the right name servers my website can be reached at, wait a bit, and BAM! That’s it.

Once that is done, I really don’t have to deal with GoDaddy again. Every year, I just make sure to pay my annual fee of about $10 and that would be it. On the HostGator side, things do get more expensive but the concept is the same. I need to make sure I pay my monthly fee and HostGator will continue to make sure that the necessary resource records to reach my website are maintained. Simple, right?!

In the End…

I hope that you’ve enjoyed this article series! It was fun writing about DNS, one of my most beloved networking topics. There certainly is a lot to take in but if you think about it, it mainly boils down to understanding a couple of key important pieces. They include understanding the DNS hierarchy, name servers, resource records and finally, the actual name resolution process itself. Many of the information I’ve presented in this series was a bit overkill for your average DNS understanding but nonetheless, it should give you an even better understanding of just what goes on behind the scenes.

Now that you have a better understanding of DNS, you’re probably now wondering what are its future plans. DNS has remain largely unchanged throughout the years. If there were changes, it wasn’t big enough to really cause a change in how DNS performs name resolution. However, when DNS was built in the beginning, its creators didn’t really incorporate security into the process. While the creators did a magnificent job at making DNS as scalable as possible, they really had no way of imagining the threat vectors our networks face on a daily basis years after its creation. Well, that’s about to change with DNSSEC. This technology aims to allow clients to authenticate the origin of DNS responses and to prove that the data has not been modified in any way during its transit. Ultimately, while DNSSEC won’t really change how DNS functions today, it will bring a huge shift of changes in the security area and that is definitely a good thing. However, DNSSEC still has a long way to go before it sees widespread use.

With that all said, I want to thank you again for taking the time to reading this article/series on DNS. As with my reasoning for writing all my technical articles, I really hope that you have learned something useful. You should have realized by now that DNS plays an extremely important part in making the Internet work for millions and millions of users around the world. Can the Internet survive without it? It might. But in reality, it’s really not possible at the moment to be able to use the biggest network in the world without some sort of name resolution. While it is possible to remember one or even two IP addresses of our favorite websites, it is almost impossible to remember each and every one of them. It is probably impossible to cram our HOST file with every single Internet host in the world. In fact, it is this very fact that DNS was created in the first place!

So, the next time someone asks you if you know how computers can reach one another on the vast network called the Internet, I hope that by you finishing this article series, your answer will be a definitive YES!

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
Getting to Know DNS! Part 3, 5.0 out of 5 based on 1 rating

Speak Your Mind

*


(humans only, please) *