Installer et utiliser OpenDNSSEC.

Les composants qui suivent s'installent très simplement; ils sont indispensables. Ils doivent être tous disponibles sur la plupart des distributions Gnu/linux sans problème. OpenSSL et d'autres programmes peuvent évidemment être compilés à part.

Le 25 janvier 2010, l'équipe « OpenDNSSEC » à procéder à deux mises à jour importantes. Les versions opendnssec 1.0.RC3 et softhsm 1.1.3 sont disponibles. J'ai mis à jour ma documentation, en particulier pour les paramètres d'installation, sans modifier les exemples. Donc ne soyez pas surpris de rencontrer des anciennes versions, les modifications ne portent pas sur les commandes, mais le sur fonctionnement intrinsèque des logiciels.

apt-get install g++ libopenssl-ruby1.9 subversion autoconf automake libtool \
libxml2 libxml2-dev openssl libssl-dev sun-java6-jre sun-java6-plugin \
sun-java6-fonts sqlite3 libsqlite3-dev python-4suite-xml ruby rubygems1.9 \
libruby-extras 

Cette commande relativement longue peut bloquer, il vous reste sinon le traitement individuel au cas par cas pour débloquer la situation.

L'arrivée de DNSSEC bouscule certaines règles purement DNS. En effet avant, il était souhaitable de garder le plus longtemps possible des données en cache. Cette action optimise le réseau en limitant les flux et les requêtes. Avec désormais des clés qui peuvent changer sans préavis, les contraintes ne sont plus pareilles. Il faut être sur de pouvoir garder les informations DNS le plus longtemps possible, sans pour cela compromettre les aspects de sécurité. Ceci reste une analyse personnelle, mais seules des valeurs temporelles relativement courtes permettent de pouvoir recharger une zone (DNSSEC), ou des données pour un DNS rapidement. Néanmoins, tout ceci dépend des données de la zone concernée et de ses modifications, plus ou moins régulières. Je cherche une formule mathématique pour cela... Voici les données (pour mémoire je l'espère) des entêtes à régler au plus juste pour une zone. Je passe sur l'explication des réglages des valeurs $TTL. Elles aussi doivent respecter la philosophie globale « DNSSEC ».

OpenDNSSEC a été pour moi un sujet d'expérience et non un besoin. Pour mémoire ma zone de test est totalement virtuelle (non routable sur internet). Dans ce document, je vais travailler dans mes exemples uniquement avec la zone de type « FORWARD ». Néanmoins ma « REVERSE » est gérée par OpenDNSSEC, la méthode reste identique pour les deux.

Voici ma zone « vierge » ou non signée :

$TTL 2H
@               SOA     portable.archi.amt.  dnsmaster.archi.amt. (
                        1259995801 ; serial (date +%s)
                        1800S      ; refresh
                        2H         ; retry
                        1W         ; expiry
                        1H )       ; minimum
@               NS   portable.archi.amt.
@               NS   serveur.archi.amt.
serveur         A    192.168.1.11
archi.amt.      MX 10 serveur.archi.amt.
www             CNAME        serveur.archi.amt.
wpad            CNAME        serveur.archi.amt.
ftp             A    192.168.1.11
portable2       A    192.168.1.13
portable        A    192.168.1.203

<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: conf.xml.in 2056 2009-10-02 09:01:16Z jakob $ -->
<Configuration>
	<RepositoryList>
		<Repository name="softHSM">
			<Module>/usr/local/lib/libsofthsm.so</Module>
			<TokenLabel>OpenDNSSEC</TokenLabel>
			<PIN>#############</PIN>
		</Repository>

	</RepositoryList>
	<Common>
		<Logging>
			<Syslog><Facility>local0</Facility></Syslog>
		</Logging>
		
		<PolicyFile>/etc/opendnssec/kasp.xml</PolicyFile>
		<ZoneListFile>/etc/opendnssec/zonelist.xml</ZoneListFile>
	<!--
		<ZoneFetchFile>/etc/opendnssec/zonefetch.xml</ZoneFetchFile>
	-->
	</Common>
	<Enforcer>
<!--
		<Privileges>
			<User>opendnssec</User>
			<Group>opendnssec</Group>
		</Privileges>
-->
		<Datastore><SQLite>/var/opendnssec/kasp.db</SQLite></Datastore>
		<Interval>PT3600S</Interval>
	</Enforcer>
	<Signer>
<!--
		<Privileges>
			<User>opendnssec</User>
			<Group>opendnssec</Group>
			<Directory>/</Directory>
		</Privileges>
-->
		<WorkingDirectory>/var/opendnssec/tmp</WorkingDirectory>
		<WorkerThreads>8</WorkerThreads>
		<!-- the <NotifyCommmand> will expand the following variables:
		     %zone      the name of the zone that was signed
		     %zonefile  the filename of the signed zone
		-->
	    <!-- Cette ligne  t adapt  mes besoins vis-a-vis de <xref linkend="Bind"/> -->
		<NotifyCommand>rndc notify %zone; rndc reload %zone</NotifyCommand>
	</Signer>

	<Auditor>
<!--
		<Privileges>
			<User>opendnssec</User>
			<Group>opendnssec</Group>
			<Directory>/</Directory>
		</Privileges>
-->
		<WorkingDirectory>/var/opendnssec/tmp</WorkingDirectory>
	</Auditor>

</Configuration>a 

Ce fichier permet de configurer tout ce qui concerne les paramètres NSEC3 (ou DNSSEC), en fonction d'une politique. Il est possible de créer plusieurs politiques pour la gestion des zones, une zone ne peut pas être gérée par plusieurs politiques. A noter : toutes les données temporelles doivent commencer par la lettre P. Elles doivent être suivies ensuite par la ou les valeurs souhaitées (année, mois, jour, heure et seconde). Elles peuvent être combinées comme ceci par exemple : P1Y30D5H.

Pour comprendre les différents paramètres, il est nécessaire de bien connaître DNSSEC/NSEC3.

<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: kasp.xml.in 2238 2009-10-16 07:38:12Z rb $ -->
<KASP>

	<Policy name="default">
		<Description>A default policy that will amaze you and your friends</Description>
		<Signatures>
			<Resign>PT2H</Resign>
			<Refresh>P3D</Refresh>
			<Validity>
					<Default>P7D</Default>
					<Denial>P7D</Denial>
			</Validity>
			<Jitter>PT12H</Jitter>
			<InceptionOffset>PT300S</InceptionOffset>
		</Signatures>

		<Denial>
			<NSEC3>
				<OptOut/>
				<Resalt>P100D</Resalt>
				<Hash>
					<Algorithm>1</Algorithm>
					<Iterations>5</Iterations>
					<Salt length="8"/>
				</Hash>
			</NSEC3>
		</Denial>

		<Keys>
			<!-- Parameters for both KSK and ZSK -->
			<TTL>PT3600S</TTL>
			<RetireSafety>PT3600S</RetireSafety>
			<PublishSafety>PT3600S</PublishSafety>
			<!-- <ShareKeys/> -->
			<Purge>P7D</Purge>

			<!-- Parameters for KSK only -->
			<KSK>
				<Algorithm length="2048">7</Algorithm>
				<Lifetime>P365D</Lifetime>
				<Repository>softHSM</Repository>
				<Standby>1</Standby>
				<!-- <ManualRollover/> -->
			</KSK>

			<!-- Parameters for ZSK only -->
			<ZSK>
				<Algorithm length="1024">7</Algorithm>
				<Lifetime>P30D</Lifetime>
				<Repository>softHSM</Repository>
				<Standby>1</Standby>
			</ZSK>
		</Keys>

		<Zone>
			<PropagationDelay>PT9999S</PropagationDelay>
			<SOA>
				<TTL>PT3600S</TTL>
				<Minimum>PT3600S</Minimum>
				<Serial>unixtime</Serial>
			</SOA>
		</Zone>

		<Parent>
			<PropagationDelay>PT9999S</PropagationDelay>
			<DS>
				<TTL>PT3600S</TTL>
			</DS>
			<SOA>
				<TTL>PT3600S</TTL>
				<Minimum>PT3600S</Minimum>
			</SOA>
		</Parent>

		<Audit/>
	</Policy>
</KASP>

Ce fichier incorpore 2 paramètres spécifiques à NSEC3. Ses valeurs évitent les attaques par dictionnaire, en créant des valeurs aléatoires. Elles interviennent pour le hachage des signatures. Elles sont réalisées selon un nombre d'itérations (« <Iterations>5</Iterations> »), et de lettres et de chiffres aléatoires. C'est le fameux « salt » (« <Salt length="8"/> »).

Ce fichier de configuration concerne les paramètres globaux pour OpenDNSSEC vis-à-vis du serveur DNS déclaré en primaire. On retrouve donc les paramètres, comme le port d'écoute, des paramètres non activés pour TSIG, et la déclaration de l'adresse IP du DNS primaire concernée par les zones. Au moins pour le moment, OpenDNSSEC dialogue uniquement avec un seul DNS (primaire).

        
        <?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: zonefetch.xml.in 1920 2009-09-30 07:49:39Z matthijs $ -->
<ZoneFetch>
	<!-- where to listen for notifies -->
	<!-- DEFAULT: do not listen to notify on specific address -->
	<NotifyListen><Port>53</Port></NotifyListen>

	<!-- default inbound AXFR settings
	     (per zone setting not yet implemented) -->
	<Default>
		<!-- TSIG secret for inbound AXFR -->
		<!-- DEFAULT: don't use TSIG -->
		
		<!-- address of host to request AXFR from -->
		<!-- incoming NOTIFY has to match this address as well -->
		<!-- DEFAULT: none -->
		<RequestTransfer>
			<IPv4>192.168.1.11</IPv4><Port>53</Port>
		</RequestTransfer>
	</Default>
</ZoneFetch>

Ce fichier est créé à la suite d'une demande d'intégration de zone. Cette action est réalisée par la commande « ods-ksmutil setup ». Bien que non testé récemment (mais lors de mes essais), OpenDNSSEC ajoutait systématiquement un « pavé » lors d'une demande d'intégration. Je ne peux que conseiller, sans mettre à défaut OpenDNSSEC tout de même, de vérifier ce fichier avant de procéder à la première signature d'une nouvelle zone.

<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: zonelist.xml.in 1443 2009-07-30 13:17:16Z rb $ -->
<ZoneList>
	<Zone name="archi.amt">
		<Policy>default</Policy>
		<SignerConfiguration>/var/opendnssec/signconf/archi.amt.xml</SignerConfiguration>
		<Adapters>
			<Input>
				<File>/var/opendnssec/unsigned/archi.amt</File>
			</Input>
			<Output>
				<File>/var/opendnssec/signed/archi.amt.signed</File>
			</Output>
		</Adapters>
	</Zone>
	<Zone name="1.168.192.in-addr.arpa">
		<Policy>default</Policy>
		<SignerConfiguration>/var/opendnssec/signconf/1.168.192.in-addr.arpa.xml</SignerConfiguration>
		<Adapters>
			<Input>
				<File>/var/opendnssec/unsigned/1.168.192.in-addr.arpa</File>
			</Input>
			<Output>
				<File>/var/opendnssec/signed/1.168.192.in-addr.arpa.signed</File>
			</Output>
		</Adapters>
	</Zone>
</ZoneList>

C'est vraiment pas une obligation, les développeurs ont tout de même tout prévu à cet effet. Ce compte ne me sert à rien chez moi; c'est probablement une erreur que je vais résoudre un jour... Sinon, vous êtes libre de donner un répertoire diffèrent de mon exemple.

adduser --disabled-login --disabled-password --home /var/opendnssec opendnssec

