APRENDER. PRATICAR. EVOLUIR.Construir a cronologia por consumidor
Usa uma linha por entrada observada, com valor, instante de obtenção e TTL recebido. R1 obtém um A às 10:00 com TTL 600; R2 obtém o mesmo A às 10:04. Às 10:05 restam 300 e 540 segundos, respetivamente. A diferença não implica um erro. Este modelo exclui refresh antecipado, serve-stale e políticas locais. Escreve essas hipóteses ao lado do cálculo. Um prazo útil para uma entrada concreta não representa o comportamento de todas as caches e aplicações existentes.
Preparar a mudança antes da janela
Se o TTL antigo era 600 e todas as autoridades passam a 60 às 11:00, uma entrada recebida imediatamente antes ainda pode durar até perto das 11:10 no modelo simples. Reduzir o TTL no momento do cutover chega tarde para essa população. Para nomes novos, inclui a possibilidade de respostas negativas guardadas antes da criação. Define observações nos consumidores relevantes, capacidade de sobreposição e um plano de comunicação. Não uses a hora de gravação no portal como evidência de atualização de todos os clientes.
Rollback também tem uma população remanescente
R2 recebe o destino novo às 14:05 com TTL 60. A equipa reverte a autoridade às 14:05:20 depois de uma falha. Restam 40 segundos nessa entrada se não houver refresh antecipado. Planeia a mitigação para esse consumidor e mantém o estado do incidente baseado na recuperação observada. Além disso, uma aplicação pode conservar uma ligação TCP já estabelecida: uma nova resposta DNS não muda o destino dessa sessão. A investigação passa então pela política de reconexão e pelo ciclo de vida da aplicação.
Observar truncagem e repetição de facto
O runner usa apenas 127.0.0.1, numa porta efémera, e envia respostas fictícias ao dig 9.10.6 instalado. Para large.fund.test, a resposta UDP tem TC; a repetição normal usa TCP e recebe A. Com +ignore fica apenas a resposta truncada. Com +tcp a consulta começa diretamente em TCP. Os eventos do fixture mostram os transportes realmente usados. Este conjunto distingue uma saída incompleta de um transporte funcional e confirma que uma consulta A por TCP não é, por esse motivo, uma transferência AXFR.
Limites do ensaio e critérios de produção
As oito observações confirmam leitura e escolhas de transporte do cliente contra mensagens controladas. Não há resolver recursivo, expiração real de cache, percurso externo de delegação ou validação DNSSEC. Os cálculos temporais são exercícios, não medições de cache. A documentação BIND consultada identifica 9.20.29; não foi essa a versão executada. Em produção, um fecho exige testes autorizados nas origens relevantes, incluindo respostas que precisem de TCP. Serve-stale pode alterar expectativas após expiração quando o refresh falha; confirma a política antes de atribuir o resultado a corrupção.
# Execute the loopback fixture from the project root:
python3 content/labs/dns-evidence/run.py
# evidence.json records fallback: [udp, tcp]
# ignoredTruncation: [udp]; forcedTCP: [tcp]
# TTL examples are calculations, not measured resolver behavior.Caso fictício: uma regra deixa passar consultas UDP curtas, mas bloqueia TCP após TC. A escalada entrega a sequência de pacotes e a regra efetiva; o fecho inclui uma resposta completa pela origem afetada.
Armadilhas comuns
Não declares propagação global com base num TTL, não confundas +ignore com resposta completa e não uses sucesso em loopback como prova de conectividade de produção.
Tópicos relacionados: Resolver, autoridade e contexto do cliente · TTL, cache negativa e mudança controlada · Transporte DNS e validação DNSSEC
Calcula por entrada, observa por origem e reporta apenas o comportamento que os comandos, eventos e contexto realmente demonstram.
Referência: RFC 1035 · DNS RFC 1034/1035 with RFC 2181, 2308, 3596, 4033, 7766 and 8767; dig BIND 9.20