What's the difference between A and AAAA records?

A maps a name to an IPv4 address; AAAA maps it to IPv6. A name can have both — if one family fails to resolve, clients with only that family can't connect.

Why does my TXT record show up split into multiple strings?

TXT records are limited to 255 characters per string. Long values (SPF, DKIM keys, domain verification tokens) are split into multiple quoted strings that receivers concatenate.

What does TTL mean when I read it?

Time To Live — seconds a resolver may cache the answer. High TTLs (3600+) make lookups fast but slow propagation; low TTLs (60–300) are for records you change often.

DNS Lookups for Debugging: A, AAAA, MX, TXT & More

A field guide to DNS record types and the queries that debug them — A, AAAA, CNAME, MX, TXT, NS, SOA — with real output shapes and TTL reading.

DNS is the first thing that breaks and the last thing people check. The site "isn't deployed", the email "doesn't arrive", the API "doesn't resolve" — and nine times out of ten, dig or its web equivalent answers in under a second.

The DNS Lookup tool returns every record family for a domain in one call. This guide is the decoder ring for its output.

A and AAAA: where the site actually lives

"A": [{ "address": "93.184.216.34", "ttl": 300 }],
"AAAA": [{ "address": "2606:2800:220:1:248:1893:25c8:1946", "ttl": 300 }]

A — IPv4. If it's missing, the domain has no IPv4 host and roughly half the internet can't reach it.
AAAA — IPv6. Absence is normal for small sites; presence with a broken path is worse than absence.

Debugging move: if A resolves but the site still times out, the problem is not DNS — it's routing, firewall, or the server itself.

CNAME: the redirect of DNS

"CNAME": ["www.yourdomain.com."]

A CNAME points a name at another name — the resolver follows it until it reaches A/AAAA records. Debugging move: a CNAME loop (a → b → a) is a classic misconfiguration that produces "server not found" errors that look like the internet is broken.

MX: where mail goes

"MX": [{ "priority": 10, "exchange": "mx1.yourdomain.com." }]

Lower priority wins. Debugging move: when mail "disappears", check MX first — then check that the exchange hosts have A records (a mail server pointing at an unresolvable hostname is a silent black hole).

TXT: the record that's actually a database

"TXT": ["v=spf1 include:_spf.google.com ~all", "google-site-verification=..."]

TXT carries everything that isn't addressing: SPF policies, DKIM keys, domain verification tokens, DMARC policies, MTA-STS announcements. Debugging move: long TXT values come back split into multiple quoted strings — when you paste them into your DNS provider, make sure you're pasting the concatenated value, not one fragment.

NS and SOA: who's authoritative

"NS": ["ns1.yourdomain.com.", "ns2.yourdomain.com."],
"SOA": ["ns1.yourdomain.com. hostmaster.yourdomain.com. serial=2026080801"]

NS lists the authoritative nameservers. SOA carries the serial number — the version counter of your zone. Debugging move: if a change "didn't propagate", check whether the SOA serial actually incremented. If it didn't, secondary nameservers will never pick up your update, no matter how long you wait.

Reading TTLs like an operator

Every answer carries a TTL — the number of seconds resolvers are allowed to cache it:

TTL 60–300: deliberately volatile (failover DNS, record you're about to change).
TTL 3600+: stable records. Changes to them take up to the TTL to propagate everywhere.

Debugging move: before changing a record you'll need to move fast, lower its TTL a day in advance. Change the TTL before the content, wait, then change the content.

One call for everything

curl -X POST https://yas.sh/api/v1/tools/dns-lookup -d '{"input":"yourdomain.com"}'

returns A, AAAA, MX, TXT, NS, CNAME and SOA in one JSON response — the same data a stack of dig commands gives you, in a shape scripts can parse. DNS is the most reliable debugging tool on the internet. The trick is asking it the right questions.

A practical debugging sequence

When something is wrong, run the checks in a consistent order so you can rule layers out methodically rather than guessing:

Resolve the name. Confirm the A/AAAA records exist and point somewhere. If resolution fails entirely, the problem is likely missing or wrong records, or a registrar/authoritative-server issue.
Check propagation. After any DNS change, confirm the new value is visible from an external resolver, not just from your cached machine. The tool queries authoritative answers so a stale local cache does not mislead you.
Verify mail records. For email problems, look at MX (where mail should go) and the TXT records for SPF, DKIM, and DMARC. A missing or malformed MX stops mail; a broken SPF or missing DMARC explains why mail lands in spam. See the MX health guide and email authentication guide for the deeper reads.
Confirm the server actually answers. If DNS is correct but the service is still down, the problem has moved past DNS to routing, the firewall, or the server itself.

Running these four checks in order converts "the site is down" into a precise diagnosis in under a minute.

Common DNS failure patterns

A few patterns account for most real-world DNS incidents:

TTL left high before a change. A long TTL means old answers linger for hours after you update. Lower the TTL well before the change so the new value propagates quickly.
Wrong record type used. Pointing a CNAME at a host that expects an A, or putting mail delivery on an A record where MX is required, silently breaks the use case.
Conflicting or duplicate records. Two SPF records, or an SPF record that exceeds the DNS lookup limit, makes the whole authentication fail.
Registrar vs provider confusion. A record that looks right in your DNS provider but was never configured at the registrar never resolves publicly.

Knowing these patterns tells you what to look for before you even query.

Using DNS for the link-infrastructure angle

DNS sits underneath a custom short-link domain too: when you wire go.yourbrand.com to a shortener, the CNAME or A record is what makes it resolve, and the propagation delay is why you schedule DNS changes before a launch. The same checks that debug a website — resolve, propagate, verify — apply to making sure your branded short links come up on time and keep working. The custom domains guide walks that specific setup.

In short, DNS answers most "why isn't this working" questions faster than anything else. Run the four checks in order — resolve, propagate, verify mail records, confirm the server answers — and you convert a vague outage into a precise, fixable diagnosis in under a minute.

Reading SOA and NS for deeper diagnosis

Two record families tell you who is authoritative and how fresh the data is. The NS records show which name servers are authoritative for the domain — useful when you suspect a change was made at the wrong provider. The SOA record's serial number and refresh fields tell you whether the zone is being served from an updated copy. When resolution works locally but not externally, checking NS and SOA often reveals a propagation or authority problem that the A record alone cannot.

Conclusion

This guide covered the practical essentials of dns lookup debugging guide. Apply the discipline, test before relying on it, and revisit when your needs change.