DNS & WHOIS Lookup

A and AAAA hold addresses — IPv4 from RFC 1035, IPv6 from RFC 3596 — and a name can publish both. That dual publication is worth checking deliberately, because a stale AAAA record is invisible from an IPv4-only network and a hard failure from an IPv6-only one, so it produces bug reports that nobody in the office can reproduce. MX records carry a preference number where lower is preferred, which reads backwards to most people; equal preferences distribute load between hosts.

TXT is where SPF, DKIM, DMARC, and every domain-ownership verification token end up. RFC 1035 caps a single character-string at 255 octets, so a 2048-bit DKIM public key has to be published as several quoted chunks that the verifier concatenates. This tool returns each TXT record as an array of its constituent strings, so a key appearing split across several entries is correct, not corrupted — what breaks DKIM is a chunk boundary that introduces whitespace.

CAA (RFC 8659) names which certificate authorities are permitted to issue for the domain, and CAs have been contractually required to honour it since 8 September 2017 under the CA/Browser Forum Baseline Requirements. No CAA record means any CA may issue; a record listing the wrong CA silently blocks issuance and surfaces later as an inexplicable certificate renewal failure. PTR is the reverse mapping and needs an address rather than a name — pass a hostname here and you will get an error telling you so.

RFC 1034 section 3.6.2 states that if a CNAME record is present at a node, no other data should be present there, and RFC 2181 section 10.1 restates the restriction in stronger terms. The apex of a zone necessarily carries SOA and NS records, so a CNAME at the apex is illegal by construction — there is no configuration that makes it valid.

Some providers accept one in the control panel anyway and produce a zone that resolvers handle inconsistently. Mail is the usual casualty: an MX lookup at a name occupied by a CNAME may be answered with the alias target instead, and delivery quietly stops. If you are debugging vanished email immediately after a hosting change, this is the first thing to check.

The common workarounds are provider-side synthesis rather than real record types. Route 53 ALIAS, Cloudflare CNAME flattening, and the ALIAS records offered by DNSimple and NS1 all resolve the target at the authoritative server and answer the query with plain A and AAAA records. That is why a CNAME lookup against such an apex returns nothing here even though the dashboard clearly shows an alias — the alias never leaves the provider. The ANAME internet-draft that attempted to standardise the behaviour expired without ever becoming an RFC. The standardised replacement is RFC 9460: an HTTPS record in AliasMode, written as example.com. 3600 IN HTTPS 0 svc.example.net., which aliases the apex for HTTP traffic and is explicitly allowed to coexist with other records.

Nothing propagates. A change to an authoritative zone is live the instant it is written, and no update is pushed anywhere. What you are waiting out is every recursive resolver that already holds the previous answer letting its copy expire. "DNS propagation" is a cache TTL counting down independently on thousands of resolvers that each cached at a different moment.

The scheduling consequence catches people every time: lowering a TTL only helps if you do it before the change, by at least the length of the old TTL. Dropping a record from 86400 seconds to 300 an hour before a cutover accomplishes nothing, because every resolver holding yesterday's answer will keep it for the rest of the day regardless. Reduce the TTL a full old-TTL period ahead, make the change, then raise it again once traffic has settled.

Negative answers are cached as well, and this is the one that produces genuinely baffling behaviour. RFC 2308 defines the caching duration for an NXDOMAIN or empty response as the SOA MINIMUM field, capped by the TTL of the SOA record itself. Query a name before you create it and the not-found result is pinned for that interval — so a mistyped verification record can appear broken for hours after you have already corrected it. The SOA output here includes that minttl value, which tells you exactly how long you are stuck. Note also that many resolvers clamp incoming TTLs to their own floor and ceiling, so a one-second TTL is aspirational rather than binding.

Be precise about what this lookup gives you. The query runs on our server through the system resolver, which means the answer is a recursive one and is subject to that resolver's cache. It does bypass your machine's stub cache, your browser's, and your ISP's, which is usually enough to confirm a change has taken effect somewhere other than your laptop — but it is not the same thing as reading the zone from the authority.

To do that, take a nameserver from the NS results and query it directly: dig @ns1.example.com example.com A +norecurse. An authoritative reply sets the AA flag in the DNS header, and that flag is the difference between "this is the zone" and "this is what somebody remembered." If the authoritative answer is right and the recursive answer is wrong, you have a cache waiting to expire, not a misconfiguration to fix — a distinction that saves a lot of pointless editing.

Two further splits are worth checking during a migration. First, the NS records published inside the zone should match the delegation recorded at the parent TLD; when they diverge you get a lame delegation, and resolution succeeds or fails depending on which nameserver a resolver happens to try. dig +trace walks the chain from the root and shows where they disagree. Second, a DNS response over UDP is limited to 512 bytes unless EDNS(0) is negotiated (RFC 6891); oversized TXT or DNSSEC responses set the truncation flag and force a retry over TCP, so a firewall that blocks TCP port 53 causes failures that look intermittent but actually track response size.

Since ICANN's 2018 response to the GDPR, registrant name, postal address, phone number, and email are redacted from gTLD registration records, usually replaced by an anonymised forwarding address or a web contact form. What remains public is still genuinely useful: creation, updated, and expiry dates, the sponsoring registrar and its IANA identifier, the nameservers, DNSSEC status, and the EPP status codes.

Those status codes carry the most operational signal. clientTransferProhibited means a registrar-level transfer lock is active, which is what you want on anything valuable. redemptionPeriod means the name has expired and is inside the 30-day recovery window, where restoring it costs a punitive fee. pendingDelete is the five-day stage after that, during which nothing can be done and the name is about to drop. serverHold means the registry has pulled the domain out of the zone entirely, which is why it stopped resolving.

Expect different amounts of detail per TLD, because registries follow one of two models. .com and .net are thin: the Verisign registry server this tool queries for them returns only the sponsoring registrar, the dates, the nameservers, and the status codes, and everything else lives at that registrar's own WHOIS server behind a second query. .org and most newer gTLDs are thick and return the full record from the registry. Separately, since 28 January 2025 ICANN no longer requires gTLD registries and registrars to operate WHOIS on port 43 at all, and many have switched it off; RDAP (RFC 7480, RFC 9082, and RFC 9083) now serves the same data as JSON over HTTPS. An empty WHOIS result for a newer gTLD usually means the port-43 server has been retired rather than that the domain is unregistered.