Je vous propose ici de faire un retour d’expérience, ou post mortem, concernant la gestion de mes serveurs de noms de domaines (DNS).

Du serveur dédié tout-en-un au parc de serveurs spécialisés

Jusqu’en début 2008, je louais un serveur dédié doté d’un système d’exploitation Linux Gentoo OVH Release 2, spécifique à mon prestataire d’hébergement, OVH. J’avais ainsi pris l’habitude de rassembler sur un même serveur dédié l’ensemble des services relatifs aux sites web, dont la gestion du serveur de noms de domaines (DNS) primaire, confiant à OVH, qui est autant mon prestataire d’hébergement que bureau d’enregistrement (ou registrar) des noms de domaines, la gestion du DNS secondaire.

Depuis début 2008, cependant, j’ai voulu diversifier mon parc de serveurs. J’en gère aujourd’hui 5, au total, répartis auprès de trois prestataires différents : trois RPS-1 chez OVH, un VPS chez Gandi, une Dedibox XL chez Dedibox. Pour harmoniser les configurations logicielles, j’ai opté pour un système d’exploitation Linux Debian Etch. La gestion des DNS sur chacun de ces serveurs serait possible, mais la taille et l’hétérogénéité du parc la rendrait rapidement difficile.

DNS : définition des besoins et solutions

D’expérience, j’avais deux types de besoins très spécifiques : la réactivité des modifications, d’une part, et l’accessibilité, d’autre part, le tout avec une notion de productivité.

DNS avec propagation rapide

Tout d’abord, sur certains de mes noms de domaines sur lesquels j’interviens régulièrement, j’ai besoin d’un temps de propagation rapide de mes modifications de DNS. Cela se fait par la définition du paramètre Time to Live (TTL) réduit dans la configuration du DNS. Or, sur les DNS de la plupart des prestataires web, dont OVH, ce temps de propagation n’est pas éditable et reste à la discrétion du prestataire, généralement fixé à 24 heures. Cette voie ne pouvait par conséquent être explorée pour répondre à mes attentes.

Pour satisfaire mes besoins, j’ai donc consacré un RPS-1 comme DNS primaire, ainsi qu’un VPS comme DNS secondaire. De cette manière, lorsque je fais des modifications dans les DNS des domaines concernés, je peux si besoin est mettre un TTL de 60 secondes, par exemple, permettant en principe une propagation d’une minute (mais en contrepartie alourdissant les requêtes des utilisateurs, puisqu’elles doivent faire des résolutions de domaines fréquentes), et une fois toutes les modifications effectuées, remettre un TTL plus long (1 à 24 h en général, augmentant d’autant les temps de propagation, mais réduisat les requêtes de résolution de domaines inutiles lorsque le domaine est prévu pour être stable dans le futur proche).

En matière de stabilité de cette solution, elle ne m’a pas posé de problème depuis le mois de février 2008 que je l’ai mise en place, à savoir le lancement officiel des RPS-1, et cela malgré les quelques défauts liés à la mise en production des RPS, dont des problèmes de blocage de durée indéterminée lors de certains accès disque. En somme, tous les domaines ainsi gérés ont toujours pu être accédés d’une manière ou d’une autre sans aucune gêne (du moins que j’aurais notée) pour les utilisateurs.

DNS stables avec disponibilité et productivité optimales

Ensuite, j’avais besoin de DNS primaire et secondaires sûrs que je puisse mettre à jour sans perdre de temps.

Pour cela, je fais appel aux DNS de mon hébergeur web, OVH. En effet, depuis 2005 que je fais appel aux services d’OVH, je ne me souviens pas d’un seul défaut de DNS ayant empêché l’accès à mes sites. Ca, c’est pour la disponibilité. Pour répondre à mes besoins de productivité, l’usage de l’API SOAPI d’OVH, interface de programmation SOAP dotée d’un générateur de code dans la plupart des langages de programmation courants sur le web.

