← Back to Blog

The Domain Name System (DNS) is the backbone of the internet. Every time someone visits your website, sends you an email, or connects to your API, DNS is quietly translating human-readable domain names into the IP addresses that machines use to communicate. Yet for most IT professionals, DNS remains a black box, something that “just works” until it doesn’t.

When DNS breaks, the consequences are immediate and severe: websites go offline, email stops flowing, SSL certificates fail to validate, and customers lose trust. The challenge isn’t just understanding what DNS records exists, it’s knowing how to monitor them, detect changes before they cause outages, and maintain visibility across hundreds or thousands of domains.

That’s exactly what DNS Assistant was built to solve. As an enterprise DNS monitoring platform, DNS Assistant continuously tracks every record type covered in this guide, alerts you to unauthorized changes, and gives your team a single dashboard to manage DNS health across your entire domain portfolio.

In this guide, we’ll walk through every DNS record type you need to know. What it does, when you’d use it, what can go wrong, and how proactive monitoring prevents those problems from becoming incidents.

The Fundamentals: How DNS Resolution Works

Before diving into individual record types, it helps to understand the resolution process. When a user types yourcompany.com into their browser:

  1. The browser checks its local cache if an IP address for yourcompany.com exists, if not,
  2. The operating system checks its resolver cache for the IP address, if not found,
  3. The query goes to a recursive resolver (typically your ISP or a public resolver like 8.8.8.8)
  4. The recursive resolver queries root nameservers which then queries the TLD nameservers which then sends the IP request to your authoritative nameservers
  5. Your authoritative nameserver returns the requested record
  6. The answer propagates back through the chain, getting cached at each level based on the record’s TTL (Time to Live)

This entire process typically takes under 100 milliseconds. But if any link in that chain is misconfigured. A wrong NS delegation, an expired DNSSEC signature, a stale CNAME, the result can be anything from slow resolution to complete domain blackout.

DNS Assistant monitors every layer of this chain. When you add a domain, the platform performs a comprehensive check across all record types, validates DNSSEC chains, tests propagation against global resolvers, and establishes a baseline. From that point on, any change — authorized or not — triggers an alert so your team can respond before users are affected.

Address Records: The Foundation of DNS

A Record (Address Record)

The A record is the most fundamental DNS record type. It maps a domain name to an IPv4 address.

yourcompany.com.    300    IN    A    203.0.113.50

This tells resolvers that yourcompany.com should resolve to the IPv4 address 203.0.113.50. The 300 is the TTL in seconds — resolvers will cache this answer for 5 minutes before querying again.

Common configurations:

  • Single A record One domain pointing to one server. Simple, but creates a single point of failure.
  • Multiple A records DNS round-robin load balancing. The resolver rotates through the IPs. This provides basic redundancy but isn’t true load balancing since DNS has no concept of server health.
  • Low TTL A records Used during migrations or with CDN/failover services. A TTL of 60 seconds means changes propagate quickly, but it increases DNS query volume.

What can go wrong:

  • Stale records after server migration — You move to a new server but forget to update the A record. Traffic goes to the old IP, which may be reassigned to someone else.
  • Unauthorized changes An attacker who gains access to your DNS provider can redirect your traffic by modifying A records.
  • Propagation delays After changing an A record, some resolvers may still serve the old IP until the previous TTL expires.

AAAA Record (IPv6 Address Record)

The AAAA record (pronounced “quad-A”) is the IPv6 equivalent of the A record. As IPv4 address space continues to exhaust, IPv6 adoption is accelerating. Your DNS needs to support both.

yourcompany.com.    300    IN    AAAA    2001:db8:85a3::8a2e:370:7334

Why it matters:

  • Major ISPs and mobile carriers increasingly route traffic over IPv6 by default
  • Cloud providers like AWS, Google Cloud, and Azure fully support IPv6
  • Having AAAA records alongside A records ensures your domain is reachable from any network
  • Some compliance frameworks require IPv6 readiness

A common oversight: Many organizations set up A records but forget AAAA records (or vice versa). DNS Assistant flags domains that have A records but no AAAA records (and vice versa), helping you maintain dual-stack consistency.

Aliasing and Redirection Records

CNAME Record (Canonical Name)

The CNAME record creates an alias from one domain name to another. Instead of pointing to an IP address, it points to another domain name, which then resolves to an IP.

www.yourcompany.com.    3600    IN    CNAME    yourcompany.com.
blog.yourcompany.com.   3600    IN    CNAME    hosting.provider.com.

Key rules:

  • A CNAME cannot coexist with any other record type at the same name.
  • You cannot place a CNAME at the zone apex (bare domain). yourcompany.com cannot be a CNAME, only subdomains can.
  • CNAME chains (a CNAME pointing to another CNAME) are technically valid but slow and fragile.

DNS Assistant’s approach: When monitoring domains, DNS Assistant resolves the full CNAME chain and tracks the ultimate target. If the third-party endpoint your CNAME points to changes its IP or goes offline, you’ll know immediately if you have Alerts setup, not when customers start complaining.

Mail Records

MX Record (Mail Exchanger)

The MX record tells the internet where to deliver email for your domain. Without correctly configured MX records, you cannot receive email.

yourcompany.com.    3600    IN    MX    10 mail1.yourcompany.com.
yourcompany.com.    3600    IN    MX    20 mail2.yourcompany.com.
yourcompany.com.    3600    IN    MX    30 mail3.backup-mx.com.

The number before the hostname is the priority (lower = higher priority). In this example, mail delivery is attempted first at mail1, then mail2, then the backup mail3.

What can go wrong:

  • MX pointing to a non-existent host Email bounces with “no route to host” errors
  • Hijacked MX records An attacker redirecting your MX to their server captures all incoming email, including password reset links and sensitive business communications
  • Missing backup MX If your primary mail server goes down, email bounces instead of queuing

