I always find it amazing how little so many people in IT actually know about DNS. Well, today I’m going to give you a brief overview of the basics of DNS, the Domain Name System. We’ll call this, an “Intro to DNS!”
So, what is the Domain Name System (DNS)? It is a hierarchical distributed naming system for any resource connected to the Internet or a private network. It associates various information with domain names, and translates domain names into IP addresses (and vice versa).
Example:
- 66.228.37.203
Nameserver Types
First, lets take a look at the different types of nameservers. The are Master (primary) name servers are the main servers for authoritative DNS zones. These servers provide the information for all the other servers to replicate. The Slave (secondary) servers are the ones that replicate the data from the masters.
A Caching nameserver is a server which maintains a recent cache of DNS lookups. This can increase reliability, decrease query time, and decrease network traffic.
A Recursive nameserver provides lookups for non-authoritative DNS zones. Basically, if a nameserver is responsible for a domain (like sophiedogg.com), a recusrive nameserver would provide information for domains it is not responsible for. There are public recursive name servers, such as Google’s google-public-dns-a.google.com (8.8.8.8). For the most part, your master or slave nameservers should not provide recusrive lookups, unless only for authorized users.
Finally, we have Stealth nameservers, which are hidden name servers. The benefit of having a stealth nameserver is that the internet at large does not know the address of it, and cannot easily attack it!
Note that a single nameserver can fill multiple roles, such as recursive stealth master. Next, lets take a look at some of the different items within a DNS zone record and the vocabulary associated with DNS.
Time to Live
Time to Live (TTL), specified in seconds, limits the lifespan of a record. This value specifies how long a caching nameserver can consider a record valid. If the TTL of a record is set at 1 day (86400 seconds), a caching name server will keep that record in memory for one day. This prevents the nameserver from going through the lookup process for any additional queries within that time period.
Shorter TTL’s can increase the load on the nameserver, however they can be beneficial when changing servers, preventing stale information from being cached. Before any changes involving DNS (like changing IP addresses), it is always a good idea to lower your TTL’s until the changes are complete.
Fully Qualified Domain Name (FQDN)
A Fully Qualified Domain Name record is the complete DNS record, that resolves to an IP address. An example of this would be:
www.sbd.example.com
IP Address Subnetting
It also helps to have some knowledge of IP address subnetting in order to understand some of the terms used in the Domain Name System.
Ex: IP: 10.11.12.13 – Subnet: 255.255.0.0
DNS Record Types
There are many different types of DNS records, more than we will cover here, but these are the most important and most common records.
| Type | Description | Function |
| A | IPv4 Address Record | 32-bit IPv4 Address |
| AAAA | IPv6 Address Record | 128-bit IPv6 Address |
| CNAME | Canonical Name | Alias; Nickname |
| MX | Mail Exchange | Mail Server |
| PTR | Pointer Record | Reverse DNS |
| SOA | Start of Authority | Authoritative Info |
| TXT | Text Record | Various |
So, using this information, lets put together a basic DNS zone! We will start with the SOA record, since it is normally the first record listed in a BIND zone file.
SOA Record
$ORIGIN sophiedogg.com.
$TTL 43200 ; 12 hours
@ IN SOA ns1.sophiedogg.com. sophiedogg.sophiedogg.com. (
2012120208 ; serial YYYYMMDDnumber
21600 ; refresh (6 hours)
600 ; retry (10 minutes)
1209600 ; expire (2 weeks)
10800 ) ; minimum (3 hours)
So, first we start with the domain name ($ORIGIN sophiedogg.com). This defines the domain we are referring to in the rest of our records. Next is the $TTL 43200 field, which specifies the default TTL for records. Both of these values can be changed later in the config file if you wish, affecting any records below the changes. You can also optionally specify per-record TTL values, which will take precedence over this value. Next, we have IN SOA which specifies what kind of record we are defining (SOA). After that we list the primary name server (ns1.sophiedogg.com), followed by the administrative contact email. Now, this email does not have the at (@) sign, instead, the first dot is replaced with an at symbol.
Next are some numbers… What do they mean?!
The first number is the serial number. This unique number specifies the revision number of the zone. The standard format for the serial number is the date, followed by a 2 digit revision number. For example, the serial number 2012120208 corresponds to the 8th revision made on December 2nd, 2012.
The second is the refresh interval. This is how often a slave nameserver tries to refresh the zone file from the master. This is not as important as it had been in the past, as master servers are often configured to automatically notify the slaves of any changes immediately after they are made.
The third is the retry interval, or how long a slave should wait to refresh a zone from the master, if a refresh has failed.
Fourth is the expire time. This specifies how long a slave server can be considered authoritative for a zone, when it is unable to contact a master.
Finally, fifth is the minimum time, or negative caching time. This is how long an error on a record can be kept before another lookup must be performed.
Next, we can take a look at some of the different records in our BIND zone file.
NS Records
A NS Record is what actually specifies the nameservers responsible for our domain! Below is that they look in our BIND zone file:
IN NS ns1.sophiedogg.com.
IN NS ns2.sophiedogg.com.
IN NS ns3.sophiedogg.com.
IN NS ns4.sophiedogg.com.
IN NS ns5.sophiedogg.com.
Basically, it just states the 5 different NS servers. Notice the period at the end of each line. This is necessary, so that BIND knows where the record terminates.
MX Records
The MX record is specified in a similar manner to the NS records, except there is an extra field, which is the mail server priority value. The lower the value, the higher the priority. This will allow us to specify multiple mail servers, for redundancy, if we wish.
IN MX 10 sophiedogg.com.
IN MX 20 backupmail.sophiedogg.com.
CNAME Records
A CNAME record is basically just an alias, or nickname, for another record. Below is an example of a CNAME record:
www IN CNAME sophiedogg.com.
This states that the www record is just an alias for sophiedogg.com. This can allow us to have multiple records that all point to the same IP address, without having to specify an IP address for each record. This is especially useful when updating records; instead of updating multiple records, we only have to update one! CNAME’s are also useful with VirtualHosts in webservers; the web server uses the different names to display different web pages, even though they all use the same IP address. Also, notice how there is no period after the www. This means that the server should append the value from the $ORIGIN field to the record. Thus, the record specified here is actually www.sophiedogg.com.
A Records
A Records are the main IPv4 record of the internet. Without an A record, you would not be able to find a website (via IPv4). If you do a lookup on any website, you should find an A record! We need A records for all of the records we defined above (ns1, ns2, mx, etc). Below is an example of some A records:
IN A 66.228.37.203 ns1 IN A 69.93.127.10 ns2 IN A 65.19.178.10 ns3 IN A 75.127.96.10 ns4 IN A 207.192.70.10 ns5 IN A 109.74.194.10
Notice that there is no host specified in the first record? Basically, just like above with the www CNAME record, we will append the $ORIGIN value to the record. Since there is no record, it ends up just being the $ORIGIN value all by itself. Therefore, the first record specifies the A record for sophiedogg.com, 66.228.37.203. The next 5 records are the name server records. Without these, nobody will know who to ask for information about your domain!
AAAA Records
AAAA (Quad A) Records are the IP address records for the IPv6 internet. Not as important as A records (yet), it is good to have the IPv6 access available if possible. As the internet has run out of IPv4 addresses, more and more connections will be using IPv6, so it is important to start thinking about it now, if you haven’t already.
IN AAAA 2600:3c03::f03c:91ff:fe93:f617 ns1 IN AAAA 2600:3c00::a ns2 IN AAAA 2600:3c01::a ns3 IN AAAA 2600:3c02::a ns4 IN AAAA 2600:3c03::a ns5 IN AAAA 2a01:7e00::a
Everything here is the same as specified in the A records above, except the IP address records themselves. IPv6 addresses use a different format, which is specified in more detail below…
IPv4 vs. IPv6
- Dotted quad with 256 available values per quad (0-255)
- Ex: 10.11.12.13
- 32-bit
- 2^32 available addresses
- 4,294,967,296
- Separated into eight 16-bit sections, with 65536 values per section (0000-ffff)
- Ex: 2600:3c03:0000:0000:f03c:91ff:fe93:f617 (or 2600:3c03::f03c:91ff:fe93:f617)
- 128-bit
- 2^128 available addresses
- 340,282,366,920,938,000,000,000,000,000,000,000,000
Glue Records
Glue records are the IP address records (A and AAAA) at the parent nameserver. In the case of sophiedogg.com, it would be the registrar, such as GoDaddy. If you have a subdomain delegated off of another domain, it would be whoever is responsible for the main domain name.
Hierarchial View of the Domain Name System
Here is a tree showing, as an example, the different levels of the domain name system. The top level, or root level, are the main record keepers for the internet. The root servers keep records related to the level directly below them (.com, .net, etc). Each level keeps records for the level directly below them. These are the glue records!
Example of a Recursive DNS Transaction
Below is an example of a recursive DNS query. It is important to know that a recursive server always has a copy of the IP addresses of the root nameservers, in order to provide the necessary addresses for step #2 in the figure below. This list of root nameservers need to be kept up to date, or else the recursive nameserver will not know where to start its lookups!
- 1: The Client asks a Recursive DNS server for the record associated with www.sophiedogg.com.
- 2: The Recursive DNS server query’s the Root DNS servers, asking for the DNS server records for the .com TLD.
- 3: The root DNS server responds with information for the .com DNS servers.
- 4: The Recursive DNS server query’s the .com DNS servers, asking for the DNS server records for the sophiedogg.com domain
- 5: The .com DNS server responds with information for the sophiedogg.com DNS servers
- 6: The Recursive DNS server query’s the sophiedogg.com DNS servers, asking for the specified (A, AAAA, MX, etc.) record for www.sophiedogg.com.
- 7: The sophiedogg.com DNS server responds with the requested value for www.sophiedogg.com
- 8: The Recursive DNS server responds to the client’s original request with the necessary information
- 9: The client can actually access the requested website!
Lets walk through the actual steps of a recursive DNS query, looking up the record www.sophiedogg.com, from the perspective of a recursive DNS server (note the results have been shortened).
$ dig ns ... ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518392 IN NS a.root-servers.net. . 518392 IN NS b.root-servers.net. ...
$ dig ns com @a.root-servers.net ... ;; QUESTION SECTION: ;com. IN NS ;; AUTHORITY SECTION: com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. ...
$ dig ns sophiedogg.com @a.gtld-servers.net ... ;; QUESTION SECTION: ;sophiedogg.com. IN NS ;; AUTHORITY SECTION: sophiedogg.com. 172800 IN NS ns1.sophiedogg.com. sophiedogg.com. 172800 IN NS ns2.sophiedogg.com. ...
$ dig a www.sophiedogg.com @ns1.sophiedogg.com ... ;; QUESTION SECTION: ;www.sophiedogg.com. IN A ;; ANSWER SECTION: www.sophiedogg.com. 43200 IN CNAME sophiedogg.com. sophiedogg.com. 43200 IN A 66.228.37.203 ...
Notice that the www.sophiedogg.com record is actually a CNAME for sophiedogg.com. In this case, the A record for sophiedogg.com is also returned.
Next, lets take a look at a cached DNS lookup…
Cached DNS Transaction
Notice how many fewer steps there are a cached DNS transaction!
- 1: The Client asks a RCaching DNS server for the record associated with www.sophiedogg.com.
- 2: The Caching DNS server already has a cached copy of the results of the query, and responds directly to the client, without querying any other nameservers
- 3: The client accesses the requested website!
In a recursive query, the server skips all of the steps detailed in the section above, since it already has a copy of the record! This can greatly improve DNS response time, and decrease overall network traffic.
Recursive Vs. Non-Recursive
A recursive name server will provide information about domains that it is not authoritative for, while a non-recursive name server will not. Think of it like this, if I ask you for the phone number for someone on the other side of the world that you don’t know, chances are you aren’t going to give it to me. You would have to go through the trouble and time of looking that number up before giving it to me. This would be non-recursive. If you actually did look up this phone number and provide it to me, you wold be providing a recursive lookup service. Similarly, you do not want your DNS servers answering queries that it is not authoritative for. This can add an additional burden to your nameserver, and leave your name servers open to a denial of service attack. Of course you need some recursive name server, in order to find the records necessary to access the internet, but the recursive functionality should only work for those you approve. An example of a non-recursive lookup failure is below:
$ nslookup google.com ns1.sophiedogg.com Server: ns1.sophiedogg.com Address: 2600:3c00::a#53 ** server can't find google.com.com: REFUSED
Whois records
A Whois record provides more detailed information about a domain, such as the owner, their address, phone number, and email address. Many people opt to purchase whois privacy products, which essentially let you use a 3rd party’s information in your whois record. An example of Sophiedogg.com’s whois information is below. Notice that it uses a privacy provider to hide any real information…
Domain Name: SOPHIEDOGG.COM Registrar URL: http://www.godaddy.com Updated Date: 2013-03-05 18:43:36 Creation Date: 2011-03-29 19:08:42 Registrar Expiration Date: 2015-03-29 19:08:42 Registrar: GoDaddy.com, LLC Registrant Name: Registration Private Registrant Organization: Domains By Proxy, LLC Registrant Street: DomainsByProxy.com Registrant Street: 14747 N Northsight Blvd Suite 111, PMB 309 Registrant City: Scottsdale Registrant State/Province: Arizona Registrant Postal Code: 85260 Registrant Country: United States Name Server: NS1.SOPHIEDOGG.COM Name Server: NS2.SOPHIEDOGG.COM Name Server: NS3.SOPHIEDOGG.COM Name Server: NS4.SOPHIEDOGG.COM Name Server: NS5.SOPHIEDOGG.COM
While it is possible to just fake information in your whois record, this is generally not allowed under the Terms of Service of the registrar. If they find out, they may seize your domain name…
BIND DNS Zone File Example
Here is an example of a valid BIND DNS zone file for sophiedogg.com:
$ORIGIN sophiedogg.com.
$TTL 43200 ; 12 hours
@ IN SOA ns1.sophiedogg.com. sophiedogg.sophiedogg.com. (
2012120208
21600
600
1209600
10800 )
IN NS ns1.sophiedogg.com.
IN NS ns2.sophiedogg.com.
IN NS ns3.sophiedogg.com.
IN NS ns4.sophiedogg.com.
IN NS ns5.sophiedogg.com.
IN MX 10 sophiedogg.com.
IN TXT "v=spf1 mx -all"
IN A 66.228.37.203
IN AAAA 2600:3c03::f03c:91ff:fe93:f617
ns1 IN A 69.93.127.10
ns1 IN AAAA 2600:3c00::a
ns2 IN A 65.19.178.10
ns2 IN AAAA 2600:3c01::a
ns3 IN A 75.127.96.10
ns3 IN AAAA 2600:3c02::a
ns4 IN A 207.192.70.10
ns4 IN AAAA 2600:3c03::a
ns5 IN A 109.74.194.10
ns5 IN AAAA 2a01:7e00::a
www IN CNAME sophiedogg.com.
Best Practices for your DNS Servers
Below is a list of some best practices for running your own DNS servers. This list is by no means exhaustive; there are other things you can do, that are beyond an “Intro to DNS” post.
- Primary nameserver should be stealth!
- Public nameservers should be slaves.
- At least 3 public nameservers.
- Public nameservers should not be recursive.
- Nameserver version should be hidden.
- Glue records should be used!
- Nameservers should accept TCP and UDP!
- Nameservers should be on separate networks.
- TTL Values should follow RFC recommendations.
Finally, if you are interested in learning more about DNS, below are some excellent resources.