Comment surmonter les restrictions CNAME du domaine racine?

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?

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.

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:

• http://tools.ietf.org/html/rfc1912 section «2.4 Enregistrements CNAME»
• http://www.faqs.org/rfcs/rfc1034.html section «3.6.2. Alias ​​et noms canoniques '

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

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 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

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.

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.

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}");
?>