Uma etiqueta de limite não é um certificado de propriedade
A tag psd informa o atual DMARC algoritmo de descoberta como interpretar a posição de um registro de política na hierarquia DNS . Ele não transfere a propriedade do domínio, não autoriza um serviço hospedado nem prova que um operador de sufixo público controla todos os remetentes abaixo dele. Sua importância operacional é mais restrita e substancial: a etiqueta pode interromper a caminhada nas árvores e influenciar o domínio organizacional usado para relaxar alinhamento, bem como a política disponível quando um inquilino não publica nenhuma.
Seção 4.7 RFC 9989 define y, n e o padrão u. Um registro y identifica um Domínio de Sufixo Público. Um registro n identifica explicitamente o limite organizacional desse domínio e seus subdomínios. Um registro u, incluindo uma tag omitida, não determina se o domínio é organizacional; a descoberta deve resolver essa questão. Uma tag psd ausente, portanto, não é equivalente a psd=n.
Comece com a função do operador
Um Operador de Sufixo Público ocupa uma função diferente de um registrante ou inquilino comum. Sob seção 5.2, um PSO participante deve publicar psd=y. Esta é uma declaração dentro do protocolo DMARC , não uma lista de uso geral de limites de registro. Revise quem controla a zona DNS relevante, quais organizações independentes existem abaixo dela e se a implantação proposta realmente tem a função de PSO descrita na especificação.
Uma organização que opera subdomínios para suas próprias equipes não deve definir y apenas porque o domínio tem filhos. Por outro lado, n pode tornar explícito um limite organizacional pretendido em vez de confiar em padrões. Essa mudança pode alterar os cálculos de alinhamento relaxado para identidades subordinadas, de modo que seu efeito merece uma comparação controlada com os registros existentes e os caminhos de envio reais. Uma tag sintaticamente válida não é prova de que o limite escolhido corresponde ao modelo de segurança da organização.
Siga um caso fictício de sufixo público
Suponha que registry.example seja um sufixo público fictício e tenant.registry.example pertença a um inquilino fictício. O domínio do autor é alerts.tenant.registry.example . Nem esse nome nem tenant.registry.example publicam uma política DMARC neste dispositivo. O registro em _dmarc.registry.example é v=DMARC1;p=reject; psd=y. Nenhuma pesquisa foi executada; esses fatos são estipulados para o exemplo trabalhado.
A caminhada sobe do Domínio do Autor, chega a registry.example e para em y. Como este não é o domínio inicial, seção 4.10.2 identifica o domínio um rótulo abaixo dele, tenant.registry.example , como o domínio organizacional. Sem política de inquilino ou domínio de autor, o registro PSD fornece a política na seção 4.10.1. Neste registro específico não há substituição de sp ou np, então p fornece a avaliação solicitada.
Não generalize esse exemplo para y no domínio inicial. A regra one-label-below exclui explicitamente o registro inicial. A regra de parada genérica e a regra de seleção do domínio organizacional são etapas separadas. Um acessório de conformidade deve exercer essa vantagem em vez de fabricar um domínio organizacional filho que nunca fez parte do caminho de pesquisa.
Compare n explícito com o padrão u
Altere o registro de inquilino fictício para v=DMARC1;p=quarantine; psd=n. Agora a caminhada para em tenant.registry.example . Esse domínio é organizacional, a sua política tem precedência sobre o substituto do PSD e a pesquisa não precisa ascender a registry.example . A preferência de rejeição do operador superior não substitui esse registro de inquilino apenas porque parece mais rigoroso.
Para obter um exemplo separado de descoberta padrão, comece em alerts.team.tenant.registry.example . Deixe que team.tenant.registry.example e tenant.registry.example tenham registros válidos com psd omitido ou definido como u. Suponha que não haja registros válidos em registry.example ou example. A caminhada não para no primeiro registro; o registro válido com o menor número de rótulos identifica tenant.registry.example como organizacional. Este é um resultado padrão derivado de todo o conjunto de candidatos relevantes, não uma promessa de que todo domínio portador de u é um limite organizacional.
O mesmo algoritmo também contém um retorno ao alvo inicial quando não consegue determinar um domínio organizacional. Mantenha “nenhum limite determinado”, “nenhuma política aplicável” e “erro DNS ” distintos no resultado da revisão. Eles não justificam a invenção de um limite de sufixo a partir da intuição ou a substituição silenciosa de um antigo resultado de lista de sufixos públicos.
Mantenha os relatórios de inquilinos separados dos relatórios de sufixos
A precedência da política tem uma consequência na privacidade. Seção 4.10.1 diz que a política do PSD não é usada para um domínio organizacional que publica a sua própria política DMARC . O operador de sufixo não pode usar seu registro para preencher endereços de relatórios omitidos por um inquilino. Um traço que funde a política do inquilino com os valores rua ou ruf do PSD não é o mecanismo descrito.
Relatórios de falhas são especialmente sensíveis em sufixos multiorganizacionais. Seção 10.2 proíbe ruf em Registros DMARC publicados por PSDs abrangendo múltiplas organizações. Isso não é resolvido chamando o destinatário de uma equipe central de segurança. Os relatórios agregados têm suas próprias considerações de privacidade, e a aprovação organizacional ainda é necessária antes que os destinos reais dos relatórios ou conjuntos de dados sejam alterados.
Verifique o significado e a implantação do protocolo de forma independente
A comissão exata é: Mostrar um exemplo de sufixo, domínio organizacional e descoberta padrão com referências RFC atuais. Os três exemplos fictícios acima fornecem os resultados esperados do documentário, com suposições completas retidas antes da elaboração. Eles não são dispositivos DNS reais, um inventário de inquilinos ou comportamento observado do receptor. Essas portas operacionais e de aplicabilidade permanecem abertas, juntamente com a verificação das erratas atuais e a aceitação por especialistas.
Para uma futura avaliação autorizada, retenha o conjunto completo de políticas e os domínios organizacionais descobertos pelo destinatário tanto para o Domínio do Autor quanto para as identidades autenticadas. Compare os limites atuais e propostos sem assumir que todos os receptores adotaram RFC 9989. Aumente o controle de inquilinos conflitantes ou o alinhamento relaxado inesperado antes da publicação. O resultado desejado é um limite acordado com evidências, e não uma etiqueta adicionada apenas porque aparece em um novo registro.