DNS Record Validator: Catch Syntax Mistakes Before They Propagate
A malformed DNS record can take hours to notice and hours more to fix, thanks to caching and propagation delays across resolvers worldwide. This validator checks the syntax of common record types — A, AAAA, CNAME, MX, TXT, NS, SRV, CAA — against their expected format before you commit them to a zone.
Syntax validation only — this doesn't perform a live DNS lookup.
Why DNS Mistakes Are Expensive to Fix
DNS records are cached by resolvers around the world according to their TTL, which means a typo doesn't just break immediately — it can take minutes to days for a correction to fully propagate, depending on how long the bad record was cached before you noticed. Catching a syntax error before publishing avoids that entire propagation delay.
Multi-Field Record Types Are Where Mistakes Hide
A/AAAA/CNAME records are simple — one value, one clear format. MX, SRV, and CAA records pack multiple fields into a single value (priority, weight, port, target, flags, tags), and it's easy to swap field order, use the wrong data type for a field, or forget one entirely. This validator checks field count and type for each of these structured record types specifically.
TXT Records and the 255-Character Boundary
DNS's underlying protocol limits a single TXT string to 255 characters — longer values (common for things like DKIM keys) are represented as multiple concatenated quoted strings. If you're manually writing a long TXT value, this validator flags when you've crossed that boundary so you know to split it.
Practical Examples
Validating an MX Record
Checking both priority and target format.
- 1.Input: 10 mail.example.com
- 2.Priority: 10 (valid, 0-65535)
- 3.Target: mail.example.com (valid hostname)
Catching a Malformed CAA Record
A common tag mistake.
- 1.Input: 0 issued "letsencrypt.org"
- 2.Error: Tag "issued" should be one of: issue, issuewild, iodef
- 3.Fix: 0 issue "letsencrypt.org"
Record Types Supported
- A / AAAA: IPv4 / IPv6 address format
- CNAME / NS: hostname format
- MX: priority + hostname
- TXT: quoting and length
- SRV: priority, weight, port, target
- CAA: flag, tag, value
Good Use Cases
- Double-checking a record before adding it to a DNS provider's dashboard
- Validating records generated programmatically before applying them
- Learning the exact expected format for a less-common record type
- Catching a typo'd MX priority or SRV field order
Frequently Asked Questions
Does this actually look up my DNS records?
No — this checks the syntax of a record value you type in, before you add it to your zone. It doesn't perform a live DNS query, since that requires network access this client-side tool deliberately doesn't use.
Why does an MX record need a priority number?
Priority (lower number = higher preference) tells mail servers which mail exchanger to try first when multiple MX records exist for a domain — it's what makes backup/fallback mail servers possible.
Why are TXT records shown with quotes?
DNS zone file syntax conventionally wraps TXT record values in double quotes, and most DNS providers' web interfaces expect (or automatically add) them. A TXT value longer than 255 characters gets automatically split into multiple quoted strings by the DNS protocol itself.
What are SRV records used for?
SRV records specify the host and port for a specific service (like SIP, XMPP, or Minecraft servers) using a service-specific format: priority, weight, port, and target hostname — used when a service needs more than just an IP address to be located.
What does a CAA record actually restrict?
Certificate Authority Authorization records specify which certificate authorities are allowed to issue TLS certificates for your domain, reducing the risk of an unauthorized CA mistakenly or maliciously issuing a certificate for your domain.
Is my DNS data sent anywhere?
No, validation happens entirely in your browser via regex and format checks — no DNS queries, no upload.