P15 - Serveurs DNS (BIND9) et DHCP (Kea)

P15 - Monter ses serveurs DNS (BIND9) et DHCP (Kea) sous Debian

Objectif

Passer du client (vu dans R08 - DHCP, DNS et route par défaut) au serveur : héberger sa propre zone DNS avec BIND9 (zone directe et inverse) et distribuer les adresses avec ISC Kea DHCP, y compris réservations et haute disponibilité.

Source

Fiche rédigée à partir de cours de lidstah (TP de lidstah sur le cluster Proxmox du labo).

---

1. Rappels DNS utiles côté serveur

Enregistrement	Rôle	Exemple
SOA	Infos générales de la zone : serveur principal, contact, numéro de série, délais	Un seul par zone
NS	Serveurs DNS de la zone	@ NS ns1.cogip.lan.
A / AAAA	Nom → IPv4 / IPv6	router IN A 192.168.100.1
CNAME	Alias vers un autre nom	gateway IN CNAME router
PTR	IP → nom (zone inverse)	1 IN PTR router.cogip.lan.
MX	Serveur de mail du domaine	@ MX 10 mail
TXT	Texte libre (SPF, DKIM, vérifications)
SRV	Localiser un service (utilisé par Active Directory)

flowchart LR
  C["Client"] -->|"1. qui est gateway.cogip.lan ?"| B["BIND9 du LAN"]
  B -->|"zone locale : je connais"| C
  C -->|"2. qui est epsi.fr ?"| B
  B -->|"pas ma zone : je demande"| F["Forwarders<br/>(DNS du FAI, 9.9.9.9…)"]
  F --> B --> C

2. BIND9

sudo apt install bind9 bind9-dnsutils

Fichier	Contenu
/etc/bind/named.conf.options	Options globales (forwarders, qui a le droit d’interroger)
/etc/bind/named.conf.local	Déclaration de nos zones
/var/cache/bind/	Les fichiers de zone eux-mêmes

Résolveur pour le LAN (named.conf.options)

options {
  directory "/var/cache/bind";
  // les DNS à qui demander ce qu'on ne connaît pas
  forwarders { 9.9.9.9; 1.1.1.1; };
  // ne répondre qu'au réseau local (sinon : résolveur ouvert = attaques)
  allow-query { 127.0.0.1; 192.168.100.0/24; };
  dnssec-validation auto;
  listen-on-v6 { any; };
};

Déclarer la zone et sa zone inverse (named.conf.local)

zone "cogip.lan" {
  type master;
  file "cogip.lan";
};
zone "100.168.192.in-addr.arpa" {   // le réseau 192.168.100.0/24 écrit à l'envers
  type master;
  file "100.168.192.rev";
};

Zone directe (/var/cache/bind/cogip.lan)

$TTL 86400
@   IN SOA ns1.cogip.lan. hostmaster.cogip.lan. (
        1       ; numéro de série : +1 à CHAQUE modification
        3600    ; refresh : les secondaires vérifient toutes les heures
        1800    ; retry
        604800  ; expire
        7200 )  ; TTL des réponses négatives
@        IN NS    ns1.cogip.lan.
ns1      IN A     192.168.100.175
router   IN A     192.168.100.1
polaris  IN A     192.168.100.190
proxmox  IN CNAME polaris
gateway  IN CNAME router

Zone inverse (/var/cache/bind/100.168.192.rev)

$TTL 86400
@   IN SOA ns1.cogip.lan. hostmaster.cogip.lan. ( 1 3600 1800 604800 7200 )
@   IN NS  ns1.cogip.lan.
175 IN PTR ns1.cogip.lan.
1   IN PTR router.cogip.lan.
190 IN PTR polaris.cogip.lan.

Les pièges des fichiers de zone

