Verificar a conformidade KINDNS
Rodar os requisitos de boas práticas globais de DNS, entender cada resultado e decidir o que vale corrigir.
KINDNS é um conjunto de boas práticas publicado para operadores de DNS. O produto verifica os requisitos aplicáveis ao seu servidor e mostra, item a item, o que está atendido.
Verificar não altera nada
A checagem é opt-in e somente leitura: ela olha a configuração e reporta. Nenhum requisito é aplicado sem você mandar.
Onde clicar, passo a passo
Três abas: a adequação (o resultado), a documentação de cada requisito, e o contexto sobre o que é o KINDNS.
A checagem é refeita sob demanda. Rode depois de qualquer mudança relevante de configuração — o resultado guardado é do último exame, não do estado atual.
Ao lado, gerar relatório produz o documento com o resultado completo, útil para anexar a um processo de auditoria ou a uma proposta.
A barra mostra atendidos, parciais e pendentes sobre o total aplicável.
O detalhe que muda tudo está à direita: o perfil. Ele define quais requisitos se aplicam:
| Perfil | Avalia |
|---|---|
| Recursivo | Só os requisitos de resolvedor |
| Autoritativo | Só os requisitos de servidor de zonas |
| Ambos | Os dois conjuntos |
Perfil errado produz resultado errado nas duas direções: cobra requisitos que não se aplicam, ou deixa de cobrar os que se aplicam. Confira antes de tirar conclusão do número.
Cada linha tem o estado, o código do requisito e o que ele exige. Clicar abre a explicação e o que precisaria mudar.
Repare nas duas marcações à direita:
- Aplicado — o produto configurou isso, e a checagem confirma;
- Atestado — depende de algo fora deste servidor e foi declarado por um operador. O requisito de ter dois servidores de recursão, por exemplo, não é verificável de dentro de uma única máquina.
O estado parcial é o mais informativo: significa que existe configuração no caminho certo, mas não completa. É por onde começar.
O que fazer com o resultado
Confirme o perfil
Antes de qualquer coisa. Um servidor que só resolve não deveria ser cobrado por requisitos de zona.
Ataque os parciais primeiro
Eles costumam ser o menor esforço para o maior ganho: já existe algo configurado, falta completar.
Trate os pendentes por risco, não por quantidade
Fechar cinco requisitos cosméticos vale menos do que fechar um que deixa o servidor exposto. Vários deles têm receita própria nesta documentação — a ACL de recursão e a autorização de A transferência de uma zona inteira do servidor primário para o secundário, protegida por TSIG e por lista de IPs. aparecem aqui e são as de maior efeito.
Rode de novo depois de corrigir
E gere o relatório para registrar o antes e o depois.
Armadilhas
- Perfil errado invalida a leitura do placar inteiro.
- Tratar o resultado como nota. Não é prova: é uma lista de riscos conhecidos, e nem todos se aplicam à sua operação do mesmo jeito.
- Confiar num resultado antigo. A checagem não roda sozinha a cada mudança.
- Ignorar os parciais por parecerem menos graves — costumam ser os mais baratos de fechar.
- Esquecer que atestado não é verificado: alguém declarou. Se a realidade mudou, a declaração continua lá.