DNS: Comprendre Les Bases Du Système De Noms De Domaine (article en anglais)

Are you tired of trying to look for an introduction to DNS, and finding only blogs that skim over too quickly, and others that dig too greedily into details? This post explains the basics of DNS, starting with what problems it was developed to solve, then going more and more into detail. The information is brought forth at a slow pace, one concept at a time, so that at the end of the post, everything fits together into a big picture. From this, you can get a strong grasp of the basics.

History of DNS

This section provides some historical highlights about what led to DNS in its current form.

ARPANET

The idea of wide area networks slowly became possible in the mid-1960s. The ARPA succeeded at the turn of the decade in connecting three universities (UCLA, UCSB, and Utah) and a research center (SRI-ARC), which gave birth to the ARPANET. Users who wanted to connect to a remote server would use a terminal.

Even though the network addresses at the time were only 8 bits long, numeric addresses are cumbersome to remember and type. Because of this, terminals provided from the beginning a way for users to specify a hostname, which was mapped by the system to a network address, similar to a “phone book” mapping names to telephone numbers. For example, RFC 208 lists the network addresses of 1971 with associated site and host names.

Hosts file

Early on, the hostname-to-address mapping was configured manually by a network’s system administrator (sysadmin for short). Larger networks used various configuration files, but one in particular eventually became dominant, the hosts file. A sysadmin was in charge of keeping this file updated on all terminals, by reading various channels, including RFCs, eg. RFC 590.

Not only was the hosts file’s format different on each operating system, it was outdated more often than not, and the hostnames themselves were arbitrary. This led to some efforts which resulted in an official list of hostnames (RFC 289, RFC 384) in 1972, and a standardized HOSTS.TXT file format (RFC 606, RFC 608) with a designated maintainer (RFC 627) in 1974.

The NIC, an organisation based in the SRI-ARC, was thus in charge of maintaining the centralized HOSTS.TXT, which would be FTP’d automatically at night (or manually by sysadmins) to keep their network updated. Someone who wanted to add a host from their network to the ARPANET had to call the NIC by phone during business hours.

This system could work in the 1970s, because then it was still possible to publish bi-weekly host status, monthly traffic statistics, and map the network. There were but 45 hosts in 1972, but the popularity of the ARPANET, and its exponential growth, pushed it to around 600 10 years later, reaching 10,000 before the 1980s were over.

Because of this popularity, official updates were slow. All of this was, of course, problematic for a manually-updated centrally-managed directory. There is even a story about a young sysadmin automating his HOSTS.TXT file, which might have become more popular than the official NIC file.

In the early 1980s, work towards a solution was already underway, which led to some tentative solutions. Some of them are shown in the next sections, to show the ideas that led to DNS, and what system we could have ended up with. Nevertheless, the hosts file is still in use today by most systems as the first step towards hostname resolution and has been standardized in RFC 952 and RFC 953.

IEN 116, IEN 117

IEN 116, published in 1979, proposed a way to retrieve a host’s IP address by communicating with a centralized Internet Name Server.

The hostname is prefixed with the network name or number (IEN 117) surrounded by exclamation points, eg. !ARPA!EXAMPLE, !10!EXAMPLE, !ARPA!#65. The network is optional and, if empty, indicates the local network, eg. EXAMPLE, which makes it backward-compatible.

RFC 799

RFC 799, published in 1981, acknowledged that a hierarchical name-space partitioning can be easy to find, but difficult to make backward-compatible with existing mail systems. It proposes a new way to write email addresses so that the domain can be specified.

The domain would replace the hostname, which would be moved to the left of the @, with the user name. For example, User@EXAMPLE could become User.EXAMPLE@ARPA. The receiving mail server would then have to parse the address to figure out which host it should forward the email to.

RFC 819, RFC 830

RFC 819 and RFC 830, published in 1982, proposed a distributed System for Internet Name Service, or SINS. The host would now be a hierarchical list of names separated by dot characters.

