DNS and Name Resolution

Nobody types 203.0.113.10 to visit a website. We type names, and a worldwide system quietly turns them into numbers. That system is the Domain Name System, or DNS. It is one of the most important services on the Internet, and also one of the richest sources of clues for a security professional, because almost everything that happens on a network starts with a DNS question.

In the previous lesson you learned that IP addresses identify machines. This lesson answers the obvious follow-up: how does your computer find the address that goes with a name like example.com? Then in lesson 3 we will see what it does with that address.

The phone book of the Internet

DNS is often compared to a phone book: you know a person's name, and you look up the number. The comparison is good but incomplete. There is no single giant book. Instead, DNS is a distributed, hierarchical database: thousands of servers each know a small part and know whom to ask for the rest.

A domain name is read from right to left. In www.shop.example.com:

• com is the top-level domain (TLD).
• example is the domain registered by an organisation, under that TLD.
• shop is a subdomain created by the owner of the domain.
• www is another label, often just the name of a machine or service.

The very top of the tree is called the root, written as an invisible dot at the end of the name. Root servers know where to find the TLD servers, TLD servers know where to find the servers of each domain, and those servers hold the real answers.

What happens when you type a name

Four players are involved in a typical lookup:

1. The stub resolver on your computer, a small piece of the operating system that asks questions.
2. The recursive resolver, usually run by your Internet provider, your company or a public service. It does the legwork for you and keeps answers in a cache.
3. The authoritative servers for the domain, which hold the official records.
4. The root and TLD servers, which point the resolver in the right direction.

If the answer is already in the cache of your computer or of the recursive resolver, it is returned immediately. If not, the resolver asks a root server, which says "ask the servers for com". The com servers say "ask the servers of example.com", and those finally answer with the address. The result is cached for a duration set by the domain owner, called the TTL (time to live). This is why DNS changes take time to spread: caches around the world keep the old answer until their TTL expires.

DNS usually runs over UDP on port 53, because questions and answers are small. It switches to TCP port 53 for large answers and for some administrative transfers.

The record types you must know

A domain's configuration is made of records. Each has a type:

Type	Meaning	Example use
A	Name to IPv4 address	www points to an IPv4 address
AAAA	Name to IPv6 address	same, for IPv6
CNAME	Alias to another name	blog is an alias of another host name
MX	Mail servers of the domain	where email for the domain is delivered
NS	Authoritative name servers	who is in charge of the domain
TXT	Free text	email policies (SPF, DKIM, DMARC), ownership proofs
PTR	Address to name (reverse lookup)	find the name that goes with an IP

For a defender, TXT and MX records are goldmines: they reveal which email protections a domain has and which providers it uses. For an auditor working with permission, the full set of records of a domain is part of its "attack surface".

Querying DNS yourself

Two classic tools let you ask DNS questions: nslookup (available on Windows, macOS and Linux) and dig (common on Linux and macOS). Always use them against names you are allowed to query. Looking up a public record is not an attack, but to stay clean, use example.com, which is reserved for documentation, or a domain you own.

nslookup example.com

dig example.com A
dig example.com MX
dig example.com NS
dig +short example.com

A dig answer shows several sections. The question section repeats what you asked. The answer section contains the records, each with its TTL. At the bottom you will see which server answered and how long it took. Run the same query twice in a row and compare the TTL values: if the second answer shows a lower TTL, you are looking at a cached response counting down.

Why DNS matters for security

Because DNS is trusted by default and is involved in nearly every connection, it plays a role in many incidents:

• Spoofing and cache poisoning: if an attacker can inject a false answer into a resolver, users are sent to the wrong server without noticing. Modern resolvers include protections, and signed records (DNSSEC) let a resolver verify that an answer is authentic.
• Typosquatting and look-alike domains: an attacker registers a name that resembles a legitimate one, which is a classic phishing ingredient that you met in the first course.
• Subdomain takeover: a company forgets to remove a DNS record pointing to a service it no longer uses; someone else claims that service and gets a trusted subdomain.
• DNS tunnelling: because DNS is allowed almost everywhere, malware can hide small amounts of data inside DNS queries to leave a network.
• Reconnaissance: listing the records of a domain is one of the first steps of an authorised assessment.

On the defensive side, DNS logs are very valuable. A machine that suddenly asks for thousands of strange, random-looking names is worth investigating. Encrypted DNS (DNS over HTTPS or DNS over TLS) protects the privacy of questions in transit, though it also moves some visibility from the network administrator to the browser or resolver, which is a trade-off companies have to manage.

The hosts file: a local override

Before asking the network, your computer checks a local file named hosts (on Linux and macOS, /etc/hosts). A line such as 127.0.0.1 localhost maps a name to an address. You will use this trick in your lab to give friendly names to your virtual machines, such as victim.lab or webserver.lab. Malware also likes to edit this file to redirect banking sites, so it is useful to know where it lives.

Your turn: investigate a domain you are allowed to query

With example.com (or a domain you own), run dig or nslookup for the A, NS and MX records. Then run the same A query twice, a few seconds apart. In your lab notebook, answer these questions: what are the authoritative name servers? What is the TTL of the A record, and how did it change between the two runs? Which of the DNS layers (stub resolver, recursive resolver, authoritative server) answered your second query, according to you, and why?

See a solution

The NS query lists the authoritative servers, usually two or more for resilience. The A record shows a TTL in seconds. On the second run, the TTL is typically lower than on the first, because it is the remaining lifetime of a cached entry. That indicates the answer came from a cache, either the one in your operating system or the one in your recursive resolver, and not directly from the authoritative server. Note also that for example.com the MX record may be empty or contain a special "null" entry: documentation domains are not meant to receive mail.

Extra step: add the line 127.0.0.1 mytest.lab to your hosts file (this requires administrator rights) and check with ping mytest.lab that the name resolves to your own machine. Remove the line afterwards.