+++

title = "DNSSEC : méthode BIND9.9"
date = 2013-02-15
aliases = [ "post/2013/02/15/DNSSEC-:-méthode-BIND9.9"]
[taxonomies]
tags = [ "internet", "dns" ]
+++

Nan, parce que la [précédente](/depucelage-dnssec-1/) [méthode](/depucelage-dnssec-2/), c'était vraiment _hardcore_

<!-- more -->

Ah ah, ça faisait longtemps qu'on avait pas fait des trucs un peu gue-din avec du DNSSEC et des poils autour.

DNSSEC en BIND9.7, c'était quand même un bon pain dans le cul : obligé de gérer des clés (c'est pas forcément ce qu'il y a de pire), de signer les zones systématiquement et surtout pas vraiment de souplesse.

Heureusement BIND9.9 apporte une solution durable et élégante au problème, avec une touche de barbe quand même.

# Comment ça marche-t-il donc dis donc ?

Le principe de base dans BIND9.9 pour automatiser et simplifier le plus possible DNSSEC est de transformer les zones en zones dynamiques. Ça peut paraître bizarre de faire que du dynamique alors qu'il n'y a pas particulièrement de raison, mais c'est là tout le génie de la chose : BIND re-signe tout seul les zones comme un grand à chaque modification et re-signe même automatiquement les zones plusieurs fois par jour !

À la base, il faut toujours générer les clés (et toujours de la même manière), sauf que là, on va toutes les grouper dans le même répertoire (en espérant qu'elles fassent pas de cochonneries ces petites dévergondées). 

La méthode de génération des clés est toujours la même (que ce soit pour la KSK ou la ZSK) :

```
# dnssec-keygen -f KSK -r /dev/urandom -a RSASHA256 -b 2048 -n ZONE ve.lu
# dnssec-keygen -r /dev/urandom -a RSASHA256 -b 2048 -n ZONE ve.lu
```

Dans /etc/bind/keys, on a donc :

```
ls /etc/bind/keys/
/etc/bind/keys/Kve.lu.+008+10578.key
/etc/bind/keys/Kve.lu.+008+10578.private
/etc/bind/keys/Kve.lu.+008+45370.key
/etc/bind/keys/Kve.lu.+008+45370.private
```

Sauf que cette fois-ci, il faut éviter de renommer les clés (BIND les repère comme ça, je ne sais pas exactement pourquoi). Et va falloir dire à pépère où elles sont les cléclés pour pas qu'il soit paumé :

```
options {
[…]
    directory "/var/cache/bind";
    key-directory "/etc/bind/keys";
}
```

D'ailleurs, il faut en profiter pour mettre un répertoire de cache, c'est là où BIND fera toutes ses salades avec les zones tampons et les re-calculs de clé. Au passage, n'oublie surtout pas de rendre les clés privées lisibles par l'utilisateur bind (quelque soit la distribution d'ailleurs), sinon il va avoir du mal à savoir ce qui se passe.

Avec ces instructions, en redémarrant le serveur de nom, il devrait cracher un peu de purée dans les logs pour dire qu'il a compris qu'il y avait des clés.

#  Dynamise-moi la zone DNS

On y vient petit margoulin. On va commencer, par créer une zone DNS tout ce qu'il y a de plus normale, bien propre sur elle, avec quelques enregistrements rigolos :

```
$ORIGIN .
$TTL 21600	; 6 hours
ve.lu	\	IN SOA\	nameserverdelamort.mabite.net. root.mabite.net. (
	\	\	\	2012111710 ; serial
	\	\	\	10800      ; refresh (3 hours)
	\	\	\	900        ; retry (15 minutes)
	\	\	\	604800     ; expire (1 week)
	\	\	\	10800      ; minimum (3 hours)
	\	\	\	)
	NS\	nameserverdelamort.mabite.net.
	A\	1.2.3.4
```

Et pour faire sobre, au niveau de BIND, la configuration de zone peut être réduite au strict minimum :

```
zone "ve.lu" {
	type master;
	file "/etc/bind/masters/db.ve.lu";
};
```

On va maintenant rendre la zone dynamique, ce qui permettra de lui baisser sa petite culotte et de lui mettre un gros taquet dans les fesses à n'importe quel moment de la journée. La zone dynamique, c'est un peu la culotte fendue du DNS avec les salsifis qui dépassent du cabas :

```
allow-update { localhost; }
```

À partir de maintenant, on peut faire des modifs à la volée avec `nsupdate` (et une syntaxe un peu à chier, faut reconnaître mais bon) :
```
# nsupdate -l
> zone ve.lu
> update add www.ve.lu. 86400 CNAME superserverweb.moncul.net.
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;ve.lu.	\	\	\	IN\	SOA

;; UPDATE SECTION:
www.ve.lu.	\	86400\	IN\	CNAME\	superserverweb.moncul.net.

> send
> quit
```

`nsupdate` permet donc de sélectionner une zone, d'envoyer des modifications (ajout ou suppression) voire même des modifications conditionnelles, et de les appliquer par un simple send.

On peut d'ailleurs voir que le fichier journal de la zone `ve.lu` a été créé et qu'il contient notre dernière modif :

```
# named-journalprint db.ve.lu.jnl
del ve.lu.	\	\	21600\	IN\	SOA\	nameserverdelamort.mabite.net. root.mabite.net. 2012111710 10800 900 604800 10800
add ve.lu.	\	\	21600\	IN\	SOA\	nameserverdelamort.mabite.net. root.mabite.net. 2012111711 10800 900 604800 10800
add www.ve.lu.	\	86400\	IN\	CNAME\	superserverweb.moncul.net.
```

En prime, il met automatiquement à jour la version de la zone (tu sais, le truc que tu oublies tout le temps et qui te fout bien la rage !). Et maintenant, magie du DNSSEC, en une seule ligne supplémentaire dans la section de la zone, BIND signe tout seul la zone dynamique :

```
    auto-dnssec maintain;
```

Et là, après un reload, les soirées de l'ambassadeur sont toujours un succès : non seulement la zone est mis à jour automatiquement grâce à `nsupdate` mais en plus, c'est BIND qui se débrouille tout seul comme un grand pour tout signer à chaque modif \o/\

La semaine prochaine, je fais de la blanquette de veau.
