myip
🇬🇧 EN

DNS lookup

All common record types for a domain, in one query.

What a DNS lookup actually shows you

The domain name system is the layer that turns names people can remember into the addresses machines actually use. It was described in 1987 in RFC 1034 and 1035, and the design has held up so well that almost everything added since — mail routing, certificate authorisation, mail authentication, service discovery — was bolted on as new record types rather than a new system.

A lookup asks for the records attached to a name. This page asks for the common types in one go, which is the useful way to do it: nearly every real problem shows up as a disagreement between record types rather than inside one. Mail failing while the website is fine is an MX question. A certificate that will not renew is a CAA question. A site that works for some people and not others is usually an A-versus-AAAA question.

One caveat before you read anything else: what you see here is what our resolver was told, just now. If a record was changed recently, resolvers around the world will still be serving the old answer until their cached copy expires. That is not us being out of date — it is how the system is supposed to work, and the section on TTL explains how to predict it.

The record types, and what each one is for

A and AAAA
The addresses a name points to: A for IPv4, AAAA for IPv6. Several of each is normal and means either simple load sharing or a delivery network. If a name has both and something is unreachable over one of them, you get the classic "works for me" split — see the IPv6 test for why the browser's choice matters.
CNAME
An alias: "this name is really that name, go and ask again". The rule that catches everyone is that a name with a CNAME can have no other records, which is why a CNAME is not allowed at the top of a domain — you cannot alias example.com itself, only www.example.com. Providers work around this with something usually called ALIAS or flattening, which resolves the target for you and answers with plain addresses.
MX
Where mail for the domain goes. Each entry carries a preference number and the lower number wins — a common and expensive misreading. A domain that sends no mail at all should say so explicitly with a single "null" entry, a lone dot at priority zero, which tells senders to stop rather than to keep retrying for days.
NS
The authoritative servers for the zone. Compare these with what the registry publishes in the domain's registry record: when the two disagree, part of the world reaches one set of servers and part reaches another, and the symptoms are maddeningly intermittent.
TXT
Free-form text, in practice the place where mail policy lives. SPF sits here at the top of the domain, DKIM keys under a selector name, and DMARC under _dmarc. Also where domain-ownership verification strings from every service you have ever signed up to accumulate.
SOA
The zone's own metadata: which server is primary, the serial number that secondaries watch to know a change happened, the refresh and retry timers, and the negative-caching time that decides how long "this name does not exist" is remembered.
CAA
Which certificate authorities are permitted to issue for the domain. Since September 2017 every public CA is required to check it before issuing, which makes this the one DNS record that can block a certificate outright.
SRV
Service discovery: which host and port run a given service. Used heavily by chat, voice and directory protocols, and by Microsoft environments in particular.

TTL, and why "DNS propagation" is the wrong phrase

Every record carries a time-to-live in seconds. It is an instruction to caches: keep this answer for this long before asking again. Nothing is pushed anywhere. When people say a change is "propagating", what is actually happening is that resolvers around the world are still holding an answer they were given permission to hold, and will fetch the new one when it expires.

This makes the delay predictable rather than mysterious, and it makes the standard procedure obvious: lower the TTL before you make a change, not after. Drop it to a few minutes, wait for the old, long TTL to expire everywhere, then make the change, then raise the TTL again once the new value has settled. Skip that first step and you are committed to waiting out whatever value was published — which for a comfortable 24-hour TTL means a day of two different answers circulating.

Negative answers cache too. If somebody looks up a name before it exists, the "does not exist" answer is remembered for the period set in the SOA record, so creating the name does not immediately fix it for that person. This is behind a good share of "I added the record and it still does not work" reports.

Mail records: the part that breaks most often

If mail is the problem, four records decide almost everything, and they are checked in this order by the receiving system.

  1. MX — where to deliver. No MX at all means senders fall back to the domain's A record, which is usually a web server and usually not what anyone intended.
  2. SPF, a TXT record starting v=spf1 — which servers may send on the domain's behalf. There must be exactly one; two SPF records is a permanent error, not a merge. It also has a hard limit of ten DNS lookups during evaluation, and stacking several include: statements from different mail vendors quietly blows past it. Everything after that fails regardless of how correct it looks.
  3. DKIM — the public key that verifies the signature on outgoing mail, published under a selector chosen by the sending system.
  4. DMARC, a TXT record at _dmarc — what a receiver should do when SPF and DKIM disagree with the visible From address, and where to send reports about it. Publishing it with a policy of none is the correct first move: it changes nothing about delivery and starts the reports that tell you who is sending as you.

