Is it DNS? Audit a site or domain that isn't working: one call says if it resolves and why. No key.
Scored across 6 tools
Each tool targets a distinct DNS diagnostic task, and the descriptions explicitly cross-reference alternatives to prevent misselection. The overlapping domain-level tools are cleanly separated by scope: check_domain audits a zone, sweep_domain checks authoritative nameservers, and trace follows delegation.
All names use snake_case and remain readable, but the set mixes verb_noun (check_domain, sweep_domain), bare verbs (dig, trace), and noun forms (registration, dnssec_chain). No single predictable pattern governs the set, though it is not chaotic.
Six tools is well within the ideal range for a focused DNS diagnostic server. Each tool covers a distinct and necessary task, so none feel redundant or missing from a count perspective.
The surface covers core DNS troubleshooting: single queries, delegation traces, nameserver sweeps, DNSSEC chain walks, registration data, and domain audits. Minor gaps remain, such as no explicit DNSSEC validation tool (the chain walk does not verify signatures) and no dedicated zone-transfer or reverse-DNS operation, though dig can partially cover the latter.
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 | Required | Description | Default |
|---|---|---|---|
| from | No | Region of the probe for the recursion, TTL and UDP truncation rows | |
| name | Yes | The domain to audit. Also as "domain"; a URL is read as its host. |
| Name | Required | Description |
|---|---|---|
| api | Yes | The /api GET that asks it again, as a new reading |
| checks | No | 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) |
| summary | No | Counts of ok, warn, fail and skip rows |
| askAgain | No | The isitdns.net page that asks it again, when one does |
| receipts | No | One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer |
| resolves | No | The first line: state, the line, the receipt ids it rests on |
| generatedAt | No | When the audit ran |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the description's job is added context, and it delivers: results are measured from the isitdns edge and its probes rather than the caller's network, and 'from' relocates only the recursion, TTL and UDP truncation rows. It does not describe result aggregation or failure modes, but an output schema exists to carry return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: the core operation and exclusions come first, with the probe-region nuance last. The compressed phrasing ('not for one record: dig', 'from moves the ... rows') is efficient, though the run-on clauses demand a second read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only audit tool with an output schema, annotations and full parameter coverage, the description supplies the scope, the measurement vantage point, and the row semantics. Only the shape of the summary/worst-case outcome is left implicit, which the output schema plausibly covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are documented there, so the baseline is 3. The description restates the 'from' behaviour (recursion/TTL/UDP truncation rows) already present in the schema and adds no new format or alias detail for 'name'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource: resolve a name in public DNS plus an eleven-check audit of the zone, returning per-row ok/warn/fail/skipped. It explicitly carves itself away from dig ('not for one record') and from HTTP/TLS work, so an agent can distinguish it from siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the triggering condition ('a domain that is not working'), the explicit exclusions (DNS only, not HTTP or TLS), and names the alternative for the single-record case ('dig'). This is the when/when-not/alternative triad in two sentences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| cd | No | Ask the resolver not to validate | |
| ecs | No | EDNS Client Subnet, e.g. 192.0.2.0/24 | |
| from | No | Ask over Do53/UDP from the probe in this region (no other transport) | |
| name | Yes | The name, e.g. _dmarc.example.com. Also as "domain"; a URL is read as its host. | |
| nsid | No | Request NSID (RFC 5001) | |
| type | No | Record type, e.g. A, MX, TXT, DS, HTTPS, or TYPE<n> | A |
| norec | No | Clear RD, like dig +norec | |
| dnssec | No | Set the DO bit and read AD | |
| family | No | Address family for Do53 dials; a DoH request does not choose it | v4 |
| follow | No | Also walk the CNAME chain from this name, hop by hop, to its addresses | |
| resolver | No | A board resolver 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), its address or host name (8.8.8.8, dns.google), or all for cloudflare, google, quad9, adguard side by side. | cloudflare |
| Name | Required | Description |
|---|---|---|
| api | Yes | The /api GET that asks it again, as a new reading |
| query | No | The question as asked: name, type, flags, transport |
| follow | No | follow: the CNAME hops, how the chain ends, its reads |
| results | No | One row per resolver: id, response (rcode, flags, records, EDE), latencyMs, at, vantage, or error |
| askAgain | No | The isitdns.net page that asks it again, when one does |
| receipts | No | One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer |
| agreement | No | resolver all: rows grouped by answer, and the ones with none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world safety, and the description adds meaningful behavior: DoH from the isitdns edge, from switching to Do53/UDP, follow adding separate CNAME reads with DNSSEC off, and the constraint that address resolvers must be on the board.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense, front-loaded single paragraph with no filler; purpose, exclusion, transport, and special modes are ordered usefully. Every clause contributes operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter tool with full schema coverage, rich annotations, and an output schema, the description supplies enough operational context about scope, transport, alternatives, and edge cases. Return values are appropriately left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics for resolver=all, from, follow, and the address-resolver board requirement. Most individual parameter meanings remain in the schema, so it does not fully earn a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Dig one name and type at one board resolver'), describes the side-by-side resolver-all mode, and lists the result artifacts. It explicitly differentiates from sibling check_domain for whole-domain queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear when-not rule ('Not for a whole domain: check_domain') and explains context-dependent modes such as resolver=all, from region probes, and follow: true for CNAME-chain walks. The agent can choose between this and the named alternative without inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Walk the DNSSEC chain from the root to one answer: DS and DNSKEY at each signed zone cut, key tags, signers, signature windows, and the first link that breaks or goes insecure. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name, e.g. www.example.com. Also as "domain"; a URL is read as its host. | |
| type | No | The record type to check at the end of the chain | A |
| Name | Required | Description |
|---|---|---|
| api | Yes | The /api GET that asks it again, as a new reading |
| links | Yes | One per zone cut: zone, DS, key tags and roles, signer, problems, readFrom |
| answer | No | The end: rcode, records, signatures, denial, problems |
| readAt | Yes | When the walk began |
| receipts | Yes | One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer |
| firstBreak | No | The first link that breaks: at, why, readFrom (the resolvers whose readings it rests on) |
| insecureAt | No | The zone where it goes insecure |
| signaturesVerified | Yes | Always false: signature bytes are not checked |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations, it discloses the resolution path (Cloudflare DoH with CD=1 from the isitdns edge) and the cross-check via Google's resolver. Most importantly it flags a critical limitation: signature bytes are not verified, so a clean walk does not prove the answer validates — exactly the caveat an agent needs to avoid over-claiming results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: purpose, scope, resolver path, caveat, and parameter constraint in that order. Every clause carries information, though the middle sentences are jargon-heavy and could be tightened slightly for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, high-stakes DNSSEC tool with an output schema present, the description covers the operation, the resolver/cross-check path, the validation caveat, and the type constraint — nothing essential for correct invocation is missing, and return-value structure is rightly left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real constraint beyond the schema: 'type' is the record checked at the end of the chain and must not be OPT, RRSIG, or a meta type such as ANY. That prevents predictable invalid invocations the schema alone does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('walk the DNSSEC chain from the root to one answer') and enumerates exactly what the walk returns (DS/DNSKEY at each zone cut, key tags, signers, signature windows, first breaking link). It explicitly distinguishes itself from the sibling 'dig' for the single-record case, so an agent can route correctly without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-not ('Not for one signed record: dig') and names the alternative tool, which is strong routing guidance. The positive 'when' is implied by the purpose (end-to-end chain validation rather than a single record) rather than stated outright, and no other siblings (trace, check_domain) are contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain or a hostname under it. Also as "name"; a URL is read as its host. |
| Name | Required | Description |
|---|---|---|
| api | Yes | The /api GET that asks it again, as a new reading |
| reads | Yes | Each HTTP read: url, at, ms, status, error |
| domain | Yes | The registered domain answered for |
| events | No | Dates by event: registration, expiration, last changed |
| readAt | Yes | When the lookup began |
| status | Yes | Each status, its effect, what it means for resolution |
| nameservers | No | The nameservers on file, null if the registry sent none |
| delegationSigned | No | DS at the registry, null if not stated |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly/openWorld/idempotent/non-destructive), the description adds substantial context: no contacts are returned, reads traverse the hostname up through each parent to the registered domain, and each HTTP read is reported with URL, status and time. These are behavioral traits the structured fields do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and resource, and every clause carries information about output or traversal. Some sentences are dense and comma-heavy, which slightly hurts scannability, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Annotations cover the safety profile and an output schema exists, so return values need not be described — yet the description still characterizes them. Nothing needed to select or invoke this single-parameter tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents that a URL is read as its host, so the baseline is 3. The description adds meaning by explaining that a hostname is resolved progressively at each parent down to the registered domain, clarifying how the single 'domain' argument is interpreted beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Read) and resource (a domain's registration from its registry's RDAP server) and enumerates the returned content: statuses, registration/expiry/change dates, nameservers, DNSSEC delegation state. It explicitly distinguishes itself from the nearest sibling with 'Not for what DNS answers: check_domain.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-not with a named alternative ('Not for what DNS answers: check_domain'), which is exactly the routing decision an agent needs. It also scopes the transport context (HTTPS via IANA RDAP bootstrap), reinforcing when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| names | No | Labels under domain, "@" for domain itself. Default: @, www, _dmarc, _acme-challenge | |
| types | No | Record types. Default: SOA, NS, A, AAAA, MX, TXT, CAA | |
| domain | Yes | The zone or name to sweep, e.g. example.com. Also as "name"; a URL is read as its host. |
| Name | Required | Description |
|---|---|---|
| api | Yes | The /api GET that asks it again, as a new reading |
| zone | No | The zone swept |
| results | No | One row per name and type: flags, answers, not asked |
| servers | No | Each nameserver address: name, address, family |
| holdback | No | The sample: addresses known, addresses asked, and each address not asked with why |
| receipts | No | One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer |
| notPrinted | No | Counts trimmed to fit, all at api |
| certReadiness | No | Per name: the CAA set that governs it and its _acme-challenge TXT and CNAME |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds genuinely new behavioral context: queries are sent with RD=0 over TCP from the isitdns edge or a probe, every unasked question is listed with a reason, and responses over 22,000 bytes are truncated with counts, with the full sweep available at an api: URL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and scope are front-loaded in the first clause, and the closing sentence packs the hard limits efficiently. The middle is written in clipped, subject-less fragments ('Asked with RD=0 over TCP...', 'named on each answer') that cost readability for a marginal word saving.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return formatting need not be explained, and the description still covers scope, exclusions, transport behavior, per-question omission reasons, truncation, and where to fetch the full result. Nothing material for correct invocation appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds constraints the schema omits: names are labels under domain with '@' meaning the zone apex, capped at 16 names and 8 types. That cap information is only available in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It names a specific verb (sweep) and resource (a zone's nameservers) and spells out exactly what is compared and reported: disagreements, lame/silent servers, serial and TTL differences, CAA, and _acme-challenge records. It also explicitly separates itself from the sibling 'dig' by stating it is not a public-resolver answer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The exclusion 'Not for a public resolver's answer: dig' gives a clear negative trigger and names the alternative tool. However, it never states positively when to reach for a sweep (e.g. auditing delegation consistency or pre-migration checks), so the agent must infer the positive case from the capability list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name to walk. Also as "domain"; a URL is read as its host. | |
| type | No | Record type for the final question | A |
| Name | Required | Description |
|---|---|---|
| api | Yes | The /api GET that asks it again, as a new reading |
| trace | Yes | query, readAt, hops, failed dials, finalAnswer, warnings |
| report | Yes | verdict, headline, steps, the TTL facts, meaning |
| askAgain | No | The isitdns.net page that asks it again, when one does |
| receipts | Yes | One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, but the description goes well beyond them: RD=0 over TCP, issued from the isitdns edge or a probe, each hop named, the walk terminating at the zone that answers, and TTLs on the final answer. Failed dials are also disclosed as part of the output, which an agent would not otherwise expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core metaphor and purpose before details. The clauses are dense and comma-spliced, making it slightly hard to parse, but no sentence is redundant and the exclusion is placed early rather than buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure need not be explained, and the description still covers protocol, vantage points, termination condition, and failure behavior. Combined with annotations covering the safety profile, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics: the name must be the full host name and determines where the walk terminates, and type applies only to the final question (default A). It also notes URLs are read as their host in the schema, not the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (trace a delegation from root to authority) and immediately anchors it to a familiar analogue, dig +trace, then enumerates what the trace contains: referrals, glue, the answering server at each zone cut, failed dials, final answer and TTLs. It explicitly differentiates from the sibling sweep_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit exclusion ('Not for every server of a zone: sweep_domain') and a prerequisite ('Give the full host name'), plus the default for type. It does not disambiguate against the other closely related siblings such as dig or check_domain, which is a real gap given how similar trace and dig sound.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_domain1 field changedOutput schema / properties / checks / descriptionPrevious value: -"The eleven rows: id, label, status, detail, receipt ids"New value: +"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)"check_domain1 field changedInput schema / properties / from / descriptionPrevious value: -"Ask from the probe in this region"New value: +"Region of the probe for the recursion, TTL and UDP truncation rows"dig3 fields changedInput schema / properties / family / descriptionPrevious value: -"Address family to dial"New value: +"Address family for Do53 dials; a DoH request does not choose it"Input schema / properties / from / descriptionPrevious value: -"Ask from the probe in this region"New value: +"Ask over Do53/UDP from the probe in this region (no other transport)"Input schema / properties / resolver / descriptionPrevious value: -"A board resolver 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 all for cloudflare, google, quad9, adguard side by side."New value: +"A board resolver 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), its address or host name (8.8.8.8, dns.google), or all for cloudflare, google, quad9, adguard side by side."sweep_domain2 fields changedInput schema / properties / names / descriptionPrevious value: -"Relative labels to ask, \"@\" for the apex. Default: @, www, _dmarc, _acme-challenge"New value: +"Labels under domain, \"@\" for domain itself. Default: @, www, _dmarc, _acme-challenge"Output schema / properties / certReadiness / descriptionPrevious value: -"Per name: CAA and ACME readiness"New value: +"Per name: the CAA set that governs it and its _acme-challenge TXT and CNAME"dnssec_chain2 fields changedOutput schema / properties / firstBreak / descriptionPrevious value: -"The first link that breaks: at, why"New value: +"The first link that breaks: at, why, readFrom (the resolvers whose readings it rests on)"Output schema / properties / links / descriptionPrevious value: -"One per zone cut: zone, DS, key tags and roles, signer, problems"New value: +"One per zone cut: zone, DS, key tags and roles, signer, problems, readFrom"check_domain1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "api": {
+ "description": "The /api GET that asks it again, as a new reading",
+ "type": "string"
+ },
+ "askAgain": {
+ "description": "The isitdns.net page that asks it again, when one does",
+ "type": "string"
+ },
+ "checks": {
+ "description": "The eleven rows: id, label, status, detail, receipt ids",
+ "type": "array"
+ },
+ "generatedAt": {
+ "description": "When the audit ran",
+ "type": "string"
+ },
+ "receipts": {
+ "description": "One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer",
+ "type": "array"
+ },
+ "resolves": {
+ "description": "The first line: state, the line, the receipt ids it rests on",
+ "type": "object"
+ },
+ "summary": {
+ "description": "Counts of ok, warn, fail and skip rows",
+ "type": "object"
+ }
+ },
+ "required": [
+ "api"
+ ],
+ "type": "object"
+}dig1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "agreement": {
+ "description": "resolver all: rows grouped by answer, and the ones with none",
+ "type": "object"
+ },
+ "api": {
+ "description": "The /api GET that asks it again, as a new reading",
+ "type": "string"
+ },
+ "askAgain": {
+ "description": "The isitdns.net page that asks it again, when one does",
+ "type": "string"
+ },
+ "follow": {
+ "description": "follow: the CNAME hops, how the chain ends, its reads",
+ "type": "object"
+ },
+ "query": {
+ "description": "The question as asked: name, type, flags, transport",
+ "type": "object"
+ },
+ "receipts": {
+ "description": "One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer",
+ "type": "array"
+ },
+ "results": {
+ "description": "One row per resolver: id, response (rcode, flags, records, EDE), latencyMs, at, vantage, or error",
+ "type": "array"
+ }
+ },
+ "required": [
+ "api"
+ ],
+ "type": "object"
+}dnssec_chain1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "answer": {
+ "description": "The end: rcode, records, signatures, denial, problems",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "api": {
+ "description": "The /api GET that asks it again, as a new reading",
+ "type": "string"
+ },
+ "firstBreak": {
+ "description": "The first link that breaks: at, why",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "insecureAt": {
+ "description": "The zone where it goes insecure",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "links": {
+ "description": "One per zone cut: zone, DS, key tags and roles, signer, problems",
+ "type": "array"
+ },
+ "readAt": {
+ "description": "When the walk began",
+ "type": "string"
+ },
+ "receipts": {
+ "description": "One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer",
+ "type": "array"
+ },
+ "signaturesVerified": {
+ "description": "Always false: signature bytes are not checked",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "links",
+ "signaturesVerified",
+ "readAt",
+ "api",
+ "receipts"
+ ],
+ "type": "object"
+}registration1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "api": {
+ "description": "The /api GET that asks it again, as a new reading",
+ "type": "string"
+ },
+ "delegationSigned": {
+ "description": "DS at the registry, null if not stated",
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "domain": {
+ "description": "The registered domain answered for",
+ "type": "string"
+ },
+ "events": {
+ "description": "Dates by event: registration, expiration, last changed",
+ "type": "object"
+ },
+ "nameservers": {
+ "description": "The nameservers on file, null if the registry sent none",
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "readAt": {
+ "description": "When the lookup began",
+ "type": "string"
+ },
+ "reads": {
+ "description": "Each HTTP read: url, at, ms, status, error",
+ "type": "array"
+ },
+ "status": {
+ "description": "Each status, its effect, what it means for resolution",
+ "type": "array"
+ }
+ },
+ "required": [
+ "domain",
+ "status",
+ "reads",
+ "readAt",
+ "api"
+ ],
+ "type": "object"
+}sweep_domain1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "api": {
+ "description": "The /api GET that asks it again, as a new reading",
+ "type": "string"
+ },
+ "certReadiness": {
+ "description": "Per name: CAA and ACME readiness",
+ "type": "array"
+ },
+ "holdback": {
+ "description": "The sample: addresses known, addresses asked, and each address not asked with why",
+ "type": "object"
+ },
+ "notPrinted": {
+ "description": "Counts trimmed to fit, all at api",
+ "type": "object"
+ },
+ "receipts": {
+ "description": "One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer",
+ "type": "array"
+ },
+ "results": {
+ "description": "One row per name and type: flags, answers, not asked",
+ "type": "array"
+ },
+ "servers": {
+ "description": "Each nameserver address: name, address, family",
+ "type": "array"
+ },
+ "zone": {
+ "description": "The zone swept",
+ "type": "string"
+ }
+ },
+ "required": [
+ "api"
+ ],
+ "type": "object"
+}trace1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "api": {
+ "description": "The /api GET that asks it again, as a new reading",
+ "type": "string"
+ },
+ "askAgain": {
+ "description": "The isitdns.net page that asks it again, when one does",
+ "type": "string"
+ },
+ "receipts": {
+ "description": "One per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer",
+ "type": "array"
+ },
+ "report": {
+ "description": "verdict, headline, steps, the TTL facts, meaning",
+ "type": "object"
+ },
+ "trace": {
+ "description": "query, readAt, hops, failed dials, finalAnswer, warnings",
+ "type": "object"
+ }
+ },
+ "required": [
+ "report",
+ "trace",
+ "api",
+ "receipts"
+ ],
+ "type": "object"
+}alias_chaindig1 field changedInput schema / properties / followAdded value: +{
+ "default": false,
+ "description": "Also walk the CNAME chain from this name, hop by hop, to its addresses",
+ "type": "boolean"
+}path_receiptdig1 field changedInput schema / properties / resolver / descriptionPrevious value: -"A board resolver 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 all for the tier-1 operators side by side."New value: +"A board resolver 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 all for cloudflare, google, quad9, adguard side by side."path_receiptalias_chain1 field changedInput schema / properties / name / descriptionPrevious value: -"The name to follow, e.g. www.example.com. Also accepted as \"domain\"; a URL is reduced to its host."New value: +"The name to follow, e.g. www.example.com. Also as \"domain\"; a URL is read as its host."check_domain2 fields changedInput schema / properties / fromAdded value: +{
+ "description": "Ask from the probe in this region",
+ "enum": [
+ "north-america",
+ "europe"
+ ],
+ "type": "string"
+}Input schema / properties / name / descriptionPrevious value: -"The domain to audit. Also accepted as \"domain\"; a URL is reduced to its host."New value: +"The domain to audit. Also as \"domain\"; a URL is read as its host."dig6 fields changedInput schema / properties / cd / descriptionPrevious value: -"Checking disabled: ask the resolver not to validate"New value: +"Ask the resolver not to validate"Input schema / properties / ecs / descriptionPrevious value: -"EDNS Client Subnet in CIDR form, e.g. 192.0.2.0/24"New value: +"EDNS Client Subnet, e.g. 192.0.2.0/24"Input schema / properties / family / descriptionPrevious value: -"Which address family to dial the resolver on"New value: +"Address family to dial"Input schema / properties / fromAdded value: +{
+ "description": "Ask from the probe in this region",
+ "enum": [
+ "north-america",
+ "europe"
+ ],
+ "type": "string"
+}Input schema / properties / name / descriptionPrevious value: -"The name to ask for, e.g. example.com or _dmarc.example.com. Also accepted as \"domain\"; a URL is reduced to its host."New value: +"The name, e.g. _dmarc.example.com. Also as \"domain\"; a URL is read as its host."Input schema / properties / type / descriptionPrevious value: -"Record type: A, AAAA, MX, TXT, NS, SOA, CNAME, DS, DNSKEY, CAA, SRV, HTTPS, SVCB, PTR, or TYPE<n>"New value: +"Record type, e.g. A, MX, TXT, DS, HTTPS, or TYPE<n>"dnssec_chain1 field changedInput schema / properties / name / descriptionPrevious value: -"The name, e.g. www.example.com. Also accepted as \"domain\"; a URL is reduced to its host."New value: +"The name, e.g. www.example.com. Also as \"domain\"; a URL is read as its host."registration1 field changedInput schema / properties / domain / descriptionPrevious value: -"The registered domain or a hostname under it, e.g. example.com. Also accepted as \"name\"; a URL is reduced to its host."New value: +"The domain or a hostname under it. Also as \"name\"; a URL is read as its host."sweep_domain1 field changedInput schema / properties / domain / descriptionPrevious value: -"The zone or name to sweep, e.g. example.com. Also accepted as \"name\"; a URL is reduced to its host."New value: +"The zone or name to sweep, e.g. example.com. Also as \"name\"; a URL is read as its host."trace1 field changedInput schema / properties / name / descriptionPrevious value: -"The name to walk. Also accepted as \"domain\"; a URL is reduced to its host."New value: +"The name to walk. Also as \"domain\"; a URL is read as its host."dig1 field changedInput schema / properties / resolver / descriptionPrevious value: -"A board resolver 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), a registry alias such as 8.8.8.8 or dns.google, or \"all\" for the tier-1 operators side by side (cloudflare, google, quad9, adguard). An address that is not on the board is refused here with the HTTP URL that can dial it."New value: +"A board resolver 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 all for the tier-1 operators side by side."dns_eventsksk_boardresolver_historyresolver_statustop_domainsalias_chain1 field changedInput schema / properties / name / descriptionPrevious value: -"The name to follow, e.g. www.example.com"New value: +"The name to follow, e.g. www.example.com. Also accepted as \"domain\"; a URL is reduced to its host."check_domain1 field changedInput schema / properties / name / descriptionPrevious value: -"The domain to audit"New value: +"The domain to audit. Also accepted as \"domain\"; a URL is reduced to its host."dig1 field changedInput schema / properties / name / descriptionPrevious value: -"The name to ask for, e.g. example.com or _dmarc.example.com"New value: +"The name to ask for, e.g. example.com or _dmarc.example.com. Also accepted as \"domain\"; a URL is reduced to its host."dnssec_chain1 field changedInput schema / properties / name / descriptionPrevious value: -"The name, e.g. www.example.com"New value: +"The name, e.g. www.example.com. Also accepted as \"domain\"; a URL is reduced to its host."registration1 field changedInput schema / properties / domain / descriptionPrevious value: -"The registered domain or a hostname under it, e.g. example.com"New value: +"The registered domain or a hostname under it, e.g. example.com. Also accepted as \"name\"; a URL is reduced to its host."sweep_domain1 field changedInput schema / properties / domain / descriptionPrevious value: -"The zone or name to sweep, e.g. example.com"New value: +"The zone or name to sweep, e.g. example.com. Also accepted as \"name\"; a URL is reduced to its host."trace1 field changedInput schema / properties / name / descriptionPrevious value: -"The name to walk"New value: +"The name to walk. Also accepted as \"domain\"; a URL is reduced to its host."Look up DNS information for any domain to troubleshoot issues and gather insights. Get fast, relia…
Complete domain email-auth audit in one call: SPF with RFC 7208 lookup counting, DKIM selector pr...
DNS resolution, HTTP security headers, and SPF/DMARC email hygiene audits.
Inspects live IPv4/IPv6 DNS resolution, TLS certificate issuer/expiry, and HTTP security grade.
Add one secure layer between your agents and this server.