isitdns
REMOTE · ISITDNS.NET
Is it DNS? Audit a site or domain that isn't working: one call says if it resolves and why. No key.
Available components
Last scanned (8 hours ago)
Scores higher than 96% of remote servers
Reachable. Last reached 5 Nov 2026.
Category Cloud Infrastructure
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security83
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one. See how to fix → View diagnostics → Partial
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC is configured correctly; the domain's records validate against the full chain to the root. View diagnostics → Pass
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability73
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 1797 tokens (~299/item across 6 items; 6 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 6 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 7 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 5 Nov 26 +3
- Stability: fail → pass ▲ security
- 30 Oct 26 −1
No change was recorded against any check on this day. Stability & Change Management went from 86 to 75.
- 29 Oct 26 +5
No change was recorded against any check on this day. Stability & Change Management went from 50 to 86.
- 26 Oct 26 +1
- Server version: 2026-10-24 → 2026-10-25 functional
- “dig” reworded the description of “resolver” cosmetic
- 24 Oct 26 0
- Tool “dnssec_chain” rewrote its description, which is the text the model reads security
- Server version: 2026-10-15 → 2026-10-24 functional
- “dnssec_chain” added an optional parameter “anchor” cosmetic
- “dnssec_chain” added an optional parameter “anchor_zone” cosmetic
- 15 Oct 26 0
- Server version: 2026-10-13.3 → 2026-10-15 functional
- 13 Oct 26 0
- Tool “sweep_domain” rewrote its description, which is the text the model reads security
- Tool “registration” rewrote its description, which is the text the model reads security
- Tool “trace” rewrote its description, which is the text the model reads security
- Server version: 2026-10-13.2 → 2026-10-13.3 functional
- Server version: 2026-10-13 → 2026-10-13.2 functional
- Server version: 2026-10-12.3 → 2026-10-13 functional
- Server version: 2026-10-12 → 2026-10-12.3 functional
- “check_domain” reworded the description of “from” cosmetic
- “dig” reworded the description of “from” cosmetic
- “dig” reworded the description of “resolver” cosmetic
- “sweep_domain” reworded the description of “names” cosmetic
- “dig” reworded the description of “family” cosmetic
- 12 Oct 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Tool “dig” rewrote its description, which is the text the model reads security
- Tool “dnssec_chain” rewrote its description, which is the text the model reads security
- Tool “registration” rewrote its description, which is the text the model reads security
- Tool “check_domain” rewrote its description, which is the text the model reads security
- Tool “sweep_domain” rewrote its description, which is the text the model reads security
- Tool “trace” rewrote its description, which is the text the model reads security
- Schema quality: excellent → good functional
- Server version: 2026-10-10 → 2026-10-12 functional
- Server version: 2026-10-08 → 2026-10-10 functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Probed https://isitdns.net/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=isitdns.net | CN=WE1,O=Google Trust Services,C=US | 18 Sept 2026 | 17 Dec 2026 | ECDSA 256 | ECDSA-SHA256 | 4f8f0c0c67cc39071313148a57ed95cc |
| SANs: isitdns.net | ||||||
| CN=WE1,O=Google Trust Services,C=US (CA) | CN=GTS Root R4,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | ECDSA 256 | ECDSA-SHA384 | 7ff31977972c224a76155d13b6d685e3 |
| CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 15 Nov 2023 | 28 Jan 2028 | ECDSA 384 | SHA256-RSA | 7fe530bf331343bedd821610493d8a1b |
Background: What to check on a remote MCP endpoint →
DNSSEC secure
Validation of isitdns.net. — Secure
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| net. | present | 37331 | 13 | Verified |
| isitdns.net. | present | 2371 | 13 | Verified |
| isitdns.net. | Verified address RRset verified with the apex keys |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=31536000; includeSubDomains; preload |
| x-content-type-options | nosniff |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://isitdns.net/mcp | Verified | 200 | |
| http (plaintext) | http://isitdns.net/mcp | HTTPS enforced | 301 | https://isitdns.net/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
check_domain Check a domain's DNS ~140
Check a domain that is not working: whether the name resolves in public DNS, then the eleven-check audit of its zone, each row ok, warn, fail or skipped with why. DNS only, not HTTP or TLS, and not for one record: dig. Measured from the isitdns edge and its probes, never the caller's network. from moves the recursion, TTL and UDP truncation rows to that region's probe.
| Name | Type | Req | Description |
|---|---|---|---|
| from | string | – | Region of the probe for the recursion, TTL and UDP truncation rows |
| name | string | yes | The domain to audit. Also as "domain"; a URL is read as its host. |
| Name | Type | Req | Description |
|---|---|---|---|
| api | string | yes | The /api GET that asks it again, as a new reading |
| askAgain | string | – | The isitdns.net page that asks it again, when one does |
| checks | array | – | The eleven rows: id, label, status, detail, receipt ids, and on a warn or fail row that has one, next: the one reading to take next (tool, args, command) |
| generatedAt | string | – | When the audit ran |
| receipts | array | – | One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer |
| resolves | object | – | The first line: state, the line, the receipt ids it rests on |
| summary | object | – | Counts of ok, warn, fail and skip rows |
No examples provided.
dig Dig one record ~439
Dig one name and type at one board resolver, or at Cloudflare, Google, Quad9 and AdGuard side by side (resolver all): records, flags, rcode, EDE, latency. Not for a whole domain: check_domain. Asked over DoH from the isitdns edge. from moves the question to that region's probe as Do53 over UDP, and follow: true adds the CNAME chain as separate reads with DNSSEC off. A resolver given as an address must be on the board.
| Name | Type | Req | Description |
|---|---|---|---|
| cd | boolean | – | Ask the resolver not to validate |
| dnssec | boolean | – | Set the DO bit and read AD |
| ecs | string | – | EDNS Client Subnet, e.g. 192.0.2.0/24 |
| family | string | – | Address family for Do53 dials; a DoH request does not choose it |
| follow | boolean | – | Also walk the CNAME chain from this name, hop by hop, to its addresses |
| from | string | – | Ask over Do53/UDP from the probe in this region (no other transport) |
| name | string | yes | The name, e.g. _dmarc.example.com. Also as "domain"; a URL is read as its host. |
| norec | boolean | – | Clear RD, like dig +norec |
| nsid | boolean | – | Request NSID (RFC 5001) |
| resolver | string | – | A board resolver id (cloudflare, google, quad9, opendns, adguard, cleanbrowsing, controld, quad9-unfiltered, adguard-family, cleanbrowsing-family, adguard-unfiltered, opendns-familyshield, nextdns, c… |
| type | string | – | Record type, e.g. A, MX, TXT, DS, HTTPS, or TYPE<n> |
| Name | Type | Req | Description |
|---|---|---|---|
| agreement | object | – | resolver all: rows grouped by answer, and the ones with none |
| api | string | yes | The /api GET that asks it again, as a new reading |
| askAgain | string | – | The isitdns.net page that asks it again, when one does |
| follow | object | – | follow: the CNAME hops, how the chain ends, its reads |
| query | object | – | The question as asked: name, type, flags, transport |
| receipts | array | – | One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer |
| results | array | – | One row per resolver: id, response (rcode, flags, records, EDE), latencyMs, at, vantage, or error |
No examples provided.
dnssec_chain Walk the DNSSEC chain ~303
Walk the DNSSEC chain from the root to one answer: DS and DNSKEY at each signed zone cut, key tags, signers, signature windows, the first link that breaks or goes insecure, and whether the zone where it goes insecure is itself signed (an island of security). Not for one signed record: dig. Read through Cloudflare's resolver over DoH with CD=1 from the isitdns edge, and a key set a break would rest on again through Google's. Signature bytes are not verified, so a clean walk does not prove the answer validates. type (default A) is the record checked at the end, not OPT, RRSIG or a meta type such as ANY, and anchor (a DS or DNSKEY record, with anchor_zone) starts the walk at that zone instead of the root.
| Name | Type | Req | Description |
|---|---|---|---|
| anchor | string | – | A trust anchor: "DS <key tag> <algorithm> <digest type> <digest>" or "DNSKEY <flags> <protocol> <algorithm> <key>", optionally led by its owner name |
| anchor_zone | string | – | The zone the anchor belongs to: the name or a parent of it. Optional when the anchor record leads with its owner |
| name | string | yes | The name, e.g. www.example.com. Also as "domain"; a URL is read as its host. |
| type | string | – | The record type to check at the end of the chain |
| Name | Type | Req | Description |
|---|---|---|---|
| anchor | object | – | The supplied anchor: zone, kind, record, keyTag, algorithm, match |
| answer | object|null | – | The end: rcode, records, signatures, denial, problems |
| api | string | yes | The /api GET that asks it again, as a new reading |
| firstBreak | object|null | – | The first link that breaks: at, why, readFrom (the resolvers whose readings it rests on) |
| insecureAt | string|null | – | The zone where it goes insecure |
| islandAt | string|null | – | insecureAt when that zone is itself signed: an island of security; null when it is not, or when that was not judged (notChecked says why) |
| links | array | yes | One per zone cut: zone, DS, key tags and roles, signer, problems, readFrom |
| readAt | string | yes | When the walk began |
| receipts | array | yes | One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer |
| signaturesVerified | boolean | yes | Always false: signature bytes are not checked |
No examples provided.
registration Read a registration ~136
Read a domain's registration from its registry's RDAP server: each status with what it means for resolution, the registration, expiry and change dates, the nameservers, whether the delegation is signed. Not for what DNS answers: check_domain. Read over HTTPS from the isitdns edge through IANA's RDAP bootstrap, and no contacts are returned. A hostname is read at the name, then each parent down to the registered domain, and each HTTP read is listed with its URL, status and time.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | The domain or a hostname under it. Also as "name"; a URL is read as its host. |
| Name | Type | Req | Description |
|---|---|---|---|
| api | string | yes | The /api GET that asks it again, as a new reading |
| delegationSigned | boolean|null | – | DS at the registry, null if not stated |
| domain | string | yes | The registered domain answered for |
| events | object | – | Dates by event: registration, expiration, last changed |
| nameservers | array|null | – | The nameservers on file, null if the registry sent none |
| readAt | string | yes | When the lookup began |
| reads | array | yes | Each HTTP read: url, at, ms, status, error |
| status | array | yes | Each status, its effect, what it means for resolution |
No examples provided.
sweep_domain Sweep a zone's nameservers ~238
Sweep a zone's nameservers: the same names and types asked at a sample of its authoritative addresses, reporting disagreements, lame or silent servers, serial and TTL differences, the CAA in effect, and each _acme-challenge TXT or CNAME. Not for a public resolver's answer: dig. Asked with RD=0 over TCP from the isitdns edge or a probe, named on each answer. Every question not asked is listed with why, and an answer past 22,000 bytes is trimmed with counts, the whole sweep at its api: URL. names are labels under domain (@ for domain itself), 16 at most, and types 8 at most.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | The zone or name to sweep, e.g. example.com. Also as "name"; a URL is read as its host. |
| names | array | – | Labels under domain, "@" for domain itself. Default: @, www, _dmarc, _acme-challenge |
| types | array | – | Record types. Default: SOA, NS, A, AAAA, MX, TXT, CAA |
| Name | Type | Req | Description |
|---|---|---|---|
| api | string | yes | The /api GET that asks it again, as a new reading |
| certReadiness | array | – | Per name: the CAA set that governs it and its _acme-challenge TXT and CNAME |
| holdback | object | – | The sample: addresses known, addresses asked, and each address not asked with why |
| notPrinted | object | – | Counts trimmed to fit, all at api |
| receipts | array | – | One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer |
| results | array | – | One row per name and type: flags, answers, not asked |
| servers | array | – | Each nameserver address: name, address, family |
| zone | string | – | The zone swept |
No examples provided.
trace Trace a delegation ~152
Trace a delegation from the root to the authority, like dig +trace: each referral and its glue, the one server that answered at each zone cut and any dial that failed, the final answer and its TTLs. Not for every server of a zone: sweep_domain. Each hop is asked with RD=0 over TCP from the isitdns edge or a probe, named on the hop. Give the full host name: the walk ends at the zone that answers for it, and type (default A) is what it asks there.
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | The name to walk. Also as "domain"; a URL is read as its host. |
| type | string | – | Record type for the final question |
| Name | Type | Req | Description |
|---|---|---|---|
| api | string | yes | The /api GET that asks it again, as a new reading |
| askAgain | string | – | The isitdns.net page that asks it again, when one does |
| receipts | array | yes | One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer |
| report | object | yes | verdict, headline, steps, the TTL facts, meaning |
| trace | object | yes | query, readAt, hops, failed dials, finalAnswer, warnings |
No examples provided.
How do I install the isitdns MCP server?
isitdns is a hosted endpoint at https://isitdns.net/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · isitdns.net
claude mcp add --transport http net-isitdns-isitdns 'https://isitdns.net/mcp'
What is the isitdns MCP server?
isitdns is an MCP server listed in the public MCP registry as net.isitdns/isitdns. Is it DNS? Audit a site or domain that isn't working: one call says if it resolves and why. No key. This page covers its hosted endpoint (https://isitdns.net/mcp).
Is the isitdns MCP server safe to use?
isitdns scores 88 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the isitdns MCP server expose?
isitdns exposes 6 tools: check_domain, dig, trace, dnssec_chain, sweep_domain, registration. Their descriptions and schemas cost roughly 1,408 tokens of context every time the server is loaded.
Does the isitdns MCP server require authentication?
No. We connected to isitdns without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the isitdns MCP server still maintained?
isitdns is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.