Hello, and welcome to the LinuxAcademy guide to DNS! This is going to be a quick “crash course,” so please buckle your seatbelts and keep your arms and legs inside the vehicle at all times!
What is DNS?
DNS, or “Domain Name System,” is one of the most important parts of The Internet today. DNS is essentially a server or hierarchical configuration of servers that acts as a “phone book” for a network. DNS translates a hostname (name of a computer) to an IP address (“phone number” of a computer).
If you type https://linuxacademy.com in your browser, your browser doesn’t see it as words like we see it. Your browser sees the IP address, just as when you select a contact in your cellphone, your cellphone sees a phone number.
Every networked device, including webservers, phones, computers, modems, routers, even smart lightbulbs and stoves has an IP address. Since humans aren’t as good with numbers as computers are, we invented DNS to translate these numbers into domain names and hostnames that make much more sense to us.
Exercise: Find Google’s IP address using its domain name!
1.Open the terminal or command prompt of your operating system.
a.For Windows: click on your start menu, type “Powershell” and hit “enter”.
b.For OSX: Click on the “Spotlight” magnifying glass and type “Terminal” and hit “enter”.
2.Once you have the utility up, type:
(Linux and OSX users, press ctrl+c to stop the pings after you have seen a few.)
You should see output similar to this:
[root@localhost ~]# ping google.com -c 4
PING google.com (188.8.131.52) 56(84) bytes of data.
64 bytes from lga25s40-in-f14.1e100.net (184.108.40.206): icmp_seq=1 ttl=55 time=21.1 ms
64 bytes from lga25s40-in-f14.1e100.net (220.127.116.11): icmp_seq=2 ttl=55 time=17.1 ms
64 bytes from lga25s40-in-f14.1e100.net (18.104.22.168): icmp_seq=3 ttl=55 time=22.0 ms
3.As you can see, this translates an easy to remember domain name “google.com” into an easy for a computer IP address “22.214.171.124”.
Using https://126.96.36.199 would be a nightmare to have to remember every time you wanted to “Google” something. “Just 188.8.131.52 it!” doesn’t have the same ring to it. What makes it even worse is that Google has A LOT of other IPs that go to the same place. In fact, you probably saw a different IP address than the one in the example. This is why DNS is so crucial!
How Internet DNS works
Anatomy of a DNS Name Server
A DNS Name Server is just a computer. It might be a very small computer, such as a Raspberry Pi, or it might be a giant pool of clustered server nodes. The only requirements for a server to be a DNS server is that it translates Domain Names to IP Addresses. DNS servers typically run a DNS server software such as Bind or Microsoft DNS. These servers can host simple “Static DNS” records that must be modified manually or they can dynamically update their DNS records based on queries they are asked to perform. If a DNS server does not have a particular record, it can reach out to another DNS server to ask it. If this DNS server has the information, the DNS server that initiated the query can then update its own database, or cache, in order to prevent it from having to ask again.
Anatomy of a URL or FQDN
A “Uniform Resource Locator,” commonly known as a “URL,” has a few different parts that will help make DNS easier to understand.
FQDN: The FQDN, or Fully Qualified Domain Name, is the name for an entire URL that resolves a resource. If you just tried to ping “.com” or “linuxacademy” or “www”, this probably wouldn’t work. It can be configured to work, but that’s a topic for another guide. To access resources on the web, the FQDN is required which includes at least the domain name and the TLD.
TLD: The TLD, or Top Level Domain, is the last part of an FQDN. This is typically “.com”, “.org”, or some other short abbreviation. More on this is in the following section.
Domain: The Domain is the most basic form of the record that can be accessed. In this case, linuxacademy.com is the domain name. Sometimes, the website is hosted on the “naked domain” name like this and can be accessed. Many times, however, the naked domain name redirects to the subdomain such as linuxacademy.com in order to get to a resource such as a webpage.
Subdomain or Host: The last part of the FQDN (Computers read the FQDN from right to left) is either a subdomain or a host. In this case, it is a subdomain as there are multiple hosts that respond to the linuxacademy.com subdomain. An example of a host would be webserver1.linuxacademy.com or webserver2.linuxacademy.com. Each of those servers might host the linuxacademy.com website, but when you access linuxacademy.com, there’s a chance you could receive the site from either one. This will make a little more sense when we get to the CNAME records section further in this course.
Note: There is also a dot at the end of a URL that is typically hidden. This simulates the “root servers.” You can see this dot when creating new zone records, a process that will be explained later.
A “zone” is a domain name for which the server answers queries. Zones can get very complicated, but essentially, there are Primary and Secondary zones. A Primary Zone is a zone for which the server is “authoritative.” This means the server has the final say in the DNS records it hosts. A Secondary Zone is a zone for which the server can respond, but does not have the final say. It must communicate with the Primary zone to ensure its records are correct. Having multiple DNS servers helps keep the DNS network resilient to attacks and failures.
Let’s say you have a Name Server for linuxacademy.com. If linuxacademy.com was a town, this server has the phone book for all of the townspeople. Mr. linuxacademy.com, Ms. mail.linuxacademy.com, and so on.
Root Servers and the DNS chain of command
At the top, you have a relatively small number, 13 at the time of this writing, of companies that operate the “root” servers. The group of hundreds of servers known as “Root Servers” are responsible for all of the “Top Level Domains” in existence today. Some examples of Top Level Domains, or TLDs as they’re known, are as follows:
This is by no means an exhaustive list. There are more than 1,000 TLDs in existence today. TLDs range from the very generic, such as .com, to the very specific, such as .cloud, and can also represent the country in which the website is hosted, such as .jp for Japan.
These root servers keep a list of name servers responsible for domains located within each one of these TLDs. These name servers then contain the entries for all of the servers that end with that TLD.
Under the root servers, you then have the TLD name servers. These servers are responsible for each of the TLDs and can tell you where to find the Name Server that hosts the zone for the domain. This domain Name Server can then find the particular resource you are looking for and give your browser the IP address.
A Superhero Receptionist Metaphor
I know there are a lot of words flying around with root servers, Name Servers, TLDs, and subdomains, so I’m going to try to frame these concepts into something a little easier to understand. Let’s try a receptionist metaphor and see how it goes. Oh, and maybe I’ll throw in some superheroes since that’s all the rage right now.
So, let’s say you’re trying to contact a Clark Kent in Metropolis. Let’s say “Clark Kent in Metropolis” represents “linuxacademy.com”. You live in Gotham City and you have no idea how to find this person. It’s 1969 and the internet is still in its infancy as ARPANET, so you won’t be Googling anyone today.
1.You ask your receptionist, Dick Grayson, (your DNS server) to please contact Clark Kent in Metropolis as you have some very important news regarding some green rocks you found. You know his First name (www), his last name (linuxacademy), and his city, (.com).
2.Your receptionist, Dick, takes the information and starts at the local phone carrier (The DNS server hosted by your ISP) since they will probably know how to get to Metropolis. Luckily, the operator has information for all of the cities (root servers) and knows how to get to Metropolis (.com), but they have no idea who Clark Kent is, so the operator reaches out to their boss, the root server, to get the number for the Metropolis operator.
3.Once the operator is patched to the operator in Metropolis, he asks for Clark Kent’s number. Metropolis looks at their list of numbers, finds the Kents (Linuxacademy.com Name Servers) then finds Clark. (The www server that hosts the website!)
4.So, Dick gives you the number and you call Clark. But, uh oh! The call gets disconnected and you need to call him back! You ask Dick again, who calls the operator back and, like a great operator, the operator has stored the direct number to Clark Kent on their notepad so you only have to go through one person this time.
To summarize without superheroes:
1.Your DNS server asks your ISP’s DNS server for linuxacademy.com
2.The ISP server (The resolver…I know it sounds like a superhero name, but it’s not!) looks in its own records. If it doesn’t have it, it starts at the top and asks the root server (which is stored in its “root hints” file) which server hosts the TLD, “.com”.
3.Once it finds a server that hosts the .com TLD, it asks the .com server for the linuxacademy.com IP address.
4.The .com root looks in its records and finds the linuxacademy.com domain, but it’s not sure where to find www, so it refers the resolver to the linuxacademy.com Name Server.
5.The linuxacademy.com Name Server looks in its records and finds linuxacademy.com, which it then provides to the resolver, which then provides to you.
6.Your DNS server receives the IP address for www.linxuacademy.com and stores it in its own records so it doesn’t have to go through this process again unless those records are purged (which is another topic for another guide.)
Your Own Domain Name
Ok, finally, the theory is over. Now, it’s time to get your hands dirty and get your own domain! Obviously, you don’t have to buy one, but feel free to get one and follow along. Having your own domain is especially helpful when going through other Linux Academy courses, particularly the AWS courses.
If you’ve ever seen a commercial break for a large sporting event, you’re probably aware that purchasing your own domain name is quite simple. Choosing the domain registrar isn’t always as simple. Some registrars promise scantily-clad mediocre racecar drivers and others promise the cheapest price on the block. I strongly suggest choosing a registrar that also provides the hosting you wish to use. It will greatly simplify things to have everything in one place. So, if you are using AWS, use Route53 to purchase your Domain name. It might be a few bucks more, but you’ll be glad you did.
If you don’t go the AWS route, you should always consider “WHOIS privacy” when purchasing from another registrar. Trust me when I say this, if your registrar doesn’t provide WHOIS privacy, or at least the ability to purchase it, you will want to change your phone number within a week. Most hosts provide it, but some of the cheaper ones can charge a significant amount to add it. If you do not add it, anyone can perform simple queries on your domain information to find your name, address, phone number, and email address. This includes every ad marketer, “website guru,” and ecommerce salesman out there. So, take it from me, ensure you enable it! Here is a document from AWS Route 53 discussing the privacy settings:
Exercise! Let’s do some WHOIS lookups!
1.Head over to https://who.is in your favorite browser.
2.Type “amazon.com” in the blank and click the magnifying class to search.
Registrant Contact Information:
Hostmaster, Amazon Legal Dept.
Amazon Technologies, Inc.
P.O. Box 8102
State / Province
As you can see, Amazon’s legal department is responsible for their domain. You can see when it was registered, when it expires, Name Servers, the Registrar, and contact information. Amazon certainly has the staff to handle any SPAM coming through their doors, so they can handle what they receive from having this information public. Let’s look at another one:
3.Now let’s search “linuxacademy.com”
Registrant Contact Information:
P.O. BOX 0823-03411
State / Province
This has most of the same information, but wait, when you go to look for their personal information, all you see is “WHOISGUARD PROTECTED” and an address in Panama! I doubt the Linux Academy staff is hiding in Panama right now, so this information must be fabricated! It is. This keeps the mailboxes of the wonderful staff of
Linux Academy nice and empty!
You will find that there are times when you need to enable this information to be seen to purchase SSL certificates and prove you own the domain. You can allow this by turning off the WHOIS privacy temporarily or “unlocking” the domain. These are typically more advanced topics that your registrar will have specific documentation on if the need arises to do these things.
Once you have decided on your registrar and you have your domain name picked out, it’s time to buy it! There’s not a lot to consider here as long as the name is available. You will be surprised at what’s taken and how many people buy names and don’t use them, so a simple web search won’t do. All registrars will tell you immediately if your domain name is available or not.
As you can see in the following picture, the domain name of my dreams is actually available! You will also notice AWS suggests several variations to the name in case it is taken.
Once you add the domain to your cart and click “check out”, you will be brought to an information page. Make sure you fill out this information correctly, ESPECIALLY YOUR EMAIL! Your email will be required to register SSL certificates and to prove ownership of the domain if you ever have to, so don’t lie on this! The Whois Privacy Protection option will keep it hidden. Once you have purchased the domain, you can then access your Route53 dashboard and access the domain, which is called a “Hosted Zone” (Remember Zones?).
Note: Although I will be using AWS to illustrate these concepts, they are universal concepts that apply to all registrars; the buttons and menus might just be in a different place. Consult your registrar’s documentation or support if you can’t find a specific option.
Managing Your Shiny New Domain
Parts of a Record
In AWS, there are 4 primary parts of a record set that we’re going to discuss. There are other parts, but those vary among providers, so we’re going to ignore those for now as they are covered in depth in more advanced AWS courses. To demonstrate a simple record, let’s create an A record that points to a subdomain of linuxfanboy2016.com called “redhat.linuxfanboy2016.com” This will allow anyone to enter http://redhat.linuxfanboy2016.com into the browser to access the server at, let’s just use a fake address, 184.108.40.2066 (please note, this address cannot exist in real life.).
1.Name: The record name is essentially what you would enter in a browser or application before the domain name to access the resource. For instance, in this example, we will enter “redhat” as the name.
2.Type: The record type. In this case, we are using an A, or “Address,” record. Record types will be explained further in the next section.
3.TTL: This is the “Time to Live.” This is how long until the server updates the record if it has been changed. It’s best to leave this alone for now. Amazon is typically extremely fast with DNS propagation, so there’s rarely a reason to touch any of their TTL settings.
4.Value: This is the IP address of the server you are trying to access. In this case, 220.127.116.116 (again, not a usable IP address.) If you happen to have a webserver or EC2 instance you can use, feel free to enter that address here! I strongly suggest the AWS courses for this.
Ok, so now you’ve seen a quick explanation of the required fields, let’s talk about the record types!
Now that you own your own domain and you’ve played around in the settings a little, it’s time to hop back on the theory bus and explain what these record types are. These can be a little confusing when staring at a page full of records, so let’s get started!
1.A Record: The “A Record,” AKA the “Address Record,” is what points your domain name to your server’s IP address. In the above example, we created an A record in order to allow someone to type “redhat.linuxfanboy2016.com” into a browser to access a server with the IP address 18.104.22.1686. You will always have one of these when hosting a website. In the phonebook example above, this is what makes the name to phone number connection.
2.AAAA Record: The “Quad A” record is the same as an A record, but for mapping to IPv6 addresses. It is not used much in AWS now, but as they improve infrastructure, its usage will increase rapidly to catch up with the rollout of IPv6.
3.CNAME: The CNAME record stands for “canonical name.” This record is used to map an alias to a server name. This is commonly used if you have a server at linuxfanboy2016.com and you wish to also access that same server using www.linuxfanboy2016.com. You could just create an A record and point it to the IP address, but if you have several records such as ftp.linuxfanboy.com and mail.linuxfanboy.com, this would require you to change all records if the IP address changes. Large corporations can have a very large number of aliases pointed at one server and this can be very difficult to maintain if they have to change the IP address for all of the records, so they use CNAME records. In the phonebook example, if Clark Kent lived alone, Clark would be an alias of the CNAME Kent as there is only one “Kent” (server) at that phone number. If Martha Kent lived at the house, Martha would be an Alias and Kent would be the CNAME with the same phone number.
FYI: the CNAME actually refers to the server to which the record points. The “Name” field actually refers to an alias. Feel free to use that knowledge to impress your friends. ftp.linuxfanboy.com = alias and linuxfanboy.com = cname.
4.MX Records: “Mail Exchanger” Records. These records point to your mail servers and allow other mail servers to find your mailserver when sending mail. If you send mail to firstname.lastname@example.org, your mailserver (gmail.com, perhaps?) will perform a query on linuxfanboy2016.com’s DNS records to find the MX record, it will then use this record to find the proper server to direct mail to. The mailserver addresses for most hosts can typically be found within the documentation of that host. This would be Clark Kent’s mailing address listed in the phonebook.
5.TXT Records: “Text Records.” These records are typically used for miscellaneous services that require information to be public in your DNS in order to prove ownership of the domain, setup email security, and perform other miscellaneous tasks that are outside of the scope of this guide. Usually, if a TXT record is necessary, there will be sufficient documentation on how to set it up available from the service provider. Do be aware, however, that some providers can be very picky about what goes into their TXT records. Many text records, such as DKIM, require punctuation that is not allowed to be entered manually by some registrars and you will be forced to go through support to get them entered. This would be like Clark Kent having to show his phone bill to prove he owned that phone number.
6.PTR Records: These are “Reverse DNS” records that map an IP address back to the server. Unlike A records, these can only have one record per server. These are typically used to prove that an IP address is who it is supposed to be. An instance where this is especially important is if you have a webserver that has to connect to a mailserver to send mail. The PTR helps authenticate the webserver as authorized to send mail which helps prevent spammers from connecting to your mailserver to pretend they are you. This is like looking at the caller ID and seeing who is calling.
7.SOA Records: The “Start of Authority” record indicates which server is primarily responsible for the DNS of a zone, a contact email for the domain, refresh settings, the version of the domain records, etc. These settings are outside of the scope of this guide as they are typically immutable for most DNS hosting providers. If you run your own DNS server, these can be very important.