Just a few notes on the purpose, structure of DNS, with some really basic configuration procedures and tricks for DNS on Linux
The Domain Name System (DNS) is one of the foundations on which the whole Internet stands, from venerable email to services you never heard of. Without DNS, website names would not exist. Basic knowledge of what DNS is, what kind of data it manages and how, should be part of the baggage of EVERY Internet users. Besides, Linux makes it easy to configure any kind of DNS service you want. Let’s have a first look to the DNS world!
DNS (Domain Name System) is one of those services whose basics you want to know, even if you do not have any need or interest in running it for yourself. The main reason is that DNS may be the closest thing we have to a SINGLE point of failure (and control) of the whole current Internet. Another is that you can use DNS to browse the Web a bit faster, or access your own home devices, or files, no matter where you are. This tutorial describes why DNS was developed, how it works today, and outlines some DNS services you may want to run by yourself on (or for) your Linux systems.
Purpose of DNS
Even when, as Linus Torvalds once said, “men were men and wrote their own device drivers” all Internet users needed unique identifiers for each computer on the Internet, in order to reliably connect, every time, just with the one they wanted. Software-wise, there was no problem at all. With the Internet Protocol (IP) each computer, or more exactly: each network interface of each computer connected to the Internet receives a numeric IP address. In the version of IP still dominant today (IPv4), those addresses are quartets of numbers, each ranging from 0 to 255 and connected by dots, as in “18.104.22.168”.
As far as we are concerned here, those IP addresses are all is needed to exchange data packets between computer. Unlike computers, however, human beings really hate remembering numbers. Just think what your social life would be if the ONLY way to address a relative, friend or coworker were by their social security number! The first medicines to cure this pain were plain text files, installed on each computer of a network, where system administrators could associate human-friendly names to each IP address.
That type of file still exists and works fine today. On Linux it is /etc/hosts and by default is almost empty, but you can add to it as many lines you want with this format:
The text above means just what it seems: “hello computer! Whenever any software you are running asks where to find www.linux-magazine.com, tell it to contact the computer whose IP address is 22.214.171.124! TRUST ME!”
As you can see in Figure 1, this name/address association is as simple as potentially dangerous. In a sense, Figure 1 contains the reason why you should know at least the basic concepts of DNS: DNS “mismanagement” may do a lot of harm. The ominous message in the browser appeared because I DELIBERATELY wrote in my own /etc/hosts file that the IP address of www. linux-magazine .com is NOT the right one (126.96.36.199) but the one corresponding to… www. macworld. com. What you see in Figure 1 is simply the MacWorld server telling me “Uh??? These are not the Web pages you are looking for”. But whoever managed to hack DNS may also block your Web surfing, misdirect you to fake websites, or make some servers unreachable by ordinary Web users.
DNS database and Domain names
Early Internet chronicles tell us that plain text files worked like a charm… for the first few months. Very soon, hosts became too many to keep writing their names in EVERY computer of each network. And that was decades ago. Imagine today, when every “Internet of Things” gadget must have, by definition, its own unique IP address!
DNS is a suite of database format, communication protocols and software programs, created to solve this problem for good. To achieve this, DNS:
- groups, into administrative clusters called domains, all the devices (in DNS lingo: “hosts”) directly connected to the Internet
- defines how to assign to an IP address (which may or may NOT be actually attached to a computer!) one or more so-called Fully Qualified Domain Name, or FQDN for short
- specifies how to map, store and retrieve, in the most transparent way possible, all those names and addresses in ONE, huge distributed database
- defines who is allowed to write and distribute each part of that main database
From Hosts to Servers and Records
Here are some essential concepts about the structure of domain names, how DNS servers cooperate, and what kind of data they handle.
Domain names consist of concatenated components, separated by dots, that express the hyerarchical structure of DNS from right to left. In www.linux-magazine.com, for example, the “com” part is the TOP level domain, or TLD, whereas linux-magazine and www are the second and, respectively, third level (sub) domain. In general, subdomains are just what they seem: organizational subdivisions of a larger domain. Hosts, instead, are specific computers or services in a domain. As an example, www.history.universityofcalifornia.edu may be the FQDN of the computer(s) actually hosting the web pages (www) of the history department of the University of California, which by its nature would belong to the .edu (educational) TLD.
Second level domains belong to the individuals or organizations they represent online (in Linux Magazine case, that would be Linux New Media), who pay a yearly fee to register them, that is to have those names written in the DNS database, with them as owners. TLDs, instead, are divided into categories mostly based on geographical criteria (like .de for Germany, or .uk for UK) or functional ones (e.g. .edu, or .gov and .mil for USA government or military bodies). TLDs are created and managed by international organizations like ICANN (Internet Corporation for Assigned Names and Numbers).
Strictly speaking, the really TOP level DNS domain is one that is invisible to end users, and does not correspond to any specific computer or website. This “root domain”, which represents the oneness and centralized hierarchy of the whole DNS, is a mere dot (.) Among other things it is used, in the DNS “zone files” that we will see later, to declare that a domain name is a complete FQDN, without any parts missing. As end users, though, we never have to worry about that dot, because today’s browsers and similar programs add it transparently for us.
DNS server types and ways of working
Questions like “what is the IP address of this domain?” are answered by thousands of DNS servers scattered all over the world. Just like the domain names they handle, those servers work hierarchically. The top ones are called root servers. For efficiency and redundancy there are 13 of them, with names like a.root-servers.net, b.root-servers.net and so on, distributed and mirrored worldwide. All other DNS servers know how to contact the root servers, that is their IP addresses, thanks to a “hints” file (usually /var/named/named.ca on Linux).
In practice, root servers never give complete answers to a DNS query. If you asked any root server the IP address of www.linux-magazine.com, it would only tell you the IP address… of the name server responsible for the “.com” TLD. You should then repeat the same request to that other server. Would that be the end of your quest? No! What a TLD server surely knows is only the IP address of the RIGHT name server: the one that SURELY keeps the complete DNS records for www.linux-magazine.com, including the IP address that you wanted to know in the first place. That computer is the “PRIMARY name server”, that is the server that the DNS keepers designated as the THE ultimate authority that can create, maintain and modify DNS-related information for www.linux-magazine.com. In practice, each domain also has both primary and secondary name servers, which work as backups of the primary one, and share parts of its load.
The initial request to a DNS server that starts the process described in the previous paragraph is almost never done by userspace programs like Firefox or Thunderbird. In fact, all a computer may need to use DNS as intended is the Ip addresses of one to three “resolving name servers”, or resolvers for short. The purpose of resolvers is to pass queries to “real” DNS servers, until they get the final answer their clients can use. They also cache, that is remember for a while, all the answers they get, in order to not repeat the same searches over and over. On Linux, the oldest and simplest way to declare a resolver would be to write its name in the /etc/resolv.conf file:
name server 188.8.131.52
In practice, depending on LInux your distribution, utilities like Network Manager may configure network interfaces and store the corresponding data in different formats and locations. In any case, as shown in Figures 3, you would still have the choice between using the default resolver of your ISP (via the DHCP protocol) or any other one that you prefer.
Show me the data! DNS zone files and records
The part of DNS database that contains all the complete configuration of a domain is called zone. Zone data are stored by primary DNS servers in direct (or forward) and reverse zone files. One server can handle multiple zones.
Every zone file contains two common parameters called $ORIGIN and $TTL (Time To Live) and records of several types. $ORIGIN is the domain for which the current zone is an authoritative source of DNS information. Its main purpose is to make zone files easier to read and maintain, because you can use the @ symbol as an alias for $ORIGIN. Besides, name servers automatically append the value of $ORIGIN to any name in an A or PTR record that does not end in a period (.) in order to create the FQDN for that address. The $TTL parameter dictates after how many seconds a caching server should consider its copy of certain DNS data stale, and fetch it again from the primary server.
The first, mandatory record of a zone file is the one marked as SOA (Start Of Authority). The SOA record of a domain identifies the other records that follow as authoritatives for that domain, assigning to them a unique “serial number” and several timers, usually expressed in seconds. The format is relatively simple (note the trailing periods):
example.com. 86400 IN SOA ns1.example.com. dnsadmin.example.com. (
The first line states that this is an Internet (IN) SOA record for the example.com domain, that the primary name server of that domain is ns1.example.com and that the email of the DNS administrator is firstname.lastname@example.org (yes, the DNS syntax replaces @ signs in email addresses with a dot, because in this context “@” is an alias for $ORIGIN). The first value between parentheses is a unique (for this zone file) version identifier, that MUST be incremented every time its content changes. If this does not happen, secondary DNS servers that periodically check that value will not realize that they should load a new version!
The first three timers in a SOA record define, in this order: how often secondary servers should check if there is a new version to download; how long they should wait to do that if the first attempt fails; the amount of time before the zone’s authoritative status expires. The last timer is not for secondary name servers, but for caching ones: it specifies again after how many seconds they should discard their copy of the data. Besides the SOA record, all the authoritative name servers for a zone must be declared explicitly, in this format:
IN NS ns1.example.com.
IN NS ns2.example.com.
Records like these may seem redundant, but this not the case. To begin with, a SOA record only declares one “master” server, but it is good practice, if possible, to have more than one for redundancy. Besides, listing all the name servers explicitly make their names known to all the caching servers that will need to query them again, sooner or later. The DNS records that actually map computer names to IP addresses are the “A” ones (or “AAAA” ones for IPv6), and CNAME records are used for aliases:
smarttv IN A 192.168.1.5
dadtv IN CNAME smarttv
Each domain may have one or more Mail eXchangers, which is just a fancier name for “email server” and must have their own records, in this format:
example.com. IN MX 10 mail.example.com.
example.com. IN MX 10 mailbackup.example.com.
When a domain has two or more MX hosts, the numeric priority value of their records (10 in the example above) defines how they will share the overall load of incoming email. MX hosts with the same priority take equal shares of that load, in round-robin fashion. Otherwise, the MX hosts with HIGHER priority values are contacted only if all those with lower values are unavailable.
Remember I mentioned “reverse” zone files? They host PTR records, which have the opposite function of A ones and normally used to fight spam. Here is how. By now, you know that records like these (of my own actual mail server):
nexaima.net. IN MX 10 a.mx.nexaima.net.
a.mx.nexaima.net. IN A 184.108.40.206
mean that “the email server of nexaima.net domain is a.mx.nexaima.net, whose IP address is 220.127.116.11”. The PTR record for the same host has a complementary format, with inverted numbers and in-addr.arpa as “top” domain:
18.104.22.168.in-addr.arpa 1800 PTR a.mx.nexaima.net
and just means that the host name of the computer with IP address 22.214.171.124 is a.mx.nexaima.net. Taken together, these last three records help everybody querying DNS to see that email with an @nexaima.net sender address, coming from the IP address 126.96.36.199, was indeed sent the host officially designated as Mail eXchanger for the nexaima.net domain. Nowadays, email failing this check, from any domain, is almost certainly discarded as spam.
There are other types of DNS records, but I am going to mention only one more here. CAA records specify which Certificate Authorities (CAs) can issue the digital SSL/TLS certificates that authenticate domains to Web browsers, and let us visit them over encrypted connections. The simplest form a CAA record is this:
example.com. IN CAA 0 issue “letsencrypt.org”
and means that certificates for the example.com domain can only be issued by letsencrypt.org.
Command line DNS
Linux has several utilities to check DNS data, with adequate documentation if you already know how DNS works and which records it uses. Therefore, here I will only briefly mention them, before passing to some useful “DNS hacks”.
“host” gives IP addresses and email server of a domain name, and viceversa:
#> host www.linux-magazine.com
www.linux-magazine.com has address 188.8.131.52 www.linux-magazine.com has IPv6 address 2600:3c00::f03c:91ff:fe89:28c1 www.linux-magazine.com mail is handled by 100 eileithyia.ntm-gmbh.de. #> host 184.108.40.206 220.127.116.11.in-addr.arpa domain name pointer www.linuxnewmedia.com.
Another tool to finds and displays the main DNS records about a domain is “dig” (output edited for brevity):
#> dig linuxnewmedia.com
;; ANSWER SECTION:
linuxnewmedia.com. 86400 IN A 18.104.22.168
A similar utility is “nslookup”, that can also work in interactive mode. “whois”, instead, provides contact information of the owners of a domain name. Finallly, there is “rndc” which lets you control the status of a DNS server, or change its configuration, with commands like these:
#> rndc status #check status
#> rndc addzone|delzone
#> rndc reload/reconfig