Each terminal would have an Application Interface Process (AIP) and a Domain Name Server (DNS) installed. The AIP makes requests to its DNS, and since each domain would also have its own configured DNS, the DNSes would communicate with each other to sequentially retrieve the resulting network address. The source AIP would then negotiate with the target AIP for resource availability and compatibility, including transport and application services, eg. TCP, TELNET, and SMTP mail. In other words, the application not only finds an IP Address but also the protocol and port numbers.

For example, User@EXAMPLE might now be User@EXAMPLE.ARPA. The process would query its local AIP, which would query its DNS. This DNS would resolve ARPA’s DNS’s network address, and would query that DNS for the IP address that belongs to EXAMPLE. This proposal also allows nameless domains, eg. User@A.#1.B with a host number, and User@A.[1.2.3.4].B with an IP address.

RFC 882, RFC 883

RFC 882 and RFC 883, published in 1983, were the final iteration, and resulted in the Domain Name System, or DNS. These RFCs solve the main issues related to the HOSTS.TXT file, centralized at the NIC, that had become a bottleneck.

Distributed

Instead of having a single source of truth controlled by a central authority, DNS is distributed, meaning that there are no single organizations in charge of keeping all hostname data up-to-date. Instead, each organisation designates one or more servers that control its database.

Hierarchical

Now that the hostnames’ information is distributed in multiple databases, a user needs a way to find the server that can access the database they want.

Instead of having a flat structure where all hostnames are equal, DNS is split into a hierarchy where hostnames have a parent and any number of children. This allows a server to start at the root and recursively find any hostname database.

Generic

Although DNS is often said to find a hostname’s IP address, this is not entirely correct. It offers a standardized way not only to map hostnames to IP addresses on the Internet, but also to other types of information, and on other types of networks. It is essentially a global key-value store.

Cached

The system is heavily built upon servers caching responses. It takes eventual consistency to the extreme, in the sense that updates to a database are not even replicated to other servers. This skips the hard part of caching, cache invalidation, in favor of each piece of data having a configured time-to-live (TTL), after which a copy is simply discarded.

On the other hand, this also means that a query might receive a deprecated answer, but the DNS databases are not typically updated often.

Concepts

The current base RFCs for DNS are RFC 1034 (concepts) and RFC 1035 (specs), as well as RFC 1032 and RFC 1033 for domain administrators. These RFCs, along with their numerous updates, should be used as primary reference.

This section explains the concepts and high-level details of DNS.

Zones

The DNS is made of zones of authority, each managed by an organisation or entity. A zone represents a portion of the hierarchy, which starts at the root zone and splits off to children zones through delegation to other organisations.

Domain Names

In the context of DNS, a hostname is called a domain name, and is a string composed of labels separated by dot characters, eg. www.example.com. Each label is case-insensitive and composed of letters and digits, as well as hyphens - anywhere except the first and last characters. These labels are in a specific order, starting with the least significant and ending with the root zone.

The root zone is not the com label from the example, though, but is displayed as an empty label. Since all domain names on the Internet are somewhere under this root zone, they all technically end with a dot character, eg. www.example.com.. This notation is called fully-qualified and indicates that the domain name is absolute. Relative domain names are out of scope for this post, so unless otherwise specified, all domain names can be assumed to be fully qualified, whether they end with . or not. Even though virtually all domain names that we encounter on the Internet do not end with ., it is the “correct” way to write them.

So, the domain name www.example.com. is made up of four labels: "www", "example", "com", and "" (the root zone). A sample of the Internet tree hierarchy (with some other domain names added) can be displayed as a tree:

.
├─ com.
│   ├─ example.com.
│   │   └─ www.example.com.
│   └─ kumojin.com.
├─ net.
│   └─ example.net.
└─ org.

Labels in a domain name roughly correspond to zones. The difference between them can be subtle: servers and authority are related to zones, while domain names are more of an abstract concept and related to the data. In the example tree above, ., com. and example.com. are distinct zones, but www.example.com. is not and is actually part of the zone example.com.. Why and how is explained later.

The Domain Name Space is all the zones and domain names that can be reached from the root zone. It would look like the DNS tree previously drawn but with billions of branches.

Top-Level Domains

