Um incidente de autenticação geralmente contém vários relógios: o intervalo coberto por um relatório, a chegada do relatório, uma alteração DNS , uma implantação de aplicativo e um teste controlado. Colocá-los em uma linha do tempo só será útil se cada evento mantiver seu significado original. Um diário relatório agregado geralmente não é possível informar o minuto exato em que cada mensagem incluída falhou.
Estabeleça uma base de tempo comum
Referências: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Normalize os carimbos de data/hora exibidos para um fuso horário declarado, mantendo os valores e a precisão originais. Registre as fontes do relógio e a incerteza conhecida. Distinguir o intervalo do relatório dos carimbos de data/hora de chegada e ingestão. A entrega tardia do relatório não deve ser plotada como uma nova explosão de envio no momento em que o anexo chegou.
Defina o escopo da investigação para um domínio de autor e um serviço verificado sempre que possível. Mantenha as fontes não classificadas separadas. Preserve a identidade do repórter e do relatório, contagens de mensagens, grupos de origem e identidades avaliadas, juntamente com decisões duplicadas e sobrepostas. Esses detalhes determinam quais observações podem ser legitimamente comparadas.
Adicione evidências DNS sem reescrever o histórico
Referências: RFC 1034 §3.6, RFC 8767 §4, RFC 9990 §3.3.
Registre a alteração aprovada, o tempo de publicação pretendido, as observações oficiais e quaisquer amostras do resolvedor, incluindo o tempo de pesquisa e o TTL retornado. Uma resposta DNS recente estabelece o que a pesquisa observou agora; não é uma história completa do que cada receptor viu anteriormente.
O cache DNS é importante em RFC 1034 §3.6; qualificando o comportamento de serviço obsoleto sob RFC 8767 §4 pode estender o uso do cache além da atualização normal. Não afirme que todos os receptores mudaram no momento da publicação ou que exatamente um exibiu o TTL posteriormente. Preservar a configuração anterior, o log de alterações e os limites de evidências. Quando um intervalo de relatório abrange uma mudança de política, rotule-o como misto ou potencialmente misto, em vez de atribuir cada observação à política final.
Adicionar evidências do aplicativo e do receptor
Referências: RFC 5321 §4.2.5.
Coloque implantações de aplicativos, alterações de gateway e alterações de assinatura ao lado dos eventos DNS . Mantenha testes controlados como observações individuais com sua rota, receptor e resultado reais. Um log de aplicação pode mostrar submissão ou aceitação em um salto; não estabelece necessariamente a entrega final.
Use esses tipos de evidências para testar explicações concorrentes. Um aumento de falhas após uma edição DNS também pode coincidir com um novo modelo que altera o conteúdo assinado. A correlação restringe a investigação, mas não identifica a causa sem mais evidências.
Trabalhe em um cronograma limitado
Caso ilustrativo: um relatório abrange das 00h00 às 24h00 UTC. Uma mudança de política é registrada às 12h, e um teste controlado às 12h20 passa alinhado DKIM. O relatório contém 80 observações aprovadas e 20 falhas, chegando na manhã seguinte às 05:00.
Você pode indicar os totais do intervalo e o teste bem-sucedido às 12h20. Você não pode atribuir todas as 20 falhas antes do meio-dia apenas porque o teste foi aprovado mais tarde. A próxima ação é obter evidências de receptor ou aplicação mais restritas, ou executar testes representativos adicionais. A chegada às 05h00 é um evento de cobrança e não o horário das 20 falhas.
Encerre com uma declaração causal da força certa
Rotule as conclusões como observadas, corroboradas ou ainda hipotéticas. Cite as evidências que apoiam a causa suspeita e qualquer explicação concorrente não descartada. Se a ligação exata for impossível, mantenha a incerteza em vez de traçar um limite de falha preciso no gráfico.
Salve a linha do tempo com referências de origem, revisão de consulta, intervalos incluídos e classificações de propriedade. Registre o próximo gatilho de verificação, como o primeiro período de relatório comparável completo após um reparo. Um cronograma reutilizável deverá permitir que outro analista reconstrua tanto os factos como os limites da conclusão.
Continuar a investigação
Use o passo a passo do relatório agregado para os campos subjacentes e o guia de diagnóstico de alinhamento quando o sucesso da autenticação bruta não satisfaz DMARC.
Mantenha a ilustração dentro de suas evidências
Para o intervalo fictício de 80 passagens/20 falhas, mantenha todos os 20 tempos de falha desconhecidos. O teste das 12h20 é uma observação posterior e a chegada às 5h é um evento de coleta. Nenhuma pesquisa DNS real ou teste de autenticação foi executado, e a linha do tempo não localiza uma transição causal comprovada.