Comment surmonter les restrictions CNAME du domaine racine?

117

Nous hébergeons de nombreuses applications Web pour nos clients. Comme il est évident qu'ils veulent utiliser leurs propres domaines pour faire référence à ces applications, ils veulent généralement que tout utilisateur qui tape http://www.customer1.exampleou http://customer1.exampleaccède à leur application Web.

La situation à laquelle nous sommes confrontés est que nous devons avoir la flexibilité de changer les adresses IP dans un proche avenir. Et nous ne voulons pas que le client fasse le changement d'enregistrement A sur son domaine. Nous avons donc pensé que l'utilisation d' CNAMEenregistrements fonctionnera, mais comme nous le découvrons, les CNAMEenregistrements ne fonctionneront pas pour le domaine racine.

Fondamentalement:

customer1.example IN CNAME customer1.mycompanydomain.example //this is invalid as the RFC
www.customer1.example IN CNAME customer1.mycompanydomain.example //this is valid and will work

Nous voulons pouvoir changer l'adresse IP customer1.mycompanydomain.exampleou l' Aenregistrement et nos clients suivront cet enregistrement que nous contrôlons.

dans notre DNS, cela ressemblera à:

customer1.mycompanydomain.example IN A 192.0.2.1

Des idées?

Géo
la source
Je ne comprends pas pourquoi "customer1.com IN CNAME customer1.mycompanydomain.com" n'est pas valide. Je pense que cela devrait fonctionner. Pourriez-vous expliquer où était le problème avec cette solution?
sleske
3
Oui, veuillez lire la question et la réponse suivantes. Il n'est pas valide selon la RFC DNS. stackoverflow.com/questions/655235/…
Geo
2
Je ne comprends pas le titre de la question. Où est la "racine" (.) Impliquée?
bortzmeyer
2
il veut dire la racine d'une zone, pas "la racine"
Alnitak
2
Eh bien, ce n'est pas le vocabulaire DNS habituel, alors. "Apex" n'est-il pas le mot approprié? Ou "top-level" pour les programmeurs Lisp? :-)
bortzmeyer

Réponses:

63

La raison pour laquelle cette question se pose encore souvent est que, comme vous l'avez mentionné, quelque part, quelqu'un présumé comme important a écrit que la RFC stipule que les noms de domaine sans sous-domaine devant eux ne sont pas valides. Cependant, si vous lisez attentivement la RFC, vous constaterez que ce n'est pas exactement ce qu'elle dit. En fait, la RFC 1912 déclare:

N'allez pas trop loin avec les CNAME. Utilisez-les pour renommer des hôtes, mais prévoyez de vous en débarrasser (et informez vos utilisateurs).

Certains hôtes DNS fournissent un moyen d'obtenir des fonctionnalités de type CNAME au sommet de la zone (le niveau du domaine racine, pour le nom de domaine nu) à l'aide d'un type d'enregistrement personnalisé. Ces enregistrements comprennent, par exemple:

  • ALIAS chez DNSimple
  • ANAME chez DNS Made Easy
  • ANAME chez easyDNS
  • CNAME chez CloudFlare

Pour chaque fournisseur, la configuration est similaire: pointez l'entrée ALIAS ou ANAME de votre domaine apex vers example.domain.com, comme vous le feriez avec un enregistrement CNAME. En fonction du fournisseur DNS, une valeur vide ou @ Name identifie le sommet de la zone.

ALIAS ou ANAME ou @ example.domain.com.

Si votre fournisseur DNS ne prend pas en charge un tel type d'enregistrement et que vous ne pouvez pas passer à celui qui le fait, vous devrez utiliser la redirection de sous-domaine, ce qui n'est pas si difficile, selon le protocole ou le logiciel serveur qui a besoin de le faire .

Je ne suis pas du tout d'accord avec l'affirmation selon laquelle cela n'est fait que par des "administrateurs amateurs" ou de telles idées. C'est un simple "Que doivent faire le nom et son service?" traiter, puis adapter votre configuration DNS pour répondre à ces souhaits; Si vos principaux services sont le Web et la messagerie électronique, je ne vois aucune raison VALIDE pour laquelle la suppression définitive des CNAME serait problématique. Après tout, qui préférerait @ subdomain.domain.org à @ domain.org? Qui a besoin de "www" si vous êtes déjà configuré avec le protocole lui-même? Il est illogique de supposer que l'utilisation d'un nom de domaine racine serait invalide.

Miauler à la lune
la source
1
Cette réponse particulière m'a été très utile car je voulais pointer un domaine de niveau racine vers un CDN. La plupart des CDN sont par nécessité un nom de domaine complet, car il peut se résoudre en différentes adresses IP à différents endroits ou moments. J'utilise DNS Made Easy et j'ai pu utiliser le type d'enregistrement ANAME.
Rubix
3
Je ne pourrais pas être plus d'accord. Vouloir héberger un site à partir du nom de domaine «nu» est une chose courante et logique à faire. Il utilise moins de caractères, il a l'air mieux, etc.
Ed Bishop
3
Les ANAME sont gentils, ou vous pouvez simplement 301 tous non-www à www. via le service de redirection 301 gratuit 198.251.86.133
Jacob Evans
51

