J'ai www.mydomain.com
pointé vers 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?
Malheureusement, il s'agit d'une lacune bien connue du protocole DNS. Il n'y a aucun type d'enregistrement défini dans les normes DNS qui vous permettra d'alias le sommet d'un domaine. Beaucoup de gens supposent que les enregistrements CNAME
peuvent être utilisés pour cela, mais il y a des raisons techniques pour lesquelles ils ne 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 société en utilisant une combinaison d'enregistrements A
synthétisés et une redirection de serveur Web pour atteindre votre objectif souhaité. FWD
en fait partie, tout comme le WebForward
vers lequel Michael vous a dirigé dans les commentaires.
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). Alors que certains serveurs DNS permettra cela, c'est une mauvaise chose, et peut causer des échecs difficiles à diagnostiquer (sans parler ne fonctionnera pas 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. [email protected]. ( 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.
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.
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