Name Resolution in Practice
Table of Contents
Resource Record Types
Remember, DNS is one of the most important technologies that an IT support specialist needs to know in order to troubleshoot networking issues. So, let's get into the nitty-gritty. DNS in practice operates with a set of defined resource record types. These allow for different kinds of DNS resolutions to take place. There are dozens of different resource record types defined, but a lot of them only serve very specialized purposes. We'll cover the most basic ones here.The most common resource record is known as an A record.
An A record is used to point a certain domain name at a certain IPv4 IP address.
In our earlier discussions of DNS, we made the assumption that the DNS resolver was asking for the A record for a domain name. In its most basic use, a single A record is configured for a single domain name. But, a single domain name can have multiple A records, too. This allows for a technique known as DNS round robin to be used to balance traffic across multiple IPs. Round robin is a concept that involves iterating over a list of items one by one in an orderly fashion. The hope is that this ensures a fairly equal balance of each entry on the list that's selected.
Let's say we're in charge of a domain name www.microsoft.com. Microsoft is a large company and their website likely sees a lot of traffic. To help balance this traffic across multiple servers. We configure four A records for www.microsoft.com at the authoritative name server for the microsoft.com domain. We'll use the IPs 10.1.1.1, 10.1.1.2, 10.1.1.3, and 10.1.1.4. When the DNS Resolver performs a look-up of www.microsoft.com, all four IPs would be returned in the order first configured: 10.1 1.1, followed by 10.1.1.2, followed by 10.1.1.3, and finally, 10.1.1.4. The DNS resolving computer would know that it should try to use the first entry, 10.1.1.1, but it knows about all four just in case a connection to 10.1.1.1 fails.
The next computer to perform a look up for www.microsoft.com would also receive all four IPs in the response, but the ordering will have changed. The first entry would be 10.1.1.2, followed by 10.1.1.3, followed by 10.1.1,4, and finally, 10.1.1.1 would be last on that list.
This pattern will continue for every DNS resolution attempt, cycling through all of the A records configured and balancing the traffic across these IPs. That's the basics of how DNS round robin logic works.
Another resource record type that's becoming more and more popular is the Quad A record.
A Quad A record is very similar to an A record except that it returns in IPv6 address instead of an IPv4 address.
The CNAME record is also super common.
A CNAME record is used to redirect traffic from one domain to another.
Let's say that Microsoft runs their web servers at www.microsoft.com. They also want to make sure that anyone that enters just microsoft.com into their web browser will get properly redirected. By configuring a CNAME record for microsoft.com that resolves to www.microsoft.com, the resolving client would then know to perform another resolution attempt, this time for www.microsoft.com, and then use the IP returned by that second attempt. CNAMEs are really useful because they ensure you only have to change the canonical IP address of a server in one place. In fact, CNAME is just shorthand for canonical name.
If we look again at our original example of making sure that visitors to both microsoft.com and www.microsoft.com get to the same place. We could do this in two ways. We could set up identical A records for both microsoft.com and www.microsoft.com domain names, and this would work just fine. But if the underlying IP address ever changes, we need to change it in two places. The A records for both microsoft.com and www.microsoft.com. By setting up a CNAME that points microsoft.com at www.microsoft.com, you'd only have to change the A record for www.microsoft.com. And you'd know that clients pointing at either domain would get the new IP address. This might not seem like a huge deal with just two records to worry about, but large companies with complex presences on the web might have dozens of these kinds of redirections. It's always easier to only have one source of truth.
Another important resource record type is the MX record.
MX stands for mail exchange and this resource record is used in order to deliver e-mail to the correct server.
Many companies run their web and mail servers on different machines with different IPs, so the MX record makes it easy to ensure that email gets delivered to a company's mail server, while other traffic like web traffic would get delivered to their web server.
A record type very similar to the MX record is the SRV record.
SRV stands for service record, and it's used to define the location of various specific services.
It serves the exact same purpose as the MX resource record type except for one thing, while MX is only for mail services, an SRV record can be defined to return the specifics of many different service types. For example, SRV records are often used to return the records of services like CalDAV, which has a calendar and scheduling service.
The text record type is an interesting one.
TXT stands for text and was originally intended to be used only for associating some descriptive text with a domain name for human consumption.
The idea was that, you could leave notes or messages that humans could discover and read to learn more about arbitrary specifics of your network. But over the years as the Internet and services that run on it have become more and more complex, the text record has been increasingly used to convey additional data intended for other computers to process. Since the text record has a field that's entirely free form, clever engineers have figured out ways to use it to communicate data not originally intended to be communicated by a system like DNS. It's pretty clever, right? This text record is often used to communicate configuration preferences about network services that you've entrusted other organizations to handle for your domain. For example, it's common for the text record to be used to convey additional info to an email as a service provider, which is a company that handles your email delivery for you. There are lots of other DNS resource record types in common use like the NS or SOA records which are used to define authority information about DNS zones.
Anatomy of a Domain Name
Any given domain name has three primary parts, and they all serve specific purposes. Let's take the domain name www.google.com, the three part here should be pretty easy to spot since they're each set off from each other by a period. They're www, google, and com, the last part of a domain name is known as the TLD or Top Level Domain.In this case it's the .com portion of the domain name. There are only a certain restricted number of defined TLDs available, although that number has been growing a lot in recent years. The most common TLDs are ones you're probably already familiar with .com, .net, .edu and so on. You've probably also seen some country specific TLDs such as .de for Germany or .cn for China. Due to the growth of the Internet, many of the TLDs originally defined have become very crowded. So today, a number of vanity TLDs are available, everything from .museum to .pizza. Administration and definition of TLDs is handled by a non-profit organization known as ICANN, or the Internet Corporation for Assigned Names and Numbers and I can tell you what they do.
ICANN is a sister organization to the IANA, and together they help define and control both the global IP spaces, along with the global DNS system.
A domain is the name commonly used to refer to the second part of a domain name, which would be, google in our example. Domains are used to demarcate where control moves from a TLD name server, to an authoritative name server. This is typically under the control of an independent organization, or someone outside of ICANN. Domains can be registered and chosen by any individual or company, but they must all end in one of the predefined TLDs.
That www portion of this is known as the subdomain, sometimes referred to as a host name if it's been assigned to only one host. When you combine all these parts together, you have what's known as a fully qualified domain name, or FQDN.
While it costs money to officially register a domain with a registrar, subdomains can be freely chosen and assigned by anyone who controls such a registered domain. A registrar is just a company that has an agreement with ICANN to sell unregistered domain names. We'll talk more about dealing with registrars in a future module. Technically you can have lots of subdomain names, for example host.sub.sub.subdomain.domain.com can be completely valid. Although you rarely see fully qualified domain names with that many levels. DNS can technically support up to 127 levels of domain in total for a single fully qualified domain name.
There are some other restrictions in place for how your domain name can be specified. Each individual section can only be 63 characters long and a complete FQDN is limited to a total of 255 characters
DNS Zones
We've covered how authoritative name servers are responsible for responding to name resolution requests for specific domains, but they do more than that. An authoritative name server is actually responsible for a specific DNS zone.DNS zones are a hierarchical concept. The root name servers we covered earlier are responsible for the root zone. Each TLD name server is responsible for the zone covering its specific TLD, and what we refer to as authoritative name servers are responsible for some even finer-grained zones underneath that. The root and TLD name servers are actually just authoritative name servers, too. It's just that the zones that they're authoritative for are special cases. I should call out that zones don't overlap. For example, the administrative authority of the TLD name server for the.com TLD doesn't encompass the google.com domain. Instead, it ends at the authoritative server responsible for google.com.
The purpose of DNS zones is to allow for easier control over multiple levels of a domain.
As the number of resource records in a single domain increases, it becomes more of a headache to manage them all. Network administrators can ease this pain by splitting up their configurations into multiple zones.
Let's imagine a large company that owns the domain largecompany.com. This company has offices in Los Angeles, Paris, and Shanghai, very cosmopolitan. Let's say each office has around 200 people with their own uniquely named desktop computer. This would be 600 A records to keep track of if it was all configured as a single zone.
What the company could do, instead, is split up each office into their own zone. So now, we could have la.largecompany.com, pa.largecompany.com, and sh.largecompany.com as subdomains, each with their own DNS zones. A total of four authoritative name servers would now be required for the setup, one for largecompany.com and one for each of the subdomains.
Zones are configured through what are known as zone files, simple configuration files that declare all resource records for a particular zone. So a zone file has to contain an SOA, or a Start of Authority resource record declaration. This SOA record declares the zone and the name of the name server that is authoritative for it.
Along with the SOA record, you'll usually find NS records which indicate other name servers that may also be responsible for this zone.For simplicity's sake, we've been referring to server in the singular when discussing what's responsible for its zone, whether at the root, TLD, or domain level, but there are often going to be multiple physical servers with their own FQDNs and IP addresses involved. Having multiple servers in place for something as important as DNS is pretty common. Why? Well, if one server were to have a problem or suffer a hardware failure, you could always rely on one of the other ones to serve DNS traffic. Besides SOA and NS records, you'll also find some or all of the other resource record types we've already covered, like A, quad A, and CNAME records along with configurations such as default TTL values for the records served by this zone. Just like how subdomains can go many, many layers deep, zones can be configured to do this too but, just like with subdomains, it's rare to see zones deeper than just a few levels.
Sometimes, you'll also see what are known as reverse lookup zone files.These let DNS resolvers ask for an IP, and get the FQDN associated with it returned.
These files are the same as zone files except, instead of A and quad A records, which resolve names to IPs, you'll find mostly pointer resource record declarations. As you might have guessed, a PTR, or Pointer Record, resolves an IP to a name.
Reference:
