Pourquoi les enregistrements MX ne peuvent-ils pas pointer vers une adresse IP?


89

Je comprends que vous ne devriez pas pointer un enregistrement MX à une adresse IP directement, mais devrait pointer à la place à un Aenregistrement, qui, à son tour, pointe vers l'adresse IP de votre serveur de messagerie.

Mais, en principe, pourquoi est-ce nécessaire?


Si vous pouvez configurer un enregistrement MX, vous pouvez également configurer un enregistrement A. Je ne vois pas le problème ici.
joshudson

26
@ joshudson Ce n'est pas un problème du tout, juste moi essayant de comprendre pourquoi plutôt que de simplement suivre ce que tout le monde fait.
dayuloli

Je viens d'essayer dans CloudFlare. Il n'accepte pas l'adresse IP comme valeur pour l'enregistrement MX.
LinuxBabe

Je ne m'en étais jamais préoccupé jusqu'à ce que j'ajoute un enregistrement SPF et effectuais trop de recherches. Devait trouver un moyen différent de couper certains.
gbryant

Réponses:


90

L'idée derrière l'enregistrement MX est de spécifier un hôte ou des hôtes qui peuvent accepter le courrier pour un domaine. Comme spécifié dans la RFC 1035 , l'enregistrement MX contient un nom de domaine. Il doit donc pointer vers un hôte qui peut lui-même être résolu dans le DNS. Une adresse IP ne peut pas être utilisée car elle serait interprétée comme un nom de domaine non qualifié, qui ne peut pas être résolu.

Les raisons de ceci dans les années 1980, lorsque les spécifications ont été écrites à l'origine, sont presque identiques à celles d'aujourd'hui: Un hôte peut être connecté à plusieurs réseaux et utiliser plusieurs protocoles.

Dans les années 80, il n’était pas rare d’avoir des passerelles de messagerie qui se connectaient à la fois au Internet (relativement nouveau) utilisant TCP / IP et à d’autres réseaux existants, qui utilisaient souvent d’autres protocoles. Spécifier MX de cette manière autorisait les enregistrements DNS pouvant indiquer comment atteindre un tel hôte sur un réseau autre qu'Internet, tel que Chaosnet . En pratique, cependant, cela n’est presque jamais arrivé; pratiquement tout le monde a réorganisé ses réseaux pour devenir une partie d'Internet.

Aujourd'hui, un hôte peut être atteint par plusieurs protocoles (IPv4 et IPv6) et par plusieurs adresses IP dans chaque protocole. Un seul enregistrement MX ne peut pas répertorier plus d'une adresse. La seule option est donc de pointer vers un hôte, où toutes les adresses de cet hôte peuvent ensuite être recherchées. (À titre d'optimisation des performances, le serveur DNS enverra les enregistrements d'adresse de l'hôte dans la section supplémentaire de réponse s'il possède des enregistrements faisant autorité pour eux, en sauvegardant un aller-retour.)

Il arrive également que vos échangeurs de courrier soient fournis par un tiers (par exemple, Google Apps ou Office 365). Vous pointez vos enregistrements MX vers leurs noms d’hôtes, mais il se peut que le fournisseur de services doive modifier les adresses IP des serveurs de messagerie. Étant donné que vous avez désigné un hôte, le fournisseur de service peut le faire de manière transparente et vous n'avez pas à modifier vos enregistrements.


2
Cela n'empêche pas vraiment la compatibilité avec les adresses IP; En fait, la plupart des serveurs / clients SMTP fonctionnent parfaitement avec les adresses IP des enregistrements MX, à la suite des quelques tests que j'ai effectués. Je pense que l'intention était de décourager l'industrie d'utiliser massivement les adresses IP - ce qui serait probablement ce qui se serait passé si cette règle n'avait pas été énoncée - plutôt que au cas par cas. Par conséquent, "devrait", par opposition à "doit". +1 pour la grande info, cependant. Je n'avais jamais envisagé la plupart de cela.
Zenexer

16
@Zenexer Les lois de la circulation ne sont pas là pour le dérangement de relativement peu de conducteurs experts qui savent exactement ce qui est sûr et ce qui ne l'est pas. Ils existent à cause du sous-ensemble beaucoup plus important de putains d'idiots qui pensent savoir ce qu'ils font mais ne le savent pas.
Shadur