Top-level domains, or TLDs, are the zones that are directly under the root zone. When the DNS was implemented in 1983, it established the familiar generic TLDs (gTLD) gov, edu, com, mil, org, net (a couple of months later), and int (a couple of years later). It also reserved a TLD for each countries (ccTLD) represented by the country’s two-letter ISO 3166-1 code, for example ca for Canada and de for Germany. This structure is explained in RFC 1591.

The same RFC has the following:

It is extremely unlikely that any other TLDs will be created.

Contrary to their initial expectations, more were created over the years, and the list grew to over a thousand TLDs. These TLDs are generally not available for registration - they are expensive and there are regulations and rules to follow.

Delegation

A zone can split off one of its branches into a separate, distinct child zone, effectively transferring its ownership to another organisation. Traversal of the tree from the root zone through the new zone is delegated to another set of servers. In the example tree above, example.com. could technically delegate www.example.com. into a new zone to be managed separately.

For example, Verisign owns the com. zone, and has delegated control of the child zone digitalocean.com. to DigitalOcean. Everything in this child zone is not under Verisign’s jurisdiction anymore. In fact, except for pointers to digitalocean.com.'s servers, Verisign doesn’t know anything about DigitalOcean’s zone.

Resource Records

The different kinds of data that can be queried about a domain name are called resource records, often just “record”, or RR (in RFCs). A resource record is a typed value associated with a specific domain name. An example of a resource record would be the IPv4 address of www.example.com..

Zones can have any number of resource records. If zones are like directories in the DNS tree, the resource records are like files.

Name Servers

Name servers are servers that can respond to DNS requests. They are also called resolvers.

Normally, the client sends the DNS query to the configured router or ISP to be processed. The OS can instead be configured to send the queries elsewhere, such as a public name server, for example Cloudflare, Google, Quad9, or Cisco’s OpenDNS, just to name a few. Some other name servers are private (and paid), like NextDNS, and allow the user to customize their experience.

There are two modes of operation for a name server: by iteration, and by recursion. As per RFC 1034, name servers must implement iteration, but do not need to handle recursion. If a client desires recursion out of a name server that doesn’t handle it, an iterative answer will simply be returned.

Authoritative Name Servers

Authoritative name servers are the source of truth for a specific zone. Their only job is to iteratively answer with the zone’s resource records.

For redundancy, each zone is managed by some of these name servers - one primary, and one or more secondaries. If one of these goes down or is attacked, the other name servers are still running. If all of these go down, this will only affect the zone and its children, and the whole system won’t break. Even the root zone is not a single point of failure, as it is managed by 13 root name servers.

Iterative Mode

In iterative mode, a resolver answers with information about servers that are closer to the requested data, with which the client can continue its query.

For example, a client asking a root zone’s name server (eg. a.root-servers.net.) for www.example.com.'s IP address will be referred to com.'s authoritative name servers. It is like the server is saying that it doesn’t know the IP address, but that these name servers are closer to example.com. and are better suited to answer. The client can then ask one of these servers (eg. a.gtld-servers.net.) and receive information about example.com.'s authoritative name servers.

Iterative mode is easy to implement on the server side but forces the client to find its answer manually. The client is of course free to cache the responses if they might be useful in the future.

If the name server has no idea about the requested record, eg. asking com.'s authoritative name server about example.org. records, it will refer the client to the common denominator server (the root zone in this case), or simply return an error.

Recursive Mode

In recursive mode, a resolver searches for the answer by asking other name servers. It very likely has a cache to help with further requests.

These recursive resolvers make queries to other name servers to find the answer. Typically, the first step would be to find an authoritative name server in the cache, starting at the requested domain name, and traversing the tree towards the root zone. From that name server, iteratively ask for the requested record until an answer is found.

For a quick example, a recursive name server might receive a request for www.example.com.'s IP address:

1. The resolver doesn’t have that information in its cache, nor does it know the authoritative name servers for www.example.com., example.com. and com.. It knows what the root zone’s authoritative name servers are (eg. a.root-servers.net.), along with their IP addresses (eg. 198.41.0.4);
2. It asks 198.41.0.4 about www.example.com.'s IP address, is answered with com.'s authoritative name servers (eg. a.gtld-servers.net.), and is also provided with a.gtld-servers.net.'s IP address with the value 192.5.6.30;
3. It asks 192.5.6.30 about www.example.com.'s IP address, is answered with example.com.'s authoritative name servers, (eg. a.iana-servers.net.);
4. It doesn’t know how to reach a.iana-servers.net., so must find its IP address, recursively traversing again towards the root zone, and back towards a.iana-servers.net., and ends up with the value 199.43.135.53;
5. It asks 199.43.135.53 about www.example.com.'s IP address, is answered with 93.184.216.34.

