DNS & Infrastructure 12 min read

DNS Record Lookup Guide

Use this guide to understand what the DNS Record Lookup is inspecting, why individual record types matter, and how to fix redundancy, mail-authentication, and issuance-policy gaps without breaking live resolution.

Overview

DNS is the routing layer for the website, email, and certificates. The lookup is trying to confirm that address records resolve, name servers are redundant, mail-authentication records are coherent, and issuance policy exists, because each gap turns into availability or spoofing risk later.

Records to review together

  • A / AAAA: Confirm the apex and www both resolve so users and integrations reach the site reliably.
  • NS / SOA: Keep at least two name servers and a sane SOA so the zone survives provider issues.
  • TXT / CAA: Keep one SPF record, a DMARC policy, and a CAA policy so mail and certificates stay controlled.

DNS Record Signals and Meaning

RecordHealthy stateCommon weakness
A / AAAAApex and www resolve to current infrastructureMissing address records or stale IPs after migrations.
MXPoints at the active mail providerOrphaned MX hosts from a previous provider.
NSTwo or more name servers on separate infrastructureA single name server creating a resolution single point of failure.
TXT (SPF)Exactly one SPF record covering real sendersDuplicate or conflicting SPF records that break authentication.
CAAPolicy authorizing only the CAs in useNo CAA record, so any public CA may issue certificates.

Practical Zone Examples

Redundant name servers
example.com.  IN NS ns1.dnsprovider.com.
example.com.  IN NS ns2.dnsprovider.com.
Single SPF record
example.com.  IN TXT "v=spf1 include:_spf.google.com ~all"

Recommended Remediation Flow

  1. Inventory the intended zone List what the domain should serve: web hosts, mail provider, and subdomains, before editing records.
  2. Fix availability gaps first Restore missing A/AAAA records and add a second name server before tuning policy records.
  3. Consolidate mail authentication Merge duplicate SPF records into one and publish a DMARC policy that matches real mail flow.
  4. Add issuance policy and retest Publish CAA records for the CAs you use, then re-run the lookup to confirm the zone matches intent.

Troubleshooting Common Issues

Changes do not appear in the lookup

DNS edits propagate on TTL boundaries, and some providers cache aggressively.

  • Wait for the record TTL to expire before retesting.
  • Confirm the edit was made on the authoritative provider, not a stale secondary.
  • Lower TTLs before planned migrations so future changes propagate faster.
Multiple SPF records keep reappearing

Different teams or tools often add their own SPF entries instead of editing the existing one.

  • Merge all mechanisms into a single v=spf1 record.
  • Assign one owner for mail-related DNS changes.
  • Document which include corresponds to which sending service.

Validation Checklist

Post-fix validation

  • Confirm the apex and www both resolve over IPv4 (and IPv6 if supported).
  • Verify at least two name servers respond authoritatively for the zone.
  • Check that exactly one SPF record exists and a DMARC policy is published.
  • Run the DNS Record Lookup again and compare results against the intended zone design.

FAQ

Do I need IPv6 (AAAA) records?

They are increasingly expected, but only publish them if the infrastructure actually serves IPv6 traffic.

  • Publishing AAAA records for hosts that do not listen on IPv6 causes intermittent failures.
  • Most CDNs and major hosts provide IPv6 automatically.
  • Test IPv6 reachability before and after publishing.
Is one name server ever acceptable?

No for production domains. A single name server makes DNS a single point of failure.

  • Use at least two name servers, ideally on separate networks.
  • Managed DNS providers include redundancy by default.
  • Verify both servers return identical zone data.