APRENDER. PRATICAR. EVOLUIR.Observar a política que está realmente em execução
O segundo processo do runner recebe dados com TTL trinta segundos, mas aplica cache-max-ttl de dois segundos. A observação seguinte, depois desse limite, obtém o valor atualizado com um novo pedido à fixture. O terceiro processo faz a experiência inversa: a fixture publica TTL um segundo e cache-min-ttl vale quatro. Ao fim de um segundo e meio, o endereço anterior ainda é servido sem novo pedido. São configurações deliberadas do laboratório, não recomendações de produção. Compara os ficheiros de configuração guardados em configurations e os resultados maximumTTL e minimumTTL. Explica por que razão consultar apenas a autoridade seria insuficiente para prever a resposta de cada instância. No caso fictício Farol, a equipa planeou retirar um endpoint com base no TTL publicado sem conhecer o mínimo do resolver gerido. A decisão deve ser revista antes de cortar esse endpoint.
Separar os mecanismos para evitar conclusões erradas
O runner mantém prefetch e serve-expired desativados. Isso torna a sequência observada mais simples, mas limita o que se pode concluir sobre outros ambientes. Um ensaio com renovação antecipada ou dados expirados precisaria de hipóteses e instrumentação próprias. Também usa iterator sem validator: as verificações não demonstram DNSSEC. A zona fund.test tem uma exceção local transparente e um stub dirigido à fixture; o restante espaço tem política local refuse. Assim, o objetivo é medir cache com dados controlados, sem depender de delegações públicas. Não copies esta configuração para um resolver partilhado. Ao adaptar o laboratório, altera uma variável de cada vez e conserva a configuração anterior como referência. Se não houver pedidos à fixture, verifica primeiro se uma resposta local ou uma consulta à porta errada desviou o percurso. Um contador vazio pode ser evidência útil de uma hipótese incorreta.
Conduzir uma revisão de mudança com evidência
O guião abaixo propõe quarenta minutos de trabalho. Nos primeiros dez, identifica os participantes fictícios: responsável da aplicação, DNS, produção e gestor do projeto. Distingue quem publica, quem gere a cache e quem confirma o consumidor. Nos dez minutos seguintes, lê os resultados de Farol e decide a sobreposição necessária, sem transformar o número do laboratório num SLA real. Depois avalia Cais e Ria: um nome criado tarde pode exigir observação de resposta negativa; um AAAA recém-publicado exige acompanhamento do tipo e do percurso IPv6. Nos últimos dez minutos, prepara a passagem para RUN com critérios mensuráveis, dependências e um ponto de decisão. O guião não foi realizado com participantes; é uma atividade para o formando. Entrega um plano curto que possa ser contestado com dados, em vez de uma lista de comandos sem contexto de negócio.
Definir o que permite aceitar ou adiar
Uma proposta de aceitação deve indicar o nome e tipo esperados, as origens relevantes, o resolver observado e a operação de negócio a executar. Acrescenta a verificação de ligações antigas quando a aplicação as reutiliza, a capacidade de manter o endpoint anterior e o responsável por autorizar a retirada. Uma limpeza seletiva pode ser uma opção quando permitida, mas precisa de efeito esperado, âmbito e validação posterior. Uma limpeza global não é automaticamente mais segura e pode provocar carga desnecessária. No caso Duna, o relatório local fica aceite como evidência de cache; DNSSEC e aplicação continuam com ações próprias. Resumo: trata TTL, política local e consumo como entradas do plano de mudança. Relaciona os resultados com observabilidade, gestão de incidentes e critérios de handover. A qualidade da decisão depende de reconhecer tanto o que foi medido como o que permanece sem prova.
GUIÃO DE 40 MINUTOS
0–10: identifica responsáveis, nome, tipo, resolver e origem.
10–20: compara positive, negative, nodata, maximumTTL e minimumTTL no JSON.
20–30: decide para Cais, Ria e Farol; regista alternativa e risco residual.
30–40: define aceitação, rollback, sobreposição e ações pendentes de Duna.
ENTREGÁVEIS
Uma linha por consumidor: publicação esperada | resposta observada | tempo | política | prova de aplicação | responsável.
Uma decisão de avançar/adiar com fundamento, prazo e evidência em falta.
EXECUTAR O CÓDIGO DA AULA ANTERIOR
python3 dns-cache.py --unbound /caminho/unbound --checkconf /caminho/unbound-checkconf --dig /caminho/dig --output dns-cache-evidence.json
Pré-requisitos: Unbound 1.26.1, checkconf da mesma versão, Python 3 e dig; conta sem .digrc pessoal.
A versão executada foi Python 3.13.1 com dig 9.10.6. Não altera DNS do sistema.Farol publicou TTL 30, mas a instância tem mínimo 300. A equipa mantém a sobreposição e revê a retirada com DNS e com os consumidores.
Armadilhas comuns
Aplicar configurações experimentais em produção, ignorar política efetiva, confundir cache com DNSSEC e assumir que uma resposta DNS fecha a validação do serviço.
Tópicos relacionados: Planeamento de rollback · Passagem para produção
A aceitação precisa do percurso real do consumidor e de critérios explícitos. Um teste local prova apenas os comportamentos que efetivamente executou.
Referência: Unbound configuration manual · DNS RFC 1034/1035 with RFC 2181, 2308, 3596, 4033, 7766 and 8767; dig BIND 9.20