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


18

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?


2
Ce n'est pas une réfutation explicite, cependant! Ce sont simplement des données invalides.
Michael Hampton

Réponses:


21

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.


2
Merci. Le BCP: 32 / RFC 2606 Section 2 lit "" .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 sont invalides." 2606 ne dit rien pour indiquer que ".invalid" est uniquement pour les tests locaux. C'est pour tout domaine qui doit être, eh bien, invalide
Alpha Whisky

Ok je peux voir pourquoi quelque chose qui ressemble à ce pourrait être le nom d'un hôte serait désavantageux par rapport à ".".
Alpha Whisky

1
@AlphaWhiskey Ce sont les humains qui peuvent «regarder» quelque chose et tirer des conclusions. Les ordinateurs ont besoin d'instructions explicites.
Michael Hampton

3
pour être juste, il n'est pas exactement difficile de donner des instructions explicites aux ordinateurs dans ce cas particulier.
muhmuhten

@res Il est encore plus facile de ne pas donner aux ordinateurs cette instruction explicite.
musiKk

9

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 :

  1. 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.


Pour autant que je sache, il n'y a aucune raison technique qui .n'aurait pas pu être utilisée comme enregistrement MX si des enregistrements A ou AAAA avaient été publiés à la racine. Lorsque je tape, telnet . 25il recherche sûrement les enregistrements A et AAAA à la racine.
kasperd

1
@kasperd Bien que le protocole DNS puisse le représenter, je ne pense pas que le fait d'avoir des enregistrements d'adresse à .ou (pré-RFC7505) spécifiant .que la EXCHANGEvaleur d'un MXenregistrement serait réellement valide. (Ce n'est pas un nom d'hôte valide.)
Håkan Lindqvist

Valide ou non - je peux facilement imaginer des implémentations qui, face à un enregistrement MX pointant vers un domaine sans enregistrements A, réessayeront la livraison pendant des jours avant d'abandonner.
kasperd
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.