DNS Lookup

Read the DNS records a domain publishes, queried from the OmniKitly service rather than from your own network.

Secure server processingWeb & SEOWorkingNo account needed

What this tool does

DNS Lookup sends the domain to the OmniKitly processing service, which resolves seven record types in one pass — A, AAAA, CNAME, MX, NS, TXT and SOA — and returns a JSON report with the host at the top and a records object beneath it. Inside that object, a type the zone answers for carries its values, a type with no data carries an empty array, and a type that failed for any other reason carries the resolver's error code instead, ESERVFAIL for example. The shapes differ by type: MX entries are objects with a priority and an exchange, TXT values are arrays of strings, and SOA is a single object holding the primary name server, the zone serial and the refresh, retry, expire and negative-cache timers. The output pane shows that JSON pretty-printed, with a one-line summary sitting beside the copy button below it, and the same report downloads as a file named dns- plus the domain.

Most DNS questions are answered by reading several types next to each other rather than one at a time. A site that loads for you and not for a colleague is usually an A or AAAA question; mail that quietly vanishes is an MX and TXT question; a domain that refuses to move is an NS and SOA question. Getting all seven in one report puts the record that contradicts the others directly beside them, which is the part that hides when you run dig or nslookup once per type and read the answers minutes apart.

The Record type list offers eleven entries, and eight of them are genuinely resolved: A, AAAA, CNAME, MX, NS, TXT, SOA and CAA. Three are refused before the request ever leaves your browser, each with the reason: PTR needs a reverse name such as 4.3.2.1.in-addr.arpa rather than a forward domain, SRV needs a service name such as _sip._tcp.example.com, and DNSKEY is not a type Node's own resolver — what this service runs on — can query at all. Two further limits are worth knowing. A hostname with an underscore label is accepted where the underscore is not in the top-level domain position, so _dmarc.example.com and _sip._tcp.example.com both resolve; only a TLD itself starting with an underscore is refused. And no TTL appears anywhere in the report, since the resolver is asked for values rather than for the cache timings sitting behind them.

No file takes part in this job, because the input is a name rather than a document. The domain you type travels to the processing service over an encrypted connection as an ordinary job setting, it is held in readable form in the job record for the retention window — six hours by default — and that record and the JSON report are deleted together when the window ends. The queries are made from that machine through the recursive resolver it is configured with, so what you read is that resolver's view of the zone: a record still propagating, a geo-routed answer, or a split-horizon zone that resolves differently inside a company network can all differ from what your own machine would return.

How to use it

  1. Enter the domain. Nothing in the browser inspects what you type. The tidying happens on the service, which lowercases the name, removes an http:// or https:// prefix, drops everything from the first slash, cuts anything after a colon and strips a trailing dot. No other scheme is understood — ftp://example.com is reduced to the single word ftp and looked up as that.
  2. Know which names come back refused. A hostname must be letters, digits, dots and hyphens, with no doubled dot and no more than 253 characters; anything else is answered with a flat not-a-valid-hostname error, an email address and a non-ASCII name included. Nothing else is checked, so an IP address or a single-label name such as localhost is handed to the resolver as written.
  3. Leave the Record type list alone. It offers eleven bare type names with no description attached, and the selection changes neither the query nor the result. Treat it as a control that has not been connected rather than as a filter.
  4. Run it and read the JSON. Types with answers list their values and types the zone does not publish come back empty. The summary line names only the types that answered with a non-empty array, so SOA — which arrives as an object — is never listed there even when it is present in the report. The job is cut off at fifteen seconds, so an unresponsive name server ends the run rather than stalling it.

Processing & privacy

Secure server processing. This operation requires temporary server processing.

Common use cases

Confirming a DNS change has gone out

The service resolves through its own resolver, so an updated A record visible there but not on your machine says the change is live and your side is still holding a cached answer.

Working out why mail is not arriving

MX and TXT arrive in the same report, so a missing mail exchanger and a missing SPF string are visible together instead of as two separate lookups on two different days.

Finding out who actually runs a zone

The NS records name the authoritative servers and the SOA names the primary and the zone serial — enough to tell whether a domain has really been moved to a new DNS provider or only half moved.

Reading what has accumulated in TXT

Domain verification strings, SPF and assorted one-off entries all land in the TXT section, each as an array of strings; a value over 255 characters stays split into the chunks the zone stores it in, so join them before comparing against what you meant to publish.

Questions

Is the domain name I enter sent anywhere?
Yes. No file is involved, but the name goes to the OmniKitly processing service over an encrypted connection as a job setting and the query is made from there. It sits in the job record in readable form until the retention window ends, six hours after the run by default, when that record and the JSON report are removed together.
Why do PTR, SRV and DNSKEY never return a result?
PTR and SRV need a different kind of name than a forward domain — a reverse address for PTR, a service name for SRV — so the page tells you that immediately rather than sending a query that could only fail. DNSKEY is not a type this service's resolver can query at all; a DNSSEC validator such as Verisign's DNSSEC Analyzer, or dig on your own machine, is the right tool for that one.
Can I run a reverse lookup?
No. PTR is not among the seven types the service queries, and an IP address typed into the box is not rejected either — it is passed to the resolver as though it were a name, found nowhere, and returned as seven empty results. Reverse DNS needs dig -x or the equivalent locally.
Why is _dmarc.example.com refused?
The service validates a hostname as letters, digits, dots and hyphens, so any name carrying an underscore label is rejected before a query is made. DMARC Inspector and DKIM Record Checker construct those names on the server themselves, which is why they can read records this tool cannot reach.
Does the report include TTLs?
No. Values come back without the time-to-live behind them, so this will not tell you how long a stale answer will keep being served. Query an authoritative name server directly when the caching timings are the thing you actually need.
Will the answer match what my own computer sees?
Not always, and the difference is often the useful part. The lookup uses the resolver the service is configured with, so a record mid-propagation, a geo-routed record or an internal zone can each produce a result your machine would not give.
What happens when a domain publishes nothing of a type?
That type comes back as an empty array rather than an error, because a no-data answer and a name that does not exist are flattened to the same empty list. A domain that never existed therefore reads as seven empty results under a summary of no records found, which looks here exactly like a live domain publishing nothing.

Related tools