Pourquoi la RFC 7505 (Null MX) est-elle nécessaire?

IETF RFC 7505 décrit les enregistrements MX pour un domaine / hôte qui ne devrait explicitement pas recevoir de courrier électronique. Ceci est accompli en pointant le MX vers la racine du système de noms de domaine. Par exemple,

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

Pourquoi est-ce nécessaire? À ma connaissance, une réfutation explicite est disponible en utilisant des domaines sous le TLD invalid. Par exemple,

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

Je vois que la RFC 2782, DNS SRV, spécifie également que "Une cible de '.' signifie que le service n'est décidément pas disponible sur ce domaine. " Je suppose donc que ma question est:

Pourquoi devrions-nous utiliser la racine DNS pour signifier "non disponible" alors invalidqu'il sert déjà cette fonction?

Parce que ce n'est pas ce que vous êtes censé utiliser .invalid. Comme .exampleil est destiné aux tests et à la documentation locaux.

De plus, l'utilisation .invalidcontinue d'entraîner des choses supplémentaires - des recherches DNS supplémentaires et une file d'attente sur le serveur de messagerie pour des tentatives pour un sur le dessus de ma tête.

L'utilisation du "."format est censée provoquer une défaillance matérielle immédiate. Causer le MTA pour arrêter immédiatement la tentative de livraison. C'est du moins ainsi que se lit l'intro du RFC.

La question dans son ensemble touche à quelques aspects différents qui doivent tous être pris en considération pour savoir pourquoi la RFC7505 ajoute quelque chose d'utile.

Tout d'abord, la définition antérieure à la RFC7505 de la manière dont la remise du courrier doit être effectuée n'a aucun moyen d'indiquer clairement qu'aucune tentative de remise du courrier ne doit être effectuée pour un nom qui possède des enregistrements d'adresse.

De RFC7505 section 1 :

Les clients SMTP ont une séquence prescrite pour identifier un serveur qui accepte les e-mails pour un domaine. La section 5 de [RFC5321] couvre cela en détail; en substance, le client SMTP recherche d'abord un DNS MX RR et, s'il n'est pas trouvé, il revient à rechercher un DNS A ou AAAA RR. Par conséquent, cela surcharge un enregistrement DNS (qui a une mission principale différente) avec une sémantique de service de messagerie.

Si un domaine n'a pas d'enregistrements MX, les expéditeurs tenteront de remettre du courrier aux hôtes aux adresses dans les enregistrements A ou AAAA du domaine. S'il n'y a pas d'écouteurs SMTP aux adresses A / AAAA, la remise des messages sera tentée à plusieurs reprises pendant une longue période, généralement une semaine, avant que l'agent de transfert de courrier (MTA) expéditeur n'abandonne. Cela retardera la notification à l'expéditeur en cas de courrier mal acheminé et consommera des ressources chez l'expéditeur.

Ce document définit un MX nul qui entraînera l'échec immédiat de toutes les tentatives de remise de courrier vers un domaine, sans que les domaines ne créent d'écouteurs SMTP dédiés à la prévention des tentatives de remise.

Ensuite, il y a la question de savoir comment le RFC7505 implémente cela ( IN MX 0 .).

De la RFC7505 section 3 :

3. Enregistrements de ressources MX spécifiant Null MX

   Pour indiquer qu'un domaine n'accepte pas les e-mails, il annonce un seul MX RR (voir la section 3.3.9 de la [RFC1035]) avec une section RDATA composée du numéro de préférence 0 et d'une étiquette de longueur nulle, écrite dans les fichiers maîtres comme ". ", en tant que domaine d'échange, pour indiquer qu'il n'existe aucun échangeur de messagerie pour un domaine. Puisque "." n'est pas un nom d'hôte valide, un enregistrement MX nul ne peut pas être confondu avec un enregistrement MX ordinaire. L'utilisation de "." en tant que pseudo-nom d'hôte signifiant qu'aucun service disponible n'est modélisé sur le SRV RR [ RFC2782 ] où il a une signification similaire.

   Un domaine qui annonce un MX nul NE DOIT PAS annoncer un autre MX RR.

(pas d'italique dans l'original)

Comme indiqué ici, les détails de mise en œuvre pour le "MX nul" sont basés sur un modèle déjà établi du SRVtype RR. Il est logique d'imiter cela car le SRVtype RR est plus ou moins une version généralisée du MXtype RR.

Ainsi, la décision a été essentiellement prise déjà lors de la définition du SRVtype RR .

Alors pourquoi ne pas en profiter .invalid?

De la RFC2606 section2 :

".invalid" est destiné à être utilisé dans la construction en ligne de noms de domaine qui sont sûrs d'être invalides et dont il est évident en un coup d'œil qu'ils ne sont pas valides.

Comme on peut le voir ici, ce TLD réservé est destiné à la consommation humaine. Il n'y a pas de précédent pour définir une gestion spéciale de cela dans le logiciel.

Certes, il aurait pu être implémenté d'une manière différente, mais ils ont choisi d'adopter l'approche minimale d'utilisation ., qui n'est pas un nom d'hôte valide et n'interfère donc pas avec l'utilisation normale de toute façon.