In the first step, the resolver knew about a.root-servers.net. because all resolvers are configured with initial data that contains the root zone’s authoritative name servers and their IP addresses.

This may look a bit confusing and chaotic, especially the fourth step, but a resolver would cache the answers it finds, so if it later receives a query for, say, digitalocean.com.'s IP Address, it already knows com.'s authoritative name servers and their IP addresses, so the resolution will be quicker.

Forwarding Name Servers

Forwarding name servers, also called forwarders, are not really resolvers but are very simple name servers that receive DNS requests and merely forward them to another name server. This is often seen in routers, when the resolution is delegated elsewhere, eg. the ISP.

Stub Name Servers

Stub resolvers, defined in RFC 1123, are services or library functions (such as getaddrinfo) built in the operating system for applications that need to map a hostname to an IP address. They build the DNS request and send it to the configured name server (eg. /etc/nsswitch.conf in Linux).

Details

This section explains at a lower level what DNS queries and answers are composed of, and how they work. Traditionally, these are UDP packets that go through the Internet towards the name server, but DNS is versatile and can use TCP as well.

Resource Record

The most important piece of information is the resource record. The DNS functions like a key-value store, with the key being a domain name, record type, and network class, and the value being some data and for how long it is still valid. Keys are not unique, so there can be multiple values associated with the same key, in which case there are no intrinsic orders.

The domain name is the hostname to which a resource record applies. For example, example.com. and www.example.com. are domain names.

The record type defines what the record represents. There are many record types, from IP addresses and domain names to free text. Some of the important ones are shown in the following table:

Type	Description
A	IPv4 address
AAAA	IPv6 address
CNAME	Canonical name
MX	Mail server
NS	Authoritative name server
PTR	Pointer
SOA	Start of authority
TXT	Text

The record types will be explained in a bit more detail in the next section.

The class specifies the name space, or technically, how some of the record types were encoded. There was a time in early 1980’s when multiple concurrent networks were interconnected. On paper, DNS can serve data about multiple network classes at the same time, but this is virtually always IN:

Type	Description
IN	Internet
CS	CSNET
CH	CHAOS
HS	Hesiod

The time-to-live, or TTL, represents how long, in seconds, the resource record can be cached. Past this TTL, the data should be discarded and retrieved anew.

The data simply contains the piece of information that the record is about. What it means (eg. an IPv4 address, a domain name, …) depends on the record type.

For example, a resource record might be written as the following:

example.com. NS IN 86400 a.iana-servers.net.

This would mean that a.iana-servers.net. is an authoritative name server of example.com. on the Internet, to be cached for one day (86,400 seconds). More commonly, the IN is implied and not displayed.

A domain name can also start with a wildcard label *, which matches any one or more nonexistent domain names. For example, given the following records in a database:

*.example.com.     TXT "Wildcard"
alpha.example.com. TXT "alpha"
beta.example.com.  A   93.184.216.34

Querying for test.example.com. TXT or one.two.example.com. TXT would both result in "Wildcard", while querying for example.com. TXT, alpha.example.com. TXT, or beta.example.com. TXT would not match the wildcard.

Resource Record Types

Before moving on to DNS messages, this section explains in a bit more detail how some of the important record types work.

The record types A and AAAA are IPv4 and IPv6 addresses, respectively.

CNAME, or canonical domain name, records define the record’s domain name as an alias. Processing will continue with the specified domain name. For instance, the record www.example.com. CNAME example.com. configures example.com. as the canonical name of www.example.com.. Querying for www.example.com. A would return www.example.com. CNAME example.com. and example.com.'s A records.

A domain name that is used for email has one or more MX records to configure mail servers, each with a preference value. The lowest value is preferred and tried first when delivering the email. Multiple mail servers with the same preference value are typically load-balanced.

