DNS and Domain Names
The DNS (domain name system) is referred to as the phone book of the internet, and it's responsible for mapping IP addresses to memorable names. Thus, instead of having to remember:
We can instead remember this:
System administrators need to know about DNS because they may be responsible for administrating a domain name system on their network, and/or they may be responsible for setting up and administrating web site domains. Either case requires a basic understanding of DNS.
DNS Intro Videos
To help you get started, watch these two YouTube videos. The first one provides an overview of the DNS system:
How a DNS Server (Domain Name System) works
The second video illustrates how to use a graphical user interface to create and manage DNS records.
And here is a nice intro to recursive DNS:
FQDN: The Fully Qualified Domain Name
The structure of the domain name system is like the structure of the UNIX/Linux file hierarchy; that is, it is like an inverted tree.
The fully qualified domain name includes a period at the end of the top-level domain. Your browser is able to supply that dot since we often don't use it when typing website addresses.
Thus, for Google's main page, the FQDN is:
And the parts include:
. root domain com top-level domain google. second-level domain www. third-level domain
This is important to know so that you understand how the Domain Name System works and which DNS servers are responsible for their part of the network.
The root domain is managed by root name servers.
These servers are listed on the IANA,
the Internet Assigned Numbers Authority, website, but
are managed by multiple operators.
The root servers manage the root domain,
alternatively referred to as the zone, or
the . at the end of the
Alternative DNS Root Systems
It's possible to have alternate internets by using outside root name servers. This is not common, but it happens. Read about a few of them here:
- sdf: https://web.archive.org/web/20081121061730/http://www.smtpnic.org/
- opennic: https://www.opennicproject.org/
- alternic: https://en.wikipedia.org/wiki/AlterNIC
Russia, as an example, has threated to use it's own alternate internet based on a different DNS root system. This would essentially create a large, second internet. You can read about in this IEEE Spectrum article.
Top Level Domain (TLD)
We are all familiar with top level domains. Specific examples include:
- generic TLD names:
- and ccTLD, country code TLDs
- .ca (Canada)
- .mx (Mexico)
- .jp (Japan)
- .uk (United Kingdom)
- .us (United States)
We can download a list of those top level names from IANA, and get a total count of 1,487 (as of August 2022):
wget https://data.iana.org/TLD/tlds-alpha-by-domain.txt sed '1d' tlds-alpha-by-domain.txt | wc -l
Second Level Domain Names
In the Google example, the second level domain is google. The second level domain along with the TLD together, along with any further subdomains, for the fully qualified domain name. Other examples include:
- redhat in redhat.com
- debian in debian.org.
- wikipedia in wikipedia.org
- uky in uky.edu
- twitter in twitter.com
Third Level Domain Names / Subdomains
When you've purchased (leased) a top and second level
domain like ubuntu.com,
you can choose whether you add third level domains.
For example: www is a third level domain or subdomain.
If you owned
you could dedicate a machine or a cluster of machines
resolve to a different location, or
www.example.org could resolve to the second-level domain itself.
- www.debian.org can point to debian.org
It could also point to a separate server, such that debian.org and www.debian.org would be two separate servers with two separate websites or services, just like maps.google.com points to a different site than mail.google.com. Both maps and mail are subdomains of google.com. Although this is not common with third-level domains that start with www, it is common with others.
For example, with hostnames that are not
- google.com resolves to www.google.com
- google.com does not resolve to:
- drive.google.com, or
- maps.google.com, or
This is because those other three provide different, but specific services.
A recursive DNS server is the first DNS server to be queried in the DNS system, which is usually managed by an ISP. This is the resolver server in the first video above. This server queries itself (recursive) to check if the domain to IP mapping has been cached (remembered/stored) in its system.
If it hasn't been cached, then the DNS query is forwarded to a root server. There are thirteen root servers.
Those root servers will identify the next server to query, depending on the top level domain (.com, .net, .edu, .gov, etc.). If the site ends in .com or .net, then the next server might be something like: a.gtld-servers.net. Or if the top level domain ends in .edu, then: a.edu-servers.net.. If the top level domain ends in .gov, then: a.gov-servers.net.. And so forth.
Those top level domains should know where to send the query next. In many cases, the next path is to send the query to a custom domain server. For example, Google's custom name servers are: ns1.google.com to ns4.google.com. UK's custom name servers are: sndc1.net.uky.edu and sndc2.net.uky.edu. Finally, those custom name servers will know the IP address that maps to the domain.
We can use the
dig command to query
the non-cached DNS paths.
Let's say we want to follow the DNS path for google.com,
then we can start by querying any root server.
In the output, we want to pay attention to the QUERY field,
the ANSWER field, and the Authority Section.
We keep digging until the ANSWER field returns
a number greater than 0.
The following commands query one of the root servers,
which points us to one of the authoritative servers for
which points us to Google's custom nameserver,
which finally provides an answer,
in fact six answers,
or six IP address that all map to google.com.
dig @e.root-servers.net google.com dig @a.gtld-servers.net google.com dig @ns1.google.com google.com
Alternatively, we can query UK's:
dig @j.root-servers.net. uky.edu dig @b.edu-servers.net. uky.edu dig @sndc1.net.uky.edu. uky.edu
We can also get this path information using
dig's trace command:
dig google.com +trace
There are a lot of ways to use the dig command, and you can test and explore them on your own.
DNS Record Types
dig command output above,
you will see various fields.
- SOA: Start of Authority: describes the site's DNS entries
- IN: Internet Record
- NS: Name Server: state which name server provides DNS resolution
- A: Address records: provides mapping hostname to IPv4 address
- AAAA: Address records: provides mapping hostname to IPv6 address
dig google.com google.com. IN A 22.214.171.124
Other record types include:
- PTR: Pointer Record: provides mapping from IP Address to Hostname
- MX: Mail exchanger: the MX record maps your email server.
- CNAME: Canonical name: used so that a domain name may act as an alias for another domain name. Thus, say someone visits www.example.org, but if no subdomain is set up for www, then the CNAME can point to example.org.
It's important to be able to troubleshoot DNS issues.
To do that, we have a few utilities available.
Here are examples and you should read the
man pages for each one:
host: resolve hostnames to IP Address; or IP addresses to hostnames
man -f host host (1) - DNS lookup utility host uky.edu host 126.96.36.199 host -t MX uky.edu host -t MX dropbox.com host -t MX netflix.com host -t MX wikipedia.org
dig: domain information gopher -- get info on DNS servers
man -f dig dig (1) - DNS lookup utility dig uky.edu dig uky.edu MX dig www.uky.edu CNAME
nslookup: query internet name servers
man -f nslookup nslookup (1) - query Internet name servers interactively nslookup > uky.edu > yahoo.com > exit
whois: determine ownership of a domain
man -f whois whois (1) - client for the whois directory services whois uky.edu | less
resolve.conf: local resolver info; what's your DNS info
man -f resolv.conf resolv.conf (5) - resolver configuration file cat /etc/resolv.conf resolvectl status
In the same way that phones have phone numbers, servers on the internet have IP addresses. Since we're only human, we don't remember every phone number that we dial or every IP address that we visit. In order to make such things human friendly, we use names instead.
Nameservers and DNS records act as the phone book and phone book entries of the internet. Note that I refer to the internet and not the web here. There is more at the application layer than the HTTP/HTTPS protocols, and so other types of servers, e.g., mail servers, may also have domain names and IP addresses to resolve.
In this section, we covered the basics of DNS that include:
- FQDN: the Fully Qualified Domain Name
- Root domains
- Top level domains (TLDs) and Country Code TLDS (ccTLDs)
- Second level and third level domains/subdomains
- DNS paths, and
- DNS record types
We'll come back to this material when we set up our websites.