ods-control start
Starting signer engine...
connecting to /var/run/opendnssec/engine.sock
OpenDNSSEC signer engine version 1.0.0rc1
Zone list updated: 0 removed, 2 added, 0 updated
running as pid 1611
Starting enforcer...
OpenDNSSEC ods-enforcerd started (version 1.0.0rc1), pid 1613>

Dès le lancement, et surtout pour la première fois, il est important de regarder les très nombreuses lignes écrites dans le fichier /var/log/syslog. Dans le même répertoire, vous pouvez regarder également le fichier debug. Malgré le nombre de lignes écrites, ces traces sont très lisibles.

	Note
	OpenDNSSEC ne gère les clés que par le biais des bases de données, ou d'un HSM. Il est nécessaire de sauvegarder les clés par une sauvegarde de celles ci. Voici la commande à réaliser :

ods-ksmutil backup done
SQLite database set to: /var/opendnssec/kasp.db
Marked all repositories as backed up at 2009-12-23 14:30:29

Cette commande est différente de la sauvegarde des bases de données (database backup).

Les deux programmes résidents sont ici, pour information

root  1611  0.1  0.4  85544 13772 ?  Sl  06:44  0:00 /usr/bin/python /usr/local/lib/opendnssec/signer/Engine.py
root  1613  0.0  0.1  17360  4456 ?  Ss  06:44  0:00 /usr/local/sbin/ods-enforcerd>

En théorie les programmes résidents s'activent immédiatement. Et si le besoin est avéré, la création des signatures s'opère, ou les mises jour. Néanmoins si cette procédure ne se lance pas, après recherche d'une possible erreur, un forçage est possible avec cette commande :

ods-ksmutil key generate --interval 1 --policy default

La commande est simple et efficace; elle se passe de commentaire :

ods-control --zone delete nom-de-la-zone>

, ou pour tout effacer :

ods-control zone delete --all

Ceci s'adresse plutôt aux très multiples commandes que propose ods-ksmutil, mais elles font partie aussi des commandes d'exploitation courantes.

La commande suivante liste l'ensemble des clés qui sont gérées par OpenDNSSEC. Cette commande peut être utilisée à titre de contrôle. La commande adaptée pour lister les clés d'une zone précise :

ods-ksmutil key list --zone archi.amt

La commande pour lister les clés de toutes les zones ( tombe bien y a qu'une zone...) :

ods-ksmutil key list --verbose --all
SQLite database set to: /var/opendnssec/kasp.db
Keys:
Zone:       Keytype:  State:    Date of next transition:  CKA_ID:      Repository:   Keytag:
archi.amt   KSK       active    2011-01-05 09:02:33       5a1c770008...  softHSM      31939
archi.amt   ZSK       active    2010-01-22 09:21:36       fc19fc2397...  softHSM      63770
archi.amt   ZSK       ready     next rollover             618c4fff29...  softHSM       9783
archi.amt   KSK       ready     next rollover             7bae5dba98...  softHSM      31573

Et pour vérifier si cela est vrai, c'est tout de même important, il suffit de « rentrer » dans la zone concernée. De là, vous devez avoir dans votre zone des lignes similaires aux lignes qui suivent. OpenDNSSEC à même inscrit à quoi correspond chaque valeur.

archi.amt.      3600    IN      DNSKEY  256 3 7 AwEAADFEz67ba68...D7foMWyr ;{id = 30150 (zsk), size = 1024b}
archi.amt.      3600    IN      DNSKEY  256 3 7 AwEAAbz1yXAUYqf...oZLKG6vr ;{id = 41180 (zsk), size = 1024b}
archi.amt.      3600    IN      DNSKEY  257 3 7 AwEAAdN3K+WqygF...42XI5VM= ;{id = 17010 (ksk), size = 2048b}
archi.amt.      3600    IN      DNSKEY  257 3 7 AwEAAdVjDibBSFy...P+d+Ubk= ;{id = 48021 (ksk), size = 2048b}

Cette commande est similaire, avec tout de même les explications détaillés sur les clés en moins. Son avantage est de pouvoir questionner à distance :

dig +dnssec archi.amt dnskey @127.0.0.1 +multilines