www contre domaine apex : la restriction CNAME, la portée des cookies et vers lequel rediriger

Ce que c'est

example.com (l'apex, ou racine de la zone) et www.example.com sont deux noms d'hôte qui servent généralement le même site. La RFC 1034 énonce que si un enregistrement CNAME est présent sur un nœud, aucune autre donnée ne devrait y être présente. L'apex porte toujours les enregistrements SOA et NS de la zone, si bien qu'il ne peut pas être un alias ; il lui faut des enregistrements A et AAAA littéraux. www est un nom ordinaire et peut être un CNAME vers la cible d'un fournisseur d'hébergement, ce qui permet à celui-ci de changer d'adresses sans que le client n'ait à modifier le DNS. Certains fournisseurs DNS offrent un contournement au niveau de l'apex : le CNAME flattening de Cloudflare résout lui-même l'alias et renvoie l'adresse IP finale au lieu d'un enregistrement CNAME ; sa documentation note qu'une cible sans enregistrement A/AAAA produit une réponse vide, et que ce lissage peut casser des services qui vérifient la propriété en lisant le CNAME.

Les cookies constituent la seconde différence. La RFC 6265 indique qu'un cookie défini sans attribut Domain n'est renvoyé qu'au serveur d'origine ; un cookie défini avec Domain=example.com est envoyé à tous les sous-domaines. Un site servi sur l'apex tend donc à partager ses cookies avec api., static. et tout futur sous-domaine, tandis qu'un site sur www peut les garder propres à l'hôte.

Pourquoi c'est important

Ce choix affecte la flexibilité d'hébergement (CNAME ou non), l'exposition des cookies aux sous-domaines, la couverture du certificat et tous les liens jamais publiés. Il est peu coûteux à décider une fois, et coûteux à modifier ensuite.

Comment l'appliquer

• Choisir la forme canonique. www lorsque le site est hébergé chez un fournisseur qui déplace ses adresses, ou lorsque d'autres sous-domaines ne doivent pas voir les cookies du site ; l'apex lorsque les URL courtes importent et que le fournisseur DNS offre un lissage ou des adresses stables.
• Inclure les deux noms dans le certificat et les servir tous deux en HTTPS ; rediriger le nom non canonique vers le nom canonique avec un statut permanent, en préservant le chemin et la requête.
• Maintenir AAAA et A cohérents sur les deux noms ; un CNAME www hérite des enregistrements de sa cible, l'apex doit être maintenu à la main.
• Définir les cookies applicatifs comme propres à l'hôte, sauf si des sous-domaines en ont besoin, et utiliser le préfixe __Host- là où l'article sur les cookies le recommande.
• Vérifier dig example.com A, dig www.example.com CNAME, ainsi que la redirection dans les deux sens après chaque changement de DNS ou d'hébergement.

Pièges

Un CNAME placé sur l'apex par une interface de fournisseur permissive, qui abandonne silencieusement les enregistrements MX ou TXT. Le includeSubDomains de HSTS activé sur l'apex avant que chaque sous-domaine ne serve HTTPS. Des boucles de redirection lorsque les deux noms se redirigent l'un vers l'autre après une scission de configuration.