Le CNAME d'un enregistrement racine n'est techniquement pas contre RFC, mais a des limitations, ce qui signifie que c'est une pratique qui n'est pas recommandée.

Normalement, votre enregistrement racine aura plusieurs entrées. Dites, 3 pour vos serveurs de noms, puis un pour une adresse IP.

Par RFC:

Si un RR CNAME est présent à un nœud, aucune autre donnée ne doit être présente;

Et selon le document IETF 'Common DNS Operational and Configuration Errors' Document:

Ceci est souvent tenté par des administrateurs inexpérimentés comme un moyen évident de permettre à votre nom de domaine d'être également un hôte. Cependant, les serveurs DNS comme BIND verront le CNAME et refuseront d'ajouter d'autres ressources pour ce nom. Étant donné qu'aucun autre enregistrement n'est autorisé à coexister avec un CNAME, les entrées NS sont ignorées. Par conséquent, tous les hôtes du domaine podunk.xx sont également ignorés!

Références:

Jon Swanson
la source
17
Mais POURQUOI n'y a-t-il aucun autre enregistrement autorisé à coexister avec un CNAME. S'agit-il simplement d'une limitation ajoutée par l'auteur de la RFC ou y a-t-il une raison technique à cela? S'il n'y a pas de raison technique à cela, alors on pourrait facilement proposer une extension RFC.
Sven
Donc, si cela fonctionne pour moi (utilisez CNAME pour l'enregistrement racine, d'autres sous-domaines pour ce domaine fonctionnent toujours), cela signifie que je suis juste chanceux et que l'implémentation DNS de mes fournisseurs n'ignore pas que les enregistrements supplémentaires sont possibles? Et cela signifie aussi que je n'ai pas à craindre de problèmes côté client, tant que le serveur DNS le gère comme ça?
didi_X8
Il s'agit d'une tentative pour répondre à une autre question, "pourquoi les CNAME ne sont-ils pas autorisés au sommet", alors que la question réelle est "comment surmonter cette limitation". -1.
rustyx
Pour le pourquoi voir serverfault.com/questions/613829/…
rhand
CNAMEing un enregistrement racine n'est techniquement pas contre RFC, vous devrez expliquer comment il n'est pas contre RFC1034 section 3.6.2: Si un CNAME RR est présent à un nœud, aucune autre donnée ne doit être présente; cela garantit que les données d'un nom canonique et de ses alias ne peuvent pas être différentes. . Bien sûr , la « racine » (ce qui est le sommet précisément dans ce contexte) a déjà NSet des SOAdocuments et ne peut donc avoir des CNAMEdossiers.
Patrick Mevzek
4

Je ne sais pas comment ils s'en sortent, ni quels effets secondaires négatifs ils peuvent avoir, mais j'utilise Hover.com pour héberger certains de mes domaines et j'ai récemment configuré le sommet de mon domaine en tant que CNAME. Leur outil d'édition DNS ne s'est pas plaint du tout, et mon domaine se résout joyeusement via le CNAME attribué.

Voici ce que Dig me montre pour ce domaine (domaine réel masqué en tant que mydomain.com):

; <<>> DiG 9.8.3-P1 <<>> mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2056
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mydomain.com.          IN  A

;; ANSWER SECTION:
mydomain.com.       394 IN  CNAME   myapp.parseapp.com.
myapp.parseapp.com. 300 IN  CNAME   parseapp.com.
parseapp.com.       60  IN  A   54.243.93.102
Mason G. Zhwiti
la source
L'obscurcissement, si vraiment nécessaire (le DNS est public ...), devrait utiliser les directives RFC2606. Et RFC5737 ou 3849 pour les adresses IP
Patrick Mevzek
3

Mon entreprise fait la même chose pour un certain nombre de clients où nous hébergeons un site Web pour eux, bien que dans notre cas, il s'agisse de xyz.company.com plutôt que www.company.com. Nous leur demandons de définir l'enregistrement A sur xyz.company.com pour pointer vers une adresse IP que nous leur attribuons.

Quant à savoir comment vous pourriez faire face à un changement d'adresse IP, je ne pense pas qu'il existe une solution parfaite. Quelques idées sont:

  • Utilisez un équilibreur de charge NAT ou IP et donnez à vos clients une adresse IP lui appartenant. Si l'adresse IP du serveur Web doit changer, vous pouvez effectuer une mise à jour sur le NAT ou l'équilibreur de charge,

  • Offrez également un service d'hébergement DNS et demandez à vos clients d'héberger leur domaine avec vous afin que vous soyez en mesure de mettre à jour les enregistrements A,

  • Demandez à vos clients de définir leur enregistrement A sur un serveur Web principal et d'utiliser une redirection HTTP pour les demandes Web de chaque client.

sipwiz
la source
3

Sipwiz a raison, la seule façon de le faire correctement est l'approche hybride HTTP et DNS. Mon registrar est un revendeur pour Tucows et propose le transfert de domaine racine en tant que service à valeur ajoutée gratuit.

