What Is DNS? How Domain Names Turn into IP Addresses

DNS (Domain Name System) maps names such as example.com to the data a client needs next, most often an IP address. Applications ask for a name, and DNS returns records. DNS is not a web server, a browser or an encryption layer. It answers lookup questions and nothing more.

#The short version

When you type a name into a browser, the operating system or the browser checks its own cache first. If there is no usable answer, the client sends a query to a recursive resolver. That resolver is often run by your internet provider, your employer or a public service such as 8.8.8.8.

The resolver answers from its cache when it can. If it cannot, it walks the DNS hierarchy. It asks a root server which servers handle the top-level domain (such as .com), asks that server which nameservers the domain uses, and then asks one of those authoritative nameservers for the record. The authoritative server holds the real data. The resolver stores the answer for as long as the record's TTL allows, then returns it to the client.

Real traffic adds more steps: CNAME chains, DNSSEC validation, entries in a local hosts file, encrypted DNS transports and several cache layers. After DNS finishes, the browser still has to open a connection, negotiate TLS and wait for the server to respond.

#Records you will meet first

#Try it on a domain you can document

Use a domain you own or manage. If you only want practice, example.com is one of the names reserved for documentation (RFC 2606). Stick to names you are allowed to look up, and avoid scanning hosts you have no permission to test.

On Linux or macOS, with dig installed:

dig example.com A
dig example.com AAAA
dig example.com MX

On Windows, nslookup is included with the operating system:

nslookup example.com
nslookup -type=AAAA example.com
nslookup -type=MX example.com

The output below was captured on a Windows machine on 2026-11-08 with nslookup, using the machine's default resolver (dns.google, 8.8.8.8). The answer came from that resolver, not from the domain's authoritative server. The machine printed its labels in Portuguese. They are shown here in English. The values are a snapshot and will differ on your machine and on later runs.

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

Name:    example.com
Addresses:  2606:4700:10::ac42:93f3
	  2606:4700:10::6814:179a
	  172.66.147.243
	  104.20.23.154

The same resolver returned an MX record for the domain:

example.com	MX preference = 0, mail exchanger = (root)

A mail exchanger of (root) means the target is a single dot. That is a null MX, which tells senders the domain accepts no mail (RFC 7505).

Finally, a TXT query for the same name:

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

example.com	text =

	"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
example.com	text =

	"v=spf1 -all"

The second string is an SPF policy. -all says no server is authorized to send mail for this domain, which fits the null MX above. The first string is an opaque value; strings like it are commonly used to prove ownership of a domain to a service. As the table says, a TXT record shows what the owner published and proves nothing more.

Two details from this run. The line Non-authoritative answer confirms the reply came from a resolver's cache or lookup, not from the domain's own server. And the IPv6 addresses came first, but the order is not something to depend on: a later run may list them differently or return different addresses.

To watch caching, use dig. It prints a TTL number before each record. Run the same query twice within the TTL window. If a resolver cached the answer, the second number will be lower than the first.

#Caching and why answers change

Every record carries a TTL, a time in seconds that tells resolvers how long they may keep the answer. A short TTL lets the owner move a service quickly, and it also means more queries reach the authoritative servers. A long TTL reduces load, and it means old answers can survive for a while after a change.

So one answer is a snapshot. Two resolvers can disagree during a change, and both can be correct for their own cache. When you need to know what the owner published, ask an authoritative nameserver directly, for example with dig example.com A @<nameserver> using a server listed in the domain's NS records, or follow the chain with dig +trace example.com A.

#DNS, OSINT and security

Looking up public DNS records for a domain is a normal first step in an asset inventory. A company can review its own names, its own mail records and the addresses behind them. Researchers often combine this data with certificate transparency logs and ownership information.

Two things do not follow from a DNS answer. First, a record in a search result is not permission to scan the host it points to. Second, an IP address does not identify who operates the machine. Hosting providers, CDNs and shared servers mean one address can serve many unrelated sites.

A suspicious record is also not proof of an attack. Misconfigurations, expired services and abandoned names are common. Check the authoritative answer, the change history and the domain owner before you draw a conclusion. Cache poisoning and spoofing are separate problems with separate evidence.

#Typical mistakes

• Treating one answer as permanent. Check the TTL and query again later.
• Reading a CNAME as an IP address. Follow the alias until you reach an A or AAAA record.
• Assuming the resolver you used is the authoritative server. The output tells you which server replied.
• Reading a TXT record as proof that a security control works.
• Scanning a host because DNS pointed to it. A lookup and a scan are different actions with different permissions.

#What to learn next

DNS is one step in a web request. Next, learn how HTTP and TLS handle what happens after the name becomes an address, using the RFCs and documentation listed in the sources. Then read the next article in this track, on OSINT, before you run any queries as part of reconnaissance. Keep your practice to domains and systems you own or have written permission to test.