DNS Management Guide
Introduction
DNS is one of the fundamental building blocks of the internet.
Whenever a website is opened, an email is sent, or an API is accessed, DNS is involved.
To understand DNS management, it is important to understand the following concepts:
- Domain
- Nameserver
- DNS
- Zone
- DNS Records
- TTL
- Caching
This guide explains the basics, shows simple examples, and describes common behaviors and impacts in day-to-day operations.
1. What is DNS?
DNS stands for:
Domain Name System
DNS works like the phone book of the internet.
Humans use easy-to-remember names such as:
example.com
google.com
shop.example.com
Computers, however, communicate using IP addresses:
142.250.185.14 (IPV4)
2a00:1450:4001:82b::200e (IPV6)
DNS translates domain names into IP addresses.
Example:
example.com -> 93.184.216.34
Without DNS, users would need to remember the IP address of every service they use.
2. Basic Concepts and Terminology
2.1 Domain
A domain is the human-readable name of an internet address.
Examples:
example.com
company.org
shop.mycompany.com
Structure:
shop.mycompany.com
│ │ │
│ │ └── Top-Level Domain (TLD)
│ └──────────── Main domain
└───────────────── Subdomain
2.2 Nameserver
A nameserver answers DNS queries for a domain.
When someone wants to know:
“Which IP address belongs to example.com?”
The responsible nameserver is queried.
Example:
example.com
Nameservers:
- ns1.provider.net
- ns2.provider.net
These nameservers contain the DNS configuration for the domain.
2.3 DNS Zone
A DNS zone is the actual configuration of a domain.
It contains all DNS entries such as:
- Websites
- Mail servers
- Subdomains
- Security records
- Verification records
Example:
example.com. A 203.0.113.10
www CNAME example.com.
mail A 203.0.113.20
2.4 Subdomain
A subdomain is a prefix added in front of a main domain to separate services, systems, or environments under the same domain.
It allows you to structure a domain into logical parts without registering new domains.
Examples:
www.example.com
shop.example.com
api.example.com
dev.example.com
Structure:
api.shop.example.com
│ │ │ │
│ │ │ └── Top-Level Domain (TLD)
│ │ └────────── Main domain
│ └─────────────── Subdomain (shop)
└─────────────────── Subdomain (api)
How subdomains work in DNS
A subdomain is simply another DNS entry inside the same zone.
Example zone entries:
example.com. A 203.0.113.10
www CNAME example.com.
shop A 203.0.113.20
api A 203.0.113.30
An A record maps a domain or subdomain directly to an IPv4 address (e.g. example.com → 203.0.113.10).
A CNAME record creates an alias that points one domain name to another hostname instead of an IP address (e.g. www.example.com → example.com).
Each subdomain can:
- point to a different server
- use a different service
- have its own TTL and record type
2.5 Common use cases
| Subdomain | Purpose |
|---|---|
| www.example.com | Website |
| api.example.com | Backend / API |
| shop.example.com | E-commerce system |
| dev.example.com | Development environment |
| mail.example.com | Mail services |
3. DNS Zones in Detail
The zone is the central component of every DNS configuration. You can think of it as a technical configuration file.
3.1 Structure of a Zone
A zone consists of multiple DNS records.
Example:
example.com
├── @
├── www
├── shop
├── api
└── _dmarc
Each entry can:
- point to different systems
- have its own TTL
- use different record types
3.2 Core DNS Concepts & Naming
| Term | Meaning |
|---|---|
| Zone | Complete DNS configuration for a domain |
| Resource Record (RR) | Single DNS entry |
| RRset (Resource Record Set) | Group of records with same name + type |
| Record Type (RR Type) | Type of DNS record (A, MX, TXT, etc.) |
| Owner Name | Domain or subdomain the record belongs to |
| TTL | Cache duration of a record |
Example 1 (Web)
- Zone:
example.com - RR:
www.example.com. 300 IN A 203.0.113.10 -
RRset:
www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN A 203.0.113.11 - Record Type:
A - Owner Name:
www.example.com - TTL:
300
Example 2 (Web + Mail)
- Zone:
company.io - RR:
company.io. 3600 IN A 198.51.100.10 -
RRset (MX):
company.io. 3600 IN MX 10 mail.company.io.
company.io. 3600 IN MX 20 backup.company.io. - Record Type:
A,MX - Owner Name:
company.io,mail.company.io - TTL:
3600
3.3 Alternative Terms in Practice
In real-world systems, DNS terminology varies depending on context, tooling, or vendor abstraction layers.
| Context / Industry | Term Used | Meaning |
|---|---|---|
| RFC / DNS Standards | Resource Record (RR) | Formal DNS specification term |
| Zone files (BIND-style) | DNS Record | Common configuration term |
| Cloud providers (AWS, GCP, Azure) | DNS Entry / Record Set | API-friendly abstraction |
| Load balancing systems | RRset | Set of identical records used for distribution |
| DNS engineering / ops | RR / RRset | Technical implementation terminology |
| DNS management UI panels | Record | Simplified user-facing term |
3.4 TTL (Time To Live)
The TTL (Time To Live) defines how long a DNS record may be cached by resolvers before it must be queried again from the authoritative nameserver (see later below what authoritative nameserver means). A resolver is the system (usually operated by your ISP, company network, or public DNS services like 1.1.1.1 or 8.8.8.8) that performs the actual DNS lookup on behalf of clients. It first checks its local cache for an existing answer; if the TTL has not expired, it returns the cached result immediately, otherwise it queries the authoritative nameserver again to retrieve the latest data.
Practical recommendations (rule of thumb)
- Frequently changing website (deployments, migrations, A/B testing)
→60–300 seconds
Fast propagation of changes, but more DNS queries. - New website / initial setup / go-live phase
→300–600 seconds
Flexible during early changes, then increase later. - Stable production website (rare changes)
→3600–14400 seconds (1–4 hours)
Good balance between performance and update flexibility. - Very stable systems (no expected changes, e.g. landing pages)
→86400 seconds (24 hours)
Maximum caching, minimal DNS load. - APIs / apps with dynamic infrastructure (autoscaling, failover)
→60–300 seconds
Important for fast failover and infrastructure changes. - Mail records (MX, SPF, DKIM)
→3600–86400 seconds
Usually stable, so higher TTL is preferred to avoid propagation delays.
3.5 Overview of DNS Resource Record Types (RRTypes)
| RR Type | Full Name | Purpose | Common Alternative Names |
|---|---|---|---|
| A | Address Record | Maps hostname to IPv4 address | IPv4 Record |
| AAAA | IPv6 Address Record | Maps hostname to IPv6 address | IPv6 Record |
| CNAME | Canonical Name Record | Alias to another hostname | Alias Record |
| MX | Mail Exchange Record | Defines mail servers | Mail Routing Record |
| TXT | Text Record | Free text (SPF, DKIM, verification) | Verification / Policy Record |
| NS | Name Server Record | Delegates DNS authority | Delegation Record |
| SOA | Start of Authority | Zone metadata and control info | Zone Authority Record |
| PTR | Pointer Record | Reverse DNS (IP → hostname) | Reverse Lookup Record |
| SRV | Service Record | Service discovery (port + target) | Service Discovery Record |
| CAA | Certification Authority Authorization | Controls SSL certificate issuance | Certificate Policy Record |
| DS | Delegation Signer | DNSSEC delegation security | DNSSEC Chain Record |
| DNSKEY | DNS Public Key Record | DNSSEC cryptographic key | Security Key Record |
| NAPTR | Naming Authority Pointer | Advanced service mapping | Rewrite / Routing Record |
3.6 Complete Example Zone
$ORIGIN example.com.
@ 3600 IN SOA ns1.provider.net. hostmaster.example.com. (
2026050701 ; Serial
3600 ; Refresh
900 ; Retry
1209600 ; Expire
300 ; Negative Cache TTL
)
@ 86400 IN NS ns1.provider.net.
@ 86400 IN NS ns2.provider.net.
@ 300 IN A 203.0.113.10
www 300 IN CNAME example.com.
mail 300 IN A 203.0.113.20
@ 300 IN MX 10 mail.example.com.
@ 300 IN TXT "v=spf1 include:_spf.google.com ~all"
_dmarc 300 IN TXT "v=DMARC1; p=reject"
4. Querying DNS Records and Zones with dig
dig (“Domain Information Groper”) is a standard command-line tool used to query DNS information directly from DNS servers. It is commonly used for troubleshooting, debugging, and validating DNS configurations.
A simple query for an A record looks like this:
dig opusdns.com
This returns the DNS response for the domain, including the resolved IP address, TTL, and record type:
opusdns.com. 587 IN A 198.202.211.1
Specific record types can also be queried explicitly:
dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com TXT
dig example.com NS
...
Authoritative nameservers are the DNS servers that hold the official, final version of a domain’s DNS data (the zone). They are the “source of truth” for a domain and do not rely on cached answers from other servers.
When you query them directly, you bypass intermediate resolvers and caches, which makes it ideal for checking whether a DNS change has actually been applied at the source.
It is also possible to query a specific authoritative nameserver directly, which is especially useful when validating recent DNS changes or debugging propagation issues.
dig @ns1.opusdns.com example.com
dig @ns2.opusdns.net example.com