• Les commentaires commencent par ; (pas //, qui ne marche que dans named.conf).
• Un nom complet se termine par un point : ns1.cogip.lan. Sans le point, BIND ajoute la zone derrière (ns1.cogip.lan.cogip.lan).
• Incrémenter le numéro de série à chaque modification, sinon les serveurs secondaires ne se mettent pas à jour.

Vérifier et tester

sudo named-checkconf                                   # syntaxe de named.conf
sudo named-checkzone cogip.lan /var/cache/bind/cogip.lan
sudo systemctl reload bind9
dig @192.168.100.175 gateway.cogip.lan                 # résolution directe
dig @192.168.100.175 -x 192.168.100.1                  # résolution inverse
dig @192.168.100.175 epsi.fr                           # récursion via les forwarders
journalctl -u named -e                                 # journaux en cas d'erreur

Sécurité du DNS

• Toujours au moins deux serveurs (primaire + secondaire, transfert de zone AXFR).
• DNS utilise UDP : un attaquant peut envoyer de petites requêtes avec une IP source usurpée et faire envoyer de grosses réponses à une victime (attaque par réflexion/amplification). Parades : ne pas être résolveur ouvert (allow-query), limiter le débit (iptables -A INPUT -p udp --dport 53 -m limit --limit 5/s -j ACCEPT), répartiteur dnsdist devant les serveurs.
• DNSSEC signe les réponses pour qu’on ne puisse pas les falsifier.

3. DHCP avec ISC Kea

DORA : Discover (client, broadcast, port 67) → Offer (serveur → port 68) → Request → ACK. Le client renouvelle son bail à 50 % de sa durée (en unicast), puis à 87,5 % (en broadcast), puis repart de zéro.

Kea remplace l’ancien isc-dhcp-server (abandonné). Configuration en JSON.

# dépôt officiel ISC (les versions Debian sont anciennes)
curl -1sLf 'https://dl.cloudsmith.io/public/isc/kea-3-0/setup.deb.sh' | sudo -E bash
sudo apt install isc-kea-dhcp4
sudo systemctl enable isc-kea-dhcp4-server
sudo nano /etc/kea/kea-dhcp4.conf

Extrait essentiel de /etc/kea/kea-dhcp4.conf :

{
"Dhcp4": {
  "interfaces-config": { "interfaces": [ "eth1" ] },
  "lease-database": { "type": "memfile", "lfc-interval": 3600 },
  "valid-lifetime": 3600,
  "option-data": [
    { "name": "domain-name-servers", "data": "192.168.100.175" },
    { "name": "domain-name", "data": "cogip.lan" }
  ],
  "subnet4": [
    {
      "id": 1,
      "subnet": "192.168.66.0/24",
      "pools": [ { "pool": "192.168.66.10 - 192.168.66.50" } ],
      "option-data": [ { "name": "routers", "data": "192.168.66.100" } ],
      "reservations": [
        { "hw-address": "01:23:45:67:89:ab", "ip-address": "192.168.66.134", "hostname": "hyperviseur-1" }
      ]
    }
  ]
}
}

• Réservation (bail statique) : toujours la même IP pour une adresse MAC, en dehors du pool.
• Tester la syntaxe : sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf, puis sudo systemctl restart isc-kea-dhcp4-server.
• Haute disponibilité : paquet isc-kea-hooks, bibliothèque libdhcp_ha.so, mode hot-standby (un primaire, un secours qui prend le relais). Configuration identique sur les deux serveurs sauf this-server-name.
• Relais DHCP : si les clients sont dans un autre réseau que le serveur, le routeur relaie les broadcasts (ip helper-address sur Cisco, voir R08 - DHCP, DNS et route par défaut).

Exercices

1. Tu as ajouté un enregistrement web IN A 192.168.100.20 mais le serveur secondaire ne le voit pas. Pourquoi ?
2. dig ns1.cogip.lan répond, mais dig -x 192.168.100.175 ne répond pas. Que manque-t-il ?
3. Pourquoi une réservation DHCP doit-elle être hors du pool ?

Correction

1. Le numéro de série du SOA n’a pas été incrémenté : le secondaire croit qu’il a déjà la dernière version.
2. La zone inverse (ou son enregistrement PTR) n’est pas déclarée ou contient une erreur : named-checkzone sur le fichier .rev.
3. Sinon le serveur pourrait donner cette adresse à une autre machine pendant que la machine réservée est éteinte : conflit d’adresse.

Erreurs fréquentes / dépannage

Symptôme	Cause probable
SERVFAIL	Erreur dans le fichier de zone : named-checkzone et journalctl -u named
Nom bizarre doublé (x.cogip.lan.cogip.lan)	Point final oublié
Les clients ne reçoivent pas d’IP	Kea n’écoute pas sur la bonne interface, ou pare-feu bloque UDP 67
Deux serveurs DHCP sur le même réseau	Conflits : penser à couper le DHCP de la box ou de pfSense

Voir aussi

• R08 - DHCP, DNS et route par défaut · L06 - Configurer le réseau sous Linux · W05 - Windows en entreprise et Active Directory · S03 - Pare-feu Linux (iptables et nftables)
• Cours complet : cours de lidstah · cours de lidstah · cours de lidstah
• Retour : P00 - Programme pas encore vu