¿Por qué es necesario RFC 7505 (Null MX)?

IETF RFC 7505 describe los registros MX para un dominio / host que explícitamente no debería recibir correo electrónico. Esto se logra apuntando el MX a la raíz del Sistema de nombres de dominio. Por ejemplo,

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

¿Por qué se necesita esto? Según tengo entendido, la refutación explícita está disponible mediante el uso de dominios bajo el TLD invalid. Por ejemplo,

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

Veo que RFC 2782, DNS SRV, también especifica que "Un objetivo de '.' significa que el servicio definitivamente no está disponible en este dominio ". Entonces supongo que mi pregunta es:

¿Por qué deberíamos usar la raíz DNS para significar "no disponible" cuando invalidya cumple esta función?

Porque eso no es para lo que se supone que debes estar usando .invalid. Como .examplesi estuviera destinado a pruebas y documentación locales.

Además, el uso .invalidsigue provocando que sucedan cosas adicionales: búsquedas adicionales de DNS y colas en el servidor de correo para reintentos de uno fuera de mi cabeza.

"."Se supone que el uso del formato causa un fallo inmediato inmediato. Causar que el MTA deje de intentar la entrega de inmediato. Al menos así es como se lee la introducción al RFC.

La pregunta en su conjunto toca algunos aspectos diferentes que todos deben tenerse en cuenta para responder por qué RFC7505 agrega algo útil.

En primer lugar, la definición anterior a RFC7505 de cómo se debe hacer la entrega de correo no tiene una manera de indicar claramente que no se deben realizar intentos de entrega de correo para un nombre que tenga registros de direcciones.

De RFC7505 sección 1 :

Los clientes SMTP tienen una secuencia prescrita para identificar un servidor que acepta correo electrónico para un dominio. La Sección 5 de [RFC5321] cubre esto en detalle; en esencia, el cliente SMTP primero busca un DNS MX RR y, si no se encuentra, recurre a buscar un DNS A o AAAA RR. Por lo tanto, esto sobrecarga un registro DNS (que tiene una misión principal diferente) con un servicio semántico de correo electrónico.

Si un dominio no tiene registros MX, los remitentes intentarán entregar el correo a los hosts en las direcciones en los registros A o AAAA del dominio. Si no hay escuchas SMTP en las direcciones A / AAAA, la entrega del mensaje se intentará repetidamente durante un largo período, generalmente una semana, antes de que el Agente de transferencia de correo (MTA) que se remite se rinda. Esto retrasará la notificación al remitente en el caso de correo mal dirigido y consumirá recursos en el remitente.

Este documento define un MX nulo que hará que todos los intentos de entrega de correo a un dominio fallen inmediatamente, sin requerir que los dominios creen escuchas SMTP dedicadas a prevenir los intentos de entrega.

Luego está la cuestión de cómo RFC7505 implementa esto ( IN MX 0 .).

De RFC7505 sección 3 :

3. Registros de recursos MX que especifican MX nulo

   Para indicar que un dominio no acepta correo electrónico, anuncia un solo MX RR (consulte la Sección 3.3.9 de [RFC1035]) con una sección RDATA que consta del número de preferencia 0 y una etiqueta de longitud cero, escrita en archivos maestros como ". ", como dominio de intercambio, para indicar que no existe un intercambiador de correo para un dominio. Ya que "." no es un nombre de host válido, un registro MX nulo no se puede confundir con un registro MX ordinario. El uso de "." como un pseudo-nombre de host que significa que no hay servicio disponible se modela en el SRV RR [ RFC2782 ] donde tiene un significado similar.

   Un dominio que anuncia un MX nulo NO DEBE anunciar ningún otro MX RR.

(énfasis añadido)

Como se observa aquí, los detalles de implementación para el "MX nulo" se basan en un patrón ya establecido del SRVtipo RR. Tiene sentido imitar esto, ya que el SRVtipo RR es más o menos una versión generalizada del MXtipo RR.

Entonces, la decisión ya se había tomado esencialmente al definir el SRVtipo RR .

Entonces, ¿por qué no hacer uso de .invalid?

De RFC2606 sección2 :

".invalid" está destinado a usarse en la construcción en línea de nombres de dominio que seguramente no serán válidos y que es obvio a simple vista no lo son.

Como se puede ver aquí, este TLD reservado es para consumo humano. No hay precedentes de definir un manejo especial de esto en el software.

Seguramente podría haberse implementado de alguna manera diferente, pero eligieron seguir el enfoque mínimo de uso ., que no es un nombre de host válido y, por lo tanto, no interfiere con el uso normal de todos modos.