Is it DNS? Live health of the public DNS resolvers, and a full audit for any domain.
Live health of the public resolvers. Audit any domain.
Is it DNS?
… probing…
admin@ -- monitored
What we monitor: the major public DNS resolvers every minute, the top 100 domains daily, and the ISPs our volunteer probes watch from the inside.
admin@ -- hive --mesh
Our authorities. Every node proves the path to every other one, continuously, and signs the result. Probes are volunteers, and they run at home.
Signed path attestation · Ed25519 · keys anchored in DNSSEC. How it works → · Verify the keys → · Run a probe →
Live DNS health, checked from independent networks in real time. How we decide →
// diagnose my network
Run a small battery of DNS checks from your own browser. Each one is an independent observation; together they vote and converge on a single picture of your DNS path, then name what it looks like and what to do.
Browsers can only test DNS over HTTPS. We cannot see your raw port 53 path directly, so some findings are inferred from DoH behaviour rather than measured. Inferred findings are labelled.
Investigate a domain
Ask every major resolver, audit the delegation chain, check each authoritative nameserver, validate DNSSEC, and return every record we can find.
dig
Use the options below to send DNS queries to one or multiple common resolvers.
Learning examples runnable comparisons, each one teaches a DNS concept.
Build from scratch: for beginners five plain-English questions, step by step.
Answer five questions in plain English. We'll assemble a real dig command
for you. At the end, click Use this dig ↓ to drop it into the form below.
What do you want to look up?
A website, a mail server, or an IP address (for reverse DNS). You can leave it as
example.com if you just want to see how a query looks.
What kind of information about it?
DNS holds different kinds of records for the same name. Pick the one you care about.
Which DNS server should answer?
Public resolvers all see the same DNS data, but each has its own policy: filtering, privacy, performance, geographic optimization. Try a few.
Should the request be encrypted?
Classic DNS sends queries in cleartext. Modern transports wrap them in TLS so anyone in the middle can't see what you're asking.
Anything else?
all optionalThese tweak the request itself or what the server is allowed to tell you.
Your dig command
$ dig example.com A
Clicking the button populates the form below with these choices. From there, click Run.
Anatomy of a dig answer quick reference: flags, RCODES, record types, each with an example
Sections of a response
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41037 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 300 IN A 93.184.216.34
| HEADER | opcode, status (RCODE), random 16-bit transaction id. |
|---|---|
| QUESTION | What you asked. Echoed back so you know the server understood. |
| ANSWER | The actual records. Each row is name TTL class type value. |
| AUTHORITY | Who's authoritative for this zone (NS records, usually). |
| ADDITIONAL | Helpful extras: glue A/AAAA for the auth servers, or the OPT pseudo-record (EDNS0 data: DNSSEC, ECS, NSID). |
Header flags
qr | Query / Response. Set on a response, off on a query. | ;; flags: qr rd ra |
|---|---|---|
rd | Recursion Desired: the client asked the server to resolve end-to-end. | ;; flags: qr rd ra |
ra | Recursion Available: the server is willing to recurse for you. | ;; flags: qr rd ra |
ad | Authenticated Data: DNSSEC validated successfully. | ;; flags: qr rd ra ad |
cd | Checking Disabled: the client asked the server to skip DNSSEC validation. | ;; flags: qr rd ra cd |
aa | Authoritative Answer: only set by authoritative nameservers, never by recursives. | ;; flags: qr aa rd |
tc | TrunCated: answer was too big for UDP. Client should retry over TCP. | ;; flags: qr tc rd |
do | DNSSEC OK: EDNS0 bit in the OPT record. Client says "I want DNSSEC." | ;; OPT … flags: do |
Response codes (status)
NOERROR | Query worked. ANSWER section may still be empty (the name exists, but not for that record type). |
|---|---|
NXDOMAIN | Name doesn't exist at any type. AUTHORITY usually has a SOA with negative-cache TTL. |
SERVFAIL | Server tried and gave up. Often: DNSSEC validation failure, upstream timeout, or misconfigured zone. |
REFUSED | Server refuses. Asking an auth for a zone it doesn't host, or a recursive without permission. |
FORMERR | Server thinks your query is malformed (rare; usually a buggy client). |
NOTIMP | Server doesn't implement this query type / operation. |
Record types you'll meet
A | IPv4 address | example.com. 300 IN A 93.184.216.34 |
|---|---|---|
AAAA | IPv6 address | example.com. 300 IN AAAA 2606:2800:21f:cb07::1 |
CNAME | Canonical name: alias pointing to another name | www.example.com. 300 IN CNAME example.com. |
MX | Mail exchange: priority + hostname | example.com. 300 IN MX 10 mail.example.com. |
NS | Authoritative nameserver for the zone | example.com. 300 IN NS ns1.example.com. |
TXT | Arbitrary text: SPF, DKIM, DMARC, ownership verification | example.com. 300 IN TXT "v=spf1 -all" |
SOA | Start of Authority: zone metadata (serial, refresh, retry, expire, neg-cache TTL) | example.com. 300 IN SOA ns.example.com. hostmaster.example.com. 2026052501 7200 3600 1209600 3600 |
PTR | Pointer: reverse DNS, name lookup for an IP | 1.1.1.1.in-addr.arpa. 1800 IN PTR one.one.one.one. |
CAA | Certification Authority Authorization: which CAs may issue certs for this domain | example.com. 300 IN CAA 0 issue "letsencrypt.org" |
SRV | Service location: priority, weight, port, target | _xmpp._tcp.example.com. 300 IN SRV 10 5 5222 chat.example.com. |
HINFO | Host info: repurposed by RFC 8482 to refuse ANY queries | cloudflare.com. 3789 IN HINFO "RFC8482" "" |
RRSIG | DNSSEC signature over an RRset | example.com. 3600 IN RRSIG A 13 2 3600 20260601000000 20260501000000 12345 example.com. <sig…> |
DNSKEY | DNSSEC public key for the zone (KSK or ZSK) | example.com. 3600 IN DNSKEY 257 3 13 <pubkey…> |
DS | Delegation Signer: fingerprint of child zone's KSK, lives in the parent | example.com. 86400 IN DS 12345 13 2 <sha256 digest…> |
OPT | EDNS0 pseudo-record: container for DO bit, ECS, NSID, etc. Lives in ADDITIONAL. | ;; OPT PSEUDOSECTION: EDNS: version 0; flags: do; udp: 4096 |
Anatomy of one record line
example.com. 300 IN A 93.184.216.34
example.com. | Owner name. Trailing dot = fully qualified. |
|---|---|
300 | TTL in seconds: how long any cache should remember this. |
IN | Class. Effectively always IN (Internet). CH / HS are historical. |
A | Record type. |
93.184.216.34 | Record data: format depends on type (IP, hostname, text, etc.). |
Learn DNS by doing. Run a real scenario, then read what every part of the answer means.
admin@ -- Dig scenarios runnable comparisons, each one teaches a DNS concept. Click one to run it in the dig tool.
admin@ -- when it was actually DNS windows where ≥2 monitored resolvers went bad together · last 7 days
admin@ -- resolver score combined health 0-100 · latency + uptime + DNSSEC + operator status
admin@ -- notable incidents last 7 days · sub-10-min flaps hidden by default
admin@ -- Resolvers we monitor
# the exact test every probe sends, each minute, to every monitored resolver probe: transport: DoH # RFC 8484 wire POST (application/dns-message) fallback: Do53/TCP # resolvers with no public DoH endpoint from: global edge interval: 60s timeout: 5s cache: off query: name: <canary> # rotates each minute, same for all that round: # cloudflare.com, google.com, wikipedia.org, iana.org type: A flags: [RD, DO] # recursion desired + DNSSEC requested record: - answered # RCODE 0 with a non-empty answer - latency_ms - ad_flag # DNSSEC validated (AD), signed canaries only verdict: ok: latency <= 400ms warn: latency > 400ms bad: latency > 1500ms OR no answer
admin@ -- operator status what each provider's own status page says
admin@ -- resolvers current status · last 24h timeline · addresses · docs
ISP & legacy resolvers unmonitored, listed for reference
admin@ -- probes --roster every volunteer vantage, in the order they joined
A probe measures the DNS path from someone's real network to our authoritative servers, and relays a receipt those servers signed. It holds no key, so it can add evidence but never manufacture it.
admin@ -- domains --top100 the internet's most-used domains, snapshotted daily at 11:11:11
This project exists as a free resource for other admins facing the dreaded question: Is it DNS? My goal is to develop a set of tools capable of showing that, in fact, it is not always DNS.
New to DNS? Learn more at the wiki.
What's up with the colors on this site? Easy, my favorite color is NEON.
What's up with all the weird probe / hive stuff? The hive is live and you can join it today: run a probe and your vantage appears on the roster. Monitor skynet first.