Dans ce guide nous allons mettre en place une infrastructure de serveurs DNS authoritative avec Knot.

C’est quoi un serveur autoritaire

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

• Autoritaires
• Recursive
• Forwarders

Un serveur autoritaire est responsable d’une zone DNS, il contient la base d’enregistrements DNS, c’est lui qu’il faut aller voir lorsqu’on veut connaitre le contenu d’un enregistrement DNS.
Etant donné les millions voire milliards de zone présentes sur terre, il y a un nombre gigantesque de serveurs autoritaires et aucune machine ne peut connaitre le serveur à consulter pour connaitre les enregistrements d’une zone.
C’est pour cela que le DNS a été structuré avec une délégation de responsabilité. Un groupe de serveurs sont autoritaires sur la zone “.”, ils sont connus sous le nom de serveurs root.

On compte 13 addresses IP anycast portées par ces serveurs à ce jour dans le monde dont 10 sont liés aux Etats-Unis. Ces serveurs root contiennent les enregistrements NS de tous les TLD présents sur internet. Ces enregistrements NS pointent vers les serveurs DNS des organismes responsables des TLD aussi appelés NIC, on y retrouve notamment les serveurs de l’AFNIC, l’association loi 1901 responsable du TLD “.fr”.

Chaque NIC possède des serveurs DNS autoritaires qui contiennent l’ensemble des enregistrements NS des domaines liés à leurs TLD. Ces enregistrements NS pointent vers les serveurs DNS qui gèrent le domaine. On y retrouve souvent les serveurs DNS des registrars auprès desquels on achete les domaines et qui font gérer les enregistrements associés au domaine.

Il est cependant possible d’utiliser ses propres serveurs autoritaires pour ses domaines et donc de continuer la chaine de délégation en créant des sous-zones avec des enregistrements NS associés.
Le fait d’avoir un système de délégation sous cette forme facilite la résolution, en effet, pour résoudre le domaine toto.nobell.fr, le process sera le suivant :

• Client - Hey a.root-servers.net, c’est qui toto.nobell.fr ?
• a.root-servers.net - Je ne sais pas, vas voir d.nic.fr, g.ext.nic.fr et f.ext.nic.fr, leurs addresses sont 194.0.9.1, 194.0.36.1 et 194.146.106.46, ils gèrent la zone .fr
• Client - Hey d.nic.fr, c’est qui toto.nobell.fr ?
• a.nic.fr - Aucune idée, vas voir ns1.nbl.sh et ns2.nbl.sh, leurs addresses sont 45.90.160.57 et 185.157.245.181, ils gèrent la zone nobell.fr
• Client - Hey ns1.nbl.sh, c’est qui toto.nobell.fr
• ns1.nbl.sh - Salut, toto.nobell.fr c’est 203.0.113.1

Cet échange peut être visualisé avec la commande dig toto.nobell.fr +trace @a.root-servers.net, c’est ce qu’on appelle la récursion.
Les clients finaux ne font jamais la récursion eux mêmes et font appel à des serveurs DNS dits recursive.
Ces serveurs possèdent une liste des serveurs racine et vont l’utiliser pour dessendre la hiérarchie et résoudre les domaines demandés par les clients.

Pour finir on retrouve aussi les DNS forwarders qui prennent la requette du client, la transmettent au serveur DNS et renvoient la réponse bêtment. Si le serveur DNS n’a pas l’enregistrement dans sa base, il renverra le NS de la zone contenant le domaine que le forwarder transmettra bêtement au client dans une réponse NXDOMAIN.

Généralement, lorsqu’on configure un forwarder, on y configure une liste de serveurs DNS à aller voir l’un après l’autre jusqu’à résoudre l’enregistrement. En bout de chaine on met un serveur recusrive comme 1.1.1.1 ou 8.8.8.8 qui va résoudre le domaine en suivant la délégation de zones globales d’internet.

Knot

Knot est un serveur DNS autoritaire open-source et léger concu par nic.cz, le registre national Tchèque. Son grand avantage est qu’il est très léger et simple à mettre en place. Je l’utilise sur les serveurs autoritaires de mon infrastructure de production. Dans ce guide, nous mettrons en place une paire de serveurs autoritaires sur la zone homelab.it avec une relation master-slave (ou primary-secondary selon les sensibilités lexicales du moment).

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

Configuration de Knot

La configuration principale de Knot se trouve dans /etc/knot/knot.conf

Nous allons d’abord commencer par configurer le serveur DNS. Nos enregistrements DNS seront décrits au format bind dans le répertoire /var/lib/knot

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 n’aurons que la zone homelab.it

zone:
  - domain: homelab.it
    notify: fr2

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 utiliserons cette commande.

knotc reload

Mise en place de la synchronisation master-slave

La configuration appliquée précédemment fonctionnement, cependant, si nous souhaitons modifier ou ajouter un record, il faudra le faire sur l’ensemble des serveurs autoritaires, ce qui prend beaucoup de temps.
Pour faciliter les choses, nous utiliserons la fonction AXFR / IXFR de DNS. Ces fonctionnalités de DNS sont utilisées pour le transfert de zone, ns2 pourra les utiliser pour récupérer l’ensemble de la zone sur ns1 et l’écrire dans sa base.

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 remplacer par un string généré 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 voir la synchronisation se faire, nous pouvons voir les logs de knot en temps réel sur ns2 pour voir les notify de ns1 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