Dans ce guide nous allons voir comment mettre en place une infrastructure DNS autoritaire avec Knot.

Qu’est ce qu’un serveur autoritaire ?

Dans le monde du DNS, on retrouve trois types de serveurs :

• Autoritaires
• Recurseurs
• Forwarders

Un serveur DNS autoritaire contient l’ensemble des enregistrements DNS d’une ou plusieurs zones. C’est la source de vérité pour ces zones, lorsqu’un client souhaite obtenir un enregistrement DNS, c’est finalement un serveur autoritaire qui fournit la réponse.
On estime aujourd’hui, qu’entre 380 et 390 millions de domaines sont enregistrés sur Internet, en incluant les sous-domaines, le nombre total de zones est encore plus grand. Conserver sur chaque machine connectée la liste complète des zones et de leurs serveurs autoritaires serait irréaliste. Pour résoudre ce problème, le DNS repose sur une architecture hiérarchique.
Au sommet de cette hiérarchie se trouve la zone racine (« . »), qui est découpée en sous-zones appelées TLD (Top-Level Domains) comme .fr, .com ou .net. Chaque TLD est lui-même découpé en domaines, qui peuvent à leur tour contenir des sous-domaines. Chaque zone contient des enregistrements NS (Name Server) indiquant quels serveurs sont autoritaires pour les sous-zones qu’elle délègue.
À ce jour, la zone racine est servie par 13 identifiants de serveurs racine (A à M), chacun étant distribué mondialement grâce à la technologie Anycast. La zone racine est consultable publiquement et contient l’ensemble des TLD d’Internet ainsi que les serveurs faisant autorité pour chacun d’entre eux.
La plupart des TLD sont gérés par des organismes appelés registres. En France, c’est notamment l’AFNIC qui gère le TLD .fr ainsi que plusieurs autres extensions françaises comme .paris ou .re. Les serveurs autoritaires du registre contiennent les délégations NS de tous les domaines enregistrés sous leur TLD.
Ces enregistrements NS pointent généralement vers les serveurs DNS fournis par le registrar ou par un hébergeur DNS tiers. Il est toutefois parfaitement possible d’utiliser ses propres serveurs DNS autoritaires pour héberger une zone.

Le processus de résolution pour le domaine toto.nobell.fr peut être résumé ainsi :

• Client : « Bonjour a.root-servers.net, qui est toto.nobell.fr ? »
• a.root-servers.net : « Je ne connais pas ce nom, mais les serveurs autoritaires de la zone .fr sont d.nic.fr, f.ext.nic.fr et g.ext.nic.fr. »
• Client : « Bonjour d.nic.fr, qui est toto.nobell.fr ? »
• d.nic.fr : « Je ne connais pas ce nom, mais les serveurs autoritaires de la zone nobell.fr sont ns1.nbl.sh et ns2.nbl.sh. »
• Client : « Bonjour ns1.nbl.sh, qui est toto.nobell.fr ? »
• ns1.nbl.sh : « toto.nobell.fr correspond à l’adresse IP 203.0.113.1. »

Cette chaîne de délégations peut être observée avec la commande : dig toto.nobell.fr +trace

Dans la pratique, un poste client n’effectue généralement pas lui-même cette résolution itérative. Il interroge un serveur DNS récursif (ou recursor) qui se charge de parcourir la hiérarchie DNS à sa place. Une fois la réponse obtenue, le serveur récursif la conserve temporairement en cache afin d’accélérer les requêtes suivantes.
La durée de conservation en cache est définie par le TTL (Time To Live) associé à chaque enregistrement DNS. Ce TTL est exprimé en secondes.
Enfin, on rencontre également des DNS forwarders. Contrairement à un serveur récursif, un forwarder ne réalise pas lui-même la résolution complète, il transmet simplement les requêtes à un ou plusieurs serveurs DNS en amont et renvoie les réponses obtenues au client.
Les forwarders sont souvent utilisés dans les entreprises pour résoudre des zones DNS internes tout en conservant l’accès aux domaines publics d’Internet. Une configuration classique consiste à envoyer les requêtes concernant les domaines internes vers un serveur DNS autoritaire de l’entreprise, et toutes les autres requêtes vers un serveur récursif public ou interne.

Installation de Knot

Knot peut facilement s’installer en utilisant les repositories de nic.cz, les commandes d’installation selon votre distribution sont disponibles ici : https://pkg.labs.nic.cz/doc/?project=knot-dns.

Pour éviter un conflit de ports, nous devons désactiver systemd-resolved sur Debian et Ubuntu.
En cas de conflit, il est possible de vérifier quel programme utilise le port 53 avec la commande ss -tunlp | grep 53 et le désactiver avec systemctl ou pkill.

Configuration de Knot

Dans notre exemple, nous utiliserons deux serveurs knot (ns1 et ns2) portant les IPs 192.0.2.1 et 192.0.2.2.
La configuration principale de Knot se trouve dans /etc/knot/knot.conf

