[ DNS e domínios ]

Compare respostas de vários servidores de nomes autorizados

Compare conjuntos de registros exatos em servidores autorizados para distinguir diferenças reais de publicação de pedidos de respostas inofensivos.

Pela equipe de pesquisa EmailAuth

[Pontos-chave]

  • Compare as respostas completas de cada endpoint de autoridade anunciado.
  • Normalize a ordem do conjunto de registros sem alterar os limites da string TXT .
  • As séries SOA correspondentes não comprovam o conteúdo da zona correspondente.
Nesta página

Diferentes servidores autorizados devem fornecer uma visão coerente da zona que atendem. Quando as verificações de autenticação discordam, consulte cada autoridade anunciada para saber o mesmo proprietário, tipo e classe. Mantenha as respostas não editadas antes de normalizá-las; uma lista concisa de valores pode ocultar referências, erros e sinalizadores de autoridade ausentes.

Estabeleça quais servidores são importantes

Referências: RFC 1034 §4.2, RFC 1035 §4.1.1.

Leia a delegação pai e compare-a com o conjunto NS do ápice filho. Resolva os nomes de servidores anunciados em endereços e registre qual endereço foi consultado. Um nome de host pode ter vários endereços e anycast pode rotear o mesmo endereço para instâncias diferentes. Uma consulta bem-sucedida, portanto, não prova que todos os back-end possíveis estejam atualizados.

Use uma consulta direta não recursiva, como cavar @SERVER_IP _dmarc.example .test. TXT +norecurse. Inspecione o código de resposta e o sinalizador AA, as seções de resposta e autoridade e qualquer alias. Uma referência ou resposta não oficial de um servidor que você esperava que fosse oficial é uma descoberta diferente de uma resposta oficial com conteúdo desatualizado.

Compare dados sem destruir a estrutura

Referências: RFC 2181 §5, RFC 1035 §3.3.14, RFC 1982 §3.2.

A ordenação do conjunto de registros DNS não é uma prioridade política. Classifique objetos de registro independentes para comparação, mas preserve a ordem das strings dentro de cada Registro TXT. Os TTLs podem diferir devido à configuração ou ao contexto da consulta; registre-os em vez de descartá-los silenciosamente. Uma contagem regressiva TTL recursiva não deve ser comparada como se fosse uma configuração de zona de autoridade.

Consulte SOA como contexto de suporte. Uma serial SOA não é um hash da zona. As séries correspondentes não podem provar registros correspondentes, e um número inteiro impresso maior não é universalmente mais novo porque a aritmética serial é encapsulada. De acordo com RFC 1982 , as comparações com exatamente metade do espaço serial são indefinidas; não os force a uma ordem mais nova/mais antiga. Compare diretamente os dados solicitados e use os registros de transferência ou publicação do provedor para explicar as diferenças.

Reproduza discordâncias e reordenações inofensivas

Crie duas autoridades isoladas, por exemplo.test. Ambos publicam o mesmo conjunto MX , mas retornam seus registros em ordens diferentes. A comparação normalizada esperada é igual. Em seguida, dê autoridade A _dmarc.example.test TXT "v=DMARC1; p=none" e B _dmarc.example.test TXT "v=DMARC1; p=reject". A comparação esperada é desigual, mesmo que ambas as séries SOA sejam deliberadamente iguais.

Consulte ambas as autoridades com o mesmo tipo e opções. Armazene endereço do servidor, carimbo de data/hora, código de resposta, sinalizadores, registros completos e serial. A comparação off-line original é complementada pela observação histórica de loopback retida abaixo. Nenhuma política pública ou servidor DNS de produção foi alterado.

Reparar o caminho de publicação

Referências: RFC 1034 §4.3.5, RFC 8767 §4.

Verifique se um servidor é secundário obsoleto, um provedor aposentado ainda presente na delegação ou um destino que nunca recebeu a atualização pretendida. Repare a publicação suportada ou o caminho de transferência em vez de fazer edições repetidas aleatórias em vários painéis. Confirme os mesmos dados esperados em todas as autoridades testadas após a alteração.

Repetir observações de redes relevantes quando houver suspeita de visualizações anycast ou divididas. Distinguir uma política de visão intencional de uma inconsistência pública acidental. Termine com evidências de correio recursivo e representativo porque o acordo oficial por si só não pode eliminar respostas já armazenadas em cache ou provar a autenticação de uma mensagem.

Evidências históricas de laboratório retidas

A captura retida é datada de 7 de novembro de 2026. A seguir descreve-se essa observação histórica limitada, não uma nova execução ou um teste de EmailAuth.ai .