7
@Zenexer Vous constaterez peut-être qu'un MTA le tolère aujourd'hui et pas demain. Après tout, ce n’est pas un comportement permis par la norme. Et bien sûr, tous les MTA ne le prendront pas en charge, ce qui signifie que vous êtes assuré de perdre du courrier.
Michael Hampton

1
@ MichaelHampton: Si un enregistrement MX DEVRAIT contenir un nom d'hôte au lieu d'une adresse IP, alors un MTA DOIT accepter une adresse IP. En théorie, si un enregistrement MX DOIT contenir un nom d’hôte, un MTA DEVRAIT accepter une adresse IP. Voilà comment le travail de RFC. La contrepartie à un avis de mise en œuvre "DEVRAIT" peut optimiser l'hypothèse selon laquelle l'avis est suivi, mais c'est à peu près tout ce que vous pouvez faire avec.
MSalters

2
@MSalters, je pense que vous êtes confus. Je n'ai jamais dit faut rien. En effet, j'ai dit que l'enregistrement MX DOIT contenir un nom d'hôte, ce qui est également ce que disent les RFC.
Michael Hampton

18

Le DNS en tant que protocole a différents types de valeurs, celles-ci ne sont pas interchangeables.

Il est important de noter que le DNS est un protocole binaire avec des correspondances strictes entre le type d'enregistrement et le type de données qu'un tel enregistrement contient.

Par exemple:
Un Aenregistrement contient une adresse IPv4 (4 octets de données, longueur fixe).
Un AAAAenregistrement contient une adresse IPv6 (16 octets de données, longueur fixe).

Un MXenregistrement, par contre, contient un nom (une séquence d'étiquettes sur le format <int number of bytes> <label> <int number of bytes> <label> <int 0>, longueur variable).

Il n'est pas possible pour un MXenregistrement d'avoir une adresse IP comme données.


Vous pouvez faire en sorte que l’étiquette soit la représentation textuelle d’une adresse IP, mais cela n’a aucun sens de le faire, car elle ne peut pas être résolue en tant que nom d’hôte.
Michael Hampton

@MichaelHampton En effet, il est possible d'avoir un nom avec des étiquettes entièrement numériques qui, dans une représentation conviviale, ressemble à une adresse IPv4 à première vue. Cela ne change rien en ce qui concerne la question, car il s'agirait toujours d'un nom et sera donc traité comme un nom (un nom qui, du moins sur l'Internet public, ne sera que NXDOMAIN).
Håkan Lindqvist

Cela ne répond pas vraiment à la question du PO. Vous dites essentiellement "parce que c'est comme ça" .
dr01

@ dr01 En considérant que la question montre clairement que vous n'êtes pas au courant de "la façon dont il est" ("vous ne devez pas pointer directement un enregistrement MX sur une adresse IP, mais plutôt le pointer sur un enregistrement A" alors que ce n'est pas une possibilité de n’ont aucune valeur autre qu’un nom), je ne pense pas qu’il soit déplacé de rappeler l’état actuel des choses et pourquoi cela rend toute autre option impossible. J'ai l'impression que vous lisez beaucoup dans la question qui n'est pas vraiment là.
Håkan Lindqvist

@ dr01 C'est-à-dire, ne pensez pas que la question se lit comme une question académique sur les décisions de conception dans les premiers jours de DNS ou quelque chose du genre, mais simplement sur la manière dont les MXenregistrements qui existent réellement dans le monde peuvent ou devraient être utilisés.
Håkan Lindqvist

6

Je vais jeter cela comme une supposition. Bien sûr, je suis à la maison avec la grippe, alors peut-être que je suis en manque

La RFC 974 déclare:

La première étape pour l’éditeur de courrier chez LOCAL consiste à émettre une requête pour les enregistrements de droits de reproduction MX pour REMOTE. Il est vivement recommandé que cette étape soit prise chaque fois qu'un expéditeur tente d'envoyer le message. Nous espérons que les expéditeurs utiliseront rapidement les modifications apportées à la base de données de domaines. Les administrateurs de domaine pourront ainsi rediriger les messages en transit destinés aux hôtes défectueux en modifiant simplement leurs bases de données de domaines.

