Pourquoi la racine d'un domaine ne peut pas être un CNAME - et d'autres informations sur le DNS

Ce poste utilisera la question ci - dessus pour explorer DNS, dig, les Adossiers, les CNAMEdossiers et les ALIAS/ANAMEdossiers du point de vue d'un débutant. Alors, commençons.

Tout d'abord, quelques définitions

  • Système de noms de domaine (DNS): le système global de conversion d'un nom de domaine mémorable par l'homme (example.com) en une adresse IP (93.184.216.34). L'adresse IP est celle d'un serveur, généralement un serveur Web, sur lequel sont stockés les fichiers nécessaires pour afficher une page Web.
  • Serveur DNS (également appelé serveur de noms ou serveur de noms): utilise le logiciel DNS pour stocker des informations sur les adresses de domaine. Il existe plusieurs niveaux - ceux appartenant à chaque FAI, racine (13 au total dans le monde), domaine de premier niveau (TLD, par exemple «.com») et serveurs DNS au niveau du domaine.
  • Nom de domaine : le domaine (exemple) combiné avec le TLD (.com). Le terme «domaine» est souvent utilisé comme synonyme du nom de domaine, bien qu'ils soient différents. Lorsque vous achetez un «domaine» auprès d'un registraire ou d'un revendeur, vous achetez les droits sur un nom de domaine spécifique (exemple.com) et sur tous les sous-domaines que vous souhaitez créer (mon-site.exemple.com, mail.example.com, etc).

Flux de requête de haut niveau

Le flux de haut niveau de ce qui se passe lorsque vous tapez «example.com» dans votre navigateur peut être simplifié pour supprimer les sauts vers les serveurs DNS FAI, racine et TLD comme ci-dessous:

Un domaine a généralement deux serveurs de noms ou plus, contenant des enregistrements relatifs au nom de domaine (exemple.com).

De nombreux types d'enregistrements peuvent être stockés, dont la plupart peuvent avoir plusieurs entrées par type:

  • A: Enregistrements d'adresses qui mappent le nom de domaine à une adresse IP
  • CNAME: Enregistrement de nom canonique. Utilisé pour créer un alias d'un nom de domaine (ou nom de sous-domaine) vers un autre. Nous examinerons cela plus en détail plus tard.
  • MX: Des enregistrements Mail eXchange qui indiquent aux agents de distribution de courrier électronique où ils doivent livrer votre courrier électronique
  • TXT: enregistrements de texte flexibles, pour stocker des chaînes pour une variété d'utilisations
  • SOA: enregistrement de début d'autorité singulier conservé au niveau supérieur du domaine. Contient des informations requises spécifiques sur le domaine, par exemple son serveur de noms principal
  • NS: Les serveurs de noms associés au domaine

Lorsque votre appareil envoie une requête qui atteint un serveur de noms, le serveur recherche dans le nœud d'enregistrement du domaine un Aenregistrement et l'adresse IP stockée associée (exemple.com: 93.184.216.34). Celui-ci est ensuite renvoyé à l'appareil, pour être utilisé pour envoyer une demande au serveur Web approprié pour récupérer la page Web ou la ressource demandée.

Utilisation de 'dig'

dig( domain information groper ) est un outil de ligne de commande pour interroger les serveurs DNS. Cette commande est généralement utilisée pour le dépannage, ou comme maintenant pour en savoir plus sur la configuration d'un système.

$ dig example.comse traduit par une longue réponse imprimée sur le terminal, la sortie par défaut détaillée ici, dont nous nous intéressons au ANSWER SECTION.

;; ANSWER SECTION: example.com. 72703 IN A 93.184.216.34

Et là nous allons, nous pouvons voir que example.comrenvoie un Aenregistrement de 93.184.216.34. Parfois, les domaines auront plus d'un Aenregistrement, si plus d'un serveur Web peut fournir les informations nécessaires.