Consultas UDP reais para duas autoridades de zona fixa de loopback retornadas p=none e p=reject para o mesmo proprietário absoluto TXT . Ambas as respostas tiveram AA definida. A captura preserva cada endpoint, hora UTC, TTL, tipo de resposta, código e bytes de ligação. Isto demonstra uma inconsistência real observada em laboratório; ele não pesquisa um serviço público anycast. Os rótulos de captura são autoridade_A_policy; autoridade_B_policy. O corredor retido e as capturas brutas estão incluídos neste pacote de revisão como evidência histórica. Eles foram inspecionados e não repetidos para esta revisão. DNS de produção, DNSSEC e os resultados SMTP permanecem não testados.

[ Remover ]

As séries SOA correspondentes não comprovam o conteúdo da zona correspondente.

[Por função]

O que isso significa para você

Escolha sua função para ver as próximas etapas práticas.

Administrador de TI/Correio

Compare registros estruturados

As diferenças de formatação podem ocultar ou exagerar uma incompatibilidade real.

Próximas etapas

  1. Consulte cada endpoint anunciado.
  2. Preservar sinalizadores e códigos de resposta.
  3. Mantenha os limites TXT intactos.

CISO/SecOps

Distinguir autoridade de confiança

Um sinalizador oficial não prova validação criptográfica.

Próximas etapas

  1. Investigue opiniões inexplicáveis.
  2. Retenha evidências brutas.
  3. Verifique DNSSEC separadamente.

Fundador / Não técnico

Exigir evidências de todas as rotas

Uma pesquisa verde pode deixar passar uma autoridade obsoleta.

Próximas etapas

  1. Atribuir propriedade DNS .
  2. Retenha o histórico de transição do provedor.
  3. Defina critérios de encerramento de incidentes.

[ Perguntas frequentes ]

Perguntas frequentes

A ordem dos registros é importante?

Não para comparar um conjunto de registros DNS não ordenado; A ordem das strings TXT dentro de um registro ainda é importante.

RFC 2181 §5 RFC 1035 §3.3.14

A série SOA igual prova conteúdo igual?

Não. Compare os registros reais solicitados.

RFC 1982 §3.2

Devo usar +short sozinho?

Não para a captura de evidências. Guarde bandeiras, códigos e seções também.

Um nome de servidor pode representar vários endpoints?

Sim. Pode resolver para vários endereços ou usar anycast.

O que significa AA?

A resposta é marcada como oficial para o nome consultado no contexto relevante; não é validação DNSSEC .

RFC 1035 §4.1.1

As visualizações intencionais DNS podem ser diferentes?

Sim. Documente a política de visualização e as origens da consulta antes de chamar a diferença de acidental.

A correção de um servidor limpará os caches recursivos?

Não. Os dados armazenados em cache anteriormente podem persistir.

RFC 8767 §4

Qual é a evidência de fechamento?

Dados de autoridade pretendidos correspondentes, um estado de publicação explicado e resolvedor de acompanhamento e verificações de correio.

[ Fontes ]

Fontes

  1. RFC 1034

    Seções §4.2 · §4.3.5

  2. RFC 1035

    Seções §3.3.14 · §4.1.1

  3. RFC 1982

    Seções §3.2

  4. RFC 2181

    Seções §5

  5. RFC 8767

    Seções §4

  6. Manual de escavação do BIND 9

    Seções Opções de consulta

[ Glossário ]

Glossário

Bandeira AA
O sinalizador de resposta autoritativa em uma resposta DNS .

RFC 1035 §4.1.1

Conjunto RR
Registros com o mesmo proprietário, classe e tipo.

RFC 2181 §5

Qualquer transmissão
Roteando o mesmo endereço de serviço para locais de rede diferentes.

Proveniência da empresa

Por que as principais instituições financeiras e governos retiraram seus painéis de segurança de e-mail.

As plataformas tradicionais de autenticação de e-mail vendem um painel e pedem que seus engenheiros façam o trabalho. Em ambientes de alto risco, a supervisão manual significa aplicação atrasada, desvios de configuração e domínios ocultos não monitorados.

EmailAuth é a plataforma de origem de e-mail agente. Nossos agentes impõem p=reject, mantenha remetentes terceiros alinhados e mova seus domínios para full RFC 9989 conformidade, o novo padrão DMARC , com auditabilidade humana no circuito.

Governos Grandes empresas Instituições financeiras de nível 1

SaaS · Locação dedicada · Air gap no local · Criptografia BYOK

Base de conhecimento