Contexte et coûts d’AWS

Le blog de l’auteur utilisait initialement Amazon CloudFront pour la diffusion des actifs et Route 53 pour le DNS géographique. Le modèle tarifaire de Route 53 est : 0,50 $ par zone chaque mois, 0,70 $ par million de requêtes de géolocalisation et 0,75 $ par contrôle de santé mensuel, plus 1 $ pour la clé KMS nécessaire à la signature DNSSEC. Ces frais représentent une charge non négligeable pour un site à trafic modeste.

En 2022, Bunny.net a lancé son service DNS, dont le prix a été réduit à presque zéro pour jusqu’à 500 domaines. Cette offre, combinée à la localisation européenne de l’entreprise (Slovénie), a motivé le basculement.

Fonctionnement du DNS scriptable de Bunny

Bunny DNS propose une fonctionnalité « scriptable » qui exécute du JavaScript fourni par l’utilisateur à chaque requête DNS. Le script fourni par l’auteur définit un tableau servers contenant les adresses IPv4 et IPv6, ainsi que les coordonnées géographiques de sept machines NixOS réparties à Paris, Nuremberg, Ashburn, Singapour, San Jose, São Paulo et Sydney.

const servers = [
  { ipv4: "45.90.160.60", ipv6: "2a0c:8881:5:100::1", latitude: 48.88, longitude: 2.22 },
  /* … */
  { ipv4: "139.180.162.114", ipv6: "2001:19f0:5800:1855:5400:6ff:fef0:4c0a", latitude: -33.87, longitude: 151.21 }
];

Le moteur RoutingEngine.getClosestServer() calcule les deux serveurs les plus proches du client, en filtrant les serveurs inactifs. Le script renvoie ensuite les enregistrements A ou AAAA correspondants avec un TTL de 3600 s.

Limites et solutions alternatives

Le principal problème identifié est la mauvaise expérience pour les utilisateurs situés loin des deux serveurs sélectionnés. Par exemple, un client depuis Buenos Aires reçoit à la fois le serveur de São Paulo (≈ 1000 mi, 30 ms RTT) et celui d’Ashburn (≈ 5200 mi, 140 ms RTT). Comme la plupart des résolveurs randomisent l’ordre des réponses, le navigateur peut choisir le serveur le plus distant, augmentant ainsi la latence.

Une première tentative de résolution a consisté à exploiter les enregistrements HTTPS définis par la RFC 9460. Ces enregistrements permettent de spécifier plusieurs cibles avec des priorités et des protocoles (h3, h2). Cependant, Chrome ignore les cibles qui ne se terminent pas par « . », et Bunny DNS ne fournit pas les adresses IP des cibles dans la section additionnelle, obligeant le résolveur à effectuer une requête supplémentaire. L’immaturité de la prise en charge des enregistrements HTTPS rend cette approche non viable pour le moment.

Solution hybride et analyse d’impact

Le script final adopte une logique hybride : si le deuxième serveur est à plus du double de la distance du premier et dépasse 1000 miles, le script ne renvoie que le serveur le plus proche avec un TTL de 120 s. Sinon, les deux serveurs sont renvoyés avec le TTL standard d’une heure. Cette adaptation réduit la fenêtre d’indisponibilité tout en conservant une certaine redondance.

Les tests avec l’outil doggo confirment le comportement : depuis Chicago, seul le serveur d’Ashburn est retourné avec un TTL de 2 minutes, tandis que depuis Mexico les deux serveurs (Ashburn et San Jose) sont fournis. Le passage de Route 53 à Bunny DNS élimine les coûts mensuels de plusieurs dizaines de dollars, mais introduit une dépendance à la stabilité du script et aux limites actuelles du protocole HTTPS DNS.