Deux ans après son lancement en open source, où en est
IBDNS ?

Qu’apporte le nouveau système de configuration basé sur un mini-langage ?

Dans les versions d’IBDNS plus anciennes, le comportement ne pouvait être paramétré qu’en fonction du nom de domaine demandé. Il s’est avéré que c’était insuffisant : nous avions besoin d’activer un comportement fautif si une requête entrante répondait à des critères spécifiques, allant plus loin que juste le nom demandé.

C’est pourquoi la version 0.5.0 introduit un nouveau format de fichier de configuration. Il est possible d’y exprimer des règles : si une requête DNS entrante vérifie un ou plusieurs critères d’entrée, exprimés par un mini-langage, alors le serveur doit activer tel
ou tel mode de défaillance.

Par exemple, la règle ci-dessous, qu’il n’était pas possible d’exprimer dans l’ancien système de configuration, stipule que pour toutes les requêtes dont le nom demandé (« QNAME »)
est breaks-on-edns.test ou un de ses sous-domaines et contenant une option EDNS d’identifiant 65 500, le serveur ne doit pas répondre aux requêtes EDNS.

En somme, un des buts d’IBDNS est de pouvoir reproduire à la demande des bugs qui ont été observés dans d’autres serveurs de noms faisant autorité. Ce nouveau système permet un contrôle beaucoup plus fin du comportement d’IBDNS, permettant ainsi une simulation beaucoup plus fidèle de tels serveurs défaillants.

Qu’est-ce que l’approche Diátaxis et pourquoi avoir repensé la documentation d’IBDNS
selon cette approche ?

Diátaxis est une méthode de rédaction de documentation technique ; sa principale caractéristique est de faire une distinction claire entre les tutoriels, les guides, les documents d’explication et les documents de référence.

Et du fait de sa conception, IBDNS propose de nombreux paramètres de configuration, dont le rôle et le fonctionnement doivent être rigoureusement documentés. C’est pourquoi, assez tôt dans le développement, j’ai décidé de suivre l’approche Diátaxis pour la documentation.

Dans le cas d’IBDNS, parmi les quatres catégories de Diátaxis, la plus importante est la documentation de référence, notamment pour les paramètres de configuration.

Chaque paramètre est soigneusement documenté : on commence par un résumé des valeurs possibles, on poursuit par une description détaillée de son effet, les spécifications qui sont enfreintes et les conséquences, avant de finir par les usages possibles de ce paramètre.

Il s’agit de pouvoir reproduire un comportement erroné de certains serveurs de noms faisant autorité dans un cas subtil : il peut arriver qu’on ait des enregistrements au domaine zone.example et des enregistrements au sous-domaine clé._domainkey.zone.example
(pour une clé DKIM par exemple).

Dans ce cas, _domainkey.zone.example est un nom qui existe mais qui contient zéro enregistrement : on appelle cela un nœud non feuille vide (en anglais : empty non-terminal ou ENT). Si on demande _domainkey.zone.example, on doit donc obtenir un code de réponse NOERROR.

Au lieu de cela, il arrive que certains serveurs répondent NXDOMAIN, comme pour un nom de domaine inexistant ; dans ce cas, c’est un bug dans le serveur. Un bug hélas classique contre lequel un client doit pouvoir se défendre : par exemple, en ne mémorisant que la non-existence de _domainkey.zone.example et pas celle du sous-arbre entier.

Comment IBDNS s'est-il illustré dans des cas d'usage concrets ?

En octobre 2025, j’ai participé avec quelques collègues à un hackathon DNS qui a eu lieu à Stockholm et qui a été organisé par Internetstiftelsen, DNS-OARC et Netnod. Ce hackathon m’a permis de travailler sur IBDNS, puis de faire une présentation éclair à ce sujet au RIPE 91 à la fin du mois d’octobre 2025.

Le projet sur lequel j’ai travaillé consistait à mettre en œuvre une proposition d’extension au DNS pour qu’un client puisse demander au serveur de retourner l’heure du serveur dans sa réponse (draft-liman-dns-utcstamp-00). Avec cette extension, il est possible de diagnostiquer des problèmes dus à une désynchronisation horaire d’un serveur parmi une grappe de machines.

En binôme avec l’auteur de cette spécification, j’ai intégré cette spécification dans le serveur IBDNS pendant que lui s’occupait du côté client en modifiant dig. Avec l’extension, dig était capable d’afficher l’heure renvoyée par le serveur.

La spécification étant assez simple, j’ai eu largement le temps pour commencer à ajouter la prise en charge d’EDNS dans IBDNS (un prérequis pour la suite qui manquait encore), puis la spécification, pour enfin ajouter des modes de défaillance.

Les voici :

• ne pas renvoyer l’heure dans la réponse, même si le client l’avait demandé ;
• renvoyer l’heure même si le client ne l’avait pas demandé ;
• renvoyer la valeur spéciale pour signaler l’absence d’information horaire.
• plus sournois : appliquer un décalage, paramétré dans le fichier de configuration, sur l’heure renvoyée par le serveur ;
• et plus sournois encore, renvoyer des octets aléatoires à la place d’une heure correcte.

Ainsi, il était possible de vérifier que le dig modifié était capable de gérer les cas dégradés. La première fois, quand j’ai proposé à mon binôme de tester sur le domaine qui répond avec des octets aléatoires, le client a planté : le code n’était pas assez robuste. Mais il a pu corriger et tester en toute autonomie ensuite.

À la fin, nous avions deux mises en œuvre de l’extension côté serveur : dans BIND et dans IBDNS.
Et une mise en œuvre côté client, dans dig.

Ce hackathon a pu démontrer qu’IBDNS est un outil pertinent pour tester des clients DNS, et un outil de développement utile dans le contexte d’une nouvelle extension au DNS. C’est aussi là-bas qu’est né Ibby, la mascotte d’IBDNS visible au début de ce billet.

Conclusion

Nous avons vu comment IBDNS a évolué depuis l’annonce officielle par l’Afnic de sa mise à disposition en tant que logiciel libre. Il y a encore beaucoup d’items sur sa feuille de route et l’éventail de modes de défaillance qu’il propose est encore amené à beaucoup croître.

En attendant, que vous soyez développeur d’un client DNS, d’un outil de test DNS ou tout simplement intéressé par l’architecture du serveur, vous pouvez faire un tour
sur le dépôt GitLab d’IBDNS chez Afnic Labs.