Look up a domain's DNS records

What these records do

DNS is the system that turns a domain name into the information a client needs to reach a service. The records below are the ones you will actually encounter.

• A and AAAA point a name at an IPv4 and IPv6 address respectively. These are what make a website load.
• CNAME aliases one name to another. It cannot coexist with other records at the same name, which is why it cannot be used at the zone apex — the bare domain — a restriction that surprises people constantly.
• MX directs mail for the domain, with a priority number. It must point at a hostname with an A or AAAA record, never at a CNAME.
• TXT holds arbitrary text, in practice mostly SPF, DKIM, DMARC, and verification tokens for third-party services.
• NS lists the authoritative nameservers for the zone, and SOA holds the zone's administrative parameters.
• CAA specifies which certificate authorities may issue certificates for the domain — a genuinely useful control that very few domains set.

TTL and the propagation myth

Every record carries a TTL, or time to live, in seconds. It tells resolvers how long they may cache the answer before asking again. That is the whole mechanism. Nothing propagates and nothing is pushed anywhere: authoritative servers update immediately, and what takes time is the expiry of answers already cached elsewhere.

The received wisdom that DNS changes take twenty-four to forty-eight hours is a rule of thumb from an era of much longer default TTLs, and it misleads people into waiting when they should be diagnosing. If a record's TTL is 300 seconds, resolvers holding the old answer re-query within five minutes. If it is 86,400 seconds, no amount of impatience shortens it — and lowering the TTL after the change does nothing for resolvers already holding the old value. Lower the TTL first, wait out the old TTL, make the change, then raise it again.

Negative answers are cached on a separate clock, governed by the minimum field in the zone's SOA record. This is why a newly created record can appear to be missing for a while even though it is live and correct — the resolver cached the answer that it did not exist. Nameserver changes at the registry are a third case again, governed by the parent zone's TTL rather than yours.

Three things to check when the site is down

Most outages that look like DNS problems are visible in a single lookup, and they fall into three shapes.

• Nothing resolves at all. If the lookup returns no address record, establish whether the domain is even in the DNS. A status of inactive means no nameservers are delegated; clientHold or serverHold means the domain has been deliberately removed from the zone by the registrar or registry, usually for expiry, unverified contact details or an unpaid invoice. In all three cases the problem sits upstream and no amount of editing records will fix it.
• It resolves, but to the wrong place. Compare the authoritative answer shown here against what your own machine is doing. If this tool shows the correct address and your browser does not, you are looking at a cache — yours, your resolver's, or your operating system's — and the TTL tells you how long it lasts. If this tool shows the wrong address, your change was not applied to the zone actually being served, which is the third case.
• The NS records point somewhere you did not expect. The most common self-inflicted outage of the three: somebody edits A records in the registrar's DNS panel while the delegation points at a hosting provider, or the reverse. Everything looks correct in the interface being used and none of it is served, because that zone is not the one resolvers consult.

For mail, three failures account for most of it: no MX record, in which case senders fall back to the address record and mail lands somewhere nobody reads; an MX record pointing at a CNAME, which is not permitted and fails inconsistently; and SPF, DKIM or DMARC records never recreated after a migration, which does not stop mail leaving but does stop it being delivered.

What a missing or wrong CAA record does

A CAA record declares which certificate authorities may issue TLS certificates for your domain, and the check has been mandatory for publicly trusted CAs since 8 September 2017. The search climbs the name tree from the label upwards, stopping short of the root, so a policy set at the apex is inherited by subdomains unless one of them overrides it.

No CAA record means no constraint: any publicly trusted CA may issue for the domain. That is the default state for most domains and it is not an error. The problems come from a record that is wrong rather than from having none.

• Omitting a CA you depend on. The classic failure, and the CA you forget is usually the automated one behind your CDN, load balancer or hosting platform, which you never think of as a certificate authority. Issuance fails silently at renewal and the first symptom users see is an expired certificate.
• Forgetting that wildcards are governed separately. The issuewild tag controls wildcard issuance and takes precedence over issue. A policy authorising your CA for ordinary certificates can still block the wildcard you need.
• Publishing a prohibition by accident. An issue value of a lone semicolon forbids all issuance for the name.

Set the iodef tag as well, giving the CA somewhere to report requests that violate your policy. And be clear about the limits: CAA is not enforced by browsers, does not prevent an authorised CA from mis-issuing, and without DNSSEC offers only limited protection against an attacker able to spoof DNS answers to the CA.

Reading the NS records

The NS records answer the question that determines where every other change has to be made: who actually serves this zone. The hostnames usually make it obvious.

• Registrar-branded nameservers mean the domain is on the registrar's bundled DNS, and records are edited in the registrar's panel. That is one fewer account to manage, at the cost of coupling your DNS to your registrar, whose DNS quality and redundancy vary considerably.
• Provider-branded nameservers mean a third-party DNS host, CDN or hosting company holds the zone. The registrar then controls only the delegation, and its own DNS panel — which still exists and still accepts edits — is serving nobody.
• Nameservers on the domain's own name mean self-hosting or a white-labelled service, and require glue records at the registry to resolve at all.

Two sets of NS records exist — the delegation published by the parent zone at the registry, and the NS records inside your own zone — and they should agree; where they do not you have a lame delegation and resolvers give inconsistent answers. An NS record must also point at a real hostname, never at an alias.

The security consequence is the one people miss. However well the DNS host is secured, whoever controls the registrar account can repoint the delegation and move the entire zone. The registrar account is upstream of everything in this lookup.

What a lookup will not show you

This tool queries public DNS over HTTPS and returns what a resolver on the open internet sees. It will not show records that exist only in a split-horizon internal view, and it will not show what your own machine has cached. If a result here disagrees with what your browser is doing, your local cache is the first thing to suspect.