Por que o RFC 7505 (Null MX) é necessário?

O IETF RFC 7505 descreve os registros MX de um domínio / host que explicitamente não devem receber email. Isso é feito apontando o MX para a raiz do sistema de nomes de domínio. Por exemplo,

nomail.example.com. 86400 IN MX 0 "."

Por que isso é necessário? No meu entendimento, a refutação explícita está disponível usando domínios no TLD invalid. Por exemplo,

nomail.example.com. 86400 IN MX 0 "spam.invalid."
nomail.example.com. 86400 IN MX 10 "null.invalid."

Vejo que a RFC 2782, DNS SRV, também especifica que "Um destino de '.' significa que o serviço não está decididamente disponível neste domínio ". Então, suponho que minha pergunta seja:

Por que devemos usar a raiz do DNS para significar "não disponível" quando invalidjá atende a essa função?

Porque não é para isso que você deveria estar usando .invalid. Como .examplese destina a testes e documentação locais.

Além disso, o uso .invalidainda faz com que outras coisas aconteçam - pesquisas DNS adicionais e filas no servidor de correio para novas tentativas de uma delas em cima da minha cabeça.

O uso do "."formato causa uma falha imediata no disco rígido. Fazendo com que o MTA pare imediatamente a tentativa de entrega. Pelo menos é assim que se lê a introdução à RFC.

A questão como um todo aborda alguns aspectos diferentes que precisam ser levados em consideração para responder por que o RFC7505 acrescenta algo útil.

Primeiro, a definição anterior à RFC7505 de como a entrega de correio deve ser feita não tem como indicar claramente que nenhuma tentativa de entrega de correio deve ser feita para um nome que tenha registros de endereço.

Na seção 1 do RFC7505 :

Os clientes SMTP têm uma sequência prescrita para identificar um servidor que aceita email para um domínio. Seção 5 de [RFC5321] aborda isso em detalhes; em essência, o cliente SMTP primeiro consulta um RR de DNS MX e, se isso não for encontrado, volta a procurar um RR de DNS A ou AAAA. Portanto, isso sobrecarrega um registro DNS (que tem uma missão principal diferente) com uma semântica de serviço de email.

Se um domínio não tiver registros MX, os remetentes tentarão enviar email para os hosts nos endereços nos registros A ou AAAA do domínio. Se não houver ouvintes SMTP nos endereços A / AAAA, a entrega da mensagem será tentada repetidamente por um longo período, geralmente uma semana, antes que o MTA (agente de transferência de email) desista. Isso atrasará a notificação ao remetente no caso de correio mal direcionado e consumirá recursos no remetente.

Este documento define um MX nulo que fará com que todas as tentativas de entrega de correio em um domínio falhem imediatamente, sem exigir que os domínios criem ouvintes SMTP dedicados a impedir tentativas de entrega.

Depois, há a questão de como o RFC7505 implementa isso ( IN MX 0 .).

Na seção 3 do RFC7505 :

3. Registros de recursos MX que especificam MX nulo

   Para indicar que um domínio não aceita email, ele anuncia um único MX RR (consulte a Seção 3.3.9 de [RFC1035]) com uma seção RDATA que consiste no número de preferência 0 e um rótulo de comprimento zero, gravado em arquivos mestres como ". ", como o domínio de troca, para indicar que não existe um trocador de correio para um domínio. Desde a "." não é um nome de host válido, um registro MX nulo não pode ser confundido com um registro MX comum. O uso de "." como um pseudo-hostname, significando que nenhum serviço disponível é modelado no SRV RR [ RFC2782 ], onde ele tem um significado semelhante.

   Um domínio que anuncia um MX nulo NÃO DEVE anunciar nenhum outro MX RR.

(enfase adicionada)

Conforme observado aqui, os detalhes de implementação do "MX nulo" são baseados em um padrão já estabelecido do SRVtipo RR. Faz sentido imitar isso, pois o SRVtipo RR é mais ou menos uma versão generalizada do MXtipo RR.

Portanto, a decisão já foi tomada essencialmente ao definir o SRVtipo de RR .

Então, por que não fazer uso .invalid?

Na seção2 do RFC2606 :

".invalid" destina-se ao uso na construção online de nomes de domínio que certamente são inválidos e que é óbvio à primeira vista são inválidos.

Como pode ser visto aqui, este TLD reservado é para consumo humano. Não há precedentes para definir um tratamento especial disso no software.

Certamente poderia ter sido implementado de alguma maneira diferente, mas eles optaram por usar a abordagem mínima de uso ., que não é um nome de host válido e, portanto, não interfere no uso normal.