Um registro de autenticação pode parecer local em um console DNS , dependendo dos servidores de nomes ou registros de outra organização. Para avaliar a disponibilidade, siga o caminho de resolução e autenticação em vez de contar fornecedores ou observar o número de tempo de atividade do painel. A questão útil é qual dependência deve responder quando um receptor avalia esta mensagem específica.
Distinguir os mecanismos de delegação
Uma zona DNS delegada transfere autoridade para nomes abaixo de um limite de zona para servidores de nomes especificados. UM CNAME aponta um nome para outro nome. SPF incluir e redirecionar são relacionamentos de política em nível de aplicativo, não delegação de zona. Eles criam diferentes caminhos de falha e não podem ser avaliados como formas intercambiáveis de hospedagem. RFC 1034 explica o serviço autoritativo e a resolução recursiva; RFC 7208 especifica o uso de DNS pelo SPF .
Desenhe o nome exato do proprietário e o tipo de registro para cada etapa. Para DKIM isso começa com o seletor em _domainkey para o domínio de assinatura. Para SPF , comece com a identidade autenticada relevante e siga os termos da política. Para DMARC, avalie a dependência da descoberta de políticas separadamente. Um provedor pode operar dois deles sem operar o terceiro.
Registre a semântica da falha, não apenas o tempo de atividade
Pergunte o que acontece se o destino não retornar dados, uma resposta negativa explícita, uma política malformada ou um tempo limite. Esses não são equivalentes. SPF definiu resultados de erros permanentes e temporários. A verificação DKIM pode ser afetada por informações de chave indisponíveis ou inválidas. O tratamento final da mensagem de um destinatário também pode depender de outro caminho de autenticação alinhado e de uma política local, portanto, evite prometer que uma falha de pesquisa sempre bloqueará ou sempre entregará mensagens.
O cache pode preservar temporariamente uma resposta utilizável anterior, mas não é um backup ilimitado. Registre o TTL da resposta e o tempo de observação. As respostas negativas também podem ser armazenadas em cache de acordo com as regras descritas em RFC 2308. Reduzir um TTL agora não encurta retroativamente o tempo de vida das respostas já armazenadas em cache em outro lugar.
Compare duas dependências de recuperação
Suponha que uma consulta autoritativa aprovada retorne um alvo de seletor recém-configurado enquanto um resolvedor recursivo ainda retorne o alvo armazenado em cache anterior. Registre fontes e carimbos de data/hora. A mudança oficial é observada nesse servidor; isso não prova que todos os receptores usam o novo alvo. Agora, suponha que o serviço de assinatura substituto não possua a chave privada correspondente. Mesmo depois de cada pesquisa relevante ser corrigida, DNS sozinho não consegue fazer com que esse serviço seja assinado com sucesso.
Estas são observações hipotéticas, não um laboratório DNS local ou um teste de produção. Eles levam às próximas etapas separadas: verificar o cache e a resolução de destino em pontos de vantagem aprovados e verificar a configuração real e a saída da mensagem do assinante substituto. Retenha o servidor, nome, tipo, código de resposta, sinalizadores, TTL e resposta completa. Este exemplo não exerce DNSSEC, referências ou cache negativo; teste-os independentemente onde a arquitetura os exigir.
Decida se a dependência é aceitável
Atribua um proprietário para cada alvo externo e documente as medidas reais de recuperação e saída do fornecedor. Considere se você pode substituir o registro, se possui os metadados públicos necessários e se uma alteração na assinatura requer ação dentro de outro serviço. Vários painéis na mesma infraestrutura autoritativa não removem essa dependência compartilhada.
Teste uma substituição em um ambiente autorizado e defina quando uma interrupção aciona uma alteração em vez de uma observação. Uma edição apressada pode adicionar um erro SPF ou apontar um seletor para a chave errada. Mantenha o registro anterior e um registro de decisões, mas reconheça que a recuperação é limitada por caches e qualquer perda de acesso. O resultado deve ser uma decisão de risco específica de dependência com evidências, e não uma afirmação de que toda a delegação DNS é insegura.