En effet, cette API permet permet un gain de temps considérable, puisqu’en quelques lignes auto-générées via la documentation en ligne, on peut effectuer des mises à jour en pagaille. C’est notamment particulièrement pratique lorsque l’on achète des domaines aux consonances similaires en pagaille pour limiter les cas de cyber- et typo-squatting et que l’on souhaite mettre en place des redirections web et mail sur tous les domaines secondaires vers le domaine principal. Cela prend de l’ordre de 10 minutes tout compris (lecture de la documentation, génération du code PHP, téléchargement sur un espace d’hébergement web, exécution du script de mise à jour, vérification succincte) pour une vingtaine de domaines.

D’autres prestataires mettant à disposition leurs DNS proposent eux aussi leurs API dédiées, plus ou moins exhaustives.

Conclusions

Serveurs DNS spécialisés

Bref, spécialiser un RPS-1 pour gérer un DNS primaire ou secondaire semble tout à fait possible dans d’excellentes conditions, pour ce que j’ai pu voir sur ma propre expérience. Le serveur a beau être peu puissant, et sa disponibilité imparfaite, en cas de défaillance éventuelle, le serveur secondaire prend la main de manière transparente, et aucun problème visible n’apparaît aux yeux de l’utilisateur final.

En revanche, compte tenu des blocages intempestifs que j’ai pu noter ces derniers mois sur les RPS ou aux messages des autres clients concernant la stabilité du SAN jusqu’à récemment, l’utilisation des RPS pour la gestion de l’ensemble des DNS (primaire, secondaire, et éventuellement aussi tertiaire et quaternaire) n’est pas pertinente, tout comme l’utilisation d’un ensemble de VPS chez un même prestataire pour la gestion des DNS.

Pour garantir une meilleure disponibilité d’au moins l’un des DNS, mieux vaut utiliser soit l’un des DNS secondaires proposés par son prestataire web habituel (hébergeur ou bureau d’enregistrement) comme serveur secondaire (ou tertiaire, ou quaternaire), soit un serveur tiers (par exemple, comme dans mon cas, utiliser un serveur secondaire chez un autre prestataire).

Attention aux coûts

Un point qu’il est bon de ne pas négliger est celui du coût : est-il pertinent d’investir 119,88 € HT par an (la location d’un RPS-1) pour gérer soi-même son DNS primaire alors qu’il existe des services tiers qui permettent eux aussi de redéfinir des TTL courts, que ce soit gratuitement ou contre rémunération, avec ou sans API dédiée. ZoneEdit, notamment, répond à plusieurs de ces critères.

En fait, cela dépend sans doute de la quantité de domaines à gérer, ou encore des habitudes de chacun.

En effet, si vous ne devez gérer ainsi qu’un unique nom de domaine de la sorte, ou que vous n’avez pas l’habitude d’administrer un serveur, cela devient hors de prix. Utiliser un serveur dédié, réel ou virtuel pour faire un DNS spécialisé n’est pas du tout pertinent et devrait être évité. Éventuellement, mieux vaut alors utiliser un DNS sur l’un des serveurs dédiés déjà fonctionnels et qui a déjà toutes les chances d’être configuré pour faire office de DNS, parmi les autres services en fonctionnement.

En revanche, si vous avez de nombreux noms de domaines dont vous souhaitez gérer les DNS par vous-même dans le détail, et que vous avez par ailleurs l’habitude d’administrer un serveur, l’usage d’un serveur DNS spécialisé peut être intéressant pour centraliser la gestion des DNS sur un même serveur ou groupe de serveurs et ainsi savoir où les modifier le cas échéant, d’autant que l’administration d’un serveur DNS uniquement reste fort limitée.

Mot de la fin

Pour finir, dans mon cas présent, l’utilisation d’un serveur DNS spécialisé reste un luxe, compte tenu de mes besoins réels de modifications à propagation rapide. Cependant, c’est un luxe que j’apprécie particulièrement lorsque j’y ai recours.