Transférer le domaine racine au sous-domaine www à l'aide d'enregistrements DNS

16

j'ai www.mydomain.com indiqué un site Web Azure.

www.mydomain.com --- CNAME --- mydomain.azurewebsites.net

Quand je visite www.mydomain.com, tout fonctionne bien. C'est bon.

Le problème est, mydomain.com ne fonctionne pas. Azure n'autorise que le sous-domaine www.

Dans certains serveurs de noms, j'utilise un enregistrement FWD pour transmettre la racine au www, et cela fonctionne très bien. Mon serveur de noms actuel (zoneedit.com) n'a pas cet enregistrement FWD.

Existe-t-il un enregistrement DNS que nous pouvons utiliser pour transférer le domaine racine vers le sous-domaine www?

domain-name-system forwarding

— Shaun Luttin
source

2

ZoneEdit a un "WebForward" qui fera cela.

— Michael Hampton

@MichaelHampton Perfect. Nous avons utilisé@ | StealthForward | http://www.example.com

— Shaun Luttin

C'est génial. Il fait essentiellement ce que j'ai décrit (pointe vers une véritable IP, c'est-à-dire un serveur Web qui redirige simplement avec une série HTTP 300 vers www.domain.com).

— DTK

17

Malheureusement, il s'agit d'une lacune bien connue du protocole DNS. Aucun type d'enregistrement défini dans les normes DNS ne vous permet d'aliaser le sommet d'un domaine. Beaucoup de gens supposent que les CNAMEenregistrements peuvent être utilisés à cette fin, mais il y a des raisons techniques pour lesquelles ils ne le peuvent pas .

De nombreux fournisseurs DNS implémentent des types d'enregistrement DNS personnalisés (lire: faux) pour tenter de remédier à cette lacune. Dans les coulisses, ces faux enregistrements implémentent un comportement personnalisé dans le logiciel de cette entreprise en utilisant une combinaison d' Aenregistrements synthétisés et de redirection de serveur Web pour atteindre votre objectif souhaité. FWDest l'un d'entre eux, un peu comme celui WebForwardque Michael vous a indiqué dans les commentaires.

— Andrew B
source

8

Résumé: En bref, vous ne pouvez pas avoir l'enregistrement que vous souhaitez, et votre hôte DNS fait les choses de la bonne façon.

Explication: C'est une violation des normes DNS d'avoir un CNAME (enregistrement d'alias / enregistrement de transfert) au sommet de la zone (le nom vide à l'avant de la zone).

La raison en est qu'un enregistrement CNAME ne peut pas avoir le conflit de portion de nom avec n'importe quel enregistrement à l'exception d'un enregistrement DNSSec. Dans une zone typique, un enregistrement CNAME au sommet de la zone entrerait en collision avec au moins les enregistrements SOA et NS (et probablement plusieurs autres). Bien que certains serveurs DNS le permettent, c'est une mauvaise chose et peut causer des échecs difficiles à diagnostiquer (sans parler de ne pas fonctionner si vous déplacez l'hébergement de la zone vers un serveur DNS conforme aux normes, tel que tout ce qui est basé sur BIND) .

Soit avoir des enregistrements A au sommet de la zone (ils peuvent être un simple serveur Web qui lance simplement un HTTP 302 vers www). Si vous pouvez obtenir des numéros IP statiques pour vos instances de serveur Azure, placez un enregistrement A pour chacune au sommet de votre zone et créez un seul enregistrement CNAME appelé "www" qui pointe vers l'enregistrement au sommet.

Par exemple :

 

$ ORIGIN example.com.

@ IN SOA ns1.example.com. admin@example.com. (
                                 101;
                                 172800;
                                 900;
                                 1209600;
                                 3600; )
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
@ IN A 123.234.1.123
@ IN A 123.234.1.124
@ IN A 123.234.1.125
ns1 IN A 123.234.1.126
ns2 IN A 123.234.1.127
www IN CNAME example.com.

— DTK
source

5

IMO: Cela ne vaut pas la peine de répéter sans cesse pourquoi les sommets CNAME ne fonctionnent pas. Si l'utilisateur demande pourquoi ils ne fonctionnent pas, nous avons une réponse canonique pour cela avec des références RFC. (divulgation complète: je l'ai écrit) S'ils ne posent pas de questions à ce sujet, il vaut mieux s'en tenir à répondre à la question telle qu'elle est formulée.

— Andrew B

Je vous remercie. J'aurais dû chercher une réponse canonique. Je garderai cela à l'esprit pour la prochaine fois.

— DTK

2

Certains protocoles ont des normes pour les types d'enregistrement DNS, autres que les enregistrements A, pour trouver le service. SMTP avec ses enregistrements MX associés en est un bon exemple. Il n'existe aucun type d'enregistrement DNS défini pour HTTP. Il est probable que votre ancien fournisseur DNS / registraire disposait d'un service de redirection HTTP ou de proxy inverse.

Pour atteindre votre objectif, vous devrez configurer un serveur Web (hôte virtuel) pour effectuer une redirection HTTP 301 ou 302 d'un nom d'hôte à l'autre, configurer un proxy HTTP inverse, configurer des hôtes virtuels indépendants ou utiliser des alias d'hôte virtuel afin la même instance de serveur Web répondra aux deux noms A.

— Joshua Hoblitt
source

0

Si vous voulez une réponse spécifique à Azure, vous devez créer un autre enregistrement CNAME pointant vers awverify.mydomain.azurewebsites.net comme ceci

www.mydomain.com --- CNAME --- awverify.mydomain.azurewebsites.net

— Abhishek Siddhu
source