Si votre domaine est blah.com, ils vous demanderont où vous souhaitez que le domaine soit redirigé, et vous tapez www.blah.com. Ils attribuent l'enregistrement A à leur serveur Apache et ajoutent automatiquement blah.com en tant que vhost DNS. Le vhost répond avec une erreur HTTP 302 les redirigeant vers l'URL appropriée. Il est simple à script / configuration et peut être géré par le bas de gamme, sinon le matériel serait mis au rebut.

Exécutez la commande suivante pour un exemple: curl -v eclecticengineers.com

MrEvil
la source
3

Vous devez mettre un point à la fin du domaine externe pour ne pas penser que vous voulez dire client1.monentreprisedomaine.com.localdomain;

Alors changez simplement:

customer1.com IN CNAME customer1.mycompanydomain.com

À

customer1.com IN CNAME customer1.mycompanydomain.com.
Gwerks
la source
Pour moi (BIND 9.8.2), si les enregistrements sont pour le domaine customer1.com, cela fonctionne ... mais est interprété comme spécifiant CNAMe pour un sous-domaine customer1.com.customer1.com. Si j'ajoute un point au premier élément, l'enregistrement sera interprété correctement, mais cela ne fonctionnera plus. Je ne vois aucune solution ici.
Jussi Hirvi
-2

Je vois que readytocloud.com est hébergé sur Apache 2.2.

Il existe un moyen beaucoup plus simple et efficace de rediriger le site non www vers le site www dans Apache.

Ajoutez les règles de réécriture suivantes aux configurations Apache (à l'intérieur ou à l'extérieur de l'hôte virtuel. Cela n'a pas d'importance):

RewriteCond %{HTTP_HOST} ^readytocloud.com [NC]
RewriteRule ^/$ http://www.readytocloud.com/ [R=301,L]

Ou, les règles de réécriture suivantes si vous voulez un mappage 1-à-1 des URL du site non-www vers le site www:

RewriteCond %{HTTP_HOST} ^readytocloud.com [NC]
RewriteRule (.*) http://www.readytocloud.com$1 [R=301,L]

Notez que le module mod_rewrite doit être chargé pour que cela fonctionne. Heureusement, readytocloud.com fonctionne sur une boîte CentOS, qui par défaut charge mod_rewrite.

Nous avons un serveur client exécutant Apache 2.2 avec un peu moins de 3000 domaines et près de 4000 redirections, cependant, la charge sur le serveur oscille entre 0,10 et 0,20.

Owen Blacker
la source
La question concernait le DNS. Pas sur le serveur Web Apache.
SamTzu
-7

Merci à la fois à sipwiz et à MrEvil. Nous avons développé un script PHP qui analysera l'URL que l'utilisateur entre et la collera wwwen haut de celle-ci. (par exemple, si le client entre sur kiragiannis.com , il redirigera vers www.kiragiannis.com ). Ainsi, nos clients pointent leur racine (par exemple customer1.compour Aenregistrer où se trouve notre redirecteur Web), puis www CNAMEvers le véritable Aenregistrement géré par nous.

Ci-dessous le code au cas où vous seriez intéressé pour nous.

<?php
$url = strtolower($_SERVER["HTTP_HOST"]);

if(strpos($url, "//") !== false) { // remove http://
  $url = substr($url, strpos($url, "//") + 2);
}

$urlPagePath = "";
if(strpos($url, "/") !== false) { // store post-domain page path to append later
  $urlPagePath = substr($url, strpos($url, "/"));
  $url = substr($url, 0, strpos($url,"/"));
}


$urlLast = substr($url, strrpos($url, "."));
$url = substr($url, 0, strrpos($url, "."));


if(strpos($url, ".") !== false) { // get rid of subdomain(s)
  $url = substr($url, strrpos($url, ".") + 1);
}


$url = "http://www." . $url . $urlLast . $urlPagePath;

header( "Location:{$url}");
?>
Geo
la source
10
Cela ne répond pas réellement à la question que plus de 69 000 personnes sont venues chercher sur ce fil. La question concerne davantage le DNS et n'a rien à voir avec PHP.
Matt Clark
1
La question concernait le DNS. Pas sur le codage PHP.
SamTzu
HTTP_HOST est le nom d'hôte, comme son nom l'indique, pas une URL. Par conséquent, il n'y en aura pas http://à supprimer, ni /( $urlPagePathsera toujours vide). Cf httpd.apache.org/docs/2.4/expr.html . En raison de la façon dont le code essaie de se débarrasser du sous-domaine, cela ne fonctionnera pas non plus pour des choses comme www.example.co.ukco.ukdoit être considéré comme un tout. Il ne gère pas non plus HTTPS. Et enfin, en utilisant PHP, il suffit de faire une redirection HTTP où n'importe quel serveur Web peut le faire en configuration, c'est trop compliqué. Donc, en bref, cela ne devrait certainement pas être la réponse validée à cette question.
Patrick Mevzek
Si cette règle doit s'appliquer à tous les hôtes, elle doit être effectuée en tant que configuration Apache
Svetoslav Marinov