The NS record type defines the domain name of an authoritative name server.

PTR records are similar to CNAME records, with the exception that the processing does not continue with the specified domain name. Using the same example, querying www.example.com. A would not return the PTR record.

SOA, or start of authority, records are primarily used for zone administration. The data is composed of seven fields. At the time of writing, example.com.'s SOA record looks like ns.icann.org. noc.dns.icann.org. 2022091339 7200 3600 1209600 3600. The first field is the domain name of the primary authoritative name server, the second is the email address of the zone administrator (encoded as a domain name, with the first label being the part that comes before the @, ie. noc@dns.icann.org), and the third is a serial number that, if increased, indicates that some records in the zone were modified. The last four are related to zone transfers and negative caching, and are out of scope for this post.

Furthermore, an SOA record indicates that the domain name is the beginning of a zone. Domain names that do not have SOA records are in the zone of the closest parent that does. For example, www.example.com. does not have an SOA record, so it isn’t a zone. On the other hand, its parent example.com. has one, meaning that www.example.com. is in the zone example.com..

The TXT record type is for arbitrary text. It is used when no record types are available for a given data. DKIM and domain ownership verification are examples of what TXT records are used for.

Finally, the OPT record type (EDNS, RFC 2671) is a pseudo-record. It is used to specify a greater size and extend the possible flags and options for queries and answers.

Message

A DNS message is the envelope for both DNS queries and answers, and is split into five sections: the header, question records, answer records, authority records, and additional records.

Header

A message’s header contains its ID, some options, and the number of resource records that is contained in each of the next sections.

The ID doesn’t do much by itself but is used if a client needs to match its queries to the answers it receives.

The query-response flag, or QR, indicates whether the message is a query or a response. This is important because of inverse queries, and because responses also contain the initial question.

The opcode, or OPCODE, specifies the kind of query:

Code	Description
QUERY	Standard query
IQUERY	Inverse query
STATUS	Server status request

Virtually all DNS queries are of the standard kind, also called forward lookups. IQUERYs are obsolete in favor of reverse lookups, and STATUSes do not have any specified behavior. Some other opcodes were added over the years, but they are administrative actions more than anything else.

The authoritative answer flag, or AA, indicates whether a response is authoritative, meaning that it was provided directly by an authoritative name server.

The truncation flag, or TC, indicates whether the message was truncated because of its length. Truncated messages have missing resource records, and must not be cached.

The recursion desired flag, or RD, indicates that the client is asking the name server to use recursion to find the answer. If unset, or if the name server does not support recursion, the response will be iterative.

The recursion available flag, or RA, indicates whether the name server supports recursion. If both RD and RA are set in an answer, it means the name server used recursion.

The response code, or RCODE, indicates whether the query was successful or not.

Code	Error	Description
NOERROR	No Error	The query was successful
FORMERR	Format error	The query could not be parsed
SERVFAIL	Server failure	The query could not be processed
NXDOMAIN	Non-Existent Domain	The domain name does not exist
NOTIMP	Not Implemented	The opcode is not supported
REFUSED	Query Refused	The name server refuses to answer

More errors were added over the years, but the initial ones give a very good idea of how they work.

Question Records

The question section contains the keys to a resource record (name, type, and class) that the client wants answers to. It usually has a single question record, but technically, it can have any number of them, including none.

Answer Records

The answer section contains any number of resource records. They directly answer the question records.

Authority Records

The authority section sometimes has resource records to add authoritative information related to the query, for example other NS or SOA records.

Querying for a domain name that doesn’t exist, eg. invalid.example.com., may get back example.com.'s SOA record in the authority section.

Because they do not support recursion, querying a root zone’s authoritative name server for example.com. A would instead receive 13 com. NS records in the authority section.

Additional Records

The additional section gives more information about the current query or can help with subsequent ones.

As stated before, when querying a root zone’s authoritative name server for records about example.com., the root server answers by providing com.‘s NS records in the authority section. Instead of letting clients do the obvious next step of finding one of these servers’ IP address, which might easily lead to an infinite loop, this information is instead included in the additional records section, in the form of A and AAAA records that are called glue records.

