The Problem
WebHouse manages DNS for hundreds of domains across multiple BIND servers. Updating a zone file means SSH-ing into a server, editing the zone, incrementing the serial, reloading BIND, and verifying propagation. It's error-prone, and I've been doing it for 25 years.
When Anthropic released the Model Context Protocol (MCP), I saw an opportunity: what if Claude could manage DNS directly?
Building dns-mcp
The DNS MCP server exposes tools like dns_list_zones, dns_list_records, dns_create_record, dns_upsert_record, and dns_reload_zone. Under the hood, it talks to a REST API that manages BIND zone files on the server.
The implementation was straightforward — MCP is essentially a JSON-RPC protocol over stdio. The hard part was safety. DNS is critical infrastructure. A bad record can take down email, websites, or entire services. So every destructive operation requires explicit confirmation, and the server validates record syntax before writing.
> Infrastructure as conversation — not infrastructure as code, but infrastructure as dialogue.
How It Works in Practice
In a Claude Code session, I can now say:
- "Add an A record for api.example.dk pointing to 185.x.x.x"
- "Show me all MX records for webhouse.dk"
- "Update the TTL on all CNAME records to 3600"
Claude calls the MCP tools, I see the proposed changes, and they execute. What used to take 5 minutes of careful SSH work now takes 10 seconds of conversation.
Lessons for MCP Server Builders
- Auth is non-negotiable. Every MCP server that touches real infrastructure must authenticate. I use bearer tokens.
- Validate aggressively. The AI might generate a syntactically valid but semantically wrong DNS record. Validate against RFC standards.
- Log everything. When something goes wrong with DNS, you need an audit trail. Every MCP call gets logged with timestamp, user, and the exact change made.
- Make it reversible. Every create has a delete. Every update preserves the previous value. DNS mistakes need fast rollback.