Il y a plus! Si nous essayons quelques autres exemples, nous pouvons bientôt qu'un autre enregistrement commun apparaît: CNAME.

$ dig www.skyscanner.net:

;; ANSWER SECTION: www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net. www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net. e11316.a.akamaiedge.net. 20 IN A 23.217.6.192
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

L'utilisation du +shortdrapeau nous permet de voir clairement le chemin formé:

$ dig www.skyscanner.net +short

www.skyscanner.net.edgekey.net. e11316.a.akamaiedge.net. 23.217.6.192

CNAME

Un CNAMEenregistrement permet d'utiliser un nom de domaine comme alias pour un autre domaine canonique (vrai).

Lorsque le serveur DNS renvoie un CNAMEenregistrement, il ne le renvoie pas au client. Au contraire, il recherchera à nouveau le nom de domaine retourné et retournera à son tour l' Aadresse IP de l' enregistrement. Cette chaîne peut se prolonger sur plusieurs CNAMEniveaux, mais subit ensuite des problèmes de performances mineurs dus à plusieurs recherches avant la mise en cache.

Un exemple simple de ceci pourrait être si vous avez un serveur sur lequel vous stockez toutes vos photos. Vous pouvez normalement y accéder via photos.example.com. Cependant, vous pouvez également souhaiter qu'il autorise l'accès via photographs.example.com. Une façon de rendre cela possible consiste à ajouter un CNAMEenregistrement qui pointe photographsvers photos. Cela signifie que lorsque quelqu'un visite, photographs.example.comil reçoit le même contenu que photos.example.com.

En utilisant la requête, $ dig photographs.example.comnous verrions:

photographs.example.com IN CNAME photos.example.com photos.example.com IN A xx.xxx.x.xxx

Il est important de noter que le CNAMEest cette pièce sur le côté droit. Le côté gauche est le nom d'alias, ou étiquette.

Le wwwsous - domaine est une autre utilisation courante . Après avoir acheté, example.comvous souhaitez probablement également que les utilisateurs qui saisissent www.example.comvoient le même contenu.

Il convient de noter ici que l' example.comon peut appeler le nom de domaine apex, racine ou nu.

Une option serait de créer un autre Aenregistrement, pointant vers la même adresse IP que pour example.com. C'est tout à fait valable, et c'est ce que fait le réel example.com, mais cela ne s'adapte pas bien. Que se passe-t-il si vous devez mettre à jour l'adresse IP qui example.compointe vers? Vous devrez également le mettre à jour pour le wwwsous - domaine et tous les autres que vous pourriez utiliser.

Si un CNAMEenregistrement était utilisé pour www.example.compointer vers un alias, example.comseul le domaine racine devrait être mis à jour, car tous les autres nœuds pointent vers lui.

Limitations CNAME

Au moment de la rédaction des normes DNS, certaines règles régissent leur utilisation. Les RFC 1912 et RFC 2181 stipulent que:

  • SOAet les NSenregistrements doivent obligatoirement être présents dans le domaine racine
  • CNAMEles enregistrements ne peuvent exister que des enregistrements uniques et ne peuvent être jumelée à aucune autre enregistrement de ressource (DNSSEC SIG, NXTet KEY RRdossiers exceptés)

Ceci exclut un CNAMEêtre utilisé sur le domaine racine, car les deux règles se contrediraient.

Ce qui est important ici, c'est qu'il s'agit d'une limitation contractuelle et non technique. Il est possible d'utiliser a CNAMEà la racine, mais cela peut entraîner des erreurs inattendues, car il rompt le contrat de comportement attendu.

Cloudflare en donne un exemple, décrivant les problèmes rencontrés avec les serveurs de messagerie Microsoft Exchange après avoir utilisé un CNAMEsur leur domaine racine:

Les domaines désignent généralement les serveurs qui gèrent leur courrier électronique via ce qu'on appelle un enregistrement MX. Le problème était que les serveurs Exchange… pouvaient récupérer le CNAME à l'enregistrement racine et ne pas respecter correctement le CNAME défini sur l'enregistrement MX. Vous ne pouvez pas vraiment blâmer Exchange. Ils fonctionnaient selon les hypothèses énoncées par la spécification DNS.

Here you see the downside that can appear in several server softwares or libraries. Because a standard is in place for a CNAME to be the only record at a node, no other records are looked for. All other records will be silently ignored, without warning or error messages. Even if an MX record was set to receive email, the MX will be ignored as if it doesn’t exist because the CNAME is evaluated first. The same is true if there were an A record: the CNAME would take precedence and the A record would not be read.

The modern internet

So why is this a problem? Why would you ever want to use a CNAME for your root domain anyway? Surely that is the end of the path when looking for the IP address of the web server hosting your content?

In the modern internet landscape, that is no longer the case. The world is very different from when the DNS standards were written.

You may choose to use a Platform as a Service (PaaS) provider like Heroku and store content on their web servers. You control the content, but not the infrastructure, and the PaaS provider does the heavy lifting of the network maintenance. They typically provide you with a URL (my-app.herokuapp.com) that is a subdomain of their root domain, and you can view the IP addresses for the web server(s) your content is on. But these are entirely under the PaaS provider’s control, and will change without warning.

The scale and frequency of backend changes made by the PaaS provider can make it hard to maintain your root domain A record pointing at a single IP address. Ideally you would wish to do this:

example.com IN CNAME my-app.herokuapp.com.www.example.com IN CNAME my-app.herokuapp.com.example.com IN CNAME my-app.herokuapp.com. www.example.com IN CNAME my-app.herokuapp.com.

to allow Heroku (or your chosen host provider) to manage updating the A record that the CNAME points to without any changes made on your side. However, as we now know, this breaks the DNS specification, so is a very bad idea.

It is possible to simply implement a 301/302 redirect from example.com to www.example.com. However, that instruction takes place either on the web server (so still having the problem of needing to use a fixed A record in DNS to point to that web server), or a custom DNS provider redirect (that suffers complications with HTTPS).

This also has the side effect of changing the domain that you see in the URL bar, which you may not want. This method is intended for when your website has permanently moved, or when you’re trying to preserve SEO rankings, rather than solving our problem of pointing to a complex changing backend in a scaleable way.

The solution

Several DNS providers have now developed custom solutions to work around this problem, including:

  • ALIAS at DNSimple
  • ANAME at DNS Made Easy
  • ANAME at easyDNS
  • CNAME (virtual) at CloudFlare

These are all virtual record types that provide CNAME like behaviour, with none of the downsides. The exact implementation can differ, but at a high level when the DNS server sees one of these virtual record types, it acts as a DNS resolver. It follows the chain created by the alias until it resolves at an A record (or records) and returns these A records to the DNS server. This ‘flattens’ the CNAME chain into the A record(s) returned, and is indistinguishable to the sent query. The query sees only a pure A record, which doesn’t break the DNS specification, and doesn’t have any of the disadvantages of a CNAME.

These virtual records can sit alongside other records at the root without any fear of unintended behaviours. Depending on the provider’s method of DNS resolution when following the CNAME chain, they may also have performance benefits from caching previous lookups.

For a DNSimple setup, we would then configure as below. This solution has all the advantages of domain name aliasing, and none of the risks of using it at root level.

example.com IN ALIAS my-app.herokuapp.com.www.example.com IN CNAME my-app.herokuapp.com.

Thanks for reading! ?

As always, open to any corrections or additional points.

Resources

  • What is a DNS Server
  • Set Up a DNS Name Server
  • DNSimple support pages and ALIAS blog
  • Cloudflare support and CNAME blog
  • dig HowTo
  • Several great Stack Overflow or StackExchange posts
  • Well written Wikipedia entries
  • Netlify blog ‘To www or not www’