DNS Checker

What is DNS?

The Domain Name System translates names people can remember into the addresses machines actually use. When you type a domain, your device asks a resolver, which walks down from the root servers to the top-level domain servers to the domain's own authoritative nameservers, and returns the answer. All of it normally completes in well under a tenth of a second.

The record types that matter

Understanding TTL and propagation

Every record carries a TTL — the number of seconds a resolver may cache the answer before asking again. "DNS propagation" is really just those caches expiring at different times around the world, which is why a change appears instantly for some visitors and hours later for others.

To make a migration quick, lower the TTL to a few minutes at least one full old-TTL period before the change, switch the record, confirm it, then raise the TTL again. Long TTLs are good for stability and performance; short TTLs are good for flexibility.

Common DNS problems

• Missing AAAA record. A domain with only an A record is invisible to IPv6-only clients. Check your own connectivity with the IPv6 checker.
• CNAME at the domain root. Not allowed by the specification. Providers offer ALIAS or ANAME records to work around it.
• Broken SPF or DKIM. A TXT record with a typo will send legitimate mail to spam. Both are strict about syntax.
• Stale NS records. After changing DNS provider, the old nameservers may keep answering until every cached delegation expires.

Reading the result: empty is not the same as failed

This is the distinction that causes the most confusion, and IPGet keeps the two apart on purpose. A lookup can end in three different places, and only two of them are problems.

• Records returned. The name exists and has records of the type you asked for. Each one is shown with its TTL, so you can see how long resolvers will hold it.
• An empty answer. The name exists, the zone answered, and there is simply no record of that type. Asking a domain for MX records when it does not receive mail returns this — and it is a completely normal, correct answer, not a failure. It is reported as an empty result rather than as an error, because the nameserver did respond.
• An error. Something prevented an answer. This is the case worth acting on, and the specific error tells you what to do next.

Treating "no MX record" and "the nameserver did not answer" as the same thing is how people end up debugging a mail problem that does not exist, or missing a nameserver outage that does.

What each error actually means

The difference between no zone exists and the nameserver reported a failure is particularly worth knowing. The first means the domain is unregistered, expired, or misspelled — the internet has no idea what you are asking about. The second means the zone exists and its nameservers are broken or misconfigured, which is a live outage affecting real users right now.

Authoritative and recursive answers are different things

Every DNS record has an owner: the authoritative nameservers listed in the domain's NS records, which hold the real zone. Almost nobody queries those directly. Your computer asks a recursive resolver — your provider's, or a public one — which either answers from cache or walks the chain from the root to the authoritative server on your behalf.

This lookup goes through recursive resolvers, which means what you see here is what a normal visitor's resolver would see, cache included. That is usually the right question. When you need to know what the authoritative servers are actually publishing right now — during a migration, for example — query them directly with dig @ns1.example.com example.com A, or compare several resolvers at once with the propagation checker.

How this lookup works

The query runs on IPGet's own server using Node's native DNS resolver against a fixed pair of public resolvers. You choose a domain and one of eight record types — A, AAAA, CNAME, MX, TXT, NS, SOA and CAA — and nothing else. You cannot specify a resolver, a port or a protocol, so this is a fixed-purpose lookup rather than a general network proxy.

Because the query is sent from our server rather than from your browser, the answer is unaffected by your own resolver, your router's cache, your VPN or your operating system's cache. That is frequently the point: when a record looks wrong on your machine and correct here, the problem is between you and your resolver rather than in the zone. It also means this cannot diagnose a resolver problem that is specific to your network — for that, compare with dig locally or use the propagation checker.

Requests are rate limited per address, every query has a hard timeout, and answers are cached briefly according to their own TTL. Queried domains are not logged or stored, and there is no lookup history — see the privacy policy.