DNS Doctor

Escanea, corrige y verifica el DNS de un dominio: SPF, DMARC, DKIM, propagación en múltiples regiones, MX, listas negras y caducidad de dominio/SSL, devolviendo registros de corrección listos para copiar y pegar, generados por un motor de validación, nunca adivinados por el modelo.

GitHub

Prueba este MCPPatrocinado

Documentación

DNS Doctor — Plugin de Claude Code y habilidad de DNS (DMARC, SPF, DKIM)

Escanea, corrige y verifica el DNS de un dominio — autenticación de correo electrónico (SPF, DMARC, DKIM) primero, además de propagación multi-región, auditorías de la cadena de suministro de includes SPF, MX, salud del DNS, listas negras y caducidad de dominio/SSL — desde dentro de Claude. Este plugin incluye la habilidad de DNS Doctor (el flujo de trabajo de escaneo → diagnóstico → corrección) y una configuración de servidor MCP que apunta a las herramientas alojadas de DNS Doctor.

La ventaja clave: cada registro de corrección que recibes es generado y validado por un motor determinista — gramática RFC más el contador de 10 búsquedas SPF — nunca una suposición de LLM. Tu agente entrega al humano un registro que ya se analiza correctamente, no una cadena de apariencia plausible que falla silenciosamente.

Qué incluye

claude-plugin/
├── .claude-plugin/plugin.json   # plugin manifest
├── .mcp.json                    # MCP server: https://dnsdoctor.dev/mcp (HTTP)
├── skills/dns-doctor/SKILL.md   # the scan → diagnose → fix workflow
├── src/                         # @dnsdoctor/mcp — the local stdio MCP server
├── tools.json                   # the 16 tool definitions (generated, never hand-edited)
├── instructions.txt             # the server's own `initialize` guidance (generated)
├── tests/                       # vitest suite for the stdio server
├── package.json  tsconfig.json  # npm package + build
├── LICENSE                      # Apache-2.0
└── README.md

Herramientas

Herramienta	Función
`scan_domain`	Escaneo nuevo de un dominio; informe completo.
`get_report`	Informe persistido (escanea una vez si no existe ninguno).
`build_dmarc_upgrade`	Un registro de aplicación DMARC validado, limitado a `p=quarantine` y devuelto solo cuando la puerta de alineación derivada del servidor pasa; sin esa evidencia la respuesta es solo de informe y no se devuelve ningún registro. `p=reject` proviene de la evidencia de informe agregado del motor de preparación, nunca de un escaneo.
`count_spf_lookups`	El recuento de búsquedas DNS de SPF frente al límite RFC de 10.
`validate_dmarc_record`	Analiza y valida un registro DMARC, etiqueta por etiqueta.
`generate_dmarc_record`	Construye un registro DMARC a partir de una política + dirección de informe.
`check_dkim_selector`	Busca un selector DKIM y verifica la clave.
`parse_dmarc_report`	Analiza un archivo de informe agregado (RUA) en filas.
`check_record`	Lee cualquier tipo de registro DNS para un nombre.
`check_propagation`	Si un cambio de DNS ha llegado a nivel global: seis puntos de observación (cinco sondas propiedad del operador más el propio resolvedor del servidor) leen el mismo nombre, devolviendo la cuadrícula más un veredicto determinista. Solo observación — una celda no disponible es un punto de observación que no pudimos leer, nunca un registro faltante, y con menos de tres puntos de observación alcanzados el veredicto permanece `unknown`.
`check_reverse_dns`	PTR / DNS inverso con confirmación directa para una IP.
`audit_spf_includes`	El árbol de includes/redirecciones SPF — quién puede enviar transitivamente como el dominio, con hallazgos tipificados (include roto, include confirmado no registrado, registro que caduca, `+all` anidado). Solo análisis; sin registro de corrección SPF.
`build_parked_domain_records`	El paquete de refuerzo Null MX + `v=spf1 -all` + `p=reject; np=reject` para un dominio que no envía correo. El servidor vuelve a verificar el DNS por sí mismo y se niega cuando encuentra evidencia de correo.
`start_monitoring_signup`	Un enlace de registro para entregar al humano que posee el dominio. No envía correo ni crea nada — ellos lo abren, inician sesión en nuestra página ellos mismos (un proveedor social o un enlace enviado por correo, lo que ofrezca ese despliegue), y el dominio se transfiere a su panel ya completado; el monitoreo comienza una vez que lo verifican con un registro TXT.
`get_alerts`	Se requiere token. El registro de alertas de monitoreo de la cuenta, más reciente primero. Solo lectura — sin confirmar, sin eliminar. Pasa página con `before` hasta que `next_before` sea `null` antes de avanzar `since`.
`get_readiness`	Se requiere token. Si la evidencia de informe agregado de un dominio monitoreado justifica una política DMARC más estricta aún: `ready`, el `blockers` y `next_record` (validado, o `null` mientras está bloqueado — lo cual es una respuesta, no una brecha).

