DNS MCP Server
OCI · DOCKER.IO/MCLOSE/DNS-MCP:1.3.4 · SCANNED SEP 20
Real-time DNS security analysis — DNSSEC, email auth, and RDAP. Built for SOC investigations.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security0
- Malware scan not yet available for this package.Unverified
- Known CVEs could not be checked: this artifact ships no SBOM, so there is no dependency list to read. Publishing one would let us assess it.Unverified
- Install-script risk not yet assessed.Unverified
- Dependency health could not be checked: this artifact ships no SBOM, so there is no dependency list to read. Publishing one would let us assess it.Unverified
Provenance & Transparency32
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: no license is declared. See how to fix → Fail
- Actively maintained (last published 174 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability82
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 4060 tokens (~135/item across 30 items; 27 tools + 3 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 Management83
- Stability observed for 25 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage92
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 72% of tool parameters carry a description.Partial
- 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 27 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 28 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Unverified: 1 category
A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.
How do I install the DNS MCP Server server?
DNS MCP Server runs locally as a container image, launched with docker run --rm -i docker.io/mclose/dns-mcp:1.3.4. Ready-made configuration for Claude, Cursor, VS Code, Codex and 3 more is on this page, copied from each client's own documentation.
oci · docker.io/mclose/dns-mcp:1.3.4
claude mcp add mclose-dns-mcp -- docker run --rm -i docker.io/mclose/dns-mcp:1.3.4
{
"mcpServers": {
"mclose-dns-mcp": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"docker.io/mclose/dns-mcp:1.3.4"
]
}
}
} {
"servers": {
"mclose-dns-mcp": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"docker.io/mclose/dns-mcp:1.3.4"
]
}
}
} codex mcp add mclose-dns-mcp -- docker run --rm -i docker.io/mclose/dns-mcp:1.3.4
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"mclose-dns-mcp": {
"type": "local",
"command": [
"docker",
"run",
"--rm",
"-i",
"docker.io/mclose/dns-mcp:1.3.4"
],
"enabled": true
}
}
} mcp_servers:
mclose-dns-mcp:
command: "docker"
args: ["run", "--rm", "-i", "docker.io/mclose/dns-mcp:1.3.4"] {
"McpServers": {
"mclose-dns-mcp": {
"Transport": "stdio",
"Command": "docker",
"Arguments": [
"run",
"--rm",
"-i",
"docker.io/mclose/dns-mcp:1.3.4"
]
}
}
} {
"mcpServers": {
"mclose-dns-mcp": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"docker.io/mclose/dns-mcp:1.3.4"
]
}
}
} 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.
- 19 Sept 26 −3
- Security disclosure: unverified → fail ▼ functional
- Stability: pass → 0.80 functional
- 18 Sept 26 +1
- Stability: 0.97 → pass security
- Security disclosure: fail → unverified ▼ functional
- 16 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.
- 14 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.
- 12 Sept 26 −3
- Stability: pass → 0.80 functional
- 11 Sept 26 +1
- Stability: 0.97 → pass security
- 9 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.
- 7 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.
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 20 Sept 2026 · Analysed oci/docker.io/mclose/dns-mcp:1.3.4
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | oci |
| Reason | No attestation published |
Background: How many MCP packages publish verified provenance →
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_bimi ~86
Check for BIMI (Brand Indicators for Message Identification) record. Queries {selector}._bimi.{domain} for the BIMI TXT record. Reports whether BIMI is configured, the logo SVG URL, and whether a VMC (Verified Mark Certificate) is present.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain to check BIMI record for |
| selector | string | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
check_ct_logs ~174
Query Certificate Transparency logs via crt.sh for a domain. Returns all certificates logged for the domain and its subdomains, including: unique names/SANs discovered (useful for subdomain enumeration), per-cert details (issuer, validity, wildcard status), active vs expired counts, and a CAA cross-reference that correctly maps intermediate CA names to their parent CA identity (e.g. E7/E8 -> letsencrypt.org) rather than doing a naive string comparison that produces false positives. Retries automatically -- crt.sh is unreliable and frequently returns empty responses or times out on the first attempt.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Apex domain to query CT logs for (e.g. deflationhollow.net) |
| include_expired | boolean | – | Include expired certificates in the results list (always counted in summary) |
Structured output declared, but exposes no named fields.
No examples provided.
check_dane ~157
Check for DANE TLSA records on a domain's mail servers. DANE binds TLS certificates to DNS via TLSA records, providing cryptographic assurance that a mail server's TLS certificate is the one the domain owner intended. DANE requires DNSSEC — without it, TLSA records are ignored by compliant MTAs. Queries MX records for the domain, then checks _25._tcp.{mx_host} for TLSA records and verifies DNSSEC (AD flag) for each. Classifies each MX host as dane_valid, dane_present_no_dnssec, or no_dane.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain to check DANE for (the From: domain, not the MX hostname) |
Structured output declared, but exposes no named fields.
No examples provided.
check_dbl ~202
Check a domain against DNS-based Domain Block Lists (DBLs). DBLs classify domains rather than IPs. Query pattern: {domain}.{dbl-zone}. The registered (org) domain is used for the lookup, stripping subdomains. Lists queried (in order): Spamhaus DBL — classifies: spam / phishing / malware / botnet C2 / abused-legit variants. Direct return-code lookup. URIBL (multi.uribl.com) — bitmask: black / grey / red / multi. SURBL (multi.surbl.org) — bitmask: SC / WS / AB / PH / MW / CRX. Spamhaus DBL uses dbl.spamhaus.org by default (low-volume analyst use). Set SPAMHAUS_DQS_KEY env var to enable production DQS queries.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain to check against DNS-based Domain Block Lists |
| nameserver | string | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
check_dkim_selector ~111
Verify a DKIM public key record exists for a given selector and domain. Queries {selector}._domainkey.{domain} for the DKIM TXT record and parses key parameters. Reports whether the key exists, its type, and whether it has been revoked (empty p= value).
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | DKIM domain (d= value from DKIM-Signature header) |
| selector | string | yes | DKIM selector (s= value from DKIM-Signature header) |
Structured output declared, but exposes no named fields.
No examples provided.
check_dmarc ~106
Retrieve and parse a domain's DMARC policy. Queries _dmarc.{domain} for the DMARC TXT record and parses all tags. If no record exists at the exact domain, falls back to the organizational domain (e.g., sub.example.com falls back to _dmarc.example.com). Returns the parsed policy, alignment modes, reporting URIs, and other tags.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain to check DMARC for (the From: domain) |
Structured output declared, but exposes no named fields.
No examples provided.
check_fast_flux ~307
Detect fast-flux DNS by querying a domain's A/AAAA records multiple times and comparing the returned IP sets between rounds. Fast-flux is a technique used by botnets and phishing infrastructure to evade takedowns: the domain's records rotate rapidly through a large pool of compromised hosts, with very short TTLs (often < 60 s). Detection heuristic: - Sends query_count rounds of A + AAAA queries with delay_seconds between them. - flux_detected = True when min_ttl < 300 s AND ip_set_changes > 0 Returns: - min_ttl: lowest TTL observed across all answers (seconds) - unique_ips_seen: count of distinct IPs seen across all rounds - ip_set_changes: how many times the answer set changed between consecutive rounds - all_ips: sorted list of every distinct IP observed - flux_detected: bool — True when TTL is suspiciously low AND IPs rotated - queries: per-round detail [{index, ips, ttl}]
| Name | Type | Req | Description |
|---|---|---|---|
| delay_seconds | number | – | Delay between query rounds in seconds (0.0–5.0) |
| domain | string | yes | Domain to probe for fast-flux behaviour |
| nameserver | – | – | Nameserver IP (default: 9.9.9.9) |
| query_count | integer | – | Number of A/AAAA query rounds to send (3–10) |
Structured output declared, but exposes no named fields.
No examples provided.
check_mta_sts ~134
Check for MTA-STS (Mail Transfer Agent Strict Transport Security). Queries _mta-sts.{domain} for the DNS TXT record and parses version and policy ID. When fetch_policy is True (the default), also fetches the HTTPS policy file at https://mta-sts.{domain}/.well-known/mta-sts.txt and parses the mode, MX patterns, and max_age.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain to check MTA-STS record for |
| fetch_policy | boolean | – | Also fetch the HTTPS policy file from /.well-known/mta-sts.txt |
Structured output declared, but exposes no named fields.
No examples provided.
check_rbl ~262
Check an IP address against 8 DNS-based Real-time Blackhole Lists (RBLs). Uses the standard DNS lookup method: reverses the IP octets (IPv4) or nibbles (IPv6), appends the RBL zone, and queries for A + TXT records. An A record answer means the IP is listed; the return code identifies the listing type. RBLs queried (in order): Spamhaus ZEN, SpamCop, UCEProtect L1, UCEProtect L2, Mailspike, PSBL, Barracuda, SORBS Spamhaus ZEN uses zen.spamhaus.org by default (low-volume analyst use). Set the SPAMHAUS_DQS_KEY env var to enable production DQS queries. SORBS may timeout occasionally — handled gracefully with per-RBL error capture so a slow zone never blocks the rest of the results. Mailspike returns positive reputation codes (127.0.0.10–14) for known-good senders — these are reported with listed=false and a reputation description.
| Name | Type | Req | Description |
|---|---|---|---|
| ip_address | string | yes | IPv4 or IPv6 address to check against DNS-based RBLs |
| nameserver | string | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
check_smtp_tlsrpt ~69
Check for SMTP TLS Reporting (TLSRPT) DNS record. Queries _smtp._tls.{domain} for the TXT record and parses version and reporting URIs. Often paired with MTA-STS.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain to check SMTP TLS Reporting record for |
Structured output declared, but exposes no named fields.
No examples provided.
check_spf ~94
Retrieve and recursively parse a domain's SPF policy. Enumerates all authorized sending IPs/networks by following include chains. Enforces the RFC 7208 10-lookup limit to prevent infinite recursion. Returns the raw SPF record, parsed mechanisms, authorized networks, the 'all' qualifier, and the total lookup count.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain to check SPF record for (e.g., 'example.com') |
Structured output declared, but exposes no named fields.
No examples provided.
check_tlsa ~217
Check for TLSA records at an arbitrary host:port:protocol combination. Builds the TLSA FQDN as _{port}._{protocol}.{hostname} and queries for TLSA records with DNSSEC (DO flag set). Reports whether records exist, their parameters (usage, selector, matching type, certificate data), and whether DNSSEC validation confirms authenticity (AD flag). Useful for non-mail DANE (HTTPS on 443, XMPP, etc.) or when you already know the MX hostname and want to check it directly without the MX lookup. For a domain-level mail DANE check across all MX hosts, use check_dane.
| Name | Type | Req | Description |
|---|---|---|---|
| hostname | string | yes | Hostname to check TLSA record for (e.g., 'mx1.example.com') |
| nameserver | – | – | Nameserver IP to query (default: 9.9.9.9) |
| port | integer | yes | Port number (e.g., 25 for SMTP, 443 for HTTPS) |
| protocol | string | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
cymru_asn ~181
Look up the Autonomous System Number (ASN) for an IP via Team Cymru's DNS service. Step 1 — Origin lookup: IPv4: {reversed_octets}.origin.asn.cymru.com TXT IPv6: {reversed_nibbles}.origin6.asn.cymru.com TXT Response format: "ASN | prefix | CC | registry | allocated" Step 2 — Org name lookup: AS{asn}.asn.cymru.com TXT Response format: "ASN | | CC | registry | allocated | org name" 100% DNS — no HTTP. Authoritative BGP routing data. Flags known bulletproof / high-abuse ASNs from a built-in reference list.
| Name | Type | Req | Description |
|---|---|---|---|
| ip_address | string | yes | IPv4 or IPv6 address for ASN lookup |
| nameserver | string | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
detect_hijacking ~271
Test a DNS resolver for signs of DNS hijacking or tampering. WiFi routers and ISPs sometimes intercept DNS queries and return spoofed responses — captive portals, ad-injection landing pages, or NXDOMAIN redirects. This tool sends five probes directly to the specified resolver and reports a clean/suspicious/hijacked verdict with per-check detail. Checks performed: 1. NXDOMAIN probe — queries a random domain; hijacked resolvers return IPs 2. Known stable record — a.root-servers.net A must return 198.41.0.4 3. DNSSEC AD flag — cloudflare.com A; AD set means resolver validates DNSSEC 4. Resolver identity — whoami.akamai.net TXT reveals the resolver's source IP 5. Transparent proxy — queries root server directly with RD=0; RA=1 means a transparent DNS proxy is intercepting port 53 traffic Verdict logic: - hijacked: NXDOMAIN probe returned NOERROR+IPs, OR known record IP wrong - suspicious: partial failures or timeouts without a clear hijack signal - clean: all checks passed
| Name | Type | Req | Description |
|---|---|---|---|
| resolver | string | yes | IP address of the resolver to test (e.g. 192.168.1.1) |
Structured output declared, but exposes no named fields.
No examples provided.
dns_dig_style ~127
Perform a dig-style DNS query showing full response details. Sends a direct UDP query to the specified nameserver and returns detailed response information similar to the `dig` command output. Returns: - Header flags including DNSSEC-related flags (AD=Authenticated Data, CD=Checking Disabled) - Response status (NOERROR, NXDOMAIN, SERVFAIL, etc.) - Answer, Authority, and Additional sections with full record details
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain name to query |
| nameserver | string | – | Nameserver to query |
| record_type | string | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
dns_dnssec_validate ~218
Perform DNSSEC chain-of-trust validation similar to `delv +vtrace`. Walks the trust chain from the root zone down to the target domain, validating DNSKEY and DS records at each level. Reports whether each step in the chain validates successfully. This tool reconstructs the chain manually (educational "show your work" output) and cross-checks its verdict against the resolver's AD flag on the same query. If the two disagree, a "discrepancy" field explains which to trust and suggests `delv +vtrace <domain>` for final confirmation. Returns: - Chain of trust from root to target domain - Validation status at each level - DNSKEY and DS record details - Final validation result (secure/insecure/bogus)
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain name to validate (e.g., 'claude.lab.deflationhollow.net') |
| nameserver | string | – | DNSSEC-validating resolver to use |
| record_type | string | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
dns_query ~166
Query DNS records safely using dnspython library. Performs standard DNS lookups for common record types using the system resolver or a specified nameserver. Returns structured results with TTL information. Supports: A, AAAA, MX, TXT, NS, SOA, CNAME, PTR, SRV, DNSKEY, DS, TLSA, CAA, SSHFP, RRSIG, CDS, CDNSKEY, HTTPS, SVCB, NAPTR record types. No shell execution - pure Python DNS resolution via dnspython.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain name to query (e.g., 'example.com') |
| nameserver | – | – | Optional nameserver IP (e.g., '9.9.9.9') |
| record_type | string | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
dns_query_dot ~207
Perform a DNS over TLS (DoT) query showing full response details. Establishes a TLS session directly to the resolver and sends a DNSSEC-enabled query, similar to: kdig @resolver +tls +dnssec +multi <type> <domain> Returns: - TLS session: protocol version (TLS1.3), cipher suite, key bits - Header: status (NOERROR/NXDOMAIN/SERVFAIL/REFUSED), flags (qr/rd/ra/ad/aa/tc/cd) - EDNS pseudosection: version, DO flag, UDP payload size, padding bytes - Answer, Authority, Additional sections with full record details - Round-trip time in ms
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain name to query |
| nameserver | string | – | Resolver IP supporting DoT on port 853 (default: 1.1.1.1) |
| port | integer | – | – |
| record_type | string | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
nsec_info ~340
Probe a zone's DNSSEC denial-of-existence mechanism (NSEC vs NSEC3). Resolves the zone's authoritative nameserver, sends a DNSSEC-enabled query for a synthetic nonexistent name, and parses the NSEC or NSEC3 records returned in the authority section. Reports whether the zone is walkable (i.e., all names can be enumerated). Also queries the NSEC3PARAM record at the zone apex and cross-checks it against actual NSEC3 records to detect re-signing misconfigurations. Example: nsec_info("example.com") might return: denial_type: "nsec" zone_walkable: true walkability_note: "Zone uses plain NSEC. Every name in the zone is exposed — each NSEC record points to the next name in alphabetical order, allowing full zone enumeration by following the chain. This is common on smaller or older zones but considered a privacy risk for zones with sensitive hostnames." vs. denial_type: "nsec3" nsec3_params: {algorithm: 1, iterations: 10, salt: "aabbccdd", opt_out: false} zone_walkable: false walkability_note: "Zone uses NSEC3 with 10 iterations and a 4-byte salt. Names are SHA-1 hashed before publication, preventing direct zone enumeration. An attacker would need offline dictionary/rainbow table attacks against the hashed names to recover hostnames."
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain to check (e.g., 'example.com') |
Structured output declared, but exposes no named fields.
No examples provided.
ping ~30
Lightweight health check. Returns server status and timestamp with no external dependencies — no DNS queries, no HTTP requests.
Input schema present but exposes no named parameters.
Structured output declared, but exposes no named fields.
No examples provided.
quine ~43
Return the source code of this MCP server. Reads and returns the contents of server.py via __file__. A diagnostic/introspection tool — no parameters, no external dependencies.
Input schema present but exposes no named parameters.
Structured output declared, but exposes no named fields.
No examples provided.
rdap_lookup ~119
Retrieve domain registration data via RDAP (modern WHOIS replacement). Looks up the IANA RDAP bootstrap to find the correct server for the TLD, then queries for registration data. Calculates domain age for risk assessment (< 30 days = HIGH RISK, < 90 days = ELEVATED). This is the one tool that makes HTTP calls (not DNS). The domain input is validated before any HTTP request is made.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain to look up via RDAP (registrable domain, not subdomain) |
Structured output declared, but exposes no named fields.
No examples provided.
reset_stats ~43
Reset all per-tool call statistics and restart the session clock. Use this to start a fresh measurement window without restarting the container. Returns a confirmation with the new session start time.
Input schema present but exposes no named parameters.
Structured output declared, but exposes no named fields.
No examples provided.
reverse_dns ~119
Perform reverse DNS (PTR) lookup for an IP address, with forward-confirmed rDNS (FCrDNS) verification. Converts the IP to its in-addr.arpa / ip6.arpa name, queries PTR records, then resolves each PTR hostname forward (A + AAAA) to confirm it maps back to the original IP. FCrDNS pass is required for trustworthy mail server identity.
| Name | Type | Req | Description |
|---|---|---|---|
| ip_address | string | yes | IPv4 or IPv6 address for reverse DNS lookup |
| nameserver | string | – | – |
Structured output declared, but exposes no named fields.
No examples provided.
server_info ~43
Show server configuration: dnspython version, configured nameservers, search domains, and default domain. Useful for understanding which resolver the server is using and debugging query behavior.
Input schema present but exposes no named parameters.
Structured output declared, but exposes no named fields.
No examples provided.
session_stats ~50
Return per-tool call statistics for this container session. Reports uptime, total calls, and per-tool count/errors/latency since container start. Stats reset on every container restart — in-process only, no persistence.
Input schema present but exposes no named parameters.
Structured output declared, but exposes no named fields.
No examples provided.
timestamp_converter ~124
Convert between different timestamp formats. Useful for interpreting DNS record timestamps, SOA serial numbers, and other time-based data encountered during DNS analysis. Accepts: - ISO 8601 strings (e.g., "2024-01-15T10:30:00Z") - Unix epoch timestamps (seconds since 1970-01-01) - Human-readable strings (YYYY-MM-DD, MM/DD/YYYY) Returns conversions to ISO, epoch, human-readable, date, time, and unix_ms formats.
| Name | Type | Req | Description |
|---|---|---|---|
| convert_to | string | – | – |
| timestamp | – | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
What is the DNS MCP Server server?
DNS MCP Server is listed in the public MCP registry as io.github.mclose/dns-mcp. Real-time DNS security analysis, DNSSEC, email auth, and RDAP. Built for SOC investigations. This page covers its container image (docker.io/mclose/dns-mcp:1.3.4).
Is the DNS MCP Server server safe to use?
DNS MCP Server scores 50 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 DNS MCP Server server expose?
DNS MCP Server exposes 27 tools: ping, server_info, quine, session_stats, reset_stats, and 22 more. Their descriptions and schemas cost roughly 4,000 tokens of context every time the server is loaded.
Is the DNS MCP Server server still maintained?
DNS MCP Server is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.