A DNS Primer

For more primers like this, subscribe to get notifications about them as they are released.

What is DNS?

Domain Name System (DNS) makes the Internet usable to humans by providing a naming structure for online resources and mapping those names to the addresses where the resources reside. Without it, websites would be accessible only by entering long strings of numbers, such as: “120.238.104.535”.

Humans aren’t good at retaining such things but remember, “npr.org” is manageable. Enter the DNS.

History

Paul Mockapetris created the DNS at UC Irvine in 1983. Before then, people were mapping names to addresses by sharing a big text file called hosts.txt. This is why most operating systems have a host file even today.

How it Works

Let’s look at how the DNS works.

Basics

As we said in the intro, the DNS system finds resources for you by name. You ask where a character is, and it returns you an IP address. This is done through a distributed database system whereby requests for names are handed off to various tiers of servers delineated by the dot (.) in the word you’re looking for. It uses the client-server model.

The structure is hierarchical and moves from right to left like so:

• The root domain (dot)
• The top-level domain (TLD)
• The second-level domain
• The subdomain
• The host/resource name

Clients, like your laptop or desktop, are usually configured with a DNS server that it uses to get names resolved. Clients typically make recursive queries, meaning they want the final answer—leaving the DNS server to walk the tree.

Name resolution for a typical client follows the steps described below:

1. A DNS server is configured with an initial cache (so-called hints) of the known addresses of the root name servers. The hint file is updated periodically in a trusted, authoritative way.
2. When a client makes a (recursive) request of that server, it services that request either through its cache (if it already had the answer from a previous lookup) or by performing the following steps on the client’s behalf.
3. A query is made to one of the root servers to find the server authoritative for the requested top-level domain.
4. An answer is received that points to the nameserver for that resource.
5. The server “walks the tree” from right to left, going from nameserver to nameserver, until the final step returns the IP address of the host in question.
6. The IP address of the resource is then given to the client.

The name resolution process is different for recursive vs. iterative queries. See that section for more detail.

The protocol

The DNS protocol is relatively light (see the image above) and thus sits on top of UDP, so queries can happen quickly and without much overhead. Questions over 512 bytes, and certain heavier operations such as Zone Transfers, however, switch to TCP so that delivery will not become an issue. A recent addition is DoH or DNS over HTTPS, to add support for SSL and other security enhancements lacking in native DNS.

Fields

The protocol has the following fields:

• The Identifier: a 16-bit ID field that matches requests and responses.
• The Query/Response Flag: a 4-bit field that designates whether the packet is a request or a response.
• Opcode: Specifies the type of message being carried. Options include: 0 for a standard query, 1 for an inverse query (obsolete), 2 for server status, 3 is reserved and unused, 4 is a notify message, and 5 is an update (used for Dynamic DNS).
• AA: This is a 1-bit field indicating an authoritative answer. The bit is set to 1 if it’s authoritative, meaning that the server who answered is authoritative for the domain in question. If it’s set to 0, it’s a non-authoritative answer.
• TC: A 1-bit field for truncation, yes or no, usually indicates it was sent via UDP but was longer than 512 byes.
• RD: A 1-bit field called “Recursion Desired,” meaning that the client is asking the server to walk the tree on the client’s behalf and return the answer instead of telling it where to look next.
• RA: A 1-bit field called “Recursion Available,” in which a DNS server tells a client whether it supports recursion or not.
• Z: Three reserved bits that are always set to zeroes.
• RCode: A 4-bit field that’s set to zero in queries (because they’re not responses) with the following options: 0 is no error, 1 is format error, 2 is a server failure, 3 is name error, 4 is not implemented, 5 is refused, 6 the name exists but it shouldn’t, 7 a resource record exists that shouldn’t, a resource record that should exist doesn’t, 9 the response is not authoritative, 10 the name in the response is not within the zone specified.
• QDCount: How many questions are in the question section.
• ANCount: How many answers are in the answer section.
• NSCount: How many resource records are in the authority section.
• ARCount: How many resource records are in the additional section.

DNS Caches vs. DNS Servers vs. DNS Resolvers

One of the most significant points of confusion regarding DNS comes from the difference between DNS caches, DNS servers, and DNS resolvers.

DNS Caches

A DNS cache can mean a couple of different things, which is why it isn’t apparent.

1. The list of names and IPs you’ve recently resolved is “cached” such that if you ask the question again, you’ll get the same answer without generating network traffic.
2. A DNS server that doesn’t have any authoritative names but performs recursive queries and caching (saving those answers for future requests within a certain amount of time).

So when someone says they need to clear their DNS cache, they’re probably talking about their local cache. So if they’re talking about setting up a DNS Cache, they’re probably talking about a DNS server that makes DNS queries faster for the network.

DNS Servers

A DNS server is software that serves DNS requests for clients. It can be a cache (see above) that doesn’t have any names of its own and performs recursive queries (and caching), or it can be a “real” server, meaning that it does hold the authoritative answers for specific resources.

DNS Resolvers

DNS resolvers are just DNS clients and can make two main types of queries: iterative and recursive. See that section below.

Recursive vs. Iterative Queries