En demandant un nom à la place de la propriété intellectuelle, cela encourage fortement cette pratique. Les noms peuvent rester les mêmes et, en cas d'équilibrage de charge ou de reprise après sinistre, vous n'aurez plus à vous soucier de modifier l'enregistrement MX lui-même et d'attendre la propagation DNS.


8
Répondre aux questions de la pile d'échange pendant votre jour de congé alors que vous êtes malade de la grippe ... Je vous tire mon chapeau, mon cher monsieur!
Mike B

3

Certains serveurs de messagerie (tels que exim) n'autorisant pas spécifiquement l'envoi d'enregistrements MX pointant vers une adresse IP pure, vous devez donc utiliser un nom de domaine complet pour que cette adresse soit conforme. En effet, la plupart des serveurs s’attendent à ce que l’enregistrement MX contienne un nom d’hôte et non une adresse IP (c’est le cas pour les enregistrements A).

Éditer: Pour élaborer, dans DNS, chaque enregistrement a des exigences strictes pour le type de données que chaque enregistrement peut contenir. Dans le cas des enregistrements MX, il s'agit uniquement d'un nom d'hôte .


Alors, pourquoi exim n’a-t-il pas permis aux enregistrements MX de pointer vers une adresse IP en premier lieu? Cela me semble étrange! Je comprends que je ne devrais pas le faire à cause de la convention, mais je ne comprends pas pourquoi c'est illégal .
dayuloli

1
Je ne vois pas comment un MTA pourrait supporter cela car un MXenregistrement ne peut avoir une adresse IP comme valeur.
Håkan Lindqvist

@ HåkanLindqvist Votre réponse ci-dessus a clarifié ce point pour moi! Je vous remercie!
dayuloli

2

IN RFC 1025 Les enregistrements MX pointent uniquement vers un RR (enregistrement de ressource) d'un enregistrement A ou d'un CNAME.

Ainsi, le serveur de messagerie qui envoie le courrier demande le RR d'un enregistrement MX, l'enregistrement mx répertorie les enregistrements A de serveurs, le serveur de messagerie effectue une recherche directe pour obtenir un enregistrement A, puis transfère le courrier via smtp à l'hôte de service répertorié comme un serveur de messagerie "disposé" à recevoir du courrier pour ce domaine.

Votre question - Pourquoi le courrier ne peut-il pas être envoyé à une adresse IP?

Réponse - en raison de la confiance

De nombreuses règles en vigueur concernant le courrier ont évolué afin de maintenir la confiance entre les domaines en ce qui concerne la validité des messages échangés. Tout cela a pour finalité de réduire les spams.

  • Recherches IP inversées
  • Une recherche de nom avant pour cette question

Tous ces composants essentiels d’une fondation pour la construction d’un serveur de messagerie ont au moins un petit composant conçu pour créer des communications fiables et réduire les communications non fiables.

Référence - RFC 1035 et 974

https://www.ietf.org/rfc/rfc1035.txt35

https://www.ietf.org/rfc/rfc974.txt


2

Le but des MXenregistrements est qu'une application (transfert de courrier) puisse en savoir plus sur l'hôte à utiliser. Au niveau de l'application, les noms d' hôte sont la bonne chose à utiliser (pas les adresses IP).

En outre, l’ajout de la conception d’un enregistrement de type de variante à DNS introduit un levier de complication et, partant, un point d’entrée pour les problèmes, les problèmes d’implémentation, les problèmes de sécurité. Par exemple, 1.2.3.4.example.com.est un nom d’hôte valide (oui, même à la lumière de RFC1034, 3.5). Spécifier cet hôte comme MXdans un fichier de configuration de liaison pour exemple.com pourrait ressembler à

.  MX 10  1.2.3.4

et vraisemblablement c'est exactement la même chose qu'un enregistrement MX avec une adresse IP devrait ressembler. Et même pour transférer les informations dans un datagramme DNS, des additoins bizarres sont nécessaires; le moyen le plus simple serait d'introduire un nouveau type d'enregistrement de ressource, par MXAexemple, pour la désambiguïsation. Mais encore une fois, pourquoi introduire le fardeau d’un tel nouveau type d’enregistrement

. MXA 10 5.6.7.8

pourrait toujours être remplacé par

. MX 10 dummy
dummy A 5.6.7.8

(et serait également supporté par les clients DNS ne sachant rien des MXAenregistrements)?

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.