Tactical Intelligence Protocol

DNS Record Checker & Lookup.

Instantly query any domain for the records that matter — A, AAAA, MX, TXT, CNAME, NS, SPF, DMARC, DKIM. Built for MSP-led infrastructure audits and zero-downtime migrations.

language
list A, MX, TXT, CNAME, NS, AAAA expand_more
dns expand_more
dns

Run a query to see live DNS records.

Type a domain above, pick the record types you care about, and run the query. Results appear here as a sortable table — Hostname, Type, TTL, Class, Value.

Why MSPs Need to Audit Client DNS

For Managed Service Providers, DNS is the bedrock of connectivity and security. Misconfigured DNS records are the leading cause of deliverability issues, website downtime, and sophisticated phishing attacks like DNS hijacking. Regular audits catch drift before it becomes a client-facing incident.

  • check_circle Prevent domain spoofing by auditing SPF, DKIM, and DMARC records regularly.
  • check_circle Validate CNAME and A records during migration to ensure zero-downtime cutovers.
  • check_circle Catch nameserver drift on inherited or recently-acquired client domains.
  • check_circle Surface unauthorized record changes before they break client email.

Critical Record Types

MX Record MAIL

Specifies the mail servers responsible for receiving email on behalf of a domain. Priority + hostname pairs.

TXT Record DATA

Used for human-readable notes and machine-readable data like SPF and DKIM signatures. Where DMARC lives.

CNAME Record ALIAS

Maps an alias name to a true or canonical domain name. Used widely for SaaS subdomain setups.

A Record IPv4

Maps a domain to a 32-bit IPv4 address. The fundamental host record on the modern web.

NS Record AUTH

Identifies the authoritative nameservers for the zone. Drift here means the zone has moved.

What is a DNS Lookup?

A DNS Lookup is the process by which a computer or server queries the Domain Name System to translate a human-friendly domain name (like example.com) into a machine-readable IP address or a specific service record. Think of it as the "phonebook of the internet."

In an enterprise context, DNS Lookups are critical for troubleshooting infrastructure. Whether it's verifying that a global load balancer is pointing to the correct edge node or ensuring that a new mail provider's validation records have propagated, manual lookups are a staple of network engineering.

auto_graph Advanced Monitoring for MSPs

Manual lookups are reactive. DMARC AI provides proactive monitoring of every client zone — surfacing record changes the moment they happen, before they become deliverability incidents.

How DNS resolution actually works

When you query a domain, your request travels through four layers of the DNS hierarchy. Understanding the chain is what separates "the record isn't showing up" troubleshooting from "the propagation is in progress" patience. Every hop has its own cache, its own TTL, and its own way of failing silently.

1

Recursive resolver