As mentioned above, recursive queries are queries where the client asks the server to do all the work for it. For example, it sends the RECURSION DESIRED flag in its query, and the DNS server will either honor that or not.

Iterative queries are the opposite of recursive queries. When they’re used, the server doesn’t find the answer for the client (unless it’s on the first question and response) but instead tells the client where to look next. So if the client asks for chat.google.com, it tells the client to check with the .com servers and considers its work done.

Authoritative vs. Non-authoritative Responses

Authoritative responses come directly from a nameserver that has authority over the record in question. Non-authoritative answers come second-hand (or more), i.e., from another server or through a cache.

Reverse vs. Forward Queries

Reverse queries reverse the direction of DNS lookups, i.e., going from IP to name instead of name to IP. Forward queries are another name for regular name-to-IP queries.

Zone Transfers

Zone Transfers are how slave servers pull records from controller servers for backup and redundancy purposes. They occur over TCP because the transferred data is usually substantial (most likely over 512 bytes). During the operation, the client sends a query type of IXFR instead of AXFR.

Zone Transfers are sensitive from a security standpoint because when someone knows what and where your resources are, it helps them plan an attack against you. For example, zone Transfers should only be allowed by approved systems.

Performing a Zone Transfer

When you perform a zone transfer, you want to define two things:

1. The server you’re asking
2. The domain you’re trying to pull

You can perform the actual transfer using several tools.

Using the host command

# host -la $DOMAIN

Remember that there are two pieces to doing a Zone Transfer: defining the server you’re asking for and representing the zone you’re trying to pull. With host, you need to define the first piece by using your resolv.conf file, i.e., by setting your DNS server to be the target.

Using the dig command you can do it in one step…

# dig @server $DOMAIN axfr

You can also use nslookup to perform a Zone Transfer, it’s an elaborate process and, therefore, silly. Use host or dig.

Performing a Zone Transfer against a domain without permission may be considered “hacking” by some. You should either have permission or be prepared to face the consequences.

Anycast DNS

Anycast is a brilliant protocol that allows the same IP to be served from multiple locations. The network then decides intelligently which location to route a given user request based on distance, latency, network health conditions, etc.

Anycast DNS does this for DNS, making it almost like a CDN for your DNS. However, if you have a site accessed from many parts of the world and where speed is a consideration, you should consider using a DNS provider with an Anycast option.

This site uses Anycast DNS (through DYN) as part of its /stack.

Wildcard DNS

Wildcard DNS is a type of DNS record responding to non-existent subdomains/hosts within a zone. So if you have a wildcard for *.ctrltilde.com, then someone is going to aargghhh.ctrltilde.com will be directed to wherever I point that wildcard record to.

Dynamic DNS

Dynamic DNS allows clients with changing DHCP addresses to update a DNS server with their latest IP so that it can be found by name at its current location.

Record Types

DNS Security

There are several things to think about from a security perspective regarding DNS. First among these is that if someone controls where you are sent when you ask for a given name, they control something quite powerful.

Spoofing a legitimate site

Modifying DNS servers for clients is often a primary objective of an attacker after gaining control of a system or network. This means changing the DNS resolution so that specific sensitive names (like bankofamerica.com, for example), or even all words, are redirected to a server the attacker controls.

This enables an attacker to present a login form that looks similar to (or even identical to) the real thing. If the user signs into the fake site, the attacker has stolen their credentials.

It’s critical, therefore, that the nameserver responding to client requests in your environment is legitimate and is not compromised.

DNSSEC

By default, DNS is pretty easy to spoof because it’s based on UDP. In many cases, You can send a response to a client, and it will assume that you made a previous request and update the record in the cache.

DNSSEC is a set of security-oriented DNS extensions designed to address several issues with DNS. It is primarily concerned with helping resolvers (clients) ensure that DNS data comes from an authorized origin.

DNSSEC works by digitally signing responses using public-key cryptography and uses several new resource records, shown below.

• RRSIG – contains the DNSSEC signature for a record set. DNS resolvers verify the signature with a public key stored in a DNSKEY record.
• DNSKEY – contains the public key that a DNS resolver uses to verify DNSSEC signatures in RRSIG records.
• DS – holds the name of a delegated zone. You place the DS record in the parent zone and the delegating NS records. References a DNSKEY record in the sub-delegated zone.
• NSEC – Contains a link to the next record name in the zone and lists the record types that exist for the record’s name. DNS Resolvers use NSEC records to verify the non-existence of a record name and type as part of DNSSEC validation.
• NSEC3 – Contains links to the next record name in the zone (in hashed name sorting order) and lists the record types that exist for the name covered by the hash value in the first label of the NSEC3 -record’s name. Resolvers can use these records to verify the non-existence of a record name and type as part of DNSSEC validation. NSEC3 records are similar to NSEC records, but NSEC3 uses cryptographically hashed record names to avoid the enumeration of the record names in a zone.
• NSEC3PARAM – Authoritative DNS servers use this record to calculate and determine which NSEC3 records to include in responses to DNSSEC requests for non-existing names/types.

When DNSSEC is used, each answer to a DNS lookup contains an RRSIG DNS record in addition to the requested record type. The RRSIG record is a digital signature of the answer DNS resource record set. The digital signature is verified by locating the correct public key in a DNSKEY record.