Skip to main content
Glama

isitdns

by net.isitdns
OverviewDiscussionsAdmin

Walk the DNSSEC chain

dnssec_chain
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe name, e.g. www.example.com. Also as "domain"; a URL is read as its host.
typeNoThe record type to check at the end of the chainA

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
apiYesThe /api GET that asks it again, as a new reading
linksYesOne per zone cut: zone, DS, key tags and roles, signer, problems, readFrom
answerNoThe end: rcode, records, signatures, denial, problems
readAtYesWhen the walk began
receiptsYesOne per DNS read: what, of whom, from where, when, rcode, flags, EDE, ms, answer
firstBreakNoThe first link that breaks: at, why, readFrom (the resolvers whose readings it rests on)
insecureAtNoThe zone where it goes insecure
signaturesVerifiedYesAlways false: signature bytes are not checked

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / firstBreak / description
      Previous 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)"
    • changedOutput schema / properties / links / description
      Previous 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"
  2. Changed1 schema field changed
    • 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"
+}
  3. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous 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."
  4. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous 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."
  5. Added

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All isitdns toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources