Signer une zone DNS sous Bind9

DNSSEC repose sur le principe des autorités de certifications. Nous alors faire confiance à un tiers qui aura signé les enregistrement DNS avec une clé que l'on nomme ZSK . Cette clé ayant été elle même signé par le domaine parent :

• Une clé ZSK signe les enregistrements du domaine daedelys.org.
• Cette clé est elle même signée par une clé du domaine org.
• Cette clé étant elle même signé par la clé du domaine .

Nous n'avons donc qu'à croire la clé du domaine . comme sûre pour être assurés que les enregistrements du domaine daedelys.org. soient ceux indiqués par les gestionnaires du domaine. C'est une chaîne de confiance, de la même manière que l'on fournit une liste des serveurs racines DNS lorsque nous configurons un serveur DNS.

Nous allons donc générer une clé en suivant la documentation de bind 9.7:

dnssec-keygen -a RSASHA1 -b 768 -n ZONE daedelys.org.
Generating key pair.........++++++++ .....................++++++++ 
Kdaedelys.org.+005+43740

Toujours d'après la documentation , nous ajoutons le fichier Kdaedelys.org.+005+43740.key dans notre fichier de zone

$INCLUDE /etc/bind/Kdaedelys.org.+005+43740.key

Nous signons ensuite la zone en utilisant la commande suivante :

dnssec-signzone -K /etcv/bind -o daedelys.org db.world.daedelys.org
dnssec-signzone: fatal: no self signed KSK's found

Cette erreur est du aux vérifications après signatures :

-P The post sign verification test ensures that for each algorithm in use there is at least one non revoked self signed KSK key, that all revoked KSK keys are self signed, and that all records in the zone are signed by the algorithm. This option skips these tests.

Nous pouvons :

• soit utiliser l'option

  -P pour déactiver ces tests.

• soit créer une KSK et l'utiliser pour signer les clés qui vont signer les clés.

Pourquoi cette clé supplémentaire ? Pour des raisons de sécurités cryptographiques. Il faut bien comprendre actuellement un seul système a une sécurité inconditionnelle - c'est le chiffre de Vernam - et il est inadapté dans notre cas. De fait la cryptographie va s'efforcer de permettre de garder secrète une information au moins le temps de sa valeur : si l'ennemi déchiffre les plans de la bataille après la bataille, cela ne pose aucun problème.

Un système cryptographique est dit sur :

• soit parce que la meilleur attaque connue demande une quantité importante de calcul
• soit parce qu'il y a été démontré équivalent à un problème reconnu difficile à résoudre

D'après les recherches en théorie de l'information, Un moyen de retarder le déchiffrement est de changer fréquemment la clé. Le chiffre de Verman cité plus haut l'impose à chaque message.

Dans notre cas, cela impose donc de faire resigner la clé par la zone parent, ce qui impose de à la zone parent de revérifier l'identité du demandeur.

Pour éviter cela, nous allons intercaler une clé de signature des clés nommée KSK comme l'explique la RFC 3757: Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag:

Nous allons donc :

• générer une première clé KSK que nous ferons signer par notre zone parent, et que nous changerons tout les ans
• générer une seconde clé et une troisiéme clés ZSK que nous allons utiliser pour signer nos enregistrements.

Pourquoi deux clés ? Car Internet est un réseau qui une certaines latence , et ne va donc pas transmettre l'information instantanément dans tout les noeuds. Il nous font donc s'assurer qu'il n'y a pas rupture de la chaîne de confiance est cela impose donc des recouvrement des périodes de validité des clés. ZSK. comme expliquer dans la RFC 4641: DNSSEC Operational Practices.

ce qui nous donne :

• Génération d'une clé de type KSK de taille 2048 et de durée d'utilisation de 12 mois et de durée de vie de 13 mois :

  dnssec-keygen -f KSK -I +12mo -D +13mo -K /etc/bind/ -a RSASHA1 -b 2048 -n ZONE daedelys.org.
  Generating key pair..+++ .....................+++ 
  Kdaedelys.org.+005+21226
  

