DNS Doctor

Examine, corrija e verifique o DNS de um domínio — SPF, DMARC, DKIM, propagação em múltiplas regiões, MX, listas negras e expiração de domínio/SSL — retornando registros de correção prontos para copiar e colar, gerados por um mecanismo de validação, nunca adivinhados pelo modelo.

GitHub

Experimente este MCPPatrocinado

Documentação

DNS Doctor — plugin do Claude Code e skill de DNS (DMARC, SPF, DKIM)

Escaneie, corrija e verifique o DNS de um domínio — autenticação de e-mail (SPF, DMARC, DKIM) primeiro, além de propagação multi-região, auditorias da cadeia de suprimentos de includes SPF, MX, saúde do DNS, listas negras e expiração de domínio/SSL — de dentro do Claude. Este plugin agrupa a skill do DNS Doctor (o fluxo de trabalho scan → diagnose → fix) e uma configuração de servidor MCP apontando para as ferramentas hospedadas do DNS Doctor.

A vantagem: cada registro de correção que você recebe é gerado e validado por um motor determinístico — gramática RFC mais o contador de 10 lookups do SPF — nunca um palpite de LLM. Seu agente entrega ao humano um registro que já faz parse corretamente, não uma string de aparência plausível que falha silenciosamente.

O que está incluído

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

Ferramentas

Ferramenta	O que faz
`scan_domain`	Escaneamento novo de um domínio; relatório completo.
`get_report`	Relatório persistido (escaneia uma vez se nenhum existir).
`build_dmarc_upgrade`	Um registro de enforcement DMARC validado, limitado a `p=quarantine` e retornado somente quando a verificação de alinhamento derivada do servidor passa; sem essa evidência, a resposta é reporting-first e nenhum registro é retornado. `p=reject` vem da evidência de relatório agregado do motor de prontidão, nunca de um escaneamento.
`count_spf_lookups`	A contagem de lookups DNS do SPF contra o limite RFC de 10.
`validate_dmarc_record`	Parse e validação de um registro DMARC, tag por tag.
`generate_dmarc_record`	Construção de um registro DMARC a partir de uma política + endereço de relatório.
`check_dkim_selector`	Consulta de um seletor DKIM e verificação da chave.
`parse_dmarc_report`	Parse de um arquivo de relatório agregado (RUA) em linhas.
`check_record`	Leitura de qualquer tipo de registro DNS para um nome.
`check_propagation`	Se uma mudança de DNS já se tornou global: seis pontos de observação (cinco sondas de propriedade do operador mais o próprio resolvedor do servidor) leem o mesmo nome, retornando a grade mais um veredito determinístico. Apenas observação — uma célula indisponível é um ponto de observação que não pudemos ler, nunca um registro ausente, e com menos de três pontos de observação alcançados o veredito permanece `unknown`.
`check_reverse_dns`	PTR / DNS reverso com confirmação direta para um IP.
`audit_spf_includes`	A árvore de includes/redirects do SPF — quem pode enviar transitivamente como o domínio, com achados tipados (include quebrado, include confirmadamente não registrado, registro expirando, `+all` aninhado). Apenas análise; nenhum registro de correção SPF.
`build_parked_domain_records`	O pacote de endurecimento Null MX + `v=spf1 -all` + `p=reject; np=reject` para um domínio que não envia e-mail. O servidor re-verifica o DNS por conta própria e recusa quando encontra evidência de e-mail.
`start_monitoring_signup`	Um link de inscrição para entregar ao humano que é dono do domínio. Não envia e-mail e não cria nada — eles abrem, fazem login na nossa página (um provedor social ou um link enviado por e-mail, o que essa implantação oferecer), e o domínio é transferido para o painel deles já preenchido; o monitoramento começa quando eles verificam com um registro TXT.
`get_alerts`	Token obrigatório. O log de alertas de monitoramento da conta, do mais recente ao mais antigo. Somente leitura — sem reconhecer, sem excluir. Avance pelas páginas com `before` até que `next_before` seja `null` antes de avançar `since`.
`get_readiness`	Token obrigatório. Se a evidência de relatório agregado de um domínio monitorado justifica uma política DMARC mais forte ainda: `ready`, o `blockers` e `next_record` (validado, ou `null` enquanto bloqueado — o que é uma resposta, não uma lacuna).

As duas leituras de monitoramento estão listadas para todos e podem ser chamadas com um token: elas aparecem na lista de ferramentas em ambos os transportes, e sem um token válido a chamada é recusada com a página onde o dono da conta gera um. No transporte HTTP hospedado, o recurso dnsdoctor://domains (seus domínios monitorados) é igualmente sempre listado e recusado sem um token; o servidor stdio local registra apenas as ferramentas — nenhum recurso. O acesso anônimo cobre todas as quatorze ferramentas de diagnóstico, o que é suficiente para um diagnóstico pontual de qualquer forma.

Instalação

Claude Code

Adicione o marketplace/repositório e habilite o plugin:

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

Página pública: github.com/dnsdoctor/claude-plugin (org dnsdoctor, verificado por domínio). O plugin é desenvolvido no monorepo do DNS Doctor e publicado aqui como snapshots de release limpos.

Ou aponte o Claude Code para um checkout local deste diretório durante o desenvolvimento. Uma vez habilitado, a skill carrega automaticamente e o servidor MCP dns-doctor conecta-se a https://dnsdoctor.dev/mcp.

claude.ai (conector MCP)

Adicione um conector personalizado com:

URL: https://dnsdoctor.dev/mcp
Transporte: Streamable HTTP
Autenticação: nenhuma (anônima) — ou um token Bearer (abaixo)

Qualquer cliente MCP (configuração padrão)

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

Opcional: token de API para domínios monitorados

O acesso anônimo cobre escaneamento e correções. Um token de API por conta desbloqueia os dados de monitoramento da própria conta: as ferramentas get_alerts e get_readiness, e o recurso dnsdoctor://domains (seus domínios monitorados continuamente e seus status mais recentes por verificação).

Entre em https://dnsdoctor.dev → Configurações → Tokens de API → crie um token. O texto simples (dnsd_…) é mostrado uma vez; copie-o.

Adicione o cabeçalho Authorization ao servidor em .mcp.json:

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

Em seguida, exporte DNSDOCTOR_API_TOKEN=dnsd_YOUR_TOKEN no seu ambiente. Nunca faça commit do token.

Transporte

Dois transportes públicos suportados, mesmas 16 ferramentas:

HTTP streamable hospedado — https://dnsdoctor.dev/mcp, conectado no .mcp.json deste plugin. Sem instalação, sem chaves.
stdio local — npx -y @dnsdoctor/mcp. Um servidor leve que roda na sua máquina e chama a API REST pública do DNS Doctor; ele não contém lógica de diagnóstico própria e retransmite cada string de registro verbatim.

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

DNSDOCTOR_API_TOKEN é opcional (o acesso anônimo cobre escaneamento e correções; as duas leituras de monitoramento precisam dele). DNSDOCTOR_API_BASE substitui a origem — deve ser uma origem que atenda aos caminhos /api/…, ou seja, o site público em vez de uma porta de backend nua.

Compilar o servidor stdio a partir do código-fonte

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

tools.json e instructions.txt são gerados a partir do servidor hospedado e fixados por um teste de backend — nunca edite-os manualmente, e nunca adicione uma descrição de ferramenta a src/. Ambos os arquivos são enviados no tarball npm; sem eles o cliente não tem ferramentas e nenhuma das suas orientações de segurança.

Exemplo prático

Você: Nossas faturas continuam caindo no spam dos clientes. O domínio é example.com.

Claude (scan_domain → example.com): O DMARC está em p=none, então nada impõe alinhamento — os receptores não conseguem distinguir seu e-mail de um spoof. O registro SPF é válido, 7 de 10 lookups usados. DKIM: um seletor foi encontrado e é válido. Não está em lista negra. O domínio expira em 240 dias.

Claude (build_dmarc_upgrade → example.com): O SPF está alinhado e o DKIM está presente, então a recomendação atinge seu teto, p=quarantine. Publique este registro TXT exato em _dmarc.example.com — cole verbatim, não edite:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r; np=reject
Aplique no seu host de DNS depois de confirmar que foi aprovado, e então peça para eu re-escaneá-lo para verificar. Quer o domínio monitorado continuamente com alertas de relatório agregado? Aqui está o link de configuração — abra e entre: https://dnsdoctor.dev/start?domain=example.com&ref=agent

Saiba mais

Metodologia (como os vereditos são calculados): https://dnsdoctor.dev/methodology
API REST / esquema OpenAPI: https://dnsdoctor.dev/api/v1/openapi.json

Licença

Apache-2.0 — veja LICENSE.