alias_chain
ClaudeFollow a name's CNAME chain one hop at a time, asking one public resolver (Cloudflare DoH, recursion on) for type CNAME at each hop, so each hop's rcode is its own (a full query returns only the last name's rcode, RFC 6604 section 3). Returns each owner, target and TTL, and how the chain ends: the addresses at its end (A and AAAA, each family on its own, an address in inside space marked), no address (NOERROR, no A or AAAA), a resolver failure (SERVFAIL, REFUSED: nothing known about the records), NXDOMAIN (a dangling alias), a loop, a name that reads as inside a network (not asked, and what a split-horizon leak looks like from outside), or a stop after 8 hops. Notes a target that reads like one written without its trailing dot. Whether someone could claim a dangling target at a hosting provider is not measured.
check_domain
ClaudeThe eleven-check DNS audit for a domain: parent and child nameservers agree, no open recursion, DNSSEC chain, TTL sanity, mail posture, glue at the parent, a DS that matches a live DNSKEY, and whether a truncated UDP answer can be had over TCP. Every check reports ok, warn, fail or skipped with the reason. THERE IS NO SCORE AND NO LETTER GRADE: the checks state what they found and the caller decides what it means. It does not test HTTP, SMTP delivery, registrar status or arbitrary record types: use trace for the delegation path step by step, sweep_domain to compare the authoritative servers, dig for one record from one resolver. Six of the eleven belong to a ZONE rather than to a name (the delegation, the DNSSEC chain, the nameserver's recursion policy, the glue, the DS match and the TCP fallback), so if you ask about a hostname those six are evaluated for the enclosing zone: the answer names it and marks the rows it applies to.
dig
ClaudeAsk ONE public DNS resolver on the board for one record, live, from the isitdns seat, over DoH from the Cloudflare edge. The resolver is a board id (cloudflare, google, quad9, opendns, adguard, cleanbrowsing, controld, quad9-unfiltered, adguard-family, cleanbrowsing-family, adguard-unfiltered, opendns-familyshield, nextdns, cloudflare-malware, cloudflare-family, mullvad-base, dns4eu-protective), an alias such as 8.8.8.8 or quad9 that maps to one, or "all" for the tier-1 operators side by side (cloudflare, google, quad9, adguard); every other board resolver is asked by its id; the default is cloudflare. A private (RFC 1918), link-local or LAN address, and any address not on the board, is refused, and the answer says why. To check whether the person's own path intercepts DNS, this tool is the reference only: ask canary.probe.isitdns.net here, and hand the person dig @192.0.2.1 <name>, which should get no answer (a documentation address with no server, RFC 5737; hand it over as written), and dig @1.1.1.1 <name>, both to run on their own machine. Returns the answer, the flags, the rcode, Extended DNS Errors and the latency in the shape dig prints, plus the JSON, and ends with an "ask again" link to the same query on the site (a dig with a flag off its default has no page and carries no link). With resolver "all", one TTL line per record set (RRSIG aside) seen on two or more rows with the same data: the lowest and highest TTL and the resolver that reported each. Over MCP the transport is DoH only: DoT, Do53 over TCP and the probe's Do53 over UDP are on the HTTP surface (https://isitdns.net/api/query, transport=). A resolver with no DoH endpoint on file cannot be asked here and answers so. Each row of resolver "all" names the transport that answered. An arbitrary address (an authoritative server, an ISP resolver) is not reachable over MCP: DoH to a guessed https://<ip>/dns-query is not a measurement of it; the answer names the HTTP surface that dials it over Do53 or DoT.
dns_events
ClaudeDays when several resolvers were unhealthy at once, as episodes: when each began, how long it ran, how many resolvers were affected at the peak, and which. This is the tool for "was there a DNS outage recently".
dnssec_chain
ClaudeWalk the DNSSEC chain for one name and type from the root key set to the answer, read through one public resolver with checking disabled (Cloudflare DoH, RFC 4035 section 3.2.2), and name the first link that breaks with its RFC 4035 condition. Per signed zone cut: the DS set at the parent and who signed it, the DNSKEY set with key tags and roles (KSK, ZSK, revoked), which DS matches which key (SHA-1, SHA-256, SHA-384 digests computed), whether a DS-matched key signs the DNSKEY set, and each signature's window against the read time; then the answer's signer and key tag, or the NSEC and NSEC3 records of a negative answer (counted, not checked). An insecure delegation (no DS at the parent) is reported as where the chain ends, not as a break. Key tags, signer names and windows are checked; the signatures themselves are not verified, so a clean walk is not a validation.
ksk_board
ClaudeThe RFC 8509 root key sentinel across the public resolvers: which resolvers trust which root KSK, and the root DNSKEY set as read now.
registration
ClaudeIs the domain itself on hold, expired or being deleted? Asks the registry's RDAP server (found through IANA's RDAP bootstrap registry, RFC 9224) and returns the EPP statuses with what each means for resolution (clientHold, serverHold and redemptionPeriod mean the registry says it is not publishing the delegation; resolvers keep a cached copy until its TTL runs out, and trace shows whether the TLD servers still refer), the registration, expiration and last-changed dates, the nameservers the registry holds, and whether the delegation is signed. A hostname is walked up to the registered domain. Contacts are never returned. Not DNS: use it when every nameserver answers and the name still does not resolve, or to see an expiry date.
resolver_history
ClaudeThe incident record for the public resolvers: start time, duration and severity of each. Notable incidents by default; all=true includes short degradations. Windows where several operators failed at once are excluded as our own seat's path, and the answer says how many.
resolver_status
ClaudeThe live health board, not a list to choose from: is public DNS OK right now? Every public resolver isitdns watches, its verdict from every isitdns seat that voted this round (ok, slow, partial, bad, no data), its latency from the home seat (or from another network, named, when home did not vote), DNSSEC, and the time it was read. The text is the 30 s board text and the JSON is /api/status (60 s), so the two can be from readings up to a minute apart; in that JSON each resolver row has a status field that is still the home seat reading, and the votes are in its global field. Give a resolver to get one card.
sweep_domain
ClaudeAuthoritative consistency, not cache propagation: find the zone's nameservers from the root down, then ask one address of each nameserver name per family (IPv4 and IPv6) every name x type you list, with recursion off, over TCP, and widen to every other address: the zone apex SOA and the certificate-readiness questions first, then any question the sampled servers disagree on, then any that failed, as far as the per-sweep budget, the rate limit and the deadline allow. Readiness says not measured, naming the addresses, whenever one was held back. The result's holdback field says which addresses were sampled, which questions were widened, which addresses were never asked and which the widening pass paced out as slow or failing. Per name and type it says whether the servers agree: disagree (and which servers differ, every answered server grouped by answer, with the vantages listed when more than one asked), differs_by_vantage (the answers split exactly by vantage: the same nameserver names and families, at least two servers per vantage, agree from each vantage and the vantages got different answers; consistent with an anycast or geo-steered answer, and also with one region of an anycast authority lagging a change, which this sweep cannot tell apart; SOA serials, CAA readiness and the ACME names keep their own checks; anything short of that evidence stays disagree, with the vantages listed), not_authoritative (no aa bit), lame (answered REFUSED), no_answer (no response from this vantage, with the error per server), not_asked (never sent: held back by the sample, paced out as slow or failing, the deadline, or 3 misses in a row from that server; never counted as agreement), serial_mismatch (SOA), ttl_differs (servers that agree on the data and answered with the aa bit hand out one answer line with different TTLs: the line and each server's TTL, one flag per line that differs), same_error (every server that answered this question answered with the same error rcode, such as SERVFAIL; the servers asked, not every server of the zone), private_address (an A or AAAA answer in inside address space: RFC 1918, RFC 6598 shared space, RFC 4193 unique local, link-local or loopback; each line with its range; it may be deliberate, and it is also what a split-horizon leak looks like from outside), or unreachable_from_edge (a Cloudflare-hosted server the Cloudflare edge cannot dial, which is our reach and not their health). Those servers are asked from one of two sinks instead, pns2 (Phoenix) or p3a1 (Amsterdam), over TCP with recursion off, each sink with its own cap and budget, and each answer names its vantage in via (edge, sink:pns2 or sink:p3a1); relay_failed says the sink was asked and did not answer; not_relayed says the relay did not send it (its cap, the sink budget, repeated misses, or the deadline). A nameserver with no address found is listed as not asked, never dropped; an owner no server answered usably is reported as not measured, never as empty. Asked for HTTPS or SVCB (with A and AAAA at the same names to compare hints), the answer also reads them (svcb): each AliasMode target (at most 4, the rest named as not followed) followed one hop after the sweep from a recursive resolver, Cloudflare's DoH with recursion on, not the zone's own servers, for its own HTTPS or SVCB and its A and AAAA, reporting what those reads found (a ServiceMode record, address records only, none of the three, AliasMode again or TargetName ".", NXDOMAIN: the alias dangles), not read when a read failed, or nothing concluded when the reads contradict each other; a target that reads as inside a network is not asked; ipv4hint and ipv6hint against the address records when the target is the owner, and mandatory keys the record does not carry (RFC 9460). It also reports certificate readiness per name: the CAA set that governs issuance and where it was found (RFC 8659 section 3), and what is published at _acme-challenge (RFC 8555 section 8.4). Use this instead of many dig calls when checking a zone after a change. Limits: 16 names, 8 types; the plan samples at mos…
top_domains
ClaudeThe DNS health of the domains isitdns monitors, a list isitdns keeps, as of the last DAILY snapshot: rcode, addresses, DNSSEC and points, ordered by points, for each. Those come from one probe per day at 11:11:11 UTC and do not move intraday. The nameservers and the points are read separately, at Cloudflare's recursive, and are refreshed through the day. Ask for one domain to get its row, or omit to get the board and its summary. To check any domain right now rather than as of the snapshot, use check_domain.
trace
ClaudeWalk the delegation from the root servers down to the authoritative server for a name, like dig +trace: recursion off at every hop, referrals and glue followed, lame, refused and unreachable servers reported, the final authoritative answer as given, and a plain verdict on whether the delegation is healthy. It reads no DS, DNSKEY or RRSIG (the dnssec_check prompt does) and asks no recursive resolver (dig with resolver all does).