• Génération d'une clé de type ZSK de taille 1024 et de durée d'utilisation de 1 mois et de durée de vie de 2 mois :

  dnssec-keygen -I +1mo -D +2mo -K /etc/bind/ -a RSASHA1 -b 1024 -n ZONE daedelys.org.
  Generating key pair................................++++++ ...................++++++ 
  Kdaedelys.org.+005+65322
  

• Génération d'une clé de type ZSK de taille 1024 et de durée d'utilisation de 1 mois et de durée de vie de 2 mois ¹ activée dans 1 mois et successeuse de la clé générée précédemment:

  dnssec-keygen -S Kdaedelys.org.+005+65322 -D +3mo -I +2mo   -K /etc/bind/ daedelys.org.
  dnssec-keygen: fatal: Key daedelys.org/RSASHA1/65322 becomes inactive
  sooner than the prepublication period for the new key ends.
  Either change the inactivation date with dnssec-settime -I,
  or use the -i option to set a shorter prepublication interval.
  

  Nous voyons ici qu'il faut préciser un jour de plus à la validité de la clé Kdaedelys.org.+005+65322 pour faire un recouvrement correcte, en effet le paramètre de type -D +2mo soit la date dans deux mois à partir d'aujourd'hui est converti en seconde. L'option -S Kdaedelys.org.+005+65322 configure la date de prépublication de maniére suivante :

  -S key Create a new key which is an explicit successor to an existing key. The name, algorithm, size, and type of the key will be set to match the existing key. The activation date of the new key will be set to the inactivation date of the existing one. The publication date will be set to the activation date minus the prepublication interval, which defaults to 30 days.

  A cause de la conversion en seconde et du fait que nous n'avons pas généré les 2 clés à moins d'une seconde d'intervalle, nous n'avons pas de recouvrement entre les période de validité des deux clés d'où le message d'erreur.

  Nous ajoutons donc une journée à la date de validation de la clé Kdaedelys.org.+005+65322

  dnssec-settime -K /etc/bind/ -I +31d Kdaedelys.org.+005+65322
  /etc/bind/Kdaedelys.org.+005+65322.key
  /etc/bind/Kdaedelys.org.+005+65322.private
  
  dnssec-keygen -S Kdaedelys.org.+005+65322 -I +2mo -D +3mo  -K /etc/bind/ daedelys.org.
  Generating key pair.................++++++ ...............++++++ 
  Kdaedelys.org.+005+54612
  

• Ajout dans notre fichier de zone des trois clés :

  ; KSK 
  $INCLUDE /etc/bind/Kdaedelys.org.+005+21226.key
  ; ZSK
  $INCLUDE /etc/bind/Kdaedelys.org.+005+65322.key
  $INCLUDE /etc/bind/Kdaedelys.org.+005+54612.key
  

• Signature :

  named-checkzone daedelys.org db.world.daedelys.org
  zone daedelys.org/IN: loaded serial 2011091102
  OK
  
  dnssec-signzone -K /etc/bind/ -o daedelys.org db.world.daedelys.org
  Verifying the zone using the following algorithms: RSASHA1.
  Zone signing complete:
  Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 2 active, 0 stand-by, 0 revoked
  db.world.daedelys.org.signed
  
  named-checkzone daedelys.org db.world.daedelys.org.signed 
  zone daedelys.org/IN: loaded serial 2011091102 (DNSSEC signed)
  

Nous sommes finalement arrivé à correctement signer notre zone pour la durée mirifique de 1 mois. Mais il nous reste quelques occupations :

• Comment vérifier le bon statut DNSSEC d'une réponse ?

• Comment faire signer notre KSK ?

  Par exemple l'extension '''.org''' gére bien DNSSEC :

  whois daedelys.org
  [...]
  Name Server: 
  Name Server: 
  Name Server: 
  DNSSEC:Unsigned
  

  Mais par exemple mon bureaux d'enregistrement Gandi ne gère pas au 19 septembre 2011 DNSSEC mais c'est promis. Tant que cela ne sera pas fait la chaine de confiance ne pourra être complète, et non efforts ne sont pas très utiles.

• Comment gérer convenablement cette pléthore de clé ?

J'essaierais de traiter ces différents points dans d'autres notes...