How DNS Works

This section explains the two main types of query in more detail.

DNS Lookup

The main reason DNS is used is to query for a domain name’s resource records. This is called forward lookup (or simply lookup). With all the information that has been given in the previous sections, lookups should be easy to understand.

A DNS message can be constructed with question records. Depending on the type of name server and the options specified in the header, the response would contain the initial question record, and some answer, authority, and additional records.

For example, a client wanting to lookup example.com.'s IPv4 addresses (its A records), would build a message containing a single question record with name example.com., class IN, and type A. The name server, assuming a recursive resolver, would respond with the same question record, and an answer record with name example.com., class IN, type A, a certain TTL value, and the IPv4 address 93.184.216.34 as the record’s data.

DNS Reverse Lookup

Is it possible for a client who knows an IPv4 address, eg. 93.184.216.34, to find out which domain name it belongs to?

The idea with inverse queries (the IQUERY opcode) was that a DNS message would provide an answer and ask for the question. For example, a message would be sent containing an answer record with a class IN, type A, and value 93.184.216.34, but with an empty name. A name server receiving such a message would look in its database for matching records, then provide the desired name in the response’s question record, eg. example.com. A. This may have been too unintuitive, hacky, fragile, or computationally expensive, but the IQUERY functionality was most of the time either disabled in name servers or simply unimplemented in software, and so it was deprecated with RFC 3425.

Meanwhile, the reverse lookup functionality, sometimes called rDNS and described alongside IQUERY in RFC 1035, had continued to gain in popularity. This service is offered under the domain name in-addr.arpa., using forward lookups and PTR records. Contrary to inverse queries which can query for any record type, reverse lookups can only query IP addresses.

For example, to find the hostname that belongs to the IPv4 address 209.216.230.240, a DNS message is sent to query 240.230.216.209.in-addr.arpa.'s PTR records. The IPv4 address is written in reverse to follow a domain name’s structure, starting from the least significant octet. This would result in a PTR value of news.ycombinator.com., the Hacker News website.

Reverse DNS is normally used for network troubleshooting and anti-spam. It may have been more useful in the past, but with how popular cloud providers have become over the last 10 years, the database has slowly become filled with generic domain names. For example, at the time of writing, reverse lookup’ing 44.235.246.155 would result in the AWS EC2 instance ec2-44-235-246-155.us-west-2.compute.amazonaws.com. instead of mozilla.org. Even though it was recommended that each host have a hostname, this is not enforced, and a lot of IP addresses are not mapped, for example 93.184.216.34 and 104.18.154.42 which both result in an NXDOMAIN error instead of example.com. and digitalocean.com., respectively.

When IPv6 was added to DNS in RFC 3596, the zone ip6.arpa was assigned for reverse lookups of IPv6 addresses. Like IPv4 addresses, IPv6 addresses are encoded backwards, each hexadecimal digit in a separate label. Reverse lookup’ing 2606:2800:220:1:248:1893:25c8:1946 would query 6.4.9.1.8.c.5.2.3.9.8.1.8.4.2.0.1.0.0.0.0.2.2.0.0.0.8.2.6.0.6.2.ip6.arpa.'s PTR records.

Usage

Normally, a client does not need to build its own DNS queries. Instead, the operating system takes care of them.

Other times, DNS queries are performed manually, either for troubleshooting a problem, or simply for curiosity. This section shows how to use some common DNS tools in a terminal.

Dig

The command dig is the typical way to perform a DNS query. In its simplest form, it queries the specified domain name for its A records:

$ dig example.com.

; <<>> DiG 9.16.42-Debian <<>> example.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 291
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0123456789abcdef (echoed)
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.             4502   IN      A       93.184.216.34

;; Query time: 160 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Aug 11 19:00:00 UTC 2023
;; MSG SIZE  rcvd: 79

From this output, we can see the header and all sections. We can also see that dig has added an OPT pseudo-record to raise the maximum message length to 4,096 octets and set a cookie ID. From the line ;; SERVER: 192.168.1.1#53(192.168.1.1), I know that the request was sent to my router, which is the default name server that is configured in /etc/resolv.conf.

