The Domain Name System/Service, or DNS, is an important part of the internet. It maps host names (like freebsd.org) to IP addresses (like 96.47.72.84), and vice-versa. This mini tutorial will teach you how to use the drill utility to look up information from DNS. We only cover IPv4 here. The first part of this post is a quick introduction to DNS. You can find the actual drill commands towards the end of the post.
What is DNS?
DNS, at its simplest, is a directory of host name to IP address mappings. It is a distributed network of servers across the internet that helps clients like your web browser answer the question "what is the IP address of somedomain.com?". It also supports reverse DNS lookups (IP address to host name) through the PTR record type (see below). The servers that answer these sort of queries are called nameservers (ns). They are usually written as one word, as opposed to "name servers".
Nameservers are organized in a hiararchical tree structure. Root nameservers know how to get to top-level domain nameservers (the ones that can answer queries about host names ending with a TLD like .com, .net, .org, etc). A single nameserver can contain all host name to IP address mappings for a particular domain name and all of its subdomains (e.g. domain.com, subdomain.domain.com, sub.subdomain.domain.com, etc), or it can delegate lookups for certain subdomains in the heirarchy to additional name servers.
Record types
A host name to IP address mapping on a DNS server is called a record. A nameserver is basically a server that contains a collection of these records. Let's take a look at the main record types:
A records
A (Address) records contain two main pieces of information: a host name and an IP address. They are used to answer the question "what is the IP address of some.host.name?" (but not vice versa).
CNAME records
CNAME (Canonical NAME) records also contain two main pieces of information: a name and a canonical name (no IP addresses). It's a mechanism that allows a host name to have multiple aliases. For example, if you had an A record for somedomain.com, you could create an alias for that with a CNAME record that points www.somedomain.com to somedomain.com. This way, a lookup for www.somedomain.com will first fetch the CNAME record www.somedomain.com to get the canonical name somedomain.com, followed by an A record query for somedomain.com to get the actual IP address associated with that host name.
MX records
MX (Mail eXchange) records are used to get the host name (not IP address) of the machine responsible for handling email traffic for a specific domain or subdomain. For example, you can set up an MX record for mydomain.com to point to postfix.mydomain.com. A client trying to send an email to someone@mydomain.com will then contact postfix.mydomain.com (based on the initial MX lookup) to deliver the message.
NS records
NS (NameServer) records are used to delegate mappings for a particular domain/subdomain to a different nameserver. For example, you could have an NS entry for hr.mydomain.com to point to ns1.mydomain.com. This tells clients that they should contact the ns1.mydomain.com nameserver to look up any host names that end with hr.mydomain.com (for example, recruitment.hr.mydomain.com, applications.recruitment.hr.mydomain.com, training.hr.mydomain.com, etc).
PTR records
PTR (pointer) records are used for reverse lookups, i.e. mapping an IP address to a host name. Most Mail Transfer Agents (MTAs) will check the PTR record for inbound emails from a particular mail server to match against the FROM address. If they don't match, these emails will either be rejected or marked as spam.
Nameserver types
There are two main types of nameservers: an authoritative nameserver and a non-authoritative nameserver.
A non-authoritative nameserver, sometimes called a recursive nameserver, is a server that does not know the host name to IP address mapping of your target host name or domain name, but it knows how to query the hierarchical DNS structure till it gets to the authoritative servers that does have the requested record. In the example given in the "NS records" section above, the nameserver containing the NS record for hr.mydomain.com is a non-authoritative nameserver: it does not know the IP address of say recruitment.mydomain.com, but it does know the host name of the authoritative nameserver that can answer that question, ns1.mydomain.com.
Installing drill
drill is part of the LDNS library. This tutorial assumes you're using FreeBSD, which comes with drill pre-installed. For instructions on how to install on other systems, please refer to your operating system's package management system.
Drill syntax and examples
The man page for drill has lots of different command-line options, but for the purposes of this demo, we will focus only on the record types mentioned above. The general syntax of queries is as follows:
$ drill [-x] name|address [@nameserver] [A|CNAME|MX|NS]Reverse lookups (PTR) are a special case that uses the -x option, which is why I have not listed them in the last argument to drill. Everthing in square brackets is optional. If the record type is omitted, it defaults to A records. You can also supply a particular nameserver you want to query (preprended by @), otherwise your system's default resolver will be used.
PTR record example
$ drill -x 66.42.70.93
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 33362
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 93.70.42.66.in-addr.arpa. IN PTR
;; ANSWER SECTION:
93.70.42.66.in-addr.arpa. 3600 IN PTR 66.42.70.93.vultrusercontent.com.
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 294 msec
;; SERVER: 10.5.5.1
;; WHEN: Thu Nov 2 04:19:35 2023
;; MSG SIZE rcvd: 88Note the ANSWER section in the output. It tells us that the PTR record for 66.42.70.93 is 66.42.70.93.vultrusercontent.com. Also note that nameservers store PTR records in a specific format: the octets of the IP address are reversed and appended with "in-addr.arpa". drill in the example above sent a query to the default resolver asking for the host name associated with 93.70.42.66.in-addr.arpa, which is the same thing as asking "what's the host name associated with the IP address 66.42.70.93?".
A record example
$ drill google.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 14513
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; google.com. IN A
;; ANSWER SECTION:
google.com. 28800 IN CNAME forcesafesearch.google.com.
forcesafesearch.google.com. 29794 IN A 216.239.38.120
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 34 msec
;; SERVER: 10.5.5.1
;; WHEN: Thu Nov 2 04:35:29 2023
;; MSG SIZE rcvd: 74Here, the IP address for google.com is 216.239.38.120.
NS record example
Let's find out the authoritative nameserver for binsh.dev by looking up the NS record:
$ drill binsh.dev ns
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 10350
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; binsh.dev. IN NS
;; ANSWER SECTION:
binsh.dev. 7281 IN NS ns-122-a.gandi.net.
binsh.dev. 7281 IN NS ns-11-c.gandi.net.
binsh.dev. 7281 IN NS ns-145-b.gandi.net.
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 211 msec
;; SERVER: 10.5.5.1
;; WHEN: Thu Nov 2 04:40:28 2023
;; MSG SIZE rcvd: 104Notice how we got multiple entries in the ANSWER section. This is common and is used for redundancy so that if one server is down, we can still query one of the available nameservers in the list.
MX record example
Since we now know the nameserver(s) for binsh.dev, let's use that information and fill in the optional @nameserver bit in the syntax:
$ drill binsh.dev @ns-122-a.gandi.net mx
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 44768
;; flags: qr aa rd ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; binsh.dev. IN MX
;; ANSWER SECTION:
binsh.dev. 10800 IN MX 10 spool.mail.gandi.net.
binsh.dev. 10800 IN MX 50 fb.mail.gandi.net.
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 112 msec
;; SERVER: 173.246.100.123
;; WHEN: Thu Nov 2 04:51:56 2023
;; MSG SIZE rcvd: 82Notice how in all of the previous example, the "SERVER" part of the output said 10.5.5.1, which is my default resolver. This time around, it says 173.246.100.123, the IP address associated with ns-122-a.gandi.net. The ANSWER section tells us that the mail server for binsh.dev is spool.mail.gandi.net.
CNAME record example
$ drill www.google.com cname
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 11343
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; www.google.com. IN CNAME
;; ANSWER SECTION:
www.google.com. 28800 IN CNAME forcesafesearch.google.com.
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 22 msec
;; SERVER: 10.5.5.1
;; WHEN: Thu Nov 2 04:57:46 2023
;; MSG SIZE rcvd: 62Here, www.google.com is an alias for forcesafesearch.google.com. If you look up the A record for that, you'll find out it gives you 216.239.38.120, which is the same IP address associated with google.com. This tell us that www.google.com is indeed an alias for google.com.
Happy drilling!