DNS: sous-domaines qui nécessitent à la fois un enregistrement MX et un CNAME

17

Disons que nous possédons la zone mywebservice.com.

J'aimerais que chacun de mes clients obtienne son propre sous-domaine, tel que customer.mywebservice.com.

customer.mywebservice.com doit être un CNAME pour un serveur donné hors site. Étant donné que ce site gère son propre équipement et peut changer d'adresse à tout moment, le CNAME est une exigence.

Les utilisateurs doivent également être en mesure d'envoyer des e-mails à mailbox@customer.mywebservice.com, ce qui nécessiterait un simple enregistrement MX.

Cependant, et c'est là que j'aimerais des conseils:

Selon RFC 1034 :

If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.

J'ai également vérifié que mon serveur DNS refusera de servir autre chose qu'un CNAME pour les hôtes qui les utilisent.

Il semble donc que je puisse avoir une situation perdante. Si je veux utiliser l'enregistrement MX, je dois utiliser un A au lieu d'un CNAME.

Quelqu'un peut-il penser à des solutions de contournement? Merci!

domain-name-system cname-record mx-record

— Michael Gorsuch
source

20

Malheureusement, ce que vous rencontrez est une limitation de la spécification DNS. Avoir un enregistrement MX pour le même nom d'hôte que celui défini comme un enregistrement CNAME échouera dans la plupart des implémentations de serveur DNS. Certains serveurs DNS plus anciens le permettent, mais ils ont été principalement supprimés en faveur de mises en œuvre plus récentes et plus sécurisées.

Au lieu d'utiliser les enregistrements CNAME, vous devrez utiliser les enregistrements «A» avec les adresses IP des sites clients directement au lieu de les aliaser.

— Justin Scott
source

Ouais, je suppose que je vais juste affronter celui-ci. Merci!

— Michael Gorsuch

2

Je devrais également noter, pour ceux qui lisent ceci sur la route, que la raison de cette limitation est qu'un CNAME est censé se référer au "nom canonique" pour l'hôte recherché. Par exemple, si vous avez un hôte, x2.example.com qui est un enregistrement CNAME pointant vers x1.example.com, alors tout résolveur recherchant x2 devrait voir le CNAME, remplacer tout ce qu'il fait pour x2 par x1, et recommencer . Si vous aviez un enregistrement MX pour x2 en plus du CNAME, alors si x1 avait également un MX, il y a une chance qu'ils soient différents, ce qui n'est pas souhaitable, alors ils le refusent simplement.

— Justin Scott

18

Après beaucoup de travail et de recherche ici, j'ai trouvé une solution acceptable. Tout d'abord, il est important que nous suivions tous les RFC. J'ai corrigé mon serveur DNS pour violer le RFC, et j'ai découvert que plusieurs autres serveurs DNS majeurs ne respecteraient pas le changement.

Le mouvement approprié consiste à placer le MX sur l'hôte vers lequel le CNAME pointe. Ainsi, si customer.mywebservice.com est un CNAME pour l'enregistrement A loadbalancer.mywebservice.com, il convient également de créer un enregistrement MX pour loadbalancer.mywebservice.com. J'ai vérifié que cela fonctionne avec tous les principaux résolveurs.

Si une requête MX est effectuée pour customer.mywebservice.com, la bibliothèque du résolveur suivra le CNAME et obtiendra le MX approprié pour l'enregistrement A final. Hourra!

— Michael Gorsuch
source

4

customer.mywebservice.com doit être un CNAME pour un serveur donné hors site. Étant donné que ce site gère son propre équipement et peut changer d'adresse à tout moment, le CNAME est une exigence.

Quelqu'un peut-il penser à des solutions de contournement? Merci!

Vous avez besoin que les clients puissent changer l'adresse, avez-vous envisagé de permettre au client de mettre à jour dynamiquement son propre dossier? Avec le DNS dynamique, vous pouvez utiliser l'enregistrement A et le client peut modifier l'enregistrement selon les besoins. Cela prendrait un peu de travail, mais vous pouvez chaque sous-domaine individuel comme une zone distincte afin que vous puissiez vous assurer qu'un client ne peut toucher que sa propre zone.

Je ne l'ai pas essayé, mais gnudip semble être un outil open source pour faciliter les mises à jour dynamiques sans avoir à gérer l'authentification et à configurer de nombreuses zones sur votre serveur DNS.

— Zoredache
source

3

Si vos enregistrements MX sont les mêmes pour tous ces enregistrements, vous pouvez essayer d'utiliser un DNAME pour rediriger XYZ.mywebservice.com vers hosting.mywebservice.com. Sous hosting.mywebservice.com, ajoutez vos enregistrements MX et A pertinents.

Je dois dire que je n'ai jamais utilisé d'enregistrements DNAME en production, mais vous pouvez en lire plus à ce sujet dans la RFC2672 .

— Doug Luxem
source

Je voulais essayer d'utiliser DNAME avec certains de nos domaines SSL, mais j'ai entendu qu'il y avait encore des problèmes avec les anciens serveurs DNS, etc. Est-ce pertinent? Ou DNAME est-il sûr à utiliser sur les serveurs de production?

— drybjed

Si je devais deviner, de nombreuses applications n'attendent pas les enregistrements DNAME et cassent probablement lors de leur utilisation. Tous les serveurs de messagerie suivent-ils les DNAME pour rechercher des enregistrements MX? Je ne sais pas, mais ils devraient. Pour votre problème SSL, les serveurs DNS qui ne comprennent pas DNAME devraient plutôt recevoir une référence CNAME. Je testerais soigneusement cela avant de le mettre en œuvre.

— Doug Luxem

L'application n'a certainement PAS à traiter les enregistrements DNAME! Cela se fait uniquement dans les serveurs de noms.

— bortzmeyer

3

Le RHS du CNAME customer.mywebservice.com a-t-il une entrée MX?

Si c'est le cas, le serveur de messagerie utilisera ce MX pour trouver le serveur de messagerie à utiliser. J'espère que vous pourrez contrôler cela.

— MikeyB
source

1

La réponse de Michael Gorsuch est largement correcte, la chaîne CNAME -> A + MX fonctionne ... surtout . Cependant, il déclenche un mauvais comportement dans certains MTA. Ce que j'ai trouvé en exécutant cette solution à une échelle décente:

certains MTA refuseront simplement de trouver le document.
d'autres remplaceront incorrectement l'enregistrement A où le CNAME devrait être: c'est-à-dire que j'ai envoyé un courrier à "joe@foo.example.com", qui CNAMES à web.example.com, qui a un MX de mail.example.com, et le MTA réécrit l'en-tête d'enveloppe comme "À: joe@web.example.com".

On ne sait pas encore à quel point ces problèmes sont omniprésents (google / hotmail / yahoo / etc semblent tous gérer cela correctement), mais ils nous ont certainement à chercher de meilleures solutions.

— osheroff
source

2

C'est correct; le comportement documenté des serveurs SMTP conformes à la RFC5321 consiste à vérifier d'abord l'existence d'un enregistrement MX pour le domaine et, en cas d'échec, à vérifier l'existence d'un enregistrement A. Ce comportement est la vraie raison technique pour laquelle le MX ne devrait pas être un CNAME: il cessera de se résoudre après la première réponse utilisable.

— adaptr

0

Une solution possible et valide serait de créer un nom d'hôte de base pour tous vos clients et de le définir sur l'enregistrement a et aaaa du serveur Web hors site et de votre mx, puis CNAME tout le domaine de vos clients sur ce nom d'hôte unique. De cette façon, vous n'aurez à modifier qu'un seul enregistrement lorsque l'adresse IP hors site change.

C'est le seul moyen de valorisation et possible, car CNAME est un alias pour un ensemble complet d'enregistrements, pas seulement un.

— Bachsau
source

-4

MX et CNAME sont des enregistrements complètement séparés - le premier détermine le serveur de messagerie pour un domaine donné, le second donne l'adresse d'un domaine. Cela devrait fonctionner:

@ IN SOA ns1.mywebservice.com. root.mywebservice.com. (
                        2009060201
                        12h
                        1h
                        1w
                        8h
)

                        NS ns1.mywebservice.com.
                        NS ns2.mywebservice.com.

client CNAME offsite.host.
client MX 10 mail.server.

— drybjed
source

4

Cela peut fonctionner, mais cela viole les RFC1034 et RFC1219 qui stipulent qu'aucun autre enregistrement de ressource ne peut avoir le même nom qu'un CNAME.

— Doug Luxem

Mon démon DNS est RFC strict, qui refuse catégoriquement d'envoyer la réponse pour le MX. Je crois qu'il y a des problèmes potentiels de mise en cache du côté client si nous mettions cela en place.

— Michael Gorsuch

Quel démon DNS? J'utilise BIND9 qui devrait fonctionner avec cette configuration sans problème. Peut-être qu'il est temps de mettre à niveau? Grande infrastructure, je suppose?

— drybjed

J'utilise MyDNS. C'est une configuration assez grande, et ce petit démon a été une bénédiction jusqu'à ce point. J'envisage de le corriger, mais je ne suis pas très intéressé par les effets secondaires qui donnent naissance. Si cela va à l'encontre de la RFC, cela ressemble à une mauvaise idée.

— Michael Gorsuch

@Maciej - bien sûr, votre serveur faisant autorité pourrait être en mesure d'héberger ces enregistrements. Ils confondront l'enfer de la plupart des serveurs récursifs qui les interrogent.

— Alnitak