Building a DNS Security MCP Server and What It Found
Shipped my first open source project: dns-mcp, an MCP server designed for DNS security analysis. From a first-timer perspective, it was interesting to learn the conventions of OSS publishing — README structure, changelogs, release tagging, multi-platform builds — things that don’t come up when code lives in a private repo. One of the decisions I had to make was splitting a remote authenticated version from the Docker stdio version that’s published now. Too much scope for a first release. The local stdio version is the right call for easy deployment anyway. Here are a few insights from the development process that may be useful if you’re building something similar. ◼️ MCP enables real-time data in AI for technical workflows. Instead of manual copy/paste, dns-mcp equips an AI assistant with live DNS tool calls. This allows it to investigate domains the way a security practitioner would — performing DNSSEC validation, checking email authentication posture, and gathering domain registration intelligence in real time. That’s the shift to conversational DNS investigation. ◼️ The MCP tooling provides a straightforward path to implementation. FastMCP in Python simplified the server-side development considerably. The main learning curve was understanding the surrounding ecosystem: stdio transport, Claude Desktop configuration, Docker packaging, and the registry. It’s a short path from curiosity to a small, working build. ◼️ Proper publishing requires dedicated effort. Getting multi-platform Docker builds, MCP Registry submission, accurate release tagging, and a useful README right takes real time. None of it is complex, but it’s essential for adoption and it’s easy to underestimate. ◼️ Designing effective prompts was a significant time investment. The server ships with three first-class MCP analyst prompts: email security audit, DNSSEC chain audit, and SOC email forensics. Structuring these to produce reliable, structured output required more iteration than most of the underlying Python tool development. ◼️ Initial testing revealed real-world security gaps. Running the tool against my own domain, deflationhollow.net, on day one produced a B+ rating and three concrete, actionable gaps that I’m fixing. ◼️ Running locally matters more than you might think. Many MCP servers are built around a remote HTTP streamable architecture, which is great for a lot of use cases. But if you need to analyze sensitive emails, submitting raw email content to a remote endpoint may not be an option. A local Docker-backed stdio MCP keeps everything on your machine — your emails never leave the system. Your LLM’s cloud is a different security story, but that’s a conversation for another day. The project ships with 18 tools covering DNS query and DNSSEC validation, email authentication posture (SPF, DKIM, DMARC, DANE, BIMI, MTA-STS), domain registration info via RDAP, and WiFi DNS hijacking detection. Three MCP analyst prompts provide standardized investigation workflows. Fair warning: not every LLM respects the requested output format — structured JSON has a way of becoming narrative prose when the model decides it knows better. One of my favorite lines from Claude Code during development: “The system prompt says not to, but LLMs gonna LLM.” Give it a try, share your results and suggestions. Linked in the first comment. #OpenSource #MCP #ModelContextProtocol #DNS #Cybersecurity #EmailSecurity #SOC #Claude #Anthropic #Python #Docker