Un problème courant que rencontrent les techniciens débutant en
Commençons par une description concrète du problème. Alice,
technicienne
michu.example. IN CNAME michu-sa.example-cdn.net.
Ça devrait contenter tout le monde, pense-t-elle. Mais, si elle
connait assez le DNS pour savoir que le type d'enregistrement
CNAME existe, elle ne le connait pas assez pour avoir lu le
www.michu.example. IN CNAME michu-sa.example-cdn.net.
aurait marché mais le service communication voudrait un
Au passage, pourquoi est-ce que c'est interdit de mettre un
alias et d'autres données au même nom ? La principale raison est
qu'un enregistrement CNAME est censé créer un alias, un
synonyme. Si on pouvait écrire :
michu.example. IN AAAA 2001:db8::ff
michu.example. IN CNAME michu-sa.example-cdn.net.
Et qu'un client DNS demande l'enregistrement de type AAAA pour
Bon, se dit Alice, ça ne marche pas, mais on peut essayer
autrement : cherchons l'adresse IP correspondant au nom
% dig +short AAAA michu-sa.example-cdn.net
2001:db8:1000:21::21:4
michu.example. IN AAAA 2001:db8:1000:21::21:4
Cette fois, ça marche, mais il y a plusieurs inconvénients :
Bref, que faire ? Plusieurs sociétés ont développé une solution
non-standard ne marchant que chez
eux. L'
Voici maintenant les diverses pistes envisagées. Avant de dire
« ah, celle-ci a l'air cool », prudence. Rappelez-vous qu'il existe
de nombreux cas (minimisation de la requête -
Première idée, décider qu'il n'y a pas de problème. On laisse le
DNS comme il est et le problème doit être entièrement traité côté
avitaillement (le type qui édite le fichier de zone, ou bien le
logiciel qui le produit). C'est l'idée de base du hack utilisé par
Alice plus haut. Cela peut se faire avec un
#!/bin/sh
zonefile=$1
while :
do
target=$(awk '/ALIAS/ {print $3}' $zonefile)
ttl=$(dig A $target | awk "/^$target.*IN\s+A/ {print \$2}" | head -n 1)
ip=$(dig A $target | awk "/^$target.*IN\s+A/ {print \$5}" | head -n 1)
sed "s/IN.*ALIAS.*/ IN $ttl A $ip/" $zonefile > ${zonefile}-patched
echo "Patched with IP address $ip"
sleep $ttl
done
(En production, on voudra probablement quelque chose de plus
propre, notamment en gestion d'erreurs, et de traitement des
réponses multiples.)
Comme indiqué plus haut, cela marche, mais cela ne permet pas de
tirer profit des caractéristiques du CDN, par exemple de la réponse
différente selon le client. On peut voir cette variation de la
réponse, en demandant à cent sondes RIPE Atlas :
% blaeu-resolve --requested 100 --type A www.elysee.fr
[208.178.167.254 4.26.226.126 4.27.28.126 8.27.4.254] : 1 occurrences
[8.254.28.126 8.254.45.254 8.27.151.253 8.27.226.126] : 1 occurrences
[205.128.73.126 206.33.35.125 209.84.20.126 8.27.243.253] : 1 occurrences
[207.123.56.252 4.26.228.254 4.27.28.126 8.26.223.254] : 1 occurrences
[205.128.90.126 209.84.9.126 8.254.214.254 8.254.94.254] : 1 occurrences
[8.254.164.126 8.254.209.126 8.254.210.126 8.27.9.254] : 1 occurrences
[4.23.62.126 4.26.227.126 8.254.173.254 8.254.95.126] : 1 occurrences
[207.123.39.254 8.254.196.126 8.254.219.254 8.27.5.254] : 2 occurrences
[120.28.42.254 36.66.10.126] : 1 occurrences
...
Deuxième idée, relâcher la contrainte donnée dans le
michu.example. IN CNAME foobar.example.com.
IN MX 10 gimmedata.gafa.example.
Un client DNS qui demande le MX de
Plus ennuyeux est le fait que cela dépend : dans certains cas, un autre enregistrement que celui du CNAME est récupéré. On ne peut rien reprocher aux logiciels qui font cela : ils sont conformes aux RFC actuels. Cette variabilité rend difficile de simplement autoriser le CNAME à l'apex.
Troisième possibilité : on peut aussi décider que le
résolveur fera l'essentiel du boulot. On crée un nouveau type
d'enregistrement, mettons SEEALSO, qui peut coexister avec les
types existants :
michu.example. IN SEEALSO michu-sa.example-cdn.net.
michu.example. IN MX 10 gimmedata.gafa.example.
Le serveur faisant autorité n'aurait rien de particulier à faire,
il renvoie juste le SEEALSO au résolveur (en terminologie DNS, on
dit « il n'y a pas de traitement additionnel »). Le résolveur va alors, recevant le SEEALSO,
le suivre. Le principal problème de cette approche est
qu'initialement, peu de résolveurs auront le nouveau code, ce qui
ne motivera pas les gens qui gèrent les zones à ajouter ce SEEALSO.
Quatrième idée, toujours avec un nouveau type d'enregistrement
(et donc avec les problèmes de déploiement que cela pose dans un
Internet non centralisé),
généralement appelé ANAME ou ALIAS. L'idée est qu'on mettra dans la
zone :
michu.example. IN ANAME michu-sa.example-cdn.net.
michu.example. IN MX 10 gimmedata.gafa.example.
Le ANAME, contrairement au CNAME, a le droit de coexister avec
d'autres enregistrements, ici un MX. L'idée est que le serveur
faisant autorité, chargeant la zone, va résoudre la cible (la
partie droite du ANAME) et répondre avec l'adresse IP de la cible
lorsqu'on l'interrogera. Le résolveur ne voit donc pas le CDN, si
l'adresse au CDN est
michu.example. 3600 IN AAAA 2001:db8::ff
Le serveur faisant autorité, ayant chargé la zone, sera responsable
de changer cette valeur lorsque le
On voit que cette solution nécessite que le serveur faisant
autorité soit également résolveur. C'est considéré comme une
mauvaise pratique, car cela complique sérieusement le débogage :
on ne sait plus d'où viennent les données, et celles du résolveur
peuvent potentiellement masquer celles qui font
autorité. D'ailleurs, les meilleurs logiciels serveur faisant
autorité, comme
D'autre part, introduire un nouveau type de données DNS n'est jamais évident, cela nécessite de modifier les serveurs faisant autorité (les résolveurs, eux, n'ont pas besoin d'être modifiés, pour ce ANAME), mais également les logiciels d'avitaillement (interfaces web chez l'hébergeur DNS permettant de gérer sa zone).
Cette idée de ANAME pose également des problèmes à
On peut avoir des tas de variantes sur cette idée. C'est
d'ailleurs une des raisons pour laquelle le débat est
compliqué. Chaque idée a des sous-idées. Par exemple, puisque dans
ce cas, le
serveur faisant autorité est également résolveur, on pourrait
renvoyer le ANAME au client DNS, avec l'adresse IP du CDN, pour
gagner du temps. La réponse serait :
;; ANSWER SECTION:
michu.example. 3600 IN ANAME michu-sa.example-cdn.net.
;; ADDITIONAL SECTION:
michu-sa.example-cdn.net. 600 IN AAAA 2001:db8::ff
Plus de problèmes avec DNSSEC cette fois, puisqu'on n'importerait
plus de données extérieures dans la zone
Le projet ANAME avait fait l'objet d'un
Cinquième idée, résoudre le problème côté client, comme dans la
troisième, mais en modifiant les applications et non plus les
résolveurs. Après tout, le principal scénario d'usage est pour
michu.example. IN SRV 0 1 80 michu-sa.example-cdn.net.
; Autres types
michu.example. IN MX 10 gimmedata.gafa.example.
SRV, normalisé dans le
Tout cela pose évidemment un réel problème de déploiement puisqu'il
faudrait modifier tous les clients HTTP (rappelez-vous qu'il n'y a
pas que les
Et je n'ai pas cité toutes les idées, comme la possibilité
d'utiliser Alt-Svc (
Conclusion ? Le problème est bien sûr réel et se pose à beaucoup d'acteurs de l'Internet. Mais il n'y a pas de solution idéale. Il faudra, soit continuer comme actuellement si l'IETF n'arrive pas à un accord, soit adopter une solution qui, de toute façon, créera ses propres problèmes. Personnellement, je pense que la solution la plus propre serait de modifier HTTP, pour utiliser une indirection, comme tous les autres protocoles. Si cela n'est pas possible, il vaut encore mieux ne rien faire : le dromadaire est assez chargé comme cela.