A DNS record is an instruction stored on an authoritative nameserver that maps a domain name to an address, a mail server, or another service, and every record carries a time to live (TTL) that tells resolvers how long to cache it. Get these records wrong and your website, email, or app becomes unreachable within minutes. Get them right and nobody ever notices DNS is working at all.
TL;DR:
- Longer TTLs reduce query volume but delay DNS updates, so set a low TTL before migrations and revert after confirming stability.
- DNS zone misconfigurations, especially at the SOA and NS level, can make your entire domain unreachable, even with correct records elsewhere.
- In case of DNS issues, verify SOA and NS records first, then check that A, MX, and TXT records point correctly, restoring from backups if needed.
- A single cache miss can add up to 300 milliseconds to page load time, underscoring how cache hit rates influence perceived website speed.
- DNSSEC adds security by cryptographically verifying records but requires careful key management to avoid validation failures.
Table of Contents
- What does a DNS record actually look like?
- How does a DNS lookup actually happen?
- What are the main types of DNS records and what do they do?
- What less common records should you know about?
- How does DNSSEC protect DNS records?
- How should you set TTL and manage propagation?
- What do you do when DNS records break?
- How does Techbug apply DNS best practice for clients?
- Where does conventional DNS advice fall short?
- Sources
- FAQ
What does a DNS record actually look like?
Every DNS record has four core parts: the owner name (the domain or subdomain it applies to), the type (A, MX, TXT and so on), the value (what it points to), and the TTL, which sets how long resolvers can cache the answer before checking again. A fifth field, class, almost always reads “IN” for internet and can be ignored by most readers.
These records live in a zone file, a plain-text file held on the domain’s authoritative nameservers. Records sharing the same name and type form what RFC terminology calls an RRset, and RFC 8499 notes that every member of an RRset should share the same TTL, since mismatched values cause inconsistent caching across resolvers.
Two records anchor every zone:
- SOA (Start of Authority): one per zone, listing the primary nameserver, an admin contact, and refresh/retry timers.
- NS (Name Server): names the servers authorised to answer for that zone, and there’s usually at least two for redundancy.
Miss either one and the zone itself is broken, not just a single service.
How does a DNS lookup actually happen?
When you type a domain into a browser, your device asks a recursive resolver (often your ISP’s, or a public one like Google’s or Cloudflare’s) to find the answer. That resolver checks its own cache first, and only if the record isn’t there does it start the chase.
- The resolver asks a root server where to find the domain’s registry (
.com,.au, and so on). - The registry’s server points it to the domain’s authoritative nameservers.
- The authoritative nameserver returns the actual record, which the resolver then caches for the TTL duration and hands to your device.
That whole chain, on a cold cache, adds real time to page loading. Google’s own measurements put average resolution around 130 milliseconds for a responding nameserver, and end-to-end resolution, including failures and retries, can stretch to 300 to 400 milliseconds.
Statistic callout: A single cache miss can cost your site a third of a second before a single byte of content loads, which is why cache hit rates matter more to perceived speed than most site owners realise.
Cache hits skip nearly all of that. This is the entire point of TTL: a longer cache life means fewer round trips, but slower updates when something changes.
What are the main types of DNS records and what do they do?
Most domains only ever need a handful of record types. IANA’s protocol registry lists more than 30, but in practice five cover the bulk of domain management: A, AAAA, CNAME, MX and NS.
A and AAAA records point a name straight at an IP address. An A record uses IPv4 (“203.0.113.10”); an AAAA record uses IPv6. Which one you need depends on what your host or server supports, and most modern setups run both side by side so traffic can arrive either way.
CNAME records alias one name to another, so www.example.com might point to example.com rather than duplicating an IP. The rule that trips people up constantly: a CNAME cannot coexist with any other record type at the same name, and it’s prohibited outright at the zone apex because the apex must carry SOA and NS records. If you want apex-level aliasing, you need a provider’s ALIAS or ANAME feature instead, which synthesises the equivalent A/AAAA answer behind the scenes.
MX records route inbound email, each with a priority number where lower wins. An MX record must point to a hostname that itself resolves via an A or AAAA record, never directly to an IP.
NS and SOA records handle delegation and zone metadata, as covered above. Get the NS records wrong at your registrar and your entire domain effectively vanishes, even if every other record is perfect.
TXT records hold arbitrary text, and in practice they’re mostly used for verification and email authentication. SPF, DKIM and DMARC records all live here, telling receiving mail servers which sources are allowed to send on your domain’s behalf and what to do with messages that fail the check. If you haven’t set these up, your legitimate emails are increasingly likely to land in spam, or get rejected outright, and Techbug’s guide to phased DMARC rollout walks through doing this without breaking mail flow mid-change.
PTR records do reverse DNS, mapping an IP address back to a hostname. They matter most for mail server reputation. Many receiving servers check that an IP’s PTR record matches its sending domain, and a missing or mismatched PTR is a common, invisible reason legitimate mail gets flagged.
Pro Tip: Before touching any DNS record, export a full copy of the current zone file. If a change goes wrong, restoring from that copy is faster than rebuilding records from memory, and it removes the guesswork about what the “before” state actually looked like.
What less common records should you know about?
A handful of newer or specialised record types matter mostly to admins running modern cloud and CDN setups.
- SVCB and HTTPS records let a domain advertise alternative endpoints and connection parameters, helping clients skip extra round trips when connecting to services behind load balancers or CDNs.
- TLSA records, used with DANE, bind a domain to a specific TLS certificate, adding a DNS-level check on top of standard certificate authority trust.
- DNSKEY, DS and RRSIG records are the backbone of DNSSEC, the mechanism explained below. Provider ALIAS/ANAME behaviour varies, so confirm how yours handles’ apex aliasing before relying on it for a production domain.
Most small businesses will never touch these directly, but they show up increasingly in CDN and cloud hosting dashboards, so recognising the names saves a panicked search when one appears.
How does DNSSEC protect DNS records?
DNSSEC adds cryptographic signatures to DNS responses, so a resolver can verify that a record genuinely came from the zone’s authoritative source and wasn’t tampered with in transit. It relies on the DNSKEY, DS and RRSIG records mentioned above, layered onto the ordinary record types.
The trade-off is operational complexity. Signed zones need periodic key rollovers, and getting that rollover wrong is a well-known way to break DNSSEC validation for an entire domain, causing browsers and mail servers that enforce DNSSEC to reject otherwise valid records. If your zone uses DNSSEC, follow your provider’s specific rekeying steps rather than improvising.
How should you set TTL and manage propagation?
TTL is measured in seconds, and RFC guidance is explicit that every record in an RRset should carry the same value to avoid caching inconsistencies. A short TTL, say 300 seconds, means changes propagate fast but resolvers query your authoritative server far more often. A long TTL, such as 86,400 seconds (24 hours), cuts query load but means a mistake sits live for a full day before most caches clear it.
- Drop TTL to a low value (around 300 seconds) well ahead of any planned migration.
- Make the change during that low-TTL window.
- Once the new record is confirmed stable, raise TTL back up for normal operation.
This staged approach, standard practice for DNS migrations, is also worth applying before any broader site migration to keep downtime minimal. Adding more resolver infrastructure without a matching TTL strategy can fragment caches across your user base, so plan the two together, not separately.
What do you do when DNS records break?
Symptoms are usually blunt: the website won’t load, email bounces, or traffic quietly lands on the wrong server. Work through this before assuming the worst:
- Run
digornslookupagainst the domain and check that SOA and NS records return the expected authoritative servers. - Confirm A, AAAA and MX records point where they should, and that TXT records for SPF/DKIM/DMARC haven’t been dropped.
- If records were deleted outright, recreate the zone from a backup on the authoritative nameservers. Deleted records make a domain unreachable until the zone is rebuilt, and even then, propagation delay means old cached answers can linger.
- If the fix doesn’t resolve within a couple of TTL cycles, or you’re not confident reading the zone, escalate to your DNS host or a managed IT provider rather than guessing further.
Pro Tip: Check the SOA record’s serial number first. If it hasn’t incremented since your last change, the zone likely never saved correctly, and that’s usually faster to spot than chasing individual record values.
How does Techbug apply DNS best practice for clients?
A vendor-agnostic approach to DNS means recommending managed DNS hosting when a setup genuinely needs the redundancy and monitoring it provides, rather than defaulting to one provider regardless of fit. In practice that looks like staging TTL changes ahead of migrations, keeping zone file backups before any edit, and monitoring for unexpected record changes that could signal a compromised registrar account.
DIY works fine for a straightforward TXT update. It stops working the moment a business depends on email deliverability or uptime it can’t afford to lose. That’s the point to bring in managed IT support rather than troubleshoot alone at midnight, particularly when a misconfigured MX or SPF record is actively bouncing customer emails.
Where does conventional DNS advice fall short?
Most DNS explainers stop at “here’s what A and MX records do” and call it a day. That’s the easy 80%. The part that actually causes outages, TTL strategy, RRset consistency, and what happens operationally when a zone gets deleted or a DNSSEC rollover goes sideways, gets a paragraph if it gets mentioned at all.
The conventional wisdom that TTL should just be “low for safety” is also lazier than it looks. Low TTL everywhere isn’t free. It multiplies query load on your authoritative servers and, at scale, that has real cost and latency implications, which is exactly why the staged TTL approach matters more than a blanket rule.
If there’s one thing worth prioritising above the rest, it’s zone backups. Not because deletions are common, but because when they happen, the difference between a five-minute recovery and a half-day outage is whether someone exported the zone file last week. Everything else, record types, DNSSEC, propagation timing, is manageable once you can actually restore what was there.
— Ru
Sources
For readers who want the primary sources rather than a summary: the IANA DNS parameters registry and RFC 8499 define the official terminology; auDA covers how this applies to .au domains specifically; and IBM’s overview of DNS records is a solid applied reference for troubleshooting.
- auDA — Domain names and the DNS explained
- GoDaddy — DNS records: a basic guide
- Google Developers — Public DNS performance
FAQ
What should my DNS records be?
At minimum, every domain needs NS and SOA records for delegation, an A or AAAA record pointing to your web host, and MX records if you’re using email on that domain. Most setups also add TXT records for SPF, DKIM and DMARC to protect email deliverability, and a CNAME for subdomains like www where an alias makes sense.
What are the five types of DNS records?
The five most commonly used record types are A, AAAA, CNAME, MX and NS, which together handle the bulk of everyday domain management. IANA’s full registry lists more than 30 types, but these five cover website addressing, aliasing, email routing and delegation.
Is 1.1.1.1 DNS the fastest?
Public resolvers such as major public DNS services are generally fast because they run large, well-distributed caching infrastructure, but actual speed depends on your location and network path to that resolver. The bigger factor in real-world performance is usually cache hit rate and TTL settings on the records themselves, not which public resolver you choose.
What happens if I delete all my DNS records?
Deleting all your DNS records makes the domain unreachable: the website stops loading and email stops delivering almost immediately. Recovery means recreating the zone file on your authoritative nameservers from a backup, and even after that, propagation delay means some resolvers keep serving stale or failed lookups until their cached TTL expires.