aboutsummaryrefslogtreecommitdiff
path: root/content/prise_en_main
diff options
context:
space:
mode:
authorbaptiste <deuxfleurs@bitsofnetworks.org>2023-04-19 21:18:21 +0000
committerbaptiste <deuxfleurs@bitsofnetworks.org>2023-04-19 21:18:21 +0000
commitb5a2bd8355134aa4a6c92888cf66f68fc8392f97 (patch)
tree4f2b288a9888bc005e29b020526bb5b8d5839730 /content/prise_en_main
parent723aa523e81b215395c09085e3855a2473965354 (diff)
parenta42b9f9c80b2110ac938775f2a6b2b6353eb0c3d (diff)
downloadguide.deuxfleurs.fr-b5a2bd8355134aa4a6c92888cf66f68fc8392f97.tar.gz
guide.deuxfleurs.fr-b5a2bd8355134aa4a6c92888cf66f68fc8392f97.zip
Merge pull request 'Doc sur le problème des CNAME à l'apex d'une zone DNS' (#23) from dns_cname_apex into main
Reviewed-on: https://git.deuxfleurs.fr/Deuxfleurs/guide.deuxfleurs.fr/pulls/23
Diffstat (limited to 'content/prise_en_main')
-rw-r--r--content/prise_en_main/DNS-CNAME-apex.md84
-rw-r--r--content/prise_en_main/mettre-place-DNS.md15
2 files changed, 98 insertions, 1 deletions
diff --git a/content/prise_en_main/DNS-CNAME-apex.md b/content/prise_en_main/DNS-CNAME-apex.md
new file mode 100644
index 0000000..3b44bde
--- /dev/null
+++ b/content/prise_en_main/DNS-CNAME-apex.md
@@ -0,0 +1,84 @@
+---
+title: "CNAME à l'apex"
+description: "Les CNAME à l'apex d'une zone DNS"
+date: 2023-04-19
+weight: 0
+extra:
+ parent: "prise_en_main/mettre-place-DNS.md"
+---
+
+# Le problème
+
+Dans le protocole DNS, il n'est pas possible de mettre un champ CNAME à l'apex d'une zone.
+
+Concrètement, qu'est-ce que ça veut dire ? Si vous gérez la zone `example.com` et que vous
+aimeriez faire pointer ce nom vers `garage.deuxfleurs.fr` pour que Deuxfleurs héberge votre
+site web, la solution naturelle serait de configurer un CNAME. Dans un fichier de zone,
+cela ressemblerait à :
+
+ @ 10800 IN CNAME garage.deuxfleurs.fr.
+
+Hors, cela est interdit par le protocole DNS. Pourquoi donc ? Parce qu'un CNAME s'applique
+à tous les types d'enregistrements, pas simplement les `A` (adresse IPv4) et `AAAA` (adresse IPv6).
+Ainsi, la redirection du CNAME s'appliquerait également aux enregistrements comme `NS` et `MX`, ce qui
+rentrerait en conflit avec ces enregistrements déjà existants dans votre zone.
+
+[Une explication technique plus détaillée est disponible sur le site de l'ISC](https://www.isc.org/blogs/cname-at-the-apex-of-a-zone/).
+
+# Solutions possibles
+
+## Implémentations non-standard : ALIAS et CNAME flattening
+
+Certains hébergeurs et logiciels DNS proposent une solution non-standard à ce problème.
+
+Gandi permet de configurer un champ `ALIAS` à l'apex d'une zone qui pointe vers un autre
+nom comme `garage.deuxfleurs.fr`. Cet enregistrement `ALIAS` ne sera jamais renvoyé directement
+aux clients DNS : à la place, ce sont les serveurs DNS de Gandi qui vont dynamiquement consulter
+les enregistrements `A` et `AAAA` de `garage.deuxfleurs.fr`, puis les renvoyer dans la requête
+initiale pour `example.com`.
+
+De manière confuse, [Cloudflare permet de mettre un enregistrement CNAME à l'apex d'une zone](https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/).
+Comment font-ils, puisque c'est interdit ? En fait, ils utilisent exactement la même technique que Gandi, mais
+ils ont choisi de réutiliser le terme `CNAME` là où Gandi appelle cela un `ALIAS`. C'est un choix de nom
+très discutable puisqu'il ne s'agit pas vraiment d'un CNAME.
+
+Très peu d'implémentations logicielles libre de serveur DNS faisant autorité proposent cette fonctionnalité.
+Les logiciels classiques Bind, NSD et Knot ne l'implémentent pas. Parmi les autres logiciels couramment utilisés,
+seuls [PowerDNS Authoritative Nameserver](https://doc.powerdns.com/authoritative/index.html) et [CoreDNS](https://coredns.io/) l'implémentent :
+[PowerDNS avec la syntaxe ALIAS comme chez Gandi](https://doc.powerdns.com/authoritative/guides/alias.html), et
+[CoreDNS avec la syntaxe CNAME abusive comme chez Cloudflare](https://coredns.io/explugins/alias/).
+
+Il faut noter que c'est une technique plutôt complexe à implémenter correctement, puisqu'elle nécessite que le serveur DNS
+faisant autorité joue un rôle de récurseur, ce qui n'est pas nécessaire en temps normal.
+
+Au final, c'est une solution ad-hoc qui est très spécifique à certains fournisseurs
+et logiciels, avec même plusieurs syntaxes possibles. Elle présente donc un risque fort
+d'enfermement auprès de ces fournisseurs ou logiciels.
+
+## En cours de standardisation : SVCB et HTTPS
+
+Deux nouveaux types d'enregistrements DNS sont [en cours de standardisation : SVCB et HTTPS](https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/).
+Ce travail en cours couvre un spectre plus large, mais il résout en particulier
+ce problème de CNAME à l'apex.
+
+En mars 2023, ce document de travail en est à sa 12ème révision et n'a pas encore été publié
+officiellement comme un standard (RFC). Cependant, il semblerait que [certains navigateurs web et certains logiciels
+serveurs DNS aient déjà commencé à implémenter cette spécification depuis 2021 environ](https://serverfault.com/a/1075524).
+
+## Solutions recommandées chez Deuxfleurs
+
+Vous êtes responsable de votre nom de domaine, donc n'hésitez pas à expérimenter si
+vous le souhaitez ! Si vous avez des retours sur l'utilisation de SVCB/HTTPS, nous sommes intéressés.
+
+Cependant, Deuxfleurs recommande pour l'instant les solutions suivantes :
+
+- utiliser un sous-domaine lorsque cela est possible
+
+- sinon, utiliser l'implémentation non-standard de Gandi ou Cloudflare
+
+En effet, la solution SVCB/HTTPS est encore en cours de standardisation en 2023
+et va mettre de nombreuses années avant d'être déployée sur tous les terminaux.
+Compter uniquement sur cette solution, c'est écarter de fait tous les clients un
+peu anciens (vieux téléphones Android, anciennes versions de Windows ou d'Ubuntu
+pas mises à jour), alors que Deuxfleurs cherche à éviter l'obsolescence et faire
+en sorte que ces appareils restent utilisables le plus longtemps possible.
diff --git a/content/prise_en_main/mettre-place-DNS.md b/content/prise_en_main/mettre-place-DNS.md
index b125d4c..583e1d6 100644
--- a/content/prise_en_main/mettre-place-DNS.md
+++ b/content/prise_en_main/mettre-place-DNS.md
@@ -12,7 +12,20 @@ Les noms de domaine sont gérés et loués par les _registraires de nom de domai
Pour référence, la location d'un nom de domaine en `.fr` est d'environ 12 euros par an. Certaines offres vous fournissent «des extras» en plus comme une boîte courriel, sans que ça n'influe grandement sur les prix. En ce qui nous concerne, Gandi est un des registraires que nous recommandons.
-### Configurer un enregistrement DNS pour un site hébergé chez Deuxfleurs : exemple avec Gandi
+## Utiliser directement le nom de domaine ou un sous-domaine ?
+
+Une question importante est de choisir si on veut utiliser directement son nom de domaine (`example.com`)
+ou alors un sous-domaine, par exemple `blog.example.com`.
+
+[Utiliser le nom de domaine directement impose certaines contraintes techniques](@/prise_en_main/DNS-CNAME-apex.md)
+(la page liée contient de nombreux détails techniques sur le sujet).
+C'est une configuration qui fonctionne notamment chez Gandi grâce au champ ALIAS décrit ci-dessous, mais
+tous les hébergeurs DNS ne permettent pas cette configuration.
+
+A l'inverse, utiliser un sous-domaine comme `blog.example.com` fonctionnera chez tous les hébergeurs DNS
+et avec tous les logiciels DNS standards.
+
+## Configurer un enregistrement DNS pour un site hébergé chez Deuxfleurs : exemple avec Gandi
Une fois votre nom de domaine réservé, il faut maintenant le configurer. La procédure change en fonction de l'entreprise choisie. Nous expliquons ici comment configurer chez Gandi. Supposons que vous avez loué `camille-michu.fr` chez eux.
D'abord, rendez-vous dans votre espace utilisateur Gandi, puis de là cliquez dans le menu à gauche sur «Nom de domaine» :