At the request of a client, I terminated their existing domain and connected a new one. In this case, the client's hosting provider, domain registrar, email service provider, and previous web development company were all separate entities. This time, I unified all these elements into a single system as I started a new web development project for this company. While working on the project, I took the opportunity to organize and clarify the domain-related knowledge that had previously been tangled in my mind. So, I decided to write this series.

Through this series, you’ll gain a clear and comprehensive understanding of almost everything related to domains.

The table of contents for this series is as follows:

Part 1: Covers domains, TLDs, registries, the process of finding a domain in a browser, and more.
Part 2: Discusses A records, CNAME records, NS records, name servers, domain registrars, hosting providers, and more.
Part 3: Explores caching, MX records, resolvers, and more.

Additional DNS Records
Before Caching
Caching
After Caching

Additional DNS Records

Previously, we looked at commonly used records such as A, CNAME, NS, and AAAA.
In addition, there are other DNS records designed for specific purposes.

MX (Mail Exchange) Record

Specifies the mail servers responsible for handling emails for a domain.

example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 backup.example.com.

If someone sends an email to user@example.com, the DNS lookup for example.com will return its MX record.
The mail server then queries the A or AAAA record of mail.example.com to get the IP address and deliver the message.
The server with a lower priority number (10) is tried first, and the backup (20) is used if the primary server is unavailable.

TXT (Text) Record

Stores arbitrary text data, now primarily used for domain ownership verification and email security (SPF, DKIM, DMARC).

Domain Ownership Verification Example

Search engines (e.g., Google Search Console) require this type of record to verify domain ownership.

example.com. IN TXT "google-site-verification=1234567812345678"

How it works:

Google queries the TXT record of example.com.
If the value exists → “The user can modify DNS records, so they must be the owner!” → Verification successful
If not → Verification fails

The string "google-site-verification=1234567812345678" acts like a temporary token, proving control over the domain once added.

PTR (Pointer) Record

Used for Reverse DNS Lookup (IP address → domain name).
While A/AAAA records resolve a domain to an IP address, PTR records work in the opposite direction.

Typical use cases:

Email server trust checks (anti-spam)
Network diagnostics and logging

Resolver

A resolver is the program/service that translates domain names into IP addresses.
The browser itself doesn’t query the DNS hierarchy directly; instead, the operating system uses a Stub Resolver to handle this.

Types of Resolvers

Stub Resolver
- A lightweight resolver built into the user’s OS
- Checks local cache and the hosts file
- If not found, forwards the query to a designated DNS server (ISP or public DNS)
- Called “stub” because it only performs the initial query
Recursive Resolver
- Provided by ISPs, corporate networks, or public services like Google DNS (8.8.8.8) and Cloudflare DNS (1.1.1.1)
- Receives queries from stub resolvers
- Iteratively queries the Root → TLD → Authoritative name servers to find the final IP address
- Caches results to speed up future lookups

Example Workflow

User enters example.com in the browser
Stub Resolver (OS) checks local cache / hosts file
If not found, forwards the request to a Recursive Resolver (e.g., 8.8.8.8)
Recursive Resolver queries Root → TLD → Authoritative name servers in sequence
Final IP address is returned, cached, and passed back to the user

Note:

A Stub Resolver typically sends a recursive query to its designated DNS server (it asks: “give me the final answer”).
The Recursive Resolver then performs a series of iterative queries to other DNS servers (Root → TLD → Authoritative) until it finds the final IP address.
Once resolved, the Recursive Resolver returns the answer to the Stub Resolver.

Before Caching

If the cache already contains the IP address for the domain, it is used directly.
If not, the system checks the local hosts file to see if there is a matching entry.
The hosts file is a static mapping file, and its location depends on the operating system:

Windows: C:\Windows\System32\drivers\etc\hosts
macOS and Linux: /etc/hosts

This file allows manual mappings of domain names to IP addresses and takes precedence over the cache.
Administrator privileges are required to edit it.

If the IP address is not found in either the local cache or the hosts file, the browser queries the default DNS server provided by the Internet Service Provider (or another DNS server configured by the user).
This DNS server also caches frequently requested domain information. If the information is not available in its cache, the hierarchical lookup process begins:
Root name server → Top-Level Domain (TLD) name server → Authoritative name server.
Finally, the authoritative name server responds with the IP address, which the DNS server passes back to the browser.

Let’s take a closer look at how caching works.

Caching

Caching is a technique that stores frequently used data temporarily so it can be accessed more quickly.
The same principle applies to DNS. Once a domain and its corresponding IP address are looked up, they are stored in a cache so that subsequent requests for the same domain can be processed much faster.

Levels of Cache

DNS responses can be cached at several levels.

1. Browser Cache

The browser stores resolved IP addresses in its own cache.
These entries are kept for a short period of time, allowing repeated requests for the same domain to be processed quickly.

2. Operating System (OS) Cache

If the browser cache does not contain the information, the operating system’s DNS cache is checked.
The OS stores IP addresses for a certain period of time, and this cache is shared system-wide.
For example, other applications running on the same computer can also use this cached information.

3. Router Cache

Some home or small-office routers include a simple DNS cache.
This allows multiple devices on the same network to benefit from faster DNS lookups.

4. ISP and Public DNS Server Cache

DNS servers operated by ISPs cache frequently requested domain information on a large scale.
This way, ISP users can get quick responses without having to traverse the DNS hierarchy for every request.
Public DNS resolvers such as Cloudflare (1.1.1.1) and Google Public DNS (8.8.8.8) also provide caching in the same way.

TTL (Time to Live)

Every DNS record has a TTL (Time to Live) value, which determines how long the record should be stored in a cache.

The TTL is defined by the authoritative name server, and caches keep the record until the TTL expires.
Once the TTL has expired, the cache entry is removed and the information must be retrieved again from the authoritative server.
The TTL can be configured by the domain owner and may range from just a few seconds to several days.

Although the TTL value is the same across caches, each caching layer manages it independently, so expiration and refresh times may differ.

Information Stored in Cache

A cache stores the following key pieces of information:

Domain name
IP address
Record type (A, AAAA, CNAME, etc.)
TTL value

Other metadata included in the DNS response may also be cached, but these four are the essentials.

After Caching

Finally, the authoritative name server responds with the IP address, which the recursive resolver then returns to the stub resolver (and ultimately to the browser). The browser uses this IP address to establish a TCP connection with the web server, then sends an HTTP(S) request to retrieve the web page.
This completes the process of accessing a website by its domain name.

Almost Everything about Domain Name System (3)