diff options
author | baptiste <deuxfleurs@bitsofnetworks.org> | 2023-04-19 21:18:21 +0000 |
---|---|---|
committer | baptiste <deuxfleurs@bitsofnetworks.org> | 2023-04-19 21:18:21 +0000 |
commit | b5a2bd8355134aa4a6c92888cf66f68fc8392f97 (patch) | |
tree | 4f2b288a9888bc005e29b020526bb5b8d5839730 /content/prise_en_main/DNS-CNAME-apex.md | |
parent | 723aa523e81b215395c09085e3855a2473965354 (diff) | |
parent | a42b9f9c80b2110ac938775f2a6b2b6353eb0c3d (diff) | |
download | guide.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/DNS-CNAME-apex.md')
-rw-r--r-- | content/prise_en_main/DNS-CNAME-apex.md | 84 |
1 files changed, 84 insertions, 0 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. |