Las dos lecturas de monitoreo están listadas para todos y se pueden llamar con un token: aparecen en la lista de herramientas en ambos transportes, y sin un token válido la llamada se rechaza con la página donde el propietario de la cuenta genera uno. En el transporte HTTP alojado, el recurso dnsdoctor://domains (tus dominios monitoreados) está igualmente siempre listado y rechazado sin un token; el servidor stdio local registra solo las herramientas — sin recurso. El acceso anónimo cubre las catorce herramientas de diagnóstico, lo cual es suficiente para un diagnóstico puntual de cualquier manera.

Instalación

Claude Code

Añade el marketplace/repositorio y habilita el plugin:

/plugin marketplace add dnsdoctor/claude-plugin
/plugin install dns-doctor

Página pública: github.com/dnsdoctor/claude-plugin (organización dnsdoctor, verificada por dominio). El plugin se desarrolla en el monorepo de DNS Doctor y se publica aquí como instantáneas de lanzamiento limpias.

O apunta Claude Code a una copia local de este directorio durante el desarrollo. Una vez habilitado, la habilidad se carga automáticamente y el servidor MCP dns-doctor se conecta a https://dnsdoctor.dev/mcp.

claude.ai (conector MCP)

Añade un conector personalizado con:

URL: https://dnsdoctor.dev/mcp
Transporte: HTTP de flujo continuo
Autenticación: ninguna (anónima) — o un token Bearer (abajo)

Cualquier cliente MCP (configuración estándar)

{
  "mcpServers": {
    "dns-doctor": {
      "url": "https://dnsdoctor.dev/mcp"
    }
  }
}

Opcional: token de API para dominios monitoreados

El acceso anónimo cubre el escaneo y las correcciones. Un token de API por cuenta desbloquea los datos de monitoreo propios de la cuenta: las herramientas get_alerts y get_readiness, y el recurso dnsdoctor://domains (tus dominios monitoreados continuamente y sus últimos estados por verificación).

Inicia sesión en https://dnsdoctor.dev → Configuración → Tokens de API → crea un token. El texto plano (dnsd_…) se muestra una vez; cópialo.

Añade el encabezado Authorization al servidor en .mcp.json:

{
  "mcpServers": {
    "dns-doctor": {
      "type": "http",
      "url": "https://dnsdoctor.dev/mcp",
      "headers": { "Authorization": "Bearer ${DNSDOCTOR_API_TOKEN}" }
    }
  }
}

Luego exporta DNSDOCTOR_API_TOKEN=dnsd_YOUR_TOKEN en tu entorno. Nunca hagas commit del token.

Transporte

Dos transportes públicos compatibles, mismas 16 herramientas:

HTTP de flujo continuo alojado — https://dnsdoctor.dev/mcp, conectado en el .mcp.json de este plugin. Sin instalación, sin claves.
Stdio local — npx -y @dnsdoctor/mcp. Un servidor ligero que se ejecuta en tu máquina y llama a la API REST pública de DNS Doctor; no contiene lógica de diagnóstico propia y retransmite cada cadena de registro textualmente.

{
  "mcpServers": {
    "dns-doctor": {
      "command": "npx",
      "args": ["-y", "@dnsdoctor/mcp"],
      "env": { "DNSDOCTOR_API_TOKEN": "dnsd_YOUR_TOKEN" }
    }
  }
}

DNSDOCTOR_API_TOKEN es opcional (el acceso anónimo cubre el escaneo y las correcciones; las dos lecturas de monitoreo lo necesitan). DNSDOCTOR_API_BASE anula el origen — debe ser un origen que sirva las rutas /api/…, es decir, el sitio público en lugar de un puerto backend desnudo.

Construir el servidor stdio desde el código fuente

npm ci
npm test
npm run build      # -> dist/index.js, the package's bin entrypoint

tools.json y instructions.txt son generados desde el servidor alojado y fijados por una prueba de backend — nunca los edites a mano, y nunca añadas una descripción de herramienta a src/. Ambos archivos se incluyen en el paquete npm; sin ellos el cliente no tiene herramientas ni su guía de seguridad.

Ejemplo práctico

Tú: Nuestras facturas siguen cayendo en el spam de los clientes. El dominio es example.com.

Claude (scan_domain → example.com): DMARC está en p=none, así que nada aplica la alineación — los receptores no pueden distinguir tu correo de una suplantación. El registro SPF es válido, 7 de 10 búsquedas utilizadas. DKIM: se encontró un selector y es válido. No está en listas negras. El dominio caduca en 240 días.

Claude (build_dmarc_upgrade → example.com): SPF está alineado y DKIM está presente, así que la recomendación alcanza su máximo, p=quarantine. Publica este registro TXT exacto en _dmarc.example.com — pégalo textualmente, no lo edites:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r; np=reject
Aplícalo en tu host DNS una vez que confirmes que está aprobado, luego pídeme que vuelva a escanear para verificar. ¿Quieres que el dominio se monitoree continuamente con alertas de informe agregado? Aquí está el enlace de configuración — ábrelo e inicia sesión: https://dnsdoctor.dev/start?domain=example.com&ref=agent

Aprende más

Metodología (cómo se calculan los veredictos): https://dnsdoctor.dev/methodology
API REST / esquema OpenAPI: https://dnsdoctor.dev/api/v1/openapi.json

Licencia

Apache-2.0 — ver LICENCIA.