If mail is being rejected rather than misrouted, the records may be fine and the sending address may be the problem instead — that is a question for the blocklist check and for the reverse name on the address.

Failures, and how to tell them apart

The name does not exist (NXDOMAIN)
Authoritative and definite: no such name in the zone. Check spelling, then check whether you created the record in the zone you think you did.
The name exists but has no records of that type
Different thing entirely, and it is the normal answer when you ask for AAAA on a name that only has IPv4. Not an error.
Server failure (SERVFAIL)
The resolver could not get a usable answer. Two ordinary causes: the authoritative servers are unreachable, or DNSSEC validation failed — an expired signature takes a zone off the internet completely for anyone validating, while continuing to work perfectly for anyone who does not.
A timeout with no answer at all
Often a network or firewall problem rather than a DNS one. Large answers can exceed what fits in a single UDP packet and require a fall back to TCP, and equipment that blocks DNS over TCP produces failures that look random and affect only some domains.

Two checks worth doing every time

Do the NS records match the registry? The delegation at the registry is what the rest of the world follows; the NS records inside the zone are what the zone claims about itself. Old nameservers left behind after a migration keep answering with old data, and because resolvers pick between them, the result is that a site appears to work for half your colleagues.

Do the addresses point where you think? Look up the A and AAAA records, then check who runs those addresses. A record still pointing at a hosting provider you left two years ago is a common and quietly dangerous finding — the name is delegated to infrastructure you no longer control, and anyone who takes over that address inherits the name.

Frequently asked questions

I changed a DNS record. Why does the old one still show?

Because every record carries a time-to-live, and resolvers are entitled to keep the previous answer until it expires. Nothing is pushed out to anyone — the word "propagation" describes caches expiring, not data travelling. If the old record had a TTL of 24 hours, some resolvers will keep serving it for 24 hours. The way to avoid this is to lower the TTL a day before a planned change, not after it.

What is the difference between an A record and a CNAME?

An A record gives an address directly. A CNAME says "this name is an alias for that name, ask again there". The consequence that catches people is that a name with a CNAME cannot have any other records, which is why you cannot put one at the top of a domain — example.com itself cannot be a CNAME, only www.example.com can. Hosting providers work around this with a feature usually called ALIAS or flattening.

Which MX record is the primary one — the highest number or the lowest?

The lowest. The number is a preference, not a rank, and senders try the smallest value first, moving to higher ones only if it does not answer. Equal numbers mean the load is shared between those servers. If a domain sends and receives no mail at all, the correct thing to publish is a single null MX — a lone dot at priority zero — which tells senders to give up immediately instead of retrying for days.

The lookup returns nothing for AAAA. Is something wrong?

No. It means the name has no IPv6 address, which is still true of a large share of the internet. That is a different result from "the name does not exist", and both are normal answers rather than errors. It only matters if you expected IPv6 to work — a name with no AAAA record is simply never reached over IPv6.

Why do I get SERVFAIL for a domain that works in my browser?

The two most common causes are unreachable authoritative servers and failed DNSSEC validation. The second one is worth knowing about: when a zone's signatures expire, every resolver that validates refuses to answer while every resolver that does not validate keeps working normally. The result is a domain that is completely dead for some people and completely fine for others, which is why the reports never agree.

How many SPF records should a domain have?

Exactly one. Two SPF records do not merge — they are a permanent error, and receiving systems treat the result as unusable. There is also a limit of ten DNS lookups while evaluating one, and chaining several include: statements from different mail providers exceeds it quietly, after which the record fails no matter how correct it looks when you read it.

What does a CAA record do?

It names the certificate authorities allowed to issue certificates for the domain. Since September 2017 every public authority has been required to check it before issuing, so a CAA record left over from a provider you no longer use will block a new certificate outright — a failure that looks like a problem with the certificate authority and is not.

Whose view of DNS is this — mine or yours?

Ours. The query is sent from our resolver, so you are seeing what the authoritative servers tell us at this moment. If your own computer gets a different answer, the usual reasons are a cached older record on your side, a resolver run by your provider that answers differently, or a local hosts file overriding the name entirely.

Related checks