Voici la configuration de base que nous pourrons appliquer sur ns1 et ns2

server:
  rundir: "/run/knot"
  user: knot:knot
  automatic-acl: on
  listen: [ 0.0.0.0@53, ::@53 ]

database:
  storage: "/var/lib/knot"

template:
  - id: default
    storage: "/var/lib/knot"
    file: "%s.zone"
log:
  - target: syslog
    any: info

Nous pourrons ensuite déclarer la liste des zones, dans notre cas, nous créerons la zone homelab.it

zone:
  - domain: homelab.it

Pour terminer la première partie de cette mise en place, nous créerons quelques records dans /var/lib/knot/homelab.it.zone puis nous relancerons knot pour appliquer la configuration.

@           3600    IN  SOA ns1.homelab.it. admin.homelab.it.   2026053000  1800    900 604800  60
@           60      IN  NS  ns1.homelab.it.
@           60      IN  NS  ns2.homelab.it.
ns1         60      IN  A   192.0.2.1
ns2         60      IN  A   192.0.2.2

Pour relancer knot, nous pouvons utiliser cette commande.

knotc reload

Mise en place de la synchronisation master-slave

La configuration appliquée précédemment fonctionne, cependant, si nous souhaitons modifier ou ajouter un record, nous devrons modifier les zones sur ns1 et ns2.
Pour faciliter les choses, nous utiliserons la fonction AXFR de DNS définis dans la RFC 5936. Ce protocole sert à faire du transfert de zone, il permet à un serveur DNS de récupérer l’ensemble de la zone dns d’un autre serveur. Dans notre cas, nous l’utiliserons pour que ns2 synchronise automatiquement sa zone avec celle de ns1.

Cette synchronisation peut être déclenchée par ns2 avec la commande knotc zone-refresh <zone> ou un notify envoyé par ns1 lors d’une modification de zone.
Dans notre exemple, nous utiliserons la seconde approche.

Pour mettre en place la synchronisation de zone, nous aurons à ajouter/modifier ces lignes dans la configuration :

Sur ns1 :

key:
  - id: tsig-transfer
    algorithm: hmac-sha256
    secret: "abcd" # A générer avec 'openssl rand -base64 32'

acl:
  - id: ns2-sync
    address: 192.0.2.2
    key: tsig-transfer

remote:
  - id: ns2
    address: 192.0.2.2
    key: tsig-transfer

zone:
  - domain: homelab.it
    acl: ns2-sync
    notify: ns2

Sur ns2:

key:
  - id: tsig-transfer
    algorithm: "hmac-sha256"
    secret: "abcd" # Meme secret que sur ns1 (Utilisé pour éviter un transfert de zone vers une machine pirate)

remote:
  - id: ns1
    address: 192.0.2.1
    key: tsig-transfer

zone:
  - domain: homelab.it
    master: ns1

Une fois la configuration modifiée et knot relancé avec knotc reload, nous pouvons faire notre premier test de synchronisation dns.
Pour cela nous pouvons ajouter ce record dans /var/lib/knot/homelab.it.zone

toto        IN  A   1.2.3.4

Information importante : Pour savoir si la zone a changé et s’il faut la changer ou non, ns2 vérifie si le serial de la zone a été incrémenté. Il s’agit du premier nombre dans le record SOA de notre zone (2026053000 dans notre cas), pour que ns2 applique le changement, nous devrons donc incrémenter sa valeur de 1 :

@           IN  SOA ns1.homelab.it. admin.homelab.it. 2026053001 1800 900 604800 60

Une fois ces modifications appliquées, nous pouvons relancer knotc. Pour vérifier que la synchronisation se fasse correctement, nous pouvons vérifier les logs de knot sur ns2 avec la commande journalctl -u knot -f.

knotc reload

Voici à quoi ressemblent les logs

May 30 18:12:28 ns2 knotd[468792]: info: [homelab.it.] notify, incoming, remote 192.0.2.1@38950, serial 2026053001
May 30 18:12:28 ns2 knotd[468792]: info: [homelab.it.] refresh, remote 192.0.2.1@53, remote serial 2026053001, zone is outdated

Maintenant, les deux serveurs ont le nouveau record et nous pouvons vérifier sa résolution avec la commande

dig toto.homelab.it @192.0.2.2

; <<>> DiG 9.18.47-1~deb12u1-Debian <<>> toto.homelab.it @192.0.2.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22350
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;toto.homelab.it.               IN      A

;; ANSWER SECTION:
toto.homelab.it.        60      IN      A       1.2.3.4

;; Query time: 1 msec
;; SERVER: 192.0.2.2#53(192.0.2.2) (UDP)
;; WHEN: Sun May 31 18:14:14 CEST 2026
;; MSG SIZE  rcvd: 56

Pour aller plus loin

Si vous possédez un domaine public, vous pouvez mettre en place la même infrastructure sur deux VPS légers et remplacer les nameservers du registrar par vos propres serveurs autoritaires.