La domanda nel suo insieme tocca alcuni aspetti diversi che devono essere presi in considerazione per rispondere al motivo per cui RFC7505 aggiunge qualcosa di utile.
Prima di tutto, la definizione pre-RFC7505 di come dovrebbe essere effettuata la consegna della posta non ha un modo per indicare chiaramente che non si dovrebbero fare tentativi di consegna della posta per un nome che ha record di indirizzo.
Dalla sezione 1 di RFC7505 :
I client SMTP hanno una sequenza prescritta per identificare un server che accetta la posta elettronica per un dominio. La sezione 5 di [RFC5321] tratta questo in dettaglio; in sostanza, il client SMTP cerca prima un RR MX DNS e, se non viene trovato, ricorre alla ricerca di un RR A o AAAA DNS. Quindi, questo sovraccarica un record DNS (che ha una missione primaria diversa) con un servizio di posta elettronica semantico.
Se un dominio non ha record MX, i mittenti tenteranno di recapitare la posta agli host agli indirizzi nei record A o AAAA del dominio. Se non ci sono listener SMTP presso gli indirizzi A / AAAA, la consegna dei messaggi verrà tentata ripetutamente per un lungo periodo, in genere una settimana, prima che il Mail Transfer Agent (MTA) mittente si dimetta. Ciò ritarderà la notifica al mittente in caso di posta errata e consumerà risorse a carico del mittente.
Questo documento definisce un MX nullo che causerà immediatamente tutti i tentativi di consegna della posta a un dominio, senza richiedere ai domini la creazione di listener SMTP dedicati alla prevenzione dei tentativi di consegna.
Quindi c'è la questione di come RFC7505 implementa questo ( IN MX 0 .).
Dalla sezione 3 di RFC7505 :
Record delle risorse MX che specificano Null MX
Per indicare che un dominio non accetta la posta elettronica, pubblicizza un singolo MX RR (vedere la Sezione 3.3.9 di [RFC1035]) con una sezione RDATA composta dal numero di preferenza 0 e un'etichetta di lunghezza zero, scritta in file master come ". ", come dominio di scambio, per indicare che non esiste uno scambiatore di posta per un dominio. Da "." non è un nome host valido, un record MX null non può essere confuso con un normale record MX.
L'uso di "." come pseudo-hostname che significa che nessun servizio disponibile è modellato su SRV RR [ RFC2782 ] dove ha un significato simile.
Un dominio che pubblicizza un MX null NON DEVE pubblicizzare nessun altro MX RR.
(enfasi aggiunta)
Come indicato qui, i dettagli di implementazione per "null MX" si basano su un modello già stabilito dal SRVtipo RR. Ha senso imitare questo dato che il SRVtipo RR è più o meno una versione generalizzata del MXtipo RR.
Quindi, la decisione è stata sostanzialmente presa già durante la definizione del SRVtipo RR .
Quindi, perché non usarlo .invalid?
Dalla sezione RFC26062 :
".invalid" è destinato all'uso nella costruzione online di nomi di dominio che sono sicuramente non validi e che a prima vista è evidente non sono validi.
Come si può vedere qui, questo TLD riservato è destinato al consumo umano. Non esiste un precedente per definire la gestione speciale di questo nel software.
Sicuramente avrebbe potuto essere implementato in un modo diverso, ma hanno scelto di seguire l'approccio minimale dell'utilizzo ., che non è un nome host valido e quindi non interferisce comunque con il normale utilizzo.