Every outage ticket that says “the site is down” or “mail is bouncing” eventually becomes a question about one record in one zone. The DNS record types that matter most for troubleshooting are A and AAAA (website addresses), CNAME (aliases), MX and TXT (mail routing and authentication), PTR (reverse DNS), NS and SOA (delegation and authority), and CAA plus the DNSSEC set (certificate and integrity controls). When you know which record answers which question, you can stop guessing and query the exact record behind the failure.
PacketTools was built by an engineer with over 28 years of production IT experience, and the same lookups described below are the ones used to verify VPNs, analyze routing, and harden infrastructure. By the end, you will be able to read a DNS answer field by field, tell a stale cache from a broken zone, and match a symptom to the record that causes it.
Which Records Connect Domain Names to Websites?
Three record types get a browser from a domain name to a server: A records hold IPv4 addresses, AAAA records hold IPv6 addresses, and CNAME records point one name at another name. The apex of a zone adds a wrinkle, because the bare domain can’t hold a standard CNAME, so providers solve it with flattening.
How Do A and AAAA Records Point to IPv4 and IPv6 Addresses?
An A record maps a hostname to a 32-bit IPv4 address. An AAAA record (“quad-A”) does the same job for a 128-bit IPv6 address. If the difference between the two address families is fuzzy, the IPv4 vs IPv6 breakdown covers it.
A typical pair in a zone file looks like this:
www.example.com. 3600 IN A 198.51.100.10
www.example.com. 3600 IN AAAA 2001:db8::10A few field-tested points:
- Multiple A records on one name spread traffic across servers in round-robin fashion. That is crude load balancing with no health checks, so a dead server keeps receiving its share.
- Publish AAAA only when the server listens on IPv6. Dual-stack clients prefer the AAAA answer, and a dead IPv6 address produces slow page loads that look like a network problem.
- Address records hold the IP literally. Migrate a server and every A record pointing at the old address has to change.
Naming limits apply too. DNS labels are capped at 63 characters and a fully qualified name at 253, which occasionally bites automated subdomain generators.
When Should You Use a CNAME Instead of an Address Record?
Use a CNAME record when you want a subdomain to follow a hostname you don’t control, such as a SaaS platform, a CDN configuration, or a load balancing endpoint whose IPs rotate. The resolver hits the CNAME, restarts the lookup against the canonical name, and returns whatever that target resolves to.
www.example.com. 3600 IN CNAME webhost.example.net.Two rules cause most CNAME tickets you will see:
- A CNAME must stand alone. No A, MX, or TXT record can exist at the same name.
- The target must be a hostname. A CNAME never points at an IP address.
Chains are legal, but each hop adds a lookup and another place to break. When a subdomain resolves inconsistently, query the CNAME and then query the target separately to find which hop is stale.
What Happens When a CNAME Is Needed at the Zone Apex?
The bare domain (example.com) already carries mandatory SOA and NS records, so a standard CNAME there would violate the stand-alone rule. Yet hosting platforms and CDNs often hand you a hostname, not an IP, for the root domain.
Providers solve this with CNAME flattening, sometimes sold as ALIAS or ANAME. The authoritative server resolves the target itself and serves the resulting A and AAAA records at the apex. Resolvers never see a CNAME.
The troubleshooting consequence: a dig example.com CNAME returns nothing even though your dashboard shows one. Query A and AAAA instead, and compare the returned IPs with what the target hostname resolves to directly. A mismatch points to the provider’s flattening cache lagging behind a change at the target.
Which Records Route and Authenticate Email?
Mail depends on MX records to find the receiving server, TXT records to publish SPF, DKIM, and DMARC policy, and PTR records to prove a sending IP’s identity. A fault in any one of them produces bounces or spam-folder placement with no error on the website side.
How Do MX Priorities Direct Incoming Mail?
An MX record pairs a priority number with a mail server hostname. Sending servers try the lowest number first and fall back to higher numbers when the preferred host refuses or times out over SMTP. Equal priorities share the load.
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.Checks to run when inbound email delivery fails:
- Confirm the MX target has its own A or AAAA record. An MX pointing at a CNAME or a bare IP breaks the spec, and some senders reject it outright.
- Copy provider values exactly. Microsoft 365 tenants use a hostname ending in
mail.protection.outlook.com; a typo there silently misroutes everything. - Watch the backup MX. A low-preference server that accepts mail but never forwards it is a classic cause of “some messages vanish.”
What Do TXT Records Publish for SPF, DKIM, DMARC, and Verification?
TXT records carry free-form text that specific systems read as configuration. For email authentication, that means three records in three locations:
| Record | Location | Purpose |
|---|---|---|
| SPF | Root of the domain | Lists IPs and services allowed to send as you |
| DKIM | selector._domainkey subdomain |
Publishes the public key for signature checks |
| DMARC | _dmarc subdomain |
Tells receivers what to do when SPF and DKIM fail |
The SPF failure you will hit most often is the lookup cap. RFC 7208 limits SPF evaluation to 10 DNS lookups, and every include: counts, so a domain using several email platforms exceeds it fast and returns a permerror. Domains are also allowed only one SPF record; two v=spf1 strings break both.
DKIM keys at 2048 bits exceed the 255-character limit of a single TXT string, so they are split into quoted chunks that resolvers concatenate. A missing quote in a pasted key is a common silent failure.
Domain verification tokens for services like Microsoft 365 live here too. They accumulate over the years; prune ones tied to services you no longer use.
Why Does a Sending Server Need Reverse DNS?
A PTR record maps an IP address back to a hostname, the reverse of an A record. Receiving mail servers run a reverse DNS lookup on the connecting IP, and many reject or score down mail from IPs with no PTR or with a generic ISP-style name.
Good practice is forward-confirmed reverse DNS: the PTR for 203.0.113.10 returns mail.example.com, and the A record for mail.example.com returns 203.0.113.10.
PTR records live in the reverse zone controlled by whoever owns the IP block, so you set them in your hosting or VPS provider’s panel, not your domain’s zone. If you send through a hosted platform, the provider manages PTR for its own IPs.
How Do Delegation and Service Discovery Work?
NS and SOA records decide which servers are authoritative for a zone and how copies stay in sync. SRV, NAPTR, and HTTPS records tell clients where an application service lives, and HINFO survives mostly as a curiosity.
How Do NS and SOA Records Define Authority for a Zone?
NS records name the authoritative nameservers for a DNS zone. They appear twice: in the parent zone (the TLD), where they perform DNS delegation, and at your apex, where your own servers declare themselves. Those two sets should match. When they diverge, resolvers follow the parent’s delegation while tools read the child’s, and you get inconsistent answers that are hard to reproduce.
When a nameserver lives inside the domain it serves (ns1.example.com for example.com), the parent must also publish its IP as a glue record. Most TLD registries require at least two nameservers, ideally on separate networks.
The SOA record (start of authority) appears once per zone and holds:
- The primary nameserver and responsible contact
- A serial number that secondaries compare before pulling a zone transfer
- Refresh, retry, and expire timers
- The negative caching TTL, the last field, which controls how long resolvers remember that a name does not exist
A serial that differs between authoritative nameservers tells you a secondary failed to sync.
How Do SRV and NAPTR Records Locate Application Services?
An SRV record gives a service location as priority, weight, port, and target host. Names follow a _service._protocol pattern:
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.SIP and VoIP phones, XMPP chat servers, LDAP clients, and Active Directory domain controllers all rely on SRV lookups. If a softphone registers on one network but not another, query the SRV record from both; split DNS serving a different answer internally is a frequent culprit.
A NAPTR record adds a rewrite step, translating a name or phone number into a URI or another lookup, and it sits upstream of SRV in many telephony stacks (ENUM being the classic case). You will mostly meet NAPTR in carrier SIP trunking setups.
What Are HTTPS and HINFO Records Used For?
HTTPS records (a variant of the SVCB type) let a domain advertise connection parameters before the client connects: supported protocols such as HTTP/3, alternative endpoints, and IP hints. Unlike a CNAME, an HTTPS record works at the apex, which gives it a role in aliasing the bare domain. If clients connect over HTTP/3 to some hosts and fail over to TCP on others, check whether an HTTPS record advertises h3 on an endpoint that doesn’t support it.
HINFO records describe host CPU and operating system. Publishing that publicly hands attackers reconnaissance, so treat HINFO as legacy. You will still see it occasionally, because some servers return HINFO as a minimal reply to ANY queries.
Which Records Support DNS and Certificate Security?
CAA records control which certificate authorities can issue SSL/TLS certificates for your names, DNSSEC records let resolvers verify that answers weren’t forged, and DANE ties TLS keys directly to DNSSEC-signed data. Each one adds a failure mode you need to recognize.
How Do CAA Records Restrict Certificate Issuance?
A CAA record (certificate authority authorization) lists the CAs allowed to issue for a domain. Public CAs must check it before issuing.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"The second line blocks all wildcard issuance; the third requests reports of violations.
The troubleshooting pattern: certificate renewals suddenly fail after someone adds CAA for one vendor, and an automated tool using a different CA gets refused. CAA lookups also climb the tree, so a record on example.com governs shop.example.com unless the subdomain publishes its own. When issuance fails with a CAA error, query CAA on the exact name and every parent up to the apex.
How Do DNSKEY, DS, RRSIG, NSEC, and NSEC3 Support DNSSEC?
DNSSEC builds a chain of trust from the root down to your zone using five record types:
| Record | Role |
|---|---|
| DNSKEY | Public keys for the zone (key-signing and zone-signing) |
| DS | Hash of your key-signing key, published in the parent zone |
| RRSIG | Signature over each set of records |
| NSEC | Signed proof that a name or type does not exist |
| NSEC3 | Same proof using hashed names to hinder zone walking |
Most DNSSEC outages come from a broken link between DS and DNSKEY: you change DNS providers or roll keys, and the DS at the registrar still references the old key. Validating resolvers then return SERVFAIL for the whole domain, while non-validating resolvers answer normally. That split is the signature you’re looking for.
Expired RRSIG signatures produce the same symptom. Run dig +dnssec and check the signature expiration timestamps.
Where Does DANE Fit in TLS Authentication?
DNS-based Authentication of Named Entities (DANE) publishes TLSA records containing a certificate or public key hash, so a client can confirm the server’s TLS key using DNSSEC-validated data. Its biggest real-world use is SMTP between mail servers, where it protects opportunistic TLS against downgrade attacks.
DANE only works on a DNSSEC-signed zone. The operational trap is certificate rotation: replace a mail server’s certificate without updating the TLSA record first, and DANE-enforcing senders refuse delivery. Publish the new hash alongside the old one, wait out the TTL, and then swap certificates.
How Can You Read and Troubleshoot DNS Answers?
Every DNS answer has the same five fields, and comparing what a resolver returns against what the authoritative server holds separates caching delays from zone errors. With those two skills, a symptom narrows to one record in minutes.
What Do the Name, TTL, Class, Type, and Value Mean?
Every line in a DNS zone file or lookup output reads left to right the same way:
example.com. 3600 IN A 93.184.216.34- Name: the owner of the record. The trailing dot marks it fully qualified; forgetting that dot in a raw zone file appends the zone name and creates
www.example.com.example.com. - TTL: seconds a DNS resolver may cache the answer. Repeated queries to a resolver show it counting down, proof you’re seeing a cached copy.
- Class: almost always
INfor Internet. - Type: A, MX, TXT, and so on.
- Value: type-specific data, such as an IP, a priority plus host, or quoted text.
The header matters as much as the record. A status of SERVFAIL often signals a DNSSEC validation failure or broken delegation, while NXDOMAIN means the name does not exist. NOERROR with an empty answer section means the name exists but has no record of that type. The aa flag confirms you reached an authoritative server.
How Do You Compare Resolver Answers with Authoritative Records?
Query three places and compare the results:
- Your local resolver:
dig example.com A - Public resolvers:
dig @8.8.8.8 example.com Aanddig @1.1.1.1 example.com A - The authoritative server directly:
dig @ns1.example.com example.com A
Interpret the pattern:
| Result | Meaning |
|---|---|
| Authoritative wrong | Zone error; fix the record |
| Authoritative right, public resolvers mixed | Normal propagation; wait out the TTL |
| Only your machine wrong | Local cache; flush the DNS cache |
| Authoritative servers disagree | Secondary out of sync; compare SOA serials |
Negative answers persist too. The last number in the SOA record sets the negative cache TTL, and no one can force a third-party resolver to drop a cached NXDOMAIN before it expires. A DNS propagation checker shows the same comparison across many resolvers worldwide at once.
Before planned changes, lower the TTL to around 300 seconds, wait for the old TTL to expire, then make the edit. Mistakes then clear in minutes.
Which Checks Help Isolate Website, Email, and Delegation Failures?
Map the symptom to the smallest set of queries:
Website won’t load or loads the wrong site
- Query A and AAAA; confirm both IPs serve the site
- Follow any CNAME chain hop by hop
- If the browser shows a config error, the DNS probe finished bad config walkthrough covers client-side causes
Mail bouncing or landing in spam
- Query MX, then the A record of each MX target
- Read the SPF, DMARC, and DKIM selector TXT records
- Check PTR on your sending IP
- The PacketTools SuperTool runs DNS, MX, SPF, DKIM, DMARC, blacklist, and SSL checks in one pass
Whole domain unreachable
- Run
dig +trace example.comto watch each delegation step - Compare NS at the TLD with NS at your apex
- Check DS against DNSKEY if the zone is signed
For broader client-side failures, the guides on troubleshooting DNS issues and a DNS server not responding pick up where record checks end.
Choose the Record That Matches the Failure
Start every DNS investigation with the symptom, and let it point you to one record family:
| Symptom | Records to query first |
|---|---|
| Site unreachable or wrong server | A, AAAA, CNAME |
| Root domain broken on a CDN | Flattened A/AAAA at the apex |
| Inbound mail missing | MX and the MX target’s A record |
| Outbound mail rejected or spammed | SPF, DKIM, DMARC TXT; PTR |
| VoIP or directory clients failing | SRV, NAPTR |
| Certificate issuance refused | CAA up the tree |
| SERVFAIL on validating resolvers only | DS, DNSKEY, RRSIG |
| Every record failing | NS at parent and child, SOA serials |
Then read each answer field by field: status code, aa flag, TTL, and value. Query the authoritative server before blaming propagation, and check public resolvers before blaming the zone. If the authoritative answer is correct and only caches disagree, the fix is time; if the authoritative answer is wrong, the fix is a zone edit, made after you’ve lowered the TTL so any correction spreads within minutes.
Leave a Reply