Cela fait environ 6 mois maintenant que le serveur CLUB1 gère ses propres DNS. Ce n'est pas du tout extraordinaire mais il y a toutefois quelques details intéressants à noter.

Pourquoi diable gérer ses DNS soi-même ?

Je vous le demande ! L'un des intérêts premiers était de réduire la force du lien qui nous retenait à notre registraire, qui, bien que fort sympatique, nous enlevait une certaine part d'indépendance. Nous somme évidemment toujours tributaire de cette tierce partie mais dans une bien moindre mesure. En effet c'est toujours lui qui reserve nos noms de domaine et informe les domaines de premier niveau du nom de nos authoritative name servers mais toute la gestion et la configuration des zones se fait maintenant sur notre serveur. Cela nous amène à la deuxième raison qui nous a poussée à réaliser ce changement : les possibilités illimitées de configuration et surtout de scripting de cette dernière.

Pour bien comprendre l'intérêt majeur que représente cette histoire de scripting il faut revenir aux fondations du projet qu'est CLUB1. Apprendre et s'amuser, tels étaient les maîtres-mots dès la première ébauche de cette aventure dans les vastes étendues de l'auto-hé­ber­ge­ment. C'est donc par envie et avec entrain que nous nous engageons sur les chemins sinueux de l'installation manuelle en CLI plutôt que sur les grandes voies toutes tracées des solutions telles que https://yunohost.org. Ces dernières, fortement fréquentées et à juste titre, n'étaient effectivement pas compatibles avec notre but qui se focalisait bien moins sur la destination que sur le voyage en lui même. Mais le chemin aura beau être splendide, devoir y repasser sans cesse le rendra monotone. C'est là qu'interviennent les scripts. Ces petits bouts de code sont en fait des raccourcis qui permettent d'accélérer considérablement les portions longues et ennuyeuses du trajet pour pouvoir se concentrer sur l'exploration de terrains inconnus.

Un petit paquet de scripts a donc été réalisé, principalement pour la gestion des utilisateurs et de l'hébergement web, mais une parcelle, particulièrement rébarbative restait malheureusement impossible à scripter. Il s'agit comme vous pouvez vous en douter de la gestion des DNS. Pire encore, cette gestion, non contente de ne pas être automatisable, se devait d'être accédée par le biais d'une GUI qui, bien qu'à minima disponible de n'importe où car s'agissant d'une interface web, n'en requérait pas moins une souris pour son utilisation. Cet affront insupportable pour les intrépides aventuriers que nous étions fut sans nul doute l'élément déclencheur de l'éxpédition qui suivra.

Une première tentative

L'objectif était simple : supprimer cette inacceptable opération manuelle et de surcoît à la souris. La première approche envisagée consistait à s'appuyer sur l'API que mettait à disposition notre registraire. La présence d'une route update permettant de mettre à jour les champs de la configuration DNS nous confortant dans cette décision, nous entreprenons donc l'intégration de quelques requêtes HTTP au cœur de nos scripts. La réponse 200 ne se fait pas trop attendre et nous pouvons ainsi définitivement tirer un trait sur ce probème. Ou du moins c'est ce que nous pensions.

Quelques jours plus tard, nous remarquons qu'un de nos sous-domaines n'est plus accessible. En fait c'est une bonne partie de nos sous-domaines qui ne le sont plus. Une rapide inspection de nos zones DNS à partir de la GUI web nous indique effectivement que les entrées correspondantes n'étaient plus présentes. Nous les y ajoutons donc à nouveau mais le même schéma se reproduit à l'identique peu de temps après. Les appels API récemment ajoutés et utilisés sont rapidement supectés et une nouvelle lecture de la documentation de ces appels nous fait immédiatement comprendre notre erreur: la route que nous pensions pouvoir utiliser pour ajouter un sous-domaine permettait en fait de remplacer l'ensemble de la configuration de la zone par le contenu de la requête. Il n'éxistait donc pas de route pour ajouter un sous-domaine et plus gênant encore celle que nous utilisions avait un comportement imprédictible, car certains sous-dommaines était encore fonctionnels à l'issue de l'opération. Nous décidons donc de laisser tomber cette solution qui de toute façon n'aurait jamais apporté entière satifaction en raison de l'impossibilité de consulter facilement la configuration des zones.

La mise en place du serveur

La solution ultime d'une gestion in-house complète des DNS apparait alors encore plus attrayante maintenant qu'elle est la seule. Nous n'allons probablement pas revenir sur l'installation et la configuration du serveur bind9 puisque cela se résume finalement à un petit coup d'apt install et de quelques lignes de configuration de zones, ma foi pas bien méchantes. Un export plain text de l'ensemble de nos sous-domaines n'était pas étranger à la rapidité de la migration. Nous rendons enfin une dernière visite à l'interface web de notre registraire pour y remplacer les noms des authoritative name servers par le notre avant de la fermer en nous délectant de l'idée de ne plus jamais avoir à la rouvrir.

Une fois le script d'ajout de sous-domaine adapté à cette nouvelle architecture, la satifaction induite par cette solution est immédiate, tout fonctionne parfaitement, sans aucun accroc. Mais un défaut persiste : en réduisant notre délégation DNS de trois authoritative name servers à un seul, nous exposons nos services à une panne, puisqu'il suffit que cet unique serveur ne réponde pas pour pour que l'ensemble de nos sous-domaines soient inaccessibles. Dans notre cas ce n'est pas tellement dramatique car les services et les DNS sont gérés par le même serveur et si celui-ci est en panne alors plus rien n'est accessible de toute façon, mais nous décidons tout de même de ne pas prendre ce défaut à la légère et nous nous mettons donc en quête d'un service de réplication de DNS. Notre choix s'arrête sur https://buddyns.com, un service gratuit qui nous apporte exactement ce dont on avait besoin. Quelques modifications de fichiers de configuration plus tard, la réplication est fonctionnelle et nous pouvons enfin dormir sur nos deux oreilles.