Your operating system asks its configured resolver (usually 1.1.1.1, 8.8.8.8, or the ISP's default). The resolver checks its cache first. If the answer is fresh enough (within TTL), you get it immediately — no further hops.

2

Root server

On a cache miss the resolver asks one of the 13 root server clusters. The root tells it "for .com queries, ask one of these TLD servers." Root answers don't change; their NS records are baked into the resolver code.

3

TLD server

The resolver then asks the .com TLD server "who hosts example.com?" The TLD returns the authoritative nameservers — typically two NS records configured at the domain registrar.

4

Authoritative server

Finally the resolver asks the authoritative nameserver directly: "what's the A record for example.com?" That answer is canonical. The resolver caches it for the TTL and returns it to your client.

Every DNS record type, explained

Type Description
A Maps a hostname to an IPv4 address. The fundamental record on the modern web; almost every domain has at least one A record at the apex.
AAAA Maps a hostname to an IPv6 address. Increasingly required as ISPs and mobile carriers prefer v6. Coexists with A; clients pick based on their stack.
MX Specifies mail servers responsible for receiving email at the domain. Multiple MX records use the priority value to determine order — lower number = higher priority.
TXT Free-form text record. Used for SPF, DMARC, DKIM, BIMI, MTA-STS, domain verification challenges, and arbitrary site-ownership proofs.
CNAME Maps an alias hostname to a canonical hostname. Cannot coexist with other records at the same name (RFC 1034). Widely used for SaaS subdomain wiring.
NS Identifies the authoritative nameservers for the zone. Changes here mean the DNS is moving — drift detection here catches unauthorized provider changes.
SOA Start of Authority — one per zone. Contains the primary nameserver, the responsible-party email (with @ replaced by .), the serial number, and refresh/retry/expire/minimum TTL values.
SRV Specifies the hostname and port for a specific service. Used by SIP, XMPP, Microsoft AD (_kerberos._tcp), and modern auto-discovery protocols.
CAA Certificate Authority Authorization. Tells public CAs which issuers are allowed to issue certificates for the domain. Required check by all CAB-Forum members since 2017.
PTR Reverse DNS — maps an IP back to a hostname. Critical for outbound mail server reputation (forward-confirmed reverse DNS, FCrDNS).

Common DNS audit issues and how to spot them

Most DNS incidents trace back to one of about a dozen recurring patterns. Skim the list — if a client domain matches any of these, you have a concrete remediation to quote.

critical Multiple SPF records on the same hostname expand_more
Symptom
Two or more TXT records starting with v=spf1 at the apex.
Fix
RFC 7208 says receivers must treat this as PermError and reject. Merge into one record with combined include: clauses.
critical SPF exceeds 10 DNS lookups expand_more
Symptom
Long include chains; receivers return PermError or refuse to evaluate.
Fix
Flatten SPF via a service like ours or manually consolidate. Or move marginal senders to subdomain SPFs.
high CNAME at the apex expand_more
Symptom
Domain registrar refuses to save the CNAME at the root.
Fix
RFC 1034 forbids CNAME alongside SOA / NS at the same name. Use an ALIAS record (Route 53, Cloudflare) or flatten to A records.
high DMARC record missing the p= tag expand_more
Symptom
TXT at _dmarc starts with v=DMARC1 but no policy declaration.
Fix
Add at minimum p=none. Without p=, the record is syntactically invalid and many receivers ignore it.
high DKIM public-key TXT exceeds 255-octet limit expand_more
Symptom
Receivers report signature verification failure; the record is split across multiple strings but not properly concatenated.
Fix
Most DNS providers handle the 255-char split automatically. If yours doesn't, contact support — manual splitting needs precise concatenation.
medium NS records drifted from registrar configuration expand_more
Symptom
Your DNS provider says one thing; dig on the registrar TLD returns another.
Fix
Change the NS at the registrar and wait for TLD propagation (24–48h). NS changes at your DNS provider are advisory only — the TLD is canonical.
medium Conflicting MX priorities expand_more
Symptom
Two MX records with the same priority number — receivers pick randomly.
Fix
Choose deliberately. If you want true load balancing, give them the same priority intentionally. If you want primary + backup, differentiate (10 + 20).
medium TTL set absurdly high during migration expand_more
Symptom
You changed a record; days later, some users still get the old answer.
Fix
Lower the TTL to 300–600 seconds at least 24h before a planned migration. Bump it back up after the cutover stabilises.
low No CAA record expand_more
Symptom
Any public CA can issue a certificate for your domain.
Fix
Add CAA at the apex restricting which issuers are authorized. Adds a layer of protection against rogue or compromised CAs.

TTLs, caching, and what "propagation" actually means

There is no global DNS that "propagates" changes. Every change at the authoritative nameserver is immediate. What people call propagation is the time it takes for the *previous answer* to age out of every recursive resolver and OS-level cache between users and your server. That clock starts ticking the instant you publish — and runs for as long as the old TTL said it would. The strategy that actually works: lower TTLs 24–48h before a planned change, make the change, wait for the old TTL to expire across the population, then raise TTLs back up. Anything less, and you get the classic "it works for me, broken for some users" pattern that drags on for days.

DNS Lookup vs `dig` vs `nslookup`

Feature DNS Lookup dig nslookup
Authoritative results yes with +trace limited
TTL displayed yes yes partial
SPF / DMARC parsed view yes no (raw TXT) no
DKIM selector probing yes manual per-selector manual per-selector
Cross-resolver comparison roadmap with @<resolver> with server <ip>
Works without a terminal yes no no
Audit log (when signed in) yes no no

DNS Lookup FAQ

How fresh are the records you return? expand_more
Queries go directly to authoritative DNS via the recursive resolver our server uses — no internal cache. TTL is shown so you can see how long each record will be valid at downstream resolvers.
Do you support DNSSEC validation? expand_more
The lookup tool surfaces DS / RRSIG records when requested but does not perform full DNSSEC chain validation. Use a dedicated DNSSEC verifier (e.g. dnsviz.net) for that.
Can I look up DKIM records? expand_more
Yes — pick TXT and enter the full selector hostname (selector1._domainkey.example.com). The tool also auto-probes 8 well-known selector names (selector1, selector2, google, k1, k2, default, mandrill, dkim) when you query a bare domain.
How is this different from `dig`? expand_more
Functionally similar but with three additions: a parsed view of SPF/DMARC/DKIM TXTs, no terminal required, and an audit log when signed in. dig is unbeatable for ad-hoc deep diagnostics; this is built for MSP-style portfolio audits.
Why are some record types disabled by default? expand_more
A/AAAA/MX/TXT/CNAME/NS cover ~95% of audit needs. SOA, SRV, CAA, PTR are available but off by default to keep results focused. Toggle them on for the deeper queries.
Does the tool follow CNAME chains? expand_more
It returns the CNAME row as-is. To follow the chain, query the target hostname in a second lookup. Most chain issues are visible from the first hop anyway.
Can I query a specific resolver? expand_more
Not yet. Resolver-specific lookups are on the roadmap — useful for diagnosing CDN edge caching or Cloudflare 1.1.1.1 vs Google 8.8.8.8 mismatches. For now, use dig @resolver-ip for that.
Are queries logged? expand_more
Anonymous queries are not stored. When signed in, queries appear in your audit log so you can review what was checked when — useful for compliance and engagement billing.

Monitor every client zone, every change.

DNS Lookup is a one-shot snapshot. Sign up to get continuous zone monitoring across your entire client portfolio — alerts on record changes, drift detection, propagation tracking.