Pourquoi les enregistrements MX ne peuvent-ils pas pointer vers une adresse IP?
Je comprends que vous ne devez pas pointer directement un enregistrement MX vers une adresse IP, mais devez pointez-le à la place sur un enregistrement A, qui, à son tour, pointe vers l'adresse IP de votre serveur de messagerie.
Mais, en principe, pourquoi est-ce nécessaire?
L'idée derrière l'enregistrement MX est de spécifier un hôte ou les hôtes qui peut accepter du courrier pour un domaine. Comme spécifié dans 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 n'a pas pu ê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 cela dans les années 1980, lorsque les spécifications ont été écrites à l'origine, sont presque les mêmes que 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 à Internet (relativement nouveau) qui utilisait TCP/IP et à d'autres réseaux hérités, qui utilisaient souvent d'autres protocoles. La spécification de MX de cette manière permettait aux enregistrements DNS qui pouvaient identifier comment atteindre un tel hôte sur un réseau autre qu'Internet, tel que Chaosnet . Dans la pratique, cependant, cela ne s'est presque jamais produit; pratiquement tout le monde a repensé ses réseaux pour qu'ils deviennent plutôt des éléments d'Internet.
Aujourd'hui, la situation est qu'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. (En tant qu'optimisation des performances, le serveur DNS enverra le long des enregistrements d'adresse pour l'hôte dans la section supplémentaire de réponse s'il a des enregistrements faisant autorité pour eux, économisant ainsi un aller-retour.)
Il existe également une situation qui se produit lorsque vos échangeurs de messagerie sont fournis par un tiers (par exemple, Google Apps ou Office 365). Vous pointez vos enregistrements MX vers leurs noms d'hôtes, mais il peut arriver que le fournisseur de services doive modifier les adresses IP des serveurs de messagerie. Puisque vous avez indiqué un hôte, le fournisseur de services peut le faire de manière transparente et vous n'avez pas à apporter de modifications à vos enregistrements.
Le DNS en tant que protocole a différents types de valeurs, celles-ci ne sont pas interchangeables.
Il est important de noter que 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 enregistrement A contient une adresse IPv4 (4 octets de données, longueur fixe).
Un AAAArecord contient une adresse IPv6 (16 octets de données, longueur fixe).
Un enregistrement MX, d'autre part, contient un nom (une séquence d'étiquettes au format <int number of bytes> <label> <int number of bytes> <label> <int 0>, longueur variable).
Ce n'est pas possible pour un enregistrement MX d'avoir une adresse IP comme données.
Je vais jeter cela comme une supposition. Bien sûr, je suis à la maison avec la grippe alors peut-être que je suis fou.
La RFC 974 déclare:
La première étape pour l'expéditeur de LOCAL est d'émettre une requête pour les RR MX pour REMOTE. Il est fortement recommandé de suivre cette étape chaque fois qu'un expéditeur tente d'envoyer le message. L'espoir est que les changements dans la base de données de domaine seront rapidement utilisés par les expéditeurs, et ainsi les administrateurs de domaine pourront réacheminer les messages en transit pour les hôtes défectueux en changeant simplement leurs bases de données de domaine.
En exigeant un nom au lieu de IP, il 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 pas à vous soucier de modifier l'enregistrement MX lui-même et d'attendre la propagation DNS.
Certains serveurs de messagerie (comme exim) n'autorisent pas spécifiquement l'envoi à des enregistrements MX qui pointent vers une adresse IP pure, vous devez donc utiliser un nom de domaine complet pour qu'il soit conforme à la place. En effet, la plupart des serveurs s'attendent à ce que l'enregistrement MX contienne un nom d'hôte, pas une adresse IP (c'est à cela que servent les enregistrements A).
Modifier: 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 d'un nom d'hôte niquement.
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 des serveurs, le serveur de messagerie effectue une recherche directe pour obtenir un enregistrement A, puis transfère le courrier via smtp au service Host 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 place concernant le courrier ont évolué afin de maintenir la confiance entre les domaines que les messages envoyés dans les deux sens sont réellement valides. Tout cela vise à réduire le SPAM.
- Recherches IP inversées
- Une recherche de nom vers l'avant d'ailleurs
Tous ces composants essentiels pour une fondation sur laquelle construire un serveur de messagerie ont au moins un petit composant fondé sur la création de communications fiables et la réduction des communications non fiables.
Référence - RFC 1035 et 974
Le but de MXrecords est qu'un application (transfert de courrier) puisse en savoir plus sur l'hôte à utiliser. Au niveau de l'application, l'hôte noms est la bonne chose à utiliser (pas les adresses IP).
De plus, l'ajout de la conception d'un enregistrement de type variant à DNS introduit un levier de complication et donc un point d'entrée pour les problèmes, les incidents de mise en œuvre et les problèmes de sécurité. Par exemple, 1.2.3.4.example.com. est un nom d'hôte valide (oui, il l'est, même à la lumière de RFC1034, 3.5). La spécification de cet hôte comme MX dans un fichier de configuration de liaison pour example.com pourrait ressembler à
. MX 10 1.2.3.4
et c'est probablement exactement la même chose qu'un enregistrement MX avec une IP devrait ressembler. Et même pour transférer les informations dans un datagramme DNS, il faut des additoins excentriques; la manière la plus simple serait d'introduire un nouvea type d'enregistrement de ressource, MXA disons, pour la désambiguïsation. Mais là encore, pourquoi introduire la charge d'un nouveau type d'enregistrement lorsque
. MXA 10 5.6.7.8
pourrait toujours être remplacé par
. MX 10 dummy
dummy A 5.6.7.8
(et serait également pris en charge par les clients DNS ne connaissant pas les enregistrements MXA)?