KINDNS
Adequação opcional às boas práticas globais de DNS, com verificação ao vivo do servidor, aplicação assistida e geração do documento de autoavaliação.
Onde fica: Monitoramento → KINDNS · rota /kindns
Permissão: kindns — Administrador e Operador
Subtítulo na tela: Adequação opt-in às boas práticas globais de DNS (kindns.org) — nada é alterado sem sua ação
O KINDNS é uma iniciativa coordenada pela ICANN que reúne boas práticas de segurança e resiliência para quem opera DNS. A adesão é por autodeclaração: não há auditoria externa nem taxa. Esta tela verifica cada requisito ao vivo neste servidor, aplica o que faltar com sua autorização e, no fim, gera o relatório e o rascunho de e-mail prontos para submissão.
Nada é alterado sem clique
Os padrões do produto continuam como estão. Cada requisito é verificado, mas só é aplicado quando você confirma. Toda aplicação é reversível e fica no Registro de auditoria.
Abas
| # | PT | ES |
|---|---|---|
| 1 | Adequação | Adecuación |
| 2 | Documentação | Documentación |
| 3 | Sobre o KINDNS | Sobre KINDNS |
A aba Documentação explica em linguagem simples o que cada requisito faz, com blocos Antes e Depois. A aba Sobre o KINDNS cobre o que é a iniciativa e como funciona a adesão. O trabalho acontece na primeira aba.
O papel do servidor decide o que é verificado
Na primeira visita a tela pergunta o papel deste servidor. A escolha define o conjunto de requisitos.
| Papel | Descrição na tela | Requisitos verificados |
|---|---|---|
| Recursivo | Este nó resolve consultas para clientes | 8 recursivos + 9 de endurecimento = 17 |
| Autoritativo | Este nó hospeda zonas próprias e não serve recursão | 6 autoritativos + 9 de endurecimento = 15 |
| Ambos | Faz recursão e também hospeda zonas | 23 |
O cartão marcado como Detectado é a sugestão automática, baseada nos serviços ativos e na existência de zonas. Para trocar depois, use o link Perfil: ... — trocar, no resumo.
Escolher Recursivo num servidor que também é autoritativo faz os seis requisitos de zona sumirem da tela. Eles deixam de ser verificados, não passam a estar atendidos.
Como ler o farol
| Estado | Significa |
|---|---|
| Atende | O requisito foi verificado e está conforme |
| Parcial | Conforme em parte, ou conforme por default do daemon sem estar fixado |
| Não atende | Verificado e reprovado |
| N/A | Não se aplica a este servidor — não entra na conta do resumo |
Uma verificação que falhar por erro ou estourar o limite de 30 segundos também aparece como Parcial, com a evidência explicando a falha. O farol não distingue "meio certo" de "não consegui verificar" — leia a evidência antes de agir.
Requisitos do resolvedor recursivo
| ID | O que exige | Onde se resolve |
|---|---|---|
| R1 | Validação DNSSEC estrita | Aplicar aqui, ou Recursor |
| R2 | ACL de recursão restrita, sem resolvedor aberto | Recursor |
| R3 | Minimização de QNAME fixada na configuração | Aplicar aqui |
| R4 | Autoritativo separado do recursivo | Já atendido pela arquitetura do produto |
| R5 | Ao menos dois servidores de recursão para o cliente | Cluster ou atestação |
| R6 | Monitoramento do serviço DNS | Coletor local do produto; monitor externo é reforço opcional em Integrações |
| R7 | DNS criptografado na borda (DoT/DoH) | Aplicar aqui |
| R8 | Retenção limitada do registro de consultas | Aplicar aqui, ou Registro de consultas |
R2 fica vermelho se a lista de redes confiáveis contiver 0.0.0.0/0 ou ::/0. É a
definição de resolvedor aberto.
R6 já é atendido pelo coletor local do produto, desde que haja um instantâneo de métricas com menos de 15 minutos. Um monitor externo não é exigido.
R8 é o único requisito com campo de entrada: Dias de retenção, padrão 90, entre 1 e 3650. A política considera 90 dias o piso. Se o teto de disco do registro não comportar esse prazo, a evidência avisa e diz quantos megabytes seriam necessários — mas o requisito não força o aumento.
Requisitos do servidor autoritativo
Todos ficam N/A se o serviço autoritativo estiver parado ou sem zonas.
| ID | O que exige | Onde se resolve |
|---|---|---|
| A1 | Zonas assinadas com DNSSEC | Aplicar aqui (assina todas de uma vez) |
| A2 | Transferência de zona restrita, por IP e por chave | Zonas |
| A3 | Integridade do conteúdo da zona controlada | Aplicar aqui |
| A4 | Recursão desabilitada no autoritativo | Já atendido pela arquitetura do produto |
| A5 | Dois ou mais nameservers no apex de cada zona | Zonas |
| A6 | Monitoração de sincronização pelo serial da zona | Aplicar aqui |
A1 assina todas as zonas ainda não assinadas numa única operação, com assinatura em tempo de resposta. Depois disso é necessário publicar o registro de delegação de segurança no registrador de cada domínio — o requisito não faz isso por você, e não tem reverter.
A5 confere a quantidade de nameservers no apex de até 50 zonas. A diversidade de operadora e de localização não é medida: continua sendo decisão de planejamento de rede.
A6 liga uma varredura a cada 30 minutos que consulta o serial em cada nameserver de cada zona e gera notificação quando há divergência. Com o monitor desligado, a tela não varre ao vivo — mostra apenas o último resultado guardado, que pode ser antigo.
Requisitos de endurecimento da plataforma
Valem para qualquer papel.
| ID | O que exige | Onde se resolve |
|---|---|---|
| H1 | Consulta restrita aos seus clientes; descarte de endereços inválidos na borda | Recursor e o roteador de borda |
| H2 | Filtro anti-falsificação de origem na saída (BCP38) | Roteador de borda, com atestação aqui |
| H3 | Servidor dedicado, sem serviços extras expostos | Sistema operacional |
| H3C | Registros replicados para um servidor central remoto | Configurações do produto |
| H4 | Isolamento dos serviços DNS pelo gerenciador de serviços | Aplicar aqui |
| H5 | Configurações versionadas a cada alteração | Aplicar aqui |
| H6 | Acesso ao painel restrito às redes de gerência | Firewall |
| H7 | Console remoto apenas por chave | Configurações do produto |
| H8 | Política de senha forte e segundo fator no painel | Usuários e o perfil de cada usuário |
H1 e H2 têm um botão Ver exemplos de configuração, com abas por fabricante de roteador e um botão de copiar. Os exemplos vêm com aviso: são ilustrativos, precisam dos seus prefixos e da sua interface de saída, e aplicar sem adaptar pode derrubar a rede.
H1 não pede para você bloquear faixas privadas
A evidência do requisito diz o contrário de forma explícita: num resolvedor de provedor, descartar faixas privadas cortaria os próprios assinantes. O controle que atende o H1 é a lista de redes confiáveis fechada nos clientes reais.
H2 nasce vermelho e só fica verde por atestação. Não há como o servidor verificar o filtro do seu roteador de borda.
H3 lista os serviços em escuta fora da interface local que não fazem parte do conjunto esperado, no formato processo e porta. Ou você desabilita o que não precisa, ou atesta a necessidade.
H6 confere duas coisas: o firewall do servidor está ativo, e o grupo de IPs de administração não é mais a entrada aberta padrão. Firewall ativo com o grupo ainda aberto resulta em Parcial, porque na prática qualquer endereço alcança o painel.
H8 verifica a política de senha e informa quantos usuários já ativaram o segundo fator. Não tem aplicação por aqui: a política é ligada em Usuários e o segundo fator no perfil de cada pessoa.
O que tem consequência forte
Estes são os pontos que costumam surpreender.
Três requisitos reiniciam serviço ao aplicar
R1, R3 e R7. A confirmação mostra o impacto antes de executar.
| Requisito | O que acontece |
|---|---|
| R1 | Reinicia o resolvedor. Domínios com DNSSEC quebrado passam a responder falha de resolução para todos os clientes |
| R3 | Reinicia o resolvedor |
| R7 | Reinicia o serviço de borda. Ele passa a escutar nas portas de DNS criptografado — se o firewall de borda bloquear essas portas, libere antes |
R1 e R3 passam por validação de configuração com reversão automática. R7 desfaz a alteração sozinho se o serviço de borda não subir, e recusa a aplicação se não houver certificado TLS.
O H4 só vale depois de um reinício manual
Aplicar o H4 grava a configuração de isolamento dos serviços DNS e recarrega as definições, mas o efeito só entra no próximo reinício de cada serviço. Até lá o requisito fica em Parcial, com a evidência dizendo quais serviços estão aguardando reinício.
Reiniciar os serviços de DNS interrompe a resolução por cerca de um segundo. Faça numa janela adequada. O painel de gerência não recebe esse isolamento, de propósito: ele administra o servidor e o isolamento quebraria funções da própria interface.
O A2 fica vermelho se o portão de transferência estiver desligado
O A2 não olha só a configuração por zona. Se o portão de transferência de zona na borda estiver desligado e existir zona primária, o requisito nasce Não atende, independentemente do que estiver configurado em cada zona.
A razão é técnica: a borda encaminha a transferência ao serviço autoritativo pela interface local, então o autoritativo enxerga uma origem local e a restrição por zona não filtra quem chega pela porta pública. Sem o portão, a zona inteira é baixável sem chave.
A chave de transferência aparece uma vez só
Ao ativar a proteção por chave nas zonas primárias, o produto gera a chave e a exibe num aviso destacado, com botão de copiar.
A chave não é exibida de novo. Copie antes de fechar o aviso. Ela precisa ser configurada de forma idêntica nos servidores secundários, senão a replicação de zona para de funcionar.
Reverter o A2 desativa a chave nas zonas, mas não reabre o portão de transferência: a restrição por IP continua valendo, porque é uma proteção independente deste módulo.
Três requisitos mostram link em vez de Aplicar
A2, H3C e H7 têm ação automatizada no produto, mas ela não fica neste menu. O cartão mostra um botão de atalho para a tela correta.
| Requisito | Botão | Para onde vai |
|---|---|---|
| A2 | Gerenciar TSIG no menu Zonas | Zonas |
| H3C | Configurar nas Configurações | Configurações, aba de registros |
| H7 | Configurar nas Configurações | Configurações, aba de acesso remoto |
Quem procurar o botão Aplicar nesses três não vai encontrar. É comportamento intencional: o KINDNS valida e recomenda, a configuração mora no menu de origem.
A troca do console remoto para acesso apenas por chave tem uma proteção contra autobloqueio: ela é recusada se nenhum usuário do servidor tiver chave instalada, e a configuração é validada antes de recarregar o serviço. Depois de aplicar, teste um novo acesso remoto sem fechar a sessão atual.
Ações de cada requisito
| Botão | Quando aparece | O que faz |
|---|---|---|
| Aplicar | Requisito com aplicação automática neste menu | Mostra o impacto, pede confirmação, executa e reverifica |
| Reverter | Requisito já aplicado | Volta à configuração anterior, com confirmação em modo perigo |
| Atestar (feito na minha rede) | Requisito atestável ainda não atestado | Registra uma declaração do operador com autor, data e observação. Entra no relatório |
| Revogar atestação | Requisito já atestado | Remove a declaração. O farol pode voltar a Parcial ou Não atende |
A atestação existe para o que o servidor não consegue medir: filtro na borda, entrega de um segundo resolvedor aos clientes, versionamento externo de zonas e serviços extras que são necessários por decisão da operação.
Gerar o documento de autoavaliação
O produto não envia nada: ele monta o texto. A submissão ao KINDNS é feita por você.
Armadilhas
- Três requisitos reiniciam serviço de DNS ao aplicar — R1, R3 e R7. Leia o impacto na confirmação antes de aceitar.
- O H4 fica em Parcial indefinidamente até alguém reiniciar os serviços de DNS numa janela de manutenção.
- O A2 fica vermelho mesmo com a configuração por zona correta, se o portão de transferência estiver desligado. É intencional.
- A chave de transferência é exibida uma vez. Fechar o aviso sem copiar obriga a recuperá-la pela linha de comando do servidor.
- A2, H3C e H7 não têm botão Aplicar aqui — mostram atalho para o menu onde a configuração mora.
- Uma verificação que falha vira Parcial, igual a uma conformidade incompleta. A diferença está na evidência.
- Escolher o papel errado esconde requisitos, sem marcá-los como atendidos.
- O resultado das verificações não replica no cluster, de propósito: cada servidor tem a sua conformidade real. Já a escolha do papel e os interruptores de política replicam.
- Aplicar o R7 sem liberar as portas no firewall de borda deixa o DNS criptografado inacessível, com o requisito marcado como atendido.