Skip to main content
Glama
cenemil

DNS MCP Server

by cenemil
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

@cenemiljezweb/dns-mcp-server

A TypeScript-based Model Context Protocol (MCP) server that provides comprehensive DNS lookup capabilities to AI assistants.

Installation

NPM Global Install

npm install -g @cenemiljezweb/dns-mcp-server

NPX (no install needed)

npx @cenemiljezweb/dns-mcp-server

Related MCP server: nslookup.io MCP Server

Features

  • Multiple DNS Record Types: Support for A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, and CAA records

  • Reverse DNS Lookups: Convert IP addresses back to hostnames

  • Batch Queries: Perform multiple DNS lookups in parallel or sequentially

  • DNS Trace: Trace the DNS resolution path from root servers to final result

  • Configurable DNS Servers: Use custom DNS servers (Google, Cloudflare, or your own)

  • Logging: Comprehensive logging with configurable levels

  • Error Handling: Robust error handling with detailed error messages

Quick Start

Using with Claude Desktop

Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "dns-server": {
      "command": "npx",
      "args": ["@cenemiljezweb/dns-mcp-server"],
      "env": {}
    }
  }
}

Or if installed globally:

{
  "mcpServers": {
    "dns-server": {
      "command": "mcp-dns-server",
      "args": [],
      "env": {}
    }
  }
}

Configuration

The server can be configured using a dns-config.json file in your working directory:

{
  "dns": {
    "servers": ["8.8.8.8", "8.8.4.4", "1.1.1.1", "1.0.0.1"],
    "timeout": 5000,
    "retries": 2,
    "useTCP": false
  },
  "cache": {
    "enabled": true,
    "ttl": 300,
    "maxSize": 1000
  },
  "logging": {
    "level": "info",
    "file": "dns-server.log"
  }
}

MCP Tools Available

1. dns_lookup

Perform DNS lookup for a domain to retrieve various record types.

Parameters:

  • domain (required): The domain name to lookup

  • recordType: Type of DNS record (A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, CAA)

  • useCustomServer: Use custom DNS server if configured

  • timeout: Query timeout in milliseconds

Example:

{
  "domain": "example.com",
  "recordType": "A"
}

2. reverse_dns

Perform reverse DNS lookup to find the hostname for an IP address.

Parameters:

  • ipAddress (required): The IP address to perform reverse lookup on

  • timeout: Query timeout in milliseconds

Example:

{
  "ipAddress": "8.8.8.8"
}

3. batch_dns

Perform multiple DNS lookups in a single operation.

Parameters:

  • queries (required): Array of DNS queries to perform

    • domain: Domain name

    • recordTypes: Array of record types to query

  • parallel: Execute queries in parallel (default: true)

  • timeout: Query timeout per request

Example:

{
  "queries": [
    {"domain": "example.com", "recordTypes": ["A", "MX"]},
    {"domain": "google.com", "recordTypes": ["A", "AAAA"]}
  ],
  "parallel": true
}

4. dns_trace

Trace the DNS resolution path from root servers to the final result.

Parameters:

  • domain (required): The domain to trace DNS resolution path

  • recordType: The record type to trace (default: A)

Example:

{
  "domain": "example.com",
  "recordType": "A"
}

Development

Local Development

# Clone the repository
git clone https://github.com/yourusername/mcp-dns-server.git
cd mcp-dns-server

# Install dependencies
npm install

# Run in development mode
npm run dev

# Build the project
npm run build

# Run tests
npm test

Scripts

  • npm run build - Compile TypeScript to JavaScript

  • npm run dev - Run in development mode with hot reload

  • npm start - Run the compiled server

  • npm test - Run unit tests

  • npm run lint - Run ESLint

  • npm run typecheck - Run TypeScript type checking

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

License

MIT

Author

MCP DNS Server Contributors

Support

For issues and feature requests, please visit the GitHub repository.

Available Tools

4 tools
batch_dnsC

Perform multiple DNS lookups in a single operation

ParametersJSON Schema
NameRequiredDescriptionDefault
queriesYesArray of DNS queries to perform
parallelNoExecute queries in parallel
timeoutNoQuery timeout per request

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'multiple DNS lookups in a single operation,' implying batch processing, but lacks details on performance traits (e.g., rate limits, error handling for partial failures), authentication needs, or output format. For a tool with 3 parameters and no annotations, this leaves significant gaps in understanding its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence: 'Perform multiple DNS lookups in a single operation.' It is front-loaded with the core purpose, has zero waste, and is appropriately sized for the tool's complexity, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 parameters, batch operation) and lack of annotations and output schema, the description is incomplete. It doesn't address key aspects like error handling, output structure, or performance implications, which are crucial for a batch tool. The description alone is insufficient for an agent to fully understand how to use this tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, meaning all parameters are documented in the input schema. The description adds no additional meaning about parameters beyond the general batch operation context. Since the schema handles the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Perform multiple DNS lookups in a single operation.' It specifies the verb ('perform'), resource ('DNS lookups'), and scope ('multiple...in a single operation'), which is clear and specific. However, it doesn't explicitly distinguish this batch operation from the sibling 'dns_lookup' tool, which likely handles single lookups, missing full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tools (dns_lookup, dns_trace, reverse_dns) or clarify scenarios like handling bulk queries versus single lookups. Without such context, users must infer usage, which is inadequate for effective tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

dns_lookupC

Perform DNS lookup for a domain to retrieve various record types (A, AAAA, MX, TXT, etc.)

ParametersJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain name to lookup
recordTypeNoThe type of DNS record to queryA
useCustomServerNoUse custom DNS server if configured
timeoutNoQuery timeout in milliseconds

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving various record types but fails to describe critical behaviors like error handling, rate limits, authentication needs, or what happens if a record type is unsupported. For a tool with multiple parameters and no annotations, this leaves significant gaps in understanding how it operates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core action ('perform DNS lookup') and includes key details (domain, record types). There is no wasted text, and it directly communicates the tool's function without redundancy or unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is incomplete. It lacks information on output format, error conditions, performance characteristics, and how it differs from sibling tools. Without annotations or output schema, the description should provide more context to guide effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds minimal value beyond the schema by listing example record types (A, AAAA, MX, TXT, etc.), which aligns with the enum in the schema. No additional syntax, format details, or constraints are provided, meeting the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'perform DNS lookup' and resource 'domain' with specific examples of record types (A, AAAA, MX, TXT, etc.). It distinguishes the core lookup function from siblings like batch_dns (batch operations), dns_trace (tracing), and reverse_dns (reverse lookups), though it doesn't explicitly name these alternatives. The purpose is specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus sibling tools like batch_dns, dns_trace, or reverse_dns. It lacks context about use cases, prerequisites, or exclusions, such as when to choose batch_dns for multiple domains or reverse_dns for IP-to-domain lookups. Usage is implied but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

dns_traceB

Trace the DNS resolution path from root servers to the final result

ParametersJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain to trace DNS resolution path
recordTypeNoThe record type to traceA

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions the action ('Trace') but does not disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like (e.g., list of DNS servers, timing). For a tool with no annotation coverage, this is a significant gap in behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that is front-loaded with the core purpose. There is no wasted language, and it directly communicates the tool's function without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (tracing DNS paths), lack of annotations, and no output schema, the description is incomplete. It does not explain what the output contains (e.g., steps in resolution, error handling), behavioral aspects, or how it differs from siblings in practical use. This leaves gaps for an AI agent to understand the tool fully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('domain' and 'recordType') with descriptions and enum values. The description does not add meaning beyond what the schema provides, such as explaining parameter interactions or usage nuances. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

The description clearly states the tool's purpose with a specific verb ('Trace') and resource ('DNS resolution path'), specifying the scope ('from root servers to the final result'). It distinguishes from siblings like 'dns_lookup' (likely a simple lookup) and 'reverse_dns' (reverse resolution) by emphasizing the tracing of the full resolution path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for tracing DNS resolution paths, but does not explicitly state when to use this tool versus alternatives like 'dns_lookup' or 'batch_dns'. It provides context (tracing from root to final result) but lacks explicit guidance on exclusions or specific scenarios where this tool is preferred over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reverse_dnsB

Perform reverse DNS lookup to find the hostname for an IP address

ParametersJSON Schema
NameRequiredDescriptionDefault
ipAddressYesThe IP address to perform reverse lookup on
timeoutNoQuery timeout in milliseconds

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the core function but lacks details on error handling (e.g., for invalid IPs), rate limits, network dependencies, or what happens on timeout. For a network tool with potential failures, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without fluff. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly and understand the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete for a network tool. It doesn't cover behavioral aspects like error responses, return format (e.g., hostname string or structured data), or network constraints. For a tool with potential complexity in DNS resolution, this leaves critical gaps for an agent to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('ipAddress' and 'timeout') clearly. The description implies the 'ipAddress' parameter but adds no extra meaning beyond what the schema provides, such as format examples (IPv4 vs. IPv6) or timeout implications. Baseline 3 is appropriate as the schema does the heavy lifting.

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?

The description clearly states the specific action ('Perform reverse DNS lookup') and the resource ('IP address'), with the goal of finding the hostname. It directly distinguishes from sibling tools like 'dns_lookup' (likely forward lookup) and 'dns_trace' (likely diagnostic tracing), making the purpose unambiguous and well-differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'batch_dns' (for multiple lookups) or 'dns_lookup' (forward DNS). It states what the tool does but offers no context about appropriate scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updates
    • First observedbatch_dns
    • First observeddns_lookup
    • First observeddns_trace
    • First observedreverse_dns
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: batch_dns handles multiple lookups, dns_lookup retrieves standard records, dns_trace traces resolution paths, and reverse_dns maps IPs to hostnames. There is no overlap or ambiguity in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with underscores (e.g., batch_dns, dns_lookup, dns_trace, reverse_dns). The naming is uniform and predictable across the set.

Tool Count5/5

With 4 tools, the server is well-scoped for DNS operations, covering core functions like lookups, batch processing, tracing, and reverse lookups. Each tool earns its place without being excessive or insufficient.

Completeness4/5

The tools provide comprehensive coverage for DNS querying, including standard and reverse lookups, batch operations, and resolution tracing. A minor gap might be the lack of tools for DNS record management (e.g., create or update), but for a query-focused server, the surface is largely complete.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP DNS

    glucn
    A
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol tool that provides DNS querying capabilities for various record types (A, AAAA, MX, TXT, CNAME, NS, etc.) through a standardized MCP interface.
    1
    MIT

  • nslookup.io MCP Server

    NsLookup-io
    A
    license
    A
    quality
    B
    maintenance
    Provides comprehensive tools for real-time DNS queries across 53 record types, global propagation checks, and SSL certificate analysis. It also enables domain security scans for SPF/DKIM/DMARC configurations and HTTP uptime monitoring.
    8
    88
    22
    Apache 2.0

  • DNS MCP Server

    stanibaj
    F
    license
    Not graded
    quality
    D
    maintenance
    A comprehensive DNS query server that enables querying all types of DNS records, including A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, CAA, and DNSSEC checks, as well as advanced tools like WHOIS-style lookup and DNS delegation tracing.
    1
    -

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cenemil/dns-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server