APRENDER. PRATICAR. EVOLUIR.Construir uma hipótese antes de escolher a alteração
SERVFAIL é o início de uma investigação, não o nome de uma causa. No JSON do laboratório, os cinco defeitos produzem esse código, mas os logs distinguem dados alterados, expiração, início futuro, ausência de assinatura e digest incompatível. Regista a consulta exata e o resolver que respondeu, depois relaciona a causa indicada com dados e configuração observáveis. Um Extended DNS Error, quando disponível, acrescenta contexto; não transforma a resposta num canal autenticado nem dispensa confirmar a origem. No caso fictício Mar, só uma região falha e o relógio do validador explica a diferença. Mudar chaves ou datas partilhadas antes dessa comparação aumentaria o impacto. A equipa L3 deve construir uma hipótese que possa ser contrariada por uma medição, identificar quem controla o componente e propor uma ação com efeito esperado.
Coordenar dependências de publicação e rotação
Uma alteração de confiança atravessa responsabilidades. A aplicação pode gerir o endereço, o operador DNS publicar chaves e assinaturas, e outra entidade manter DS. No caso Ponte, retirar a chave antiga antes de completar a transição deixou uma referência sem correspondência. O exercício pede um plano por fases: estado inicial conhecido, material que precisa de coexistir, responsável por cada publicação, evidência necessária antes da fase seguinte e condição de recuperação. Não inventes um prazo universal: os conjuntos, assinaturas, caches e política do ambiente fazem parte da análise. O key tag ajuda a localizar candidatos, mas não substitui a correspondência do digest. A assinatura autoconsistente de uma chave recém-publicada também não estabelece, sozinha, o ponto de confiança que os consumidores utilizam. Uma aprovação da aplicação não executa nem autoriza automaticamente a parte de outro responsável.
Confirmar recuperação no percurso normal
Uma reparação precisa de critérios que preservem a intenção do controlo. No caso Lago, duas autoridades devolvem o mesmo A, mas só uma publica o conjunto assinado completo. A comparação deve incluir dados e provas, seguida de consultas através dos resolvers afetados. Uma consulta com CD pode ajudar a isolar validação, mas não é o critério final de recuperação. Depois da correção, observa também o estado de cache e eventuais falhas retidas antes de repetir alterações. Mantém uma cronologia com publicação, consulta e confirmação do consumidor. Se for necessário retirar temporariamente uma autoridade, o responsável avalia capacidade, redundância, delegação e autorização; o laboratório não executa essa intervenção. A aplicação continua a precisar de validação TLS e de uma transação representativa. Dados DNS autenticados não demonstram disponibilidade, identidade ou resultado de negócio do serviço que utiliza o endereço.
Preparar uma decisão de readiness em quarenta minutos
O guião divide o trabalho em quatro blocos de dez minutos. Primeiro, compara o controlo válido com tampered e escreve o que CD permite observar. Depois, atribui causas e responsáveis a Mar, Ponte e Lago usando os dados dos casos. No terceiro bloco, define sequência de reparação, evidência por fase e uma alternativa aceitável, sem recorrer automaticamente a desativar validação. No último, apresenta a Cais uma matriz de requisitos e provas: validação local já medida, cadeia pública, rotação, provas negativas e aplicação ainda com trabalho próprio. O guião não foi realizado com participantes. Entrega uma recomendação de avançar ou adiar, com fundamento e ações pendentes atribuídas. Resumo: a qualidade da decisão depende de ligar cada afirmação à sua evidência. Mais testes do mesmo percurso não substituem requisitos que esse percurso nunca executou.
GUIÃO DE 40 MINUTOS
0–10: compara valid e tampered; escreve o significado e os limites de CD e AD.
10–20: atribui hipóteses e responsáveis para Mar, Ponte e Lago.
20–30: define reparação, alternativa, critérios por fase e risco residual.
30–40: apresenta a matriz de readiness de Cais e uma decisão fundamentada.
ENTREGÁVEL
Requisito | evidência existente | evidência em falta | responsável | critério de aceitação.
Inclui consulta normal, confiança, tempo, estado de cache e transação de aplicação.
EXECUTAR O RUNNER DA AULA ANTERIOR
python3 dns-validation.py --unbound /caminho/unbound --checkconf /caminho/unbound-checkconf --openssl /caminho/openssl --dig /caminho/dig --output dns-validation-evidence.json
Pré-requisitos: Python 3, Unbound 1.26.1, checkconf correspondente, OpenSSL 3 e dig.
Execução registada: Python 3.13.1, OpenSSL 3.6.1, dig 9.10.6. Conta sem .digrc pessoal.
Usa apenas loopback, gera chave temporária e não altera DNS do sistema.Ponte publicou DNSKEY nova sem completar a mudança de DS. O plano de recuperação reúne os responsáveis pelos dois elos e define como confirmar cada fase.
Armadilhas comuns
Tratar SERVFAIL como causa única, retirar chaves cedo demais, aceitar sucesso com CD, ignorar relógios e confundir uma demonstração local com aceitação da migração.
Tópicos relacionados: Gestão de mudanças e rollback · Observabilidade e incidentes
A recuperação deve funcionar com a política normal de confiança. A passagem para RUN precisa de responsáveis, evidência por requisito e limites explícitos.
Referência: RFC 6781: DNSSEC operational practices · DNS RFC 1034/1035 with RFC 2181, 2308, 3596, 4033, 7766 and 8767; dig BIND 9.20