dig’s output is by default rather verbose. The +short flag can be added to only show the data from the answer section:

$ dig +short example.com.
93.184.216.34

The type of record can be specified at the end:

$ dig +short example.com. NS
a.iana-servers.net.
b.iana-servers.net.

The -x parameter can be used to do a reverse lookup:

$ dig +short 240.230.216.209.in-addr.arpa. PTR
news.ycombinator.com.
$ dig +short -x 209.216.230.240
news.ycombinator.com.

Finally, if the system’s default name server is not desired, another can be specified with the @ character followed by a domain name or IP address:

$ dig +short @1.1.1.1 example.com.
93.184.216.34

There are many other parameters, like +norecurse to force an iterative mode, that are listed with dig -h or man dig.

Nslookup

nslookup is another tool that can perform DNS queries. The following queries for example.com.'s A and AAAA records:

$ nslookup example.com.
Server:     192.168.1.1
Address:    192.168.1.1#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34
Name:   example.com
Address: 2606:2800:220:1:248:1893:25c8:1946

Options are specified before the domain name, and an optional name server can be specified at the end:

$ nslookup -type=TXT example.com. a.iana-servers.net.
Server:     a.iana-servers.net.
Address:    199.43.135.53#53

example.com text = "v=spf1 -all"
example.com text = "wgyf8z8cgvm2qmxpnbnldrcltvk4xqfn"

nslookup also has an interactive mode, in which commands affect the subsequent queries:

$ nslookup
> example.com.
Server:     192.168.65.7
Address:    192.168.65.7#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34
Name:   example.com
Address: 2606:2800:220:1:248:1893:25c8:1946
> server 1.1.1.1
Default server: 1.1.1.1
Address: 1.1.1.1#53
> set type=NS
> example.com.
Server:     1.1.1.1
Address:    1.1.1.1#53

Non-authoritative answer:
example.com nameserver = a.iana-servers.net.
example.com nameserver = b.iana-servers.net.

Authoritative answers can be found from:
> exit

nslookup will also automatically detect IP addresses, so nslookup 93.184.216.34 will perform a reverse lookup.

More information can be found with man nslookup.

Host

host is used to retrieve the IP addresses of a domain name:

$ host example.com.
example.com has address 93.184.216.34
example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946
example.com mail is handled by 0 .

Similarly to nslookup, options can be specified before the domain name, and the name server specified at the end:

$ host -t NS example.com. dns.opendns.com
Using domain server:
Name: dns.opendns.com
Address: 208.67.222.222#53
Aliases:

example.com name server a.iana-servers.net.
example.com name server b.iana-servers.net.

Again similarly to nslookup, host will automatically detect IP addresses, and host 93.184.216.34 will perform a reverse lookup.

More information can be found with man host.

Dog

dog is a modern rewrite of dig:

$ dog example.com A AAAA NS TXT
   A example.com. 23h42m40s   93.184.216.34
AAAA example.com. 23h42m40s   2606:2800:220:1:248:1893:25c8:1946
  NS example.com. 23h43m41s   "b.iana-servers.net."
  NS example.com. 23h43m41s   "a.iana-servers.net."
 TXT example.com. 1d0h00m00s  "v=spf1 -all"
 TXT example.com. 1d0h00m00s  "wgyf8z8cgvm2qmxpnbnldrcltvk4xqfn"

Of interest is its ability to output the response in JSON. More information can be found in the official website.

Conclusion

It’s crazy to think that DNS is 40 years old, mostly still in its initial state. It has become a strong and important pillar of the Internet, not because it is perfect (far from it), but because it is good enough. We can imagine how it might have been simpler but less flexible, making it useless over time as technology evolved around it. The people who thought and built this system did an incredible job of thinking ahead.

The basics shown in this post are straightforward and “easy” to understand, but once one digs deeper, it quickly gets more complicated (eg. DNSSEC). There are a lot of flaws and ways to abuse the system, but it doesn’t detract from its strengths. DNS has solidified its place for the foreseeable future.

In addition to the various RFCs mentioned in this post, nslookup.io’s excellent Learning Center has a lot more information to dig deeper into how DNS works.