DNS · From the Basics to DNSSEC
Everything you need to know about the address book behind your website — plain-English explanations for every record type, plus optional technical deep dives for readers who want the full picture.
If you've ever set up email for your business, connected a domain to a website host, or worked with a developer on a "propagation" delay, you've bumped into DNS. Most business owners never need to touch it directly — but understanding the basics helps you ask the right questions and avoid costly mistakes. This guide covers what DNS records are, every record type you're likely to run into, email security, DNSSEC, and how to choose a provider — in plain English throughout, with clearly-marked technical sections for readers who want to go further.
DNS stands for Domain Name System. Think of it as the internet's phone book.
Computers don't navigate the web using words like yourbusiness.com — they use numeric addresses called IP addresses, something like 192.0.2.10. DNS is the system that translates the human-friendly name you type into the numeric address a computer needs to find the right server.
A DNS record is a single instruction stored on a DNS server that tells the internet how to handle a specific part of that translation — where your website lives, where your email should be delivered, or who is allowed to send email on your behalf.
DNS translates the domain name a visitor types into the numeric address of the server hosting your site.
This entire process happens in a fraction of a second, but it involves several handoffs.
A simplified view of the DNS resolution chain that runs behind every page load.
Because a lookup like this happens on nearly every visit, DNS providers cache (temporarily store) the results close to the visitor. That caching is controlled by a setting called TTL, which we'll cover in Section 6.
The diagram above simplifies things slightly. From your computer's point of view, the lookup is recursive — it sends one request and expects a complete answer back. But the resolver doing the work performs an iterative series of queries behind the scenes: it asks the root servers, gets referred to the correct TLD servers, asks those, gets referred to your domain's authoritative nameserver, and finally asks that server directly. Each of those is a separate query the resolver makes on your behalf.
You can watch this process yourself with command-line tools that are already installed on most systems:
dig yourbusiness.com A +short # Mac/Linux — returns the IP instantly nslookup yourbusiness.com # Windows-friendly equivalent dig yourbusiness.com MX +short # Check which servers handle mailAdd +trace to a dig command to watch the full referral chain — root, TLD, then authoritative nameserver — play out step by step.
Whether you're looking at a registrar's DNS panel, a raw zone file, or the output of a command like dig, most DNS entries follow the same basic pattern.
Name, TTL, class, type, and value — the five parts you'll find in almost every DNS record.
A zone file is the actual text file containing every DNS record for a domain, in the format nameservers use internally. Here's a simplified excerpt for a fictional domain:
; Zone file excerpt for yourbusiness.com $TTL 3600 @ IN SOA ns1.provider.com. admin.yourbusiness.com. ( 2026090501 ; serial number 3600 ; refresh 900 ; retry 1209600 ; expire 3600 ) ; minimum TTL @ IN NS ns1.provider.com. @ IN NS ns2.provider.com. @ IN A 192.0.2.10 www IN CNAME yourbusiness.com. @ IN MX 10 mail.provider.com. @ IN TXT "v=spf1 include:_spf.provider.com ~all"The @ symbol is shorthand for "the domain itself," and the trailing dots after names like provider.com. mark them as fully-qualified. Most people never touch a zone file directly — registrar and DNS provider dashboards generate this for you — but recognizing the format helps when reading raw exports or troubleshooting with a hosting provider's support team.
A domain's DNS settings are really just a list of records. Here are the ones you're most likely to encounter as a business owner.
Points your domain directly to a server's IP address. This is the most common record — it's what makes yourbusiness.com load your website.
yourbusiness.com → 192.0.2.10The same idea as an A record, but for the newer, longer IPv6 address format instead of the traditional IPv4 format.
yourbusiness.com → 2606:4700::1Points one domain name to another domain name rather than to an IP address directly. Commonly used for subdomains like www or third-party tools.
www.yourbusiness.com → yourbusiness.comTells the internet which mail servers should handle email for your domain — critical for making sure @yourbusiness.com email actually arrives.
yourbusiness.com → mail.provider.com (priority 10)Stores verification and security information — most notably SPF, DKIM, and DMARC records, which prove your emails are legitimate and reduce the odds of landing in spam.
v=spf1 include:_spf.provider.com ~allIdentifies which servers are authoritative for your domain — essentially, who's "in charge" of answering DNS questions about it.
yourbusiness.com → ns1.provider.comBeyond the core six, a few more specialized records show up in security setups, telephony systems, and reverse lookups.
| Record | What It Does | Example |
|---|---|---|
| SOA | Stores administrative details for the whole DNS zone — the primary nameserver, an admin contact, and timing values that control how secondary nameservers stay in sync. | See zone file example above |
| CAA | Specifies which Certificate Authorities are allowed to issue SSL/TLS certificates for your domain, blocking unauthorized certificate issuance. | CAA 0 issue "letsencrypt.org" |
| PTR | The reverse of an A record — maps an IP address back to a domain name. Used for reverse lookups and email server reputation. | 10.2.0.192.in-addr.arpa → mail.yourbusiness.com |
| SRV | Points to a specific host and port for a particular service, commonly used for VoIP, video conferencing, and chat systems. | _sip._tcp → sipserver.yourbusiness.com:5060 |
| NAPTR | Used in advanced telephony/SIP routing to rewrite names into different formats. Rare for a typical small-business site. | Uncommon — telephony systems only |
CAA records are worth a special mention: if none exists, most Certificate Authorities can still issue a certificate for your domain. Adding one is a small, free step that closes off a rarely-used but real attack path.
TTL (Time To Live) controls how long a DNS record is cached before it's checked again.
Every DNS record has a TTL value, measured in seconds. A short TTL (like 300 seconds / 5 minutes) means changes take effect quickly but the record is looked up more often. A long TTL (like 86,400 seconds / 24 hours) reduces lookup traffic but means changes take longer to fully "propagate" across the internet.
| TTL Value | Typical Use Case |
|---|---|
| 300 seconds (5 min) | Right before making a change — lets you switch back quickly if something goes wrong |
| 3,600 seconds (1 hr) | A reasonable everyday default for most business sites |
| 86,400 seconds (24 hr) | Stable, rarely-changed records like long-established nameservers |
Caching also doesn't happen in just one place. A DNS answer can be held at several layers on its way back to you:
This is why developers say "give it 24–48 hours to propagate" after a DNS change. It's not that DNS is slow — it's that older cached answers around the internet haven't expired yet.
Resolvers don't just cache successful answers — they also cache the fact that a record doesn't exist (an NXDOMAIN response). How long that "not found" answer sticks around is controlled by the minimum field in the domain's SOA record (the last value in the zone file example from Section 3).
This is a common cause of confusion: you create a brand-new subdomain, and even after its TTL would suggest it should be live everywhere, some resolvers still say it doesn't exist — because they cached the negative answer from before the record existed, and that cache hasn't expired yet.
Three TXT records work together to prove your emails are legitimate — and DNS itself has a security layer of its own.
SPF (Sender Policy Framework) lists which mail servers are allowed to send email on behalf of your domain. DKIM (DomainKeys Identified Mail) adds a digital signature to outgoing messages, proving they weren't altered in transit. DMARC (Domain-based Message Authentication) tells receiving mail servers what to do when a message fails those checks — accept it, quarantine it, or reject it outright.
Standard DNS has no built-in way to verify that an answer hasn't been tampered with in transit — a weakness attackers can exploit through DNS spoofing or cache poisoning, tricking a resolver into caching a forged answer that sends visitors to the wrong server. DNSSEC (DNS Security Extensions) closes that gap by cryptographically signing records at every level, so a resolver can verify each link in the chain back to the root.
DNSSEC adds two new record types you'll see mentioned in provider dashboards: DNSKEY (the public key used to verify signatures) and DS (a record placed at the registrar to link your domain into the chain of trust). Most providers now offer one-click DNSSEC activation, so you rarely need to build these by hand.
For reference, here's what the three email authentication records actually look like as raw TXT values:
yourbusiness.com. TXT "v=spf1 include:_spf.provider.com ~all" selector1._domainkey.yourbusiness.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." _dmarc.yourbusiness.com. TXT "v=DMARC1; p=quarantine; rua=mailto:reports@yourbusiness.com"Your domain registrar almost always includes basic DNS hosting for free — but you can point your domain's nameservers to a different provider if you want more features.
| Provider | Pricing Model | DNSSEC | Best For |
|---|---|---|---|
| Cloudflare | Free for standard DNS management, including unlimited queries | Included free, one-click setup | Anyone who wants fast, free DNS with built-in DDoS protection — requires switching nameservers to Cloudflare |
| AWS Route 53 | No free tier — priced per hosted zone (commonly around $0.50/month) plus a small per-query fee | Supported, with an added signing cost | Teams already building on AWS who want DNS tied into the same infrastructure, with advanced routing options |
| Namecheap | Free basic DNS included with any domain registered there | Included free on eligible domains | Straightforward setups where you're also registering your domain there |
| GoDaddy | Free basic DNS with a domain purchase; Premium DNS available as a paid upgrade | A handful of free credits, more via Premium DNS | Owners who want domain, hosting, and DNS managed in one familiar dashboard |
TrimpeTech.com itself runs on Cloudflare DNS in front of an AWS-hosted site — a common, cost-effective combination for small business sites that need speed and security without a large infrastructure budget.
You don't need to manage DNS records yourself to benefit from understanding them. Here's where it actually affects day-to-day business:
| Situation | What's Really Happening |
|---|---|
| Emails going to spam | Missing or misconfigured SPF/DKIM/DMARC (TXT) records |
| Switching web hosts | Updating the A record (and possibly nameservers) to point to the new host |
| Connecting a new tool (e.g. email marketing platform) | Adding a TXT or CNAME record to verify domain ownership |
| "Site is down" right after a change | Often just TTL/propagation — the old record hasn't expired everywhere yet |
DNS is infrastructure, not decoration — it's invisible when it works and disruptive when it doesn't. A five-minute misconfiguration in a TXT record can quietly route your customer emails to spam for months without any obvious symptom.
A quick reference for terms used throughout this guide.
A Website Health Audit from TrimpeTech checks your DNS, security, and technical foundation — and explains any issues in plain English, not jargon.
Get an Audit