DNS lookup

What this tool does

Resolves the A, AAAA, CNAME, MX, TXT and NS records for a hostname from a public recursive resolver and lists each record with its TTL where the resolver gives us one, which is the A and AAAA rows. It asks the same way a browser or a mail server would, so what you see here is close to what they will see.

That last point is the whole reason a tool like this exists. You can read your own DNS settings in your host's control panel at any time, but the panel shows what you have asked for. This shows what the internet is currently being told, and the gap between those two is where most DNS problems live.

What each record type is for

A and AAAA point a name at an address — IPv4 and IPv6 respectively. A name can have several of each, and resolvers will spread traffic across them, which is the cheapest form of load balancing there is.

CNAME aliases one name to another. It has a rule that trips everyone up at least once: a name with a CNAME cannot carry any other record. That is not a vendor restriction, it is the DNS specification, and it is why a bare domain can never carry a CNAME: the apex has to hold its own SOA and NS records, and a CNAME cannot sit beside them. Mail makes it more obvious, because MX records at the apex collide too, but the rule applies whether or not you run mail.

MX lists mail servers with a priority number. Lower wins: a server at priority 10 is tried before one at 20. The second one is a fallback, not a second inbox, and mail that reaches it is expected to be relayed on rather than delivered.

TXT is the catch-all, and in practice it carries email policy and ownership proofs. SPF says which servers may send mail as your domain. DKIM, published at a selector under _domainkey, carries the public key that signs your outgoing mail. DMARC, at _dmarc, tells a receiving server what to do when neither of the first two vouches for the message. A mail passes DMARC if SPF or DKIM passes and the domain it passed for matches the one in the From header, so one of them failing is not by itself a problem — it is both failing, or passing for somebody else's domain, that triggers the policy.

NS names the servers that are authoritative for the zone. These are the ones that matter, and there is a trap in them. The delegation that actually decides who answers for your domain lives in the parent zone and is changed at your registrar, not inside the zone itself. Editing the NS records in your current DNS provider's panel moves nothing: the parent still points where it pointed, and the old provider still gets the questions. Change it at the registrar, and every other record configured at the old provider stops being consulted the moment the change takes effect.

Why your change has not appeared yet

This is the most common reason anyone opens a DNS tool, and the answer is almost always the TTL. Every record carries one, measured in seconds, and every resolver that has already asked keeps serving its cached copy until that number runs out. A record with a TTL of 86400 can go on being served for a full day after you change it.

What people call propagation is not propagation. Nothing is being pushed anywhere. Resolvers around the world are simply holding answers they collected before your edit, and each one forgets at its own moment. Which is why the change appears for a colleague an hour before it appears for you, and why clearing your browser cache does nothing.

The practical move is to lower the TTL before you make a change rather than after. Drop it to 300 a day ahead, make the edit, confirm it, then put it back up. Done after the fact it does not help at all, because the old high TTL is already out there.

Negative answers are cached too. If you query a name before it exists, the fact that it does not exist is remembered for a while, which is why a brand-new record sometimes takes longer to show than one you edited.

Common problems

If www resolves but the bare domain does not, the apex needs its own A record. A CNAME at the apex is not allowed, and providers that appear to offer one are doing something non-standard underneath — ALIAS, ANAME, or CNAME flattening — which works but is worth knowing about. Pointing a domain at a site covers the usual shapes.

If mail is failing and SPF looks right, count the lookups. An SPF record is allowed ten DNS lookups when it is evaluated, every include: spends some, and going over the limit is a hard failure rather than a warning. A domain with three mail providers chained through includes can blow the budget without any single record looking wrong.

Two SPF records on one name is also a hard failure. Not the stricter one winning, not the first one winning — both are discarded. If you added a provider and mail broke, check whether you added a second record instead of extending the first.

Records that exist at your provider but return nothing here usually mean the zone is not where you think it is. Check the NS records first: if they name a different provider than the one whose panel you have open, you have been editing a zone nobody is reading.