DNS lookup

How this tool works

Type a domain or hostname, choose a record type or leave it on ALL, and the server runs the query for you. There is nothing to install and no account to create.

The lookup is done by the resolver on our server, the same kind of resolver your operating system uses when you open a website. For each record type, the server asks the resolver and lists every answer it receives, together with the name the answer belongs to and the remaining TTL. When ALL is selected, the server queries 9 types in turn: A, AAAA, CNAME, MX, NS, TXT, SOA, SRV and CAA.

Some hosting environments run a resolver that only answers for ordinary address records. To cover that case, the server checks the health of its own resolver and, when it is not answering fully, falls back to a DNS-over-HTTPS query against a public resolver. Answers that came through the fallback are shown without a TTL, because the fallback does not report one in the same way.

Results are cached for 5 minutes per name and type. If you repeat a lookup inside that window you will see the cached answer, which keeps the tool quick and avoids hammering the resolver. The response time printed above the result is the time the server spent on the live queries, so a cached result shows a very small number.

The tool accepts names in any case, strips a leading http:// or https://, removes a path if you paste a full URL, and converts internationalized names to their ASCII (punycode) form before querying. Enter www.example.com and https://www.example.com/page and you get the same result.

How to read the result

Each record type is shown in its own block with three columns: the name the record was returned for, the TTL, and the value. The count on the right tells you how many records of that type exist. A block that says no records were found means the name resolved but publishes nothing of that type, which is different from the name not existing at all.

Record types at a glance

A and AAAA values are links to the IP lookup, so you can see where a server is located and which network announces it. CNAME, NS and MX targets are links back into this tool, which makes it easy to follow an alias chain or inspect a mail server's own address records.

MX records carry a priority number before the hostname. Lower numbers are tried first. Two servers with the same priority share the load. A domain often publishes 2 to 5 MX records so that mail still arrives when one server is down.

The SOA value shows 3 fields: the primary name server, the responsible mailbox written with a dot instead of the @ sign, and the serial number. Operators usually bump the serial every time the zone changes, so comparing serials across name servers is a quick way to tell whether they are in sync.

The TTL column

TTL is the number of seconds a resolver may keep an answer before it must ask again. The value you see here is what our resolver reported, which is the time left in its cache rather than the number configured in the zone. If you look up the same name twice a minute apart, the TTL drops by about 60 seconds. When it reaches zero the resolver fetches a fresh copy and the TTL jumps back to the zone's value. The TTL glossary entry explains how this affects changes you make.

Domain to IP and hostname to IP

The most common reason to run a DNS lookup is to turn a name into an address. Select A for the IPv4 address or AAAA for the IPv6 address. A name can have several of each; browsers pick one and fall back to the others if the connection fails.

If the A block is empty but there is a CNAME record, the name is an alias. The address lives at the target of the CNAME, which may itself be an alias. Click the target to follow the chain until you reach a name with real A or AAAA records. Long chains add latency to the first connection, which is why most providers keep them to 1 or 2 hops.

To go in the other direction, from an address to a name, use the reverse DNS lookup. Forward and reverse records are maintained separately, so the hostname you get back from a reverse lookup is not necessarily the name you started with.

How to fix common DNS problems

The IP is wrong or outdated

1. Confirm what the authoritative servers say. Look up the NS records here, then query one of those servers directly from your computer (commands below). If the authoritative answer is already correct, the old address you see elsewhere is a cached copy that will expire on its own.
2. Check the DNS propagation checker to see how many major public resolvers already return the new value.
3. If the authoritative answer is wrong, log in to wherever the zone is hosted (registrar, DNS provider or hosting panel) and correct the record. Save and wait for the TTL to run down.
4. Before the next change, lower the TTL to 300 seconds a day in advance so the switch itself completes quickly.

No MX records or mail is not arriving

1. Query MX. If the block is empty, mail servers will fall back to the A record of the domain, which is rarely what you want.
2. Make sure each MX target is a hostname, not an IP address, and that the hostname has its own A or AAAA record. An MX pointing at a CNAME violates the standard and some senders reject it.
3. Check that priorities make sense: your primary server should have the lowest number.
4. Check the TXT records for an SPF policy; a missing or broken SPF record is a frequent reason for mail landing in spam.

TXT records missing or not validating

1. TXT records are returned exactly as published. Look for stray quotes, doubled records or records placed at the wrong name (for example DMARC must live at _dmarc.example.com, not at the root).
2. DKIM selectors live at selector._domainkey.example.com. Enter that full name in the tool rather than the bare domain.
3. If the record is correct at the authoritative server but the tool still shows the old value, the cached answer has not expired yet. Check again after the TTL has passed.

A CNAME at the root of the domain

The standard does not allow a CNAME at the zone apex alongside the SOA and NS records. If a provider asks you to point the bare domain at a hostname, use their ALIAS, ANAME or flattening feature, or publish A and AAAA records instead. A lookup that shows a CNAME at the root is a sign the zone is misconfigured and may fail at some resolvers.

Which record type answers which question

If you are not sure what to query, start from the symptom.

A stale AAAA record is a frequent and easy-to-miss cause of slow or failing connections. Browsers on IPv6-capable networks try the AAAA address first; if nothing is listening there, the user waits for a timeout before falling back to IPv4. If you do not run IPv6 on the server, do not publish an AAAA record for it.

What NS and SOA records tell you

The NS records returned by a resolver come from the zone itself, while the delegation in the parent zone (for example at the .com servers) can list different servers. When the two disagree, resolvers may reach a server that holds an old copy of the zone, and changes appear to apply only part of the time. The +trace command in the next section exposes exactly this situation. The SOA serial is the second check: query each NS server directly and compare serials. A secondary server with a lower serial has not picked up the latest zone transfer.

Checking DNS from your own computer

The tool answers from our resolver. To see what your own resolver or a specific name server returns, use these commands.

Windows (Command Prompt): nslookup -type=MX example.com queries your configured resolver. Add a server at the end to ask a specific one: nslookup -type=A example.com 1.1.1.1.

Windows (PowerShell): Resolve-DnsName example.com -Type TXT -Server 8.8.8.8 returns a structured result that is easier to read than nslookup.

macOS and Linux: dig example.com MX +short gives a compact answer, dig @ns1.example.net example.com A asks a specific authoritative server, and dig +trace example.com walks the delegation from the root servers down, which shows exactly which server is responsible for each step.

To clear a stale answer on your own machine: ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS, and sudo resolvectl flush-caches on Linux systems that use systemd-resolved. Chromium-based browsers keep their own cache, which can be cleared at chrome://net-internals/#dns.

Limits of this tool

• The answers come from one resolver, located where our server is. A resolver in another region can hold a different cached copy, and services that use geo-aware DNS deliberately return different addresses to different places. The propagation checker shows what major public resolvers see; neither tool can show you the answer your own ISP's resolver would give.
• The TTL shown is the remaining cache time at our resolver, not the configured value in the zone.
• Results are cached for 5 minutes. A record changed less than 5 minutes after your last lookup will not appear until the cache expires.
• The tool queries 9 record types. Less common types such as DNSKEY, DS, TLSA, NAPTR and HINFO are not covered, and DNSSEC validation status is not shown.
• When the resolver fallback is used, TTLs are not available and the record order may differ.
• The lookup does not test whether the server behind an address is actually running. A correct A record does not mean the website is up; use the port checker for that.
• Lookups are rate-limited per visitor. Scripted bulk queries will be refused.

Nothing on this page tells you whether your own connection is leaking DNS queries past a VPN or proxy. That is a different question, answered by the DNS leak test.