Le résolveur
Le résolveur est le logiciel serveur qui va répondre aux requêtes
des clients
Pendant de nombreuses années, seul
Je teste Unbound sur une
# Récupérer le source Debian. À faire sur une machine sid, puis à copier
% apt-get source unbound
# Récupérer la dernière version d'Unbound
% wget http://unbound.net/downloads/unbound-1.3.2.tar.gz
# La détarer
% tar xzvf unbound-1.3.2.tar.gz
% cd unbound-1.3.2
# Copier le répertoire "debian", depuis le paquetage Debian
% cp -a -r ../unbound-sid/debian .
# Paquetages nécessaires pour compiler unbound (indiqués dans le champ
# Build-Depends: de debian/control)
% sudo aptitude install doxygen automake libldns-dev quilt
# Éditer le debian/changelog
% dch -i
# On y mettra:
# unbound (1.3.2-0.99) unstable; urgency=low
#
# * Local package of 1.3, to get DLV
#
# -- Stephane Bortzmeyer <bortzmeyer@nic.fr> Wed, 21 Jan 2009 15:31:23 +0100
# Créer le paquetage binaire
% dpkg-buildpackage -rfakeroot
# Voilà, le paquetage est prêt, on l'installe
% sudo dpkg -i ../unbound-host_1.3.2-0.99_i386.deb ../libunbound1_1.3.2-0.99_i386.deb ../unbound_1.3.2-0.99_i386.deb
Notez que le
Starting recursive DNS server: unbound[1232549330] unbound[25036:0] error: bind: address already in use
[1232549330] unbound[25036:0] fatal error: could not open ports failed!
Je
reconfigure BIND (dont j'ai besoin pour autre chose) pour ne
options {
listen-on-v6 { };
listen-on { };
...
et on reconfigure les paquetages :
% sudo dpkg --configure -a
Setting up unbound (1.3.2-0.99) ...
Starting recursive DNS server: unbound.
et tout est bon, comme on peut le vérifier dans le journal
Jan 21 15:52:05 batilda unbound: [26056:0] notice: init module 0: validator
Jan 21 15:52:05 batilda unbound: [26056:0] notice: init module 1: iterator
Jan 21 15:52:05 batilda unbound: [26056:0] info: start of service (unbound 1.3.2).
ainsi qu'avec
% dig @::1 SOA af.
...
;; ANSWER SECTION:
af. 86400 IN SOA ns1.nic.af. hostmaster.nic.af. 2009012100 43200 3600 604800 86400
Tout va bien, le résolveur est allé chercher l'information sur
% cat /etc/resolv.conf
...
# unbound local avec DLV 2009-01-21
nameserver ::1
Un des intérêts de Unbound (et d'un résolveur DNS sur sa propre
machine) est de pouvoir valider les réponses DNS avec
server:
...
dlv-anchor-file: "dlv.isc.org.key"
trust-anchor-file: "itar-trusted-anchors"
Où obtient-on ces fichiers ? Le premier est la clé publique du
registre DLV, trouvée sur le site de l'
% sudo wget http://ftp.isc.org/www/dlv/dlv.isc.org.key
% sudo wget http://ftp.isc.org/www/dlv/dlv.isc.org.key.asc
% gpg --verify dlv.isc.org.key.asc
gpg: Signature made Sun Sep 21 06:30:51 2008 CEST using RSA key ID 1BC91E6C
gpg: Good signature from "Internet Systems Consortium, Inc. (Signing key, 2006) <pgpkey2006@isc.org>"
...
Le second est un fichier de KSK (
% sudo wget https://itar.iana.org/anchors/anchors.mf
# On ne télécharge pas la signature PGP, on fait confiance à TLS
% sudo mv anchors.mf itar-trusted-anchors
Et on recharge Unbound :
% sudo /etc/init.d/unbound force-reload
Est-ce que tout marche ? Testons avec un nom dans un
% dig +dnssec SOA com.
...
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1
...
;; ANSWER SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1232550840 1800 900 604800 900
On a une réponse mais pas de
Maintenant, testons avec un domain signé mais pour lequel ni le
registre DLV de l'ISC ni l'ITAR ne contient de
% dig +dnssec SOA ripe.net
...
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 5
...
;; ANSWER SECTION:
ripe.net. 172419 IN SOA ns-pri.ripe.net. dns-help.ripe.net. 2009012101 3600 7200 1209600 7200
ripe.net. 172419 IN RRSIG SOA 5 2 172800 20090220060006 20090121060006 13992 ripe.net. BMAf2Ft7hEcaW0OyMluelgeUSLbfeC5Wok+7l0ZjK3Ui2boiDMBQxDcX gSqmIqIeRizi9tmTVnzNigBNHkrqe8z9fNkxl5GoTLtjXU4iwqmiSiVH 1AbWL7eyJwcIMzFdU84zj3jPadLjnbQa59x465GoFVviJgEd7+/SYZAK y5jaKyIlGB0/KZoeKAV29o1h9DcBn3ZE
Il y a bien une signature (enregistrement RRSIG) mais aucun moyen de la valider.
Maintenant, prenons un domaine qui est signé et existe dans le
registre DLV de l'ISC :
% dig +dnssec SOA mondomaineamoi.fr
...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
...
;; ANSWER SECTION:
mondomaineamoi.fr. 21600 IN SOA ns.mondomaineamoi.fr. postmaster.mondomaineamoi.fr. 2009010701 7200 3600 2419200 3600
C'est parfait, on a le
Et avec ITAR ? Le TLD suédois n'est pas dans le registre DLV mais
sa clé est dans ITAR :
% dig +dnssec SOA iis.se
...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1
...
;; ANSWER SECTION:
iis.se. 3600 IN SOA ns.nic.se. hostmaster.iis.se. 1232358302 10800 3600 1814400 14400
Ça marche aussi.
Un dernier test, que se passe t-il si les données sont invalides,
par exemple parce qu'un méchant a essayé d'empoisonner notre cache
DNS ? Utilisons le service de test
trust-anchor-file: "manual-trusted-anchors"
et je teste :
% dig +dnssec A baddata-A.test.dnssec-tools.org
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20526
et Unbound, fort logiquement, refuse de me donner ces données
incorrectes et répond SERVFAIL (
Unbound n'est pas intéressant que pour DNSSEC. Il a plein d'autres
options. Par exemple, supposons que votre entreprise utilise des
forward-zone:
name: "local"
forward-addr: 192.0.2.129
forward-addr: 2001:DB8:63::1
et on peut alors résoudre les noms en