Domain Name System (DNS)

When you type in a human-readable Web site name into the URL bar, such as “www.google.com,” your Web browser doesn’t understand what this means. It needs the machine-readable IP address of the nearest Google Web server to resolve this issue. In comes DNS to the rescue. All of your favorite Web sites have an IP address, but it’s much easier for us to remember “google.com” than to remember “172.217.7.142.” You can try this for yourself. Type in nslookup google.com in the command prompt to query DNS for the IP address of google.com.

DNS, or the Domain Name System, is a hierarchical and logical tree structure. With DNS, we can sync domain names with IP addresses enabling we humans to use memorable domain names (google.com, facebook.com, yahoo.com, gmail.com, etc.). That is it’s primary purpose…to respond with IP addresses, but it’s very transparent and quick to you and me, the end user. This data is hosted in databases called “zones.” Each zone holds many different types of Resource Records (RRs). There are over 30 different kinds of RRs, but the main ones we focus on are:

Address (A) record

The A record is also known as the “host record” because it holds the host name and IP address of a server. When a DNS client requests the IP address of a Web server, it queries DNS using a “forward lookup request” or “forward mapping.”

AAAA record

This record performs the same function as the A record; however, the AAAA record holds IPv6 addresses instead of IPv4 addresses.

Pointer (PTR) record

This is the opposite of an A record. Typically, DNS clients make forward lookup requests, that is, we query DNS with a domain name. The PTR record, however, allows us to make a”reverse lookup request” or “reverse mapping,” which means we query DNS with an IP address and it responds with a domain name. PTR records are optional, so they won’t always work.

Mail Exchanger (MX) record

The MX record is used to identify mail servers for e-mail, which is linked to either the A record or the AAAA record. Email has to be able to go from email server-to-email server. How do those servers know where to send the email? Well, they ask the DNS server. Inside the DNS server is the MX record. This is how all of our devices know where to send your emails.

Canonical Name (CNAME) record

A canonical name is an alias for a server or system. This enables an IP address to have multiple names

DNS Structure

As we know, DNS servers convert domain names into IP addresses. The DNS space is a very, very, very, very distributed database with DNS servers located all over the world. There are 13 root server clusters around the word. These root servers are the jumping off point that can help you find any other domain name in the world. There are hundreds of generic top level domains (gTLDs), such as .com, .org., .net, .gov, .edu, and so on. Additionally, there are over 275 country code top-level domains (ccTLDs), such as .us, .ca, .uk, .eu, .au, and so forth.

At the top is the root DNS server, and we work down from there. The root DNS will refer you to one of the gTLD servers, in this case, the .com gTLD server. From there, the gTLD server directs you to google.com. If you were looking for a subdomain of google.com, like “support,” it would direct you to the support.google.com server. But, how does DNS do all of this?

Berkeley Internet Name Domain (BIND)

DNS servers are usually running a type of DNS software called BIND (unless you are on a Microsoft network running Active Directory). DNS servers sometimes share information with other DNS servers in a process known as “zone transfers.” This process occurs over TCP port 53.

DNS Queries

Let’s look at an example of how we make a DNS query. All DNS queries occur over UDP port 53. I’ll be borrowing an example from What is DNS? Why It’s Important & Why We Need It, (Understanding DNS: Essential knowledge for all IT professionals). I like Mohan’s example because it is very detailed and already neatly put together for referencing, so this is 90 percent his own words…(feeling lazy tonight). I’ve managed to add in more detail and a visual representation using MS Paint to help readers truly understand and appreciate DNS.

In this example, we have a DNS recursive resolver named “ns.atrust.com,” and this will be the first time we look up the address venus.eng.barkingseal.com  No server has the address cached, and the entire hierarchy has to be traversed in order to get the IP address. The steps in the graph are numbered 1 through 9, which I’ll go through in order below.

1. Your workstation contains a stub resolver that talks to your DNS recursive resolver. It is also called a local DNS server and you can find yours by typing ipconfig in the command prompt. The local DNS server is provided to you by your ISP. It provides answers to applications, such as Web browsers, email clients, and IM software, when they ask for name mappings. Your browser does not know the IP address for venus.eng.barkingseal.com, and must therefore ask your stub resolver if it has the IP address cached. Since it does not, the stub resolver asks the recursive resolver server, named ns.atrust.com for the IP address for venus.barkingseal.com. The nsatrust.com recursive resolver has caching capabilities as well. Therefore, if anyone asks for the same address, they can get an immediate response. For the purpose of this example, let’s assume that it does not have the IP address you are looking for cached and must therefore traverse the DNS hierarchy to obtain name mapping through recursive querying.
2. Your caching, recursive resolver has a list of  IP addresses for the main root servers burned into its configuration file when it was manufactured. These “Authoritative DNS Servers,” which distributed across the world, are able to point your recursive resolver to the ones that know about the Top-Level Domain (TLD) that you are asking about (in this case, .com). Your recursive resolver asks one of the root servers where to find an address for venus.eng.barkingseal.com. Your recursive resolver queries for the Fully-Qualified Domain Name (FQDN) all the way down the hierarchy so that if one of the DNS servers along the way has the answer, the query process can stop.
3. The root server says: “I cannot help you, but why don’t you ask one of the generic TLD (gTLD) servers on this list?” This answer is called a “referral,” and for a “.com address,” the response includes addresses for four gTLD servers . The root server always responds with a referral. The gTLD servers know about some generic TLDs, including .com, while others know about TLDs, such as .edu, .gov., or .org. If you are querying for a TLD that is a country code (.us for US, .jp for Japan, or .eu for Europe), the query may be referred to servers run by the country in question, or by someone that hijacked the country’s TLD for profiteering (like Tuvalu or .tv).
4. Your recursive resolver then takes the advice of the root server and asks one of the gTLD servers where to find the name you are interested in, and the gTLD server refers the request to the servers for barkingseal.com.
5. The gTLD servers return the addresses of name servers for barkingseal.com. This is the point in the query where the responsibility shifts to the owners of the domain.
6. The name server for barkingseal.com, perhaps, named ns1.barkingseal.com, knows about names within barking seal.com. In many small and medium-sized organizations, the query would end here, as ns1.barkingseal.com would know about all names within barkingseal.com. If barkingseal.com is a large org., it might have subdomains, such as eng. And mktg. delegated to other parts of the company.
7. For the purpose of this example, ns1.barkingseal.com responds to the query by referring your recursive resolver to a name server for the subdomain eng, in this case, ns1.eng.barkingseal.com.
8. Your recursive resolver asks ns1.eng.barkingseal.com for the address, and the response is, “sure, the address for venus.eng.barkingseal.com is 63.173.189.132.”
9. Your recursive resolver caches the domain name and the IP address and passes it to your stub resolver or browser where it can be cached on your system as well.

All this takes a few milliseconds. But, we can shorten this with caching servers. Again, big thanks to Mohan for this part of the post.  When I had to review DNS again, his article really helped me.

And that’s all, for the most part. There are other uses for DNS besides purely resolves domain names to IP addresses for Web sites. But, that is for a later post.

References:

Gibson, D. (2017). CompTIA SECURITY+ Get Certified Get Ahead SY0401 Study Guide.   Virginia Beach, VA: YCDA, LLC

Mohan. (2017). What is DNS? Why It’s Important & Why We Need It, (Understanding DNS: Essential knowledge for all IT professionals). LinkedIn Corporation. Retrieved from https://www.linkedin.com/pulse/what-dns-why-its-important-we-need-understanding-essential-mohan-/