This is exactly why DNS monitoring matters. An unauthorized MX record change is one of the most dangerous DNS attacks, it’s silent, intercepting email without affecting website availability. DNS Assistant monitors MX records and alerts on any change, including priority changes that might redirect mail flow.

Email Authentication Records

Email authentication is one of the most critical — and most commonly misconfigured areas of DNS. These records work together to prove that email claiming to be from your domain actually is.

SPF (Sender Policy Framework)

SPF is published as a TXT record and defines which mail servers are authorized to send email on behalf of your domain.

yourcompany.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net -all"

Critical SPF limitations:

  • 10-lookup limit SPF has a hard limit of 10 DNS lookups. Exceeding this causes SPF to return permerror, and many receiving servers treat this as a fail. This is the single most common SPF misconfiguration.
  • No inheritance Subdomains don’t inherit the parent domain’s SPF record.
  • +all is catastrophic This authorizes the entire internet to send email as your domain.

DKIM (DomainKeys Identified Mail)

DKIM uses cryptographic signatures to verify that an email message was sent by an authorized server and hasn’t been modified in transit.

google._domainkey.yourcompany.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails.

_dmarc.yourcompany.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

Policy levels:

  • p=none Monitor only (collect reports but take no action)
  • p=quarantine Messages that fail are sent to spam/junk
  • p=reject Messages that fail are rejected entirely

Infrastructure Records

NS Record (Name Server)

NS records delegate authority for a domain to specific nameservers. They are foundational, if your NS records are wrong, nothing else matters.

What can go wrong:

  • Lame delegation The NS records point to nameservers that don’t actually serve your zone. This causes intermittent resolution failures.
  • Expired nameserver subscription If you stop paying your DNS provider, your domain becomes unreachable.
  • Hijacked nameserver If a extra nameserver is added to your domain, traffic leaks occurs.

DNS Assistant validates NS delegation by checking that all listed nameservers actually respond authoritatively for your domain.

SOA Record (Start of Authority)

The SOA record contains administrative information about the DNS zone, including serial number, refresh intervals, and expiration timers.

CAA Record (Certification Authority Authorization)

CAA records specify which Certificate Authorities are allowed to issue SSL/TLS certificates for your domain.

yourcompany.com.  3600  IN  CAA  0 issue "letsencrypt.org"
yourcompany.com.  3600  IN  CAA  0 issuewild "letsencrypt.org"
yourcompany.com.  3600  IN  CAA  0 iodef "mailto:[email protected]"

Without CAA records, any CA can issue a certificate for your domain. DNS Assistant monitors CAA records and alerts you to changes.

DNSSEC Records

DS, DNSKEY, and RRSIG Records

These records form the DNSSEC chain of trust, cryptographically signing DNS responses to prevent spoofing and cache poisoning.

What can go wrong:

  • Expired RRSIG signatures DNSSEC validating resolvers return SERVFAIL for your entire domain
  • KSK rollover failures A mismatch between DS and DNSKEY breaks the chain of trust

DNS Assistant validates the full DNSSEC chain for domains with DNSSEC enabled, checking signature validity, expiration windows, and chain-of-trust integrity.

Service Discovery Records

SRV Record (Service Record)

SRV records enable service discovery, they tell clients where to find specific services, including port numbers and load balancing weights.

Common services using SRV records: Microsoft 365 (autodiscover, SIP), XMPP, VoIP/SIP, LDAP, Kerberos, CalDAV/CardDAV.

PTR Record (Pointer / Reverse DNS)

PTR records map IP addresses back to domain names. They’re critical for email deliverability, most major email providers check that the sending server’s IP has a valid PTR record.

TTL: The Often-Overlooked Configuration

Every DNS record has a TTL (Time to Live) value that controls caching behavior:

  • Low TTL (60-300s) Changes propagate quickly. Essential during migrations. Increases query volume.
  • High TTL (3600-86400s) Reduces query volume. Provides cache resilience. Changes take longer to propagate.

Best practice: Lower TTLs for records that might change (A records), higher TTLs for stable infrastructure (NS, MX). Before a planned migration, lower the TTL well in advance.

DNS Assistant tracks TTL values across all records and includes them in change alerts.

Why DNS Monitoring Isn’t Optional

Consider these real-world scenarios:

Scenario 1: The silent email leak. An attacker adds a new MX record with higher priority. All incoming email routes through their server first, copied before forwarding. Without MX monitoring, this persists for months.

Scenario 2: The DNSSEC expiration. Your signing infrastructure silently fails. RRSIG signatures expire. For 30% of users on validating resolvers, your domain stops working.

Scenario 3: The SPF overflow. Marketing adds a new email service. The SPF lookup count goes from 9 to 11 — over the limit. Gmail starts marking your email as spam.

DNS Assistant prevents all three scenarios. Continuous monitoring, intelligent change detection, and configurable alerting mean your team knows about DNS changes as they happen.

Getting Started with DNS Assistant

DNS Assistant is built for organizations that take DNS seriously:

  • Comprehensive record monitoring Every record type covered in this guide
  • WHOIS monitoring Registration changes, expiration dates, registrar transfers
  • Multi-tenant architecture Organizations, teams, and role-based access
  • Configurable alerts Rules for the changes that matter, via email or in-app
  • DKIM selector management Track selectors across all domains
  • DNSSEC validation Full chain-of-trust verification
  • API access Integrate into your existing workflows

Whether you manage 10 domains or 10,000, DNS Assistant gives your team the visibility they need to keep DNS healthy and secure.

Start Monitoring Your DNS Today

Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.

Sign Up Free