Introduction to DNS

The Domain Name System is one of the most basic, and oldest, infrastructure components the internet. DNS is a decentralized, hierarchical database that maps keys to values, kind of like a dictionary. This store is primarily used to map names, say lainchan.org to an IP Address 107.161.19.243. This is essential to the internet because routers are able to get data to IP Addresses, but not domain names. So, a computer makes a DNS Request to translate the a name to a machine usable number. To start this process off, your computer has the IP Address of a DNS server to start with - This is normally assigned by the network you are connected to (via DHCP), and a point of contention lately: ISPs have been fighting to retain control of your DNS server as its a common point of commercial surveillance. This has played out in Comcast lobbying the government to intervene in DNS over HTTPS, ATT Routers preventing you from setting DNS, Mobile ISPs blocking DNS requests to alternate servers, and Mobile OSs not even allowing you to set DNS. More articles on DNS and privacy are to follow.

Interestingly, DNS has alternative applications than just mapping IP Addresses and Domain Names. The DNS system can also map a service type for a domain to a host with service records (SRV), and has been used to map companies to contact information. Currently, since SMTP has no built in authentication to verify messages sent to a yahoo SMTP server from a google SMTP actually come from google, out of band mechanisms involving DNS have been created including SPF, DMARC and DKIM. DNS is also used to verify ownership of domains for the purpose of issuing SSL certificates by projects like https://letsencrypt.org.

DNS uses a Tree Structure to make lookups fast and that Tree is decentralized via delegation. Owners of some portion of the namespace can delegate sub-portions to alternate owners. The DNS namespace begins at the root “.” and portions of the root namespace are delegated as “Top Level Domains” or “TLDs”. Popular TLDs include “com”, “net”, “org”, And so the top portion of the contains the following (incomplete) tree:

 .

      / | \

     / | \

   com net org

The root is owned by “ICANN”, a Yankee corporation formed for the purpose, and Domain Registrars assign people portions of the namespace below “TLDs” for a fee. For instance “lainchan.org” is really “.”->”org”->”lainchan” . Each of these parts of the namespace has a set of “authoritative” DNS servers which own a portion of the namespace and respond to requests for their portion. The DNS root servers control the root, and delegate control of TLDs, we can see this here using the dig command - a tool to preform DNS lookups. Here, we query a root server, f.root-servers.net. (“.”->”net”->”root-servers”->”f”) for com. (“.”->”com”).

dig @f.root-servers.net com.

...

;; AUTHORITY SECTION:

com. 172800 IN NS a.gtld-servers.net.

com. 172800 IN NS b.gtld-servers.net.

com. 172800 IN NS c.gtld-servers.net.

com. 172800 IN NS d.gtld-servers.net.

com. 172800 IN NS e.gtld-servers.net.

com. 172800 IN NS f.gtld-servers.net.

com. 172800 IN NS g.gtld-servers.net.

com. 172800 IN NS h.gtld-servers.net.

com. 172800 IN NS i.gtld-servers.net.

com. 172800 IN NS j.gtld-servers.net.

com. 172800 IN NS k.gtld-servers.net.

com. 172800 IN NS l.gtld-servers.net.

com. 172800 IN NS m.gtld-servers.net.

;; ADDITIONAL SECTION:

a.gtld-servers.net. 172800 IN A 192.5.6.30

a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30

b.gtld-servers.net. 172800 IN A 192.33.14.30

b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30

c.gtld-servers.net. 172800 IN A 192.26.92.30

c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30

...

Here we see that the root servers delegate the com. TLD to various servers who later in the tree have names under gtld-servers.net. An interesting question you might have is, how do the root servers know the address of “a.gtld-servers.net” which comes later in the tree? This is actually done through “glue records”. You can view the Root DNS Zone https://www.internic.net/domain/root.zone. And if you look, you see that “com.” is controlled by “a.gtld-servers.net” with the following line:

com. 172800 IN NS a.gtld-servers.net.

But you also see the following line in the file

a.gtld-servers.net. 172800 IN A 192.5.6.30

So, a Owner of the namespace that delegates (via NS record) must know the address of who he delegates too. How could it work otherwise. You delegate to a name, but as “glue” include the address of the name you delegate too.

Lets follow the Tree now for lainchan.org as an experiment:

dig @a.root-servers.net org.

org. 172800 IN NS d0.org.afilias-nst.org.

org. 172800 IN NS a0.org.afilias-nst.info.

org. 172800 IN NS c0.org.afilias-nst.info.

org. 172800 IN NS a2.org.afilias-nst.info.

org. 172800 IN NS b0.org.afilias-nst.org.

org. 172800 IN NS b2.org.afilias-nst.org.

...

dig @d0.org.afilias-nst.org lainchan.org

lainchan.org. 86400 IN NS dns1.registrar-servers.com.

lainchan.org. 86400 IN NS dns2.registrar-servers.com.

So, we see that lainchan.org has DNS servers registrar-servers.com responsible for it. Finally, We can query the official, authoritative DNS server for lainchan.org to make lookups in its space.

dig @dns1.registrar-servers.com lainchan.org

...

lainchan.org. 1800 IN A 107.161.19.243

...

This is actually a lot of DNS requests to make for a single lookup, and this is also widely inefficient. Instead, ordinary users use caching DNS servers - shared DNS servers that remember lookups therefore keeping all there users from querying the root servers, and therefore overloading it. These caching servers will preform “recursive lookups” for you - or in one shot taking an arbitarily deep and potentially unseen hostname a.subdomain.domain.tld and preforming all lookups necessary and using whatever is cached to return a result. This is actually necessary, because the “resolvers” built into computer programs that use DNS, usually through the c libraries gethostbyname() function, cannot use a non-recursive server.

So, you might naturally wonder, what does a non-recursive server do when queried for some portion of the namespace it doesn’t own. Lets find out:

dig @f.root-servers.net lainchan.org

; <<>> DiG 9.11.24-RedHat-9.11.24-2.fc32 <<>> @f.root-servers.net lainchan.org

; (2 servers found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25171

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 13

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1472

;; QUESTION SECTION:

;lainchan.org. IN A

;; AUTHORITY SECTION:

org. 172800 IN NS a0.org.afilias-nst.info.

org. 172800 IN NS a2.org.afilias-nst.info.

org. 172800 IN NS b0.org.afilias-nst.org.

org. 172800 IN NS b2.org.afilias-nst.org.

org. 172800 IN NS c0.org.afilias-nst.info.

org. 172800 IN NS d0.org.afilias-nst.org.

;; ADDITIONAL SECTION:

a0.org.afilias-nst.info. 172800 IN A 199.19.56.1

a0.org.afilias-nst.info. 172800 IN AAAA 2001:500:e::1

a2.org.afilias-nst.info. 172800 IN A 199.249.112.1

a2.org.afilias-nst.info. 172800 IN AAAA 2001:500:40::1

b0.org.afilias-nst.org. 172800 IN A 199.19.54.1

b0.org.afilias-nst.org. 172800 IN AAAA 2001:500:c::1

b2.org.afilias-nst.org. 172800 IN A 199.249.120.1

b2.org.afilias-nst.org. 172800 IN AAAA 2001:500:48::1

c0.org.afilias-nst.info. 172800 IN A 199.19.53.1

c0.org.afilias-nst.info. 172800 IN AAAA 2001:500:b::1

d0.org.afilias-nst.org. 172800 IN A 199.19.57.1

d0.org.afilias-nst.org. 172800 IN AAAA 2001:500:f::1

;; Query time: 48 msec

;; SERVER: 192.5.5.241#53(192.5.5.241)

;; WHEN: Sun Dec 06 13:07:16 EST 2020

;; MSG SIZE rcvd: 443

I have included the whole output this time, and we observe here, the root-servers, which are under heavy load, are unwilling to recurse. We see in this in these lines:

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 13

;; WARNING: recursion requested but not available

There was a query made, but No answers. We did however, receive additional information. The root server helpfully “referred” us to the authoritative servers for the org domain. We could now continue as above, querying say a0.org.afilias-nst.info (199.19.56.1) for lainchan.org and receiving another referral. As mentioned, the ordinary DNS code used by applications cannot handle this sequence of responses and new requests, nor would this be efficient, but a DNS server can. DNS servers that will issues as many requests as needed to return a response to a client are called “recursive” or support “recursion”. Ordinarily, these are run by ISPs. You must use a recursive resolver for your DNS server settings in /etc/resolv.conf or on Windows “IPv4 Settings”.

DNS Caching : TTLs

DNS records are actually quite volatile and can change. For instance, if you use a dynamic DNS service provider, like afraid.org, to map your constantly changing home IP address to a human memorable name, you might want your DNS record to change quite frequently - requiring less caching, and more queries to the authoritative name server who has the instantly correct value. Other more stable services, might have less need for change, and more caching might be desirable to reduce the number of queries that the name server receives. After all, less caching means checking more often with the original server. This trade off is controlled by the owner of the DNS record through a “Time to Live” feature, where how long the record should be cached is set. A typical time is an hour, but as long as week might be used. You might be shocked at this value, but, should a server go down, having your DNS record cached at all major ISPs as one value, when your IP address has changed to a new value, might be quite frustrating.

What kinds of DNS Records Are there

So, we now understand the structure of DNS - there are root servers who delegate downward to other authoritative servers, and then their are recursive resolvers run by ISPs and other organizations for end users to use. What kind of lookups are possible?

Obviously, a Host Name to IP Address lookup is possible. For an IPv4 host, this is an “A” record. The lainchan.org record we looked up before was an A record. We see this below in the format used in popular DNS Server, BIND ( Berkeley Internet Name Daemon ) for its databases or “zones”.

lainchan.org. 1800 IN A 107.161.19.243

We see that lainchan.org has a TTL of 1800 seconds (30 minutes), has a class of Internet (as compared to other dead classes like choasnet), and its A record (mapping lainchan.org to a host name) has the value 107.161.19.243.

We can also do this backward with PTR records, which turn an IP Address into a hostname. Our dig invocation now is to our caching name server, and we request the PTR record. Note the format of the request has the IP address backward reflecting the structure “arpa->in-addr->107->161->19->243” or essentially a tree like structure traversed most significant octet first, allowing us to group IP address by All 107.X.X.X (107.0.0.0/8) into a zone rather than all IP address that end in 243 (X.X.X.243). Because this is a pain in the ass to type, dig has the special syntax dig -x [ip] to make this simple. The long form is provided here only for demonstration.

dig 243.19.161.107.in-addr.arpa PTR

...

243.19.161.107.in-addr.arpa. 86400 IN PTR lainchan.org.

...

Also note here, the less important PTR record has a much longer cache time.

IPv6

Host name to IPv6 lookups are done with AAAA records. Separate records are provided because software expects A records to occupy a specific number of bytes, and be of a specific format. Also, the IPv6 rollout is still incomplete, and not all clients can handle equally an IPv6 or IPv4 address. IPv6 lookups can be requested with AAAA records.

We have already seen queries containing these results:

d0.org.afilias-nst.org. 172800 IN AAAA 2001:500:f::1

More records

There are actually a wide variety of DNS records, that we will get into over time here. MX records make internet mail work, mapping domain names to mail servers that accept mail for them. TXT records that provide a generic storage used at one point to make Wikipedia articles available, verify domain ownership, or shoehorn authentication onto SMTP out of band (SPF,DKIM). NS records are used to delegate portions of the namespace. We will get into all of these over time.

Conclusions

By reading this document, you should have learned how to collect information from the DNS system via dig and about the structure and type of DNS servers including Authoritative vs Caching name servers, who runs caching servers, how delegation is done, and about the Tree like structure of DNS. Upcoming will be an article explaining security and privacy surrounding DNS.