GESTION DU RENOUVELLEMENT DES CLEFS POUR DNSSEC

Ecole Nationale Supérieure des Télécommnunications de Bretagne RAPPORT DU STAGE DE FIN D ETUDE GESTION DU RENOUVELLEMENT DES CLEFS POUR DNSSEC Mai Septembre 2003 Réalisé par : LEI Zhi Yu Encadrants : Olivier COURTAY Bernard COUSIN Correspondant école : Francis DUPONT

Remerciements Remerciements à tous mes encadrants : Olivier Courtay, Bernard Cousin et Francis Dupont, pour leur accueil chaleureux et leur conseils. Merci au M. Sylvain Gombault et Gille Guette pour leus conseils. Adresses LEI Zhi Yu ENST Bretagne Option RSIFI 2, rue de la Châtaigneraie 35576 Cesson Sévigné Cedex Tel : 06 85 27 65 98 E-mail : Zhiyu.lei@enst-bretagne.fr Olivier COURTAY Equipe Armor IRISA / INRIA Rennes Campus Universitaire de Beaulieu Avenue du Général Leclerc 35042 RENNES Cedex France Tel :02 99 84 71 31 E-mail : Olivier.Courtay@irisa.fr Bernard COUSIN Equipe Armor IRISA/INRIA Campus Universitaire de Beaulieu 35042 RENNES Cedex Tel : 02 99 84 73 33 Fax : 02 99 84 25 29 E-mail : Bernard.Cousin@irisa.fr Francis DUPONT ENST Bretagne Département RSM 2, rue de la Châtaigneraie 35576 Cesson Sévigné Cedex Tel : 02 99 12 70 92 E-mail : Francis.Dupont@enst-bretagne.fr - 2 -

Résumé Le DNS (Domaine Name System), est une partie indispensable de l Internet d aujourd hui, mais le système DNS original ne propose aucune protection contre des attaques variées, sa sécurisation est-elle devenu une nécessité. Depuis 1999, une extension sécurisée du DNS, DNSSEC, a été exploitée. DNSSEC garantit l intégrité des requêtes et des données et l authentification de la source en utilisant une système de cryptographie à clef publique et de signature numérique. De nouveaux enregistrements (RR KEY, SIG, NXT et DS) sont introduits au service DNS. Des enregistrements d'une zone DNS sécurisée sont signés, par des clefs privées associée à la zone. La durée de validité d'une clef est limitée et les clefs doivent être renouvelées périodiquement, mais ce genre de gestion s'avère coûteuse en temps pour le personnel d'administration. Ce stage est proposé par l IRISA (Institut de Recherche en Informatique et Système Aléatoire), comme une partie du projet IDsA (Infrastructure DNS Sécurisé et Applications). Le but de ce stage est de développer les outils nécessaires à une gestion automatisée de ces clefs de DNSSEC, afin d améliorer l efficacité du traitement des zones et des clefs changées, et de faciliter le travail de maintenance. La durée de stage est du 22 mai au 30 septembre. Ce stage se déroule au site rennais de l IRISA et de l ENST Bretagne. Une solution pour l automatisation de renouvellement des clefs dans DNSSEC est proposée au cour de ce stage, après avoir etudié le mécanisme courant du renouvellement des clefs. Cette solution consiste en un modèle conceptuel décrivant un algorithme nommé KRO, qui efficacement gère le processus de Key Rollover, et un logiciel, implémenté en langage C sous FreeBSD, correspondant au modèle KRO. Mots Clefs : DNSSEC, Key Rollover, Gestion automatisée, KRO - 3 -

Abstract Nowadays, the DNS (Domain Name System) is an essential part of the Internet, but originally DNS system did not propose any protection against various attacks and threats, its security had become a necessity. Since 1999, the security extension of the DNS, DNSSEC, was exploited. DNSSEC guarantees the data integrity in DNS messages (requests or response) and the authentication for the source of a message by using a system combined public key infrastructure with digital signatures. New resource records (RR KEY, SIG, NXT and DS) are introduced to service DNS. The resource records of a secured DNS zone are signed by private parts of key-pairs associated with that zone. But the period of validity of a key is limited and the keys must be renewed periodically (Rollover), this kind of management proved to be time-consuming for the personnel of administration. This intern project is proposed by IRISA (Institut de Recherche en Informatique et Système Aléatoire), as a part of IDsA project (Infrastructure DNS Sécurisé et Applications). The goal of this intern is to develop a tool needed for an automated management of these DNSSEC keys so as to improve the performance in processing the changed zones and keys, and to make the work of maintenance easier. The duration of the intern is from May 22 to September 30. This intern proceeded at Rennes, in the location of IRISA and ENST Bretagne. After having studied current mechanism of the keys rollover, a solution is proposed at during this intern, for an automated rollover of the keys in DNSSEC. This solution consists a conceptual model named KRO, which describes an algorithm handles the process of Key Rollover effectively, and a software corresponding to the process of rollover described by the model KRO, implemented in language C under FreeBSD. Keywords: DNSSEC, Key Rollover, Automated Management, KRO - 4 -

Sommaire Acronyme...6 I. Introduction...7 II. Contexte...8 1. Le DNS...8 1.1 Historique...8 1.2 Architecture du système DNS...9 1.3 Contenu d une zone...10 1.4 Processus de résolution...13 2. DNSSEC...15 2.1 Extension sécurisée...15 2.2 Clef et signature...17 2.3 Chaîne de confiance (Chain of Trust)...20 III. DNSSEC Key Rollover...23 1. Problématique...23 2. KRO...24 2.1 Un algorithme de Key Rollover...24 2.2 Justification des choix...26 2.3 Avantages et inconvénients...28 3. Implémentation...29 3.1 Découpage fonctionnel...29 3.2 Flux d exécution...30 3.3 Bibliothèques utilisées...33 3.4 Interface utilisateur...34 4. Résultat...36 IV. Déroulement du projet...40 V. Conclusion et perspectives...41 Index des matériels graphiques...42 Index des extraits du fichier...42 Références...43 Annexe A : Informations sur KEY, SIG et DS...44 Annexe B : Extraits des fichiers de configuration...46 Annexe C : Extraits du code source...50-5 -

Acronyme BIND Berkeley Internet Name Domain. Un des programmes DNS sous UNIX et Windows. RFC Request For Comments. DNS Domain Name System, système de noms de domaine DNSSEC DNS security extension PKI Public Key Infrastructure DoS Denial of Service TTL Time To Live. Durée de vie, la durée de validité des données. RR Resource Record. Enregistrement de données figurant pour un nom de domaine dans un serveur de noms. Les enregistrements de données sont de plusieurs types, voici la liste (non-exhaustive) des types d'enregistrements. A Enregistrement adresse AAAA Enregistrement adresse IPv6 CNAME Enregistrement alias NS Enregistrement serveur de noms SOA Enregistrement Start Of Authority TXT Enregistrement texte HINFO Enregistrement d information sur le serveur MX Enregistrement pour l échange du mail Des enregistrements spécifiés par DNSSEC, l extension sécurisé du DNS NXT Enregistrement Next, utilisé pour vérifier la non-existance d une ressource dans une zone KEY Enregistrement clef, la partie publique d une paire de clefs PKI SIG Enregistrement signature, contenant la signature numérique des enregistrements DS Enregistrement du type Delegation Signer RRset Un ensemble de RRs avec même nom, classe et type, par exemple : tous les adresses de www.enst-bretagne.fr en IPv4. - 6 -

I. Introduction Le DNS (Domaine Name System), qui permet à une machine de communiquer sans connaître au préalable l adresse IP de ses correspondants, est une partie indispensable de l Internet d aujourd hui. Ce service est chargé, entre autres, de la conversion entre un nom de machine et son adresse IP et inversement, mais le système DNS original ne propose aucune protection contre des attaques variées, ni de moyen d authentification ou de contrôle l intégrité des informations obtenues. Une extension récente du DNS, DNSSEC (depuis mai 1999, RFC2535), vient d'être proposée afin d assurer l'authentification et l'intégrité des requêtes et des données DNS. Cette extension utilise une système de cryptographie à clef publique et introduit de nouveaux enregistrements (RR KEY, SIG, NXT et DS) au service DNS. Les enregistrements d'une zone DNS sécurisée sont signés par des clefs privées associée à la zone, afin de réaliser la sécurisation des données, qui est l'objectif principal de DNSSEC. Ainsi, des proposition sont données sur la sécurisation de transaction DNS. La gestion des clefs de zone s'appuie sur la structure hiérarchique des zones du DNS. Pour assurer un certain niveau de sécurité, la durée de validité d'une clef est limitée. Face à tous ces besoins, les clefs doivent donc être renouvelées périodiquement, mais ce genre de gestion peut s'avérer coûteuse en temps pour le personnel d'administration. Le but de ce stage est de développer les outils nécessaires à une gestion automatisée de ces clefs de DNSSEC, afin d améliorer l efficacité du traitement des zones et des clefs qui sont changées, et de faciliter le travail de maintenance du personnel d'administration à la fois. Ce stage est proposé par l IRISA (Institut de Recherche en Informatique et Système Aléatoire), comme une partie du projet IDsA (Infrastructure DNS Sécurisé et Applications). Dans les chapitres suivants, nous expliquerons brièvement d abord, l origine et fonctionnement du système de noms de domaine, DNS, la problématique qui provoque la création de l extension sécurisé de DNS, le DNSSEC, et les comportements principaux de ce dernier. Ensuite nous allons présentons notre solution pour le renouvellement des clefs dans DNSSEC, après avoir expliqué le mécanisme courant du renouvellement. Notre solution consiste d abord en un modèle conceptuel décrivant le processus de Key Rollover (renouvellement des clefs), nommé KRO, et des codes implémentés correspondant à notre modèle, que nous détaillerons. Nous presentons des résultats que nous avons obtenus d après notre solution, ainsi qu une conclusion et des perspectives future. - 7 -

II. Contexte L'accès aux services sur Internet se repose sur l'utilisation massive de l'infrastructure DNS. Aujourd'hui, son utilisation est tellement naturelle qu'elle est devenu inévitable. Aussi, sa sécurisation est-elle devenu une nécessité, vu des nombreuses attaques sur des sites célèbres commerciaux ou même des sites gouvernementaux. Donc, depuis des années récentes, une telle infrastructure sécurisée, DNSSEC, a été exploitée pour la sécurisation du service DNS. Dans la partie suivante, nous allons parcourir le principe du service DNS et son extension sécurisé, DNSSEC. 1. Le DNS 1.1 Historique Au début, l'internet (ou anciennement ARPAnet) était formé simplement de quelques machines. Elles avaient chacune une adresse que l'on retenait facilement vu leur faible nombre. Un fichier hosts.txt comprenait les noms des différentes machines avec leur(s) adresse(s). Les manipulations sur ce fichier sont peu à peu devenues trop lourdes avec l augmentation du nombre de machines connectée au réseau, car l'administrateur désirant nommer une machine devaient envoyer un courrier électronique au responsable de la maintenance du fichier, ce dernier effectuait la mise à jour, et publiait une nouvelle version du fichier. Il n'était pas souvent à jour, et les modifications étaient longues à se propager. Un nouveau système a donc été créé, puis mis en place pour remplacer l'ancien. Paul Mockapetris a conçu et spécifié le DOMAIN NAME SYSTEM, ou DNS, en éditant les RFC882 et RFC883, plus tard mises à jour par RFC1034 et RFC1035 [RFC03]. Ce sont les spécifications officielles du système DNS et ce système permet de gérer des milliers de machines, ayant des noms descriptifs. La base de données du DNS est mise à jour de façon distribuée, et qui permet à certaines machines de contrôler certains segments de la base de données, tandis que toute la base de données est accessible par des clients par un mécanisme client-serveur. Un système de réplication assure une fiabilité raisonnable, tandis que des caches augmentent la performance du système. D'autres protocoles existent pour associer des informations à des noms de machines, par exemple NIS ou yellow pages, un système développé par SUN, qui peut être configuré de manière à utiliser aussi le DNS pour la recherche de noms de machines. De même, certains clients peuvent utiliser plusieurs systèmes de recherche, la configuration est spécifique au système. Mais notre considération est plutôt concentrée sur le DNS. - 8 -

1.2 Architecture du système DNS ENST Bretagne Campus Rennes L architecture de la base de données DNS est un arbre inversé. La racine se trouve au sommet, et porte le nom vide mais s écrit. (ou racine). Chaque nœud de l'arbre porte une étiquette qui l'identifie par rapport à son parent. L'utilisation de majuscules ou de minuscules est indifférente dans l'écriture des noms d étiquettes. Seuls les lettres, les chiffres, et le symbole "-" sont autorisés. Le terme "nom de domaine" ici représente donc indifféremment les nœuds de l'arbre (domaines, sous-domaines) ou les feuilles (terminales). com edu fr cn irisa enst-bretagne Zone fr Zone enst-bretagne.fr Domaine fr titan rsm A 192.44.xx.xx AAAA 2001:... [Fig.1 Arbre des zones] Dans l exemples ci-dessus, nous avons un domaine fr, que l'on peut aussi écrire fr. pour bien montrer qu'il est en haut de l'arbre. Ce nœud de l'arbre à un certain nombre de fils, comme irisa.fr ou enst-bretagne.fr dans la figure et bien sûr d autres fils comme tf1.fr ou sncf.fr. Un domaine est la partie de l'arbre présente sous un nom donné. Par exemple, le domaine fr contient le nœud fr ainsi que tous les nœuds dont le nom de domaine se termine par fr, c'est à dire tous des nœuds sous le nœud fr. Chaque nœud peut aussi contenir un certain nombre d'informations, comme une adresse IP, un type de machine, le nom de la machine en charge du courrier pour ce domaine, etc., c est sont des enregistrements des données DNS. Ces informations sont représentées par un ensemble d'enregistrements associés au nœud de l'arbre (A, HINFO, MX, etc.). Les programmes utilisant le DNS peuvent obtenir les enregistrements d'un certain type pour un nom de domaine donné. Dans l illustration au dessus, des enregistrements des données apparaissent dans le cadre sous le label du nœud rsm, entre autres il y a une adresse IP en IPv4 et aussi une autre en IPv6. Nous allons voir - 9 -

dans la partie suivante pour les détails des enregistrements. ENST Bretagne Campus Rennes En utilisant la structure d'arbre, il est possible de définir des domaines de responsabilité dans le nommage. Chaque fléche reliant un nœud à un nœud inférieur peut convoyer une information précisant qui est responsable du niveau inférieur. En des termes plus informatique, le domaine à l'origine de la fléche, le père, contient des informations précisant quels sont les serveurs possédant des informations sur les fils. Délégation est la notion utilisée à cet effet dans le système DNS. À chaque niveau cela peut se répéter, d'ou la création d'une répartition des responsabilités de nommage et de fonctionnement mais elle peut également indiquer qu'il n'y a pas de délégation de responsabilité. Une zone est la partie d'un domaine parcourue sans franchir de fléche, délégant la responsabilité. Ou autrement dit, une zone est la partie de l'arbre gérée par le même serveur (mais le même serveur peut gérer plusieurs zones). Dans le schéma, nous pouvons voir la zone fr et la zone enst-bretagne.fr, ainsi que la délégation entre ces deux zones, qui signifie que la zone enst-bretagne.fr est la zone fille de la zone fr. Le nœud rsm est le fils du nœud enst-bretagne.fr, donc le nom complet du nœud rsm, qui est en fait l un des serveurs de notre école, est rsm.enst-bretage.fr, ou rsm.enst-bretagne.fr. avec le point terminal. Les données de chaque zone sont dupliquées sur plusieurs serveurs. Cette duplication permet d'améliorer la fiabilité du service et de répartir la charge entre les différents serveurs. Aussi, chaque enregistrement contient une durée de validité des informations. Une fois qu'une machine cliente a obtenu une information, l'enregistrement est valide pour le temps donné (TTL). Après cette durée, il faut à nouveau demander cette information. Pendant cette durée, l'information peut être stockée dans un cache. La présence de ce mécanisme de cache dans tous les serveurs de noms ainsi que dans un certain nombre de clients (résolveur) permet de limiter le nombre de requêtes faites, au prix d'une certaine latence dans la mise à jour d'informations quand un changement est effectué. 1.3 Contenu d une zone Nous avons vu que chaque nœud peut aussi contenir un certain nombre d'informations, comme une adresse IP, un type de machine, le nom de la machine en charge du courrier pour ce domaine, etc., c est sont des enregistrements. Ces informations sont représentées par un ensemble d'enregistrements décrits dans des fichiers de configuration de la zone correspondante. Dans ce rapport, des exemples sont tous faites sous FreeBSD 4.8 release en utilisant BIND (version 9.3 Snapshot). Après avoir vu la configuration d une zone, dans des serveurs de nom, c est le fichier named.conf qui contient la configuration du serveur et en particulier la liste des zones sur lesquelles le serveur - 10 -

est autoritaire (primaire ou secondaire). La syntaxe complète de ce fichier dépend de la version de BIND. La documentation et les dernières informations de la version actuelle sont disponibles sur l Internet et il est aussi possible de l obtenir par la commande man named.conf. Toutes les zones sont énumérées dans le fichier de configuration du serveur de noms en précisant si la zone est primaire, secondaire, ou cache. La syntaxe générale est la suivante : <type de la zone><nom de la zone>[source]<fichier> Par exemple : zone "lei.enst.idsa.prd.fr" { type master; file "master/lei.enst.idsa.prd.fr.signed"; ; zone "names.lei.enst.idsa.prd.fr" { type slave; masters { 192.108.119.89;; file "slave/names.lei.enst.idsa.prd.fr"; ; [Extrait du fichier /etc/namedb/named.conf, section des zones] Outre la liste des zones, le fichier named.conf contient aussi des options de configuration du serveur, par exemple, les noms de fichiers peuvent être absolus (commençant par un /), ou relatifs, l option directory peut être utilisée pour changer le répertoire courant du programme. Par exemple : options { directory "/etc/namedb"; listen-on-v6 { any; ;... ; [Extrait du fichier /etc/namedb/named.conf, section des options] Les champs sont séparés par des espaces, les tabulations sont plus ou moins bien acceptées suivant les versions. Les lignes vides sont acceptées, des commentaires peuvent figurer par ligne entière commençant par un point-virgule ;. Nous avons vu que dans named.conf, pour chaque zone gérée par ce serveur, un fichier de configuration est spécifié, dans l extrait précédant, la ligne file "master/lei.enst.idsa.prd.fr.signed"; et file "slave/names.lei.enst.idsa.prd.fr"; sont des noms de fichier correspondent à la zone - 11 -

"lei.enst.idsa.prd.fr" et "names.lei.enst.idsa.prd.fr". ENST Bretagne Campus Rennes Chaque fichier de configuration de la zone contient une liste de differents enregistrements liées à la zone, ce sont des Resource Records(RR). Dans le système DNS original, des RR de type adresse IPv4(A), adresse IPv6 (AAAA), alias (CNAME), serveur de noms (NS) et start of authority (SOA) sont définis entre autres. Géneralement un RR a une représentation corresponde à le modèle suivant : Name TTL Class Type Rdata Par exemple: names.lei.enst.idsa.prd.fr 600 IN A 192.108.xxx.xxx Pour le RR SOA, le format est plus compliqué comme le modèle extrait ci-essous : names.lei.enst.idsa.prd.fr. 60 IN SOA ps2.ipv6.rennes.enst-bretagne.fr.enst.idsa.prd.fr. zhiyu\.lei.enst-bretagne.fr.enst.idsa.prd.fr. ( 2003072501 ; serial 60 ; refresh (60 seconds) 3600 ; retry (1 hour) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) [Extrait du fichier de zone, section RR SOA] Dans l extrait on peut voir un numéro de série et les périodes de différentes opérations de la zone. Mais ici nous ne spécifions pas plus de détails de la configuration d un fichier de zone, pour des enseignements détaillés et complets, nous vous conseillons de voir [AL01] et [OK02]. Il faut noter que sur la réalisation du DNSSEC (nous allons voir en détails dans la partie II.2 du rapport), dans la version 9.2 ou plus anciennes du BIND, la méthode proposé par RFC2535[R2535] est utilisée donc des RR du type KEY, SIG NXT sont implémentés et dépuis BIND 9.3(snapshot) l approche DS est adoptée. - 12 -

1.4 Processus de résolution ENST Bretagne Campus Rennes Le DNS est utilisé par la plupart des services liés à l'internet. Chaque fois que l'un de ces services fait référence à une machine par son nom, la base de données est interrogée (si l'enregistrement recherché n'est pas dans le cache du client). Sur des système UNIX, l'interrogation de la base de données est généralement faite par la librairie C dans la routine gethostbyname(). La librairie en question s'appelle libresolv.a et ses routines sont documentées dans le man resolver(3). Cette routine est utilisée par: Telnet (connexion à d'autres machines) FTP (transfert de fichiers) sendmail (MTA) Browsers WWW (Mozilla, NetScape...) etc... Le but de la librairie est de mettre en forme la requête cliente, de l'envoyer à un (ou plusieurs) serveur(s), et de collecter la réponse. Les clients peuvent être des programmes utilisant le service de noms dans la liste précédente ou d autres outils comme nslookup et dig. Chaque serveur possède une partie de la base de données du DNS, en général une ou plusieurs zones. Si c'est un serveur qui a la version officielle des donnés de la zone et les autres serveurs s'adressent à celui-ci pour les obtenir, on dit alors que ce serveur est autoritaire sur cette zone. Les serveur gardent aussi pendant une certaine période des informations venant d'autre zones en mémoire. C'est la fonction cache. Cela permet de limiter le trafic et de diminuer les temps de réponse en n'ayant pas systématiquement besoin de s'adresser à une des serveurs officiel d'un segment de la base pour obtenir les donnés après les avoir obtenues une première fois. Néanmoins les clients interrogent en général toujours le même serveur, souvent une machine "de service" ayant pour vocation de "faire tourner un DNS". Bien sûr cette machine ne connaît pas toutes les réponses (base de données répartie) et il y a d'autres machines plus appropriées pour répondre à certaines question sur un domaine. Une fois une requête reçue pour un domaine dont le serveur n'est pas autoritaire, deux cas sont possibles: Mode itératif 1 : rsm.enst-bretagne.fr? 2 : fr->ns2 Serveur du nom 1 resolveur 3 : rsm.enst-bretagne.fr? 4 : enst-bretagne.fr->ns3 Serveur du nom 2 fr 5 : rsm.enst-bretagne.fr? Serveur du nom 3 6 : rsm.enst-bretagne.fr IN A 192.44.77.1 [Fig.2 Résolution en mode itératif] enst-bretagne.fr - 13 -

Le serveur renvoie une réponse au client en indiquant qu'il ne connaît pas la réponse, mais qu'il suppose que tel serveur est plus renseigné que lui. Le client va envoyer la requête à un premier serveur puis à un second, peut être à un troisième, etc. Mode récursif 1 :rsm.enst-bretagne.fr? Serveur du nom 1 6: rsm.enst-bretagne.fr IN A 192.44.77.1 5 2 resolveur Serveur du nom 2 fr 4 3 Serveur du nom 3 enst-bretagne.fr [Fig.3 Résolution en mode récursif] Le serveur envoie la question à un serveur supposé plus renseigné que lui, attend la réponse et la fait suivre au client. Le client envoie la requête à un serveur, celui-ci la fait suivre à un second serveur, ce dernier l'envoie peut-être à un troisième serveur, etc. Par défaut, un resolveur envoie des requêtes en mode récursif aux serveurs de noms, et des serveurs font des requêtes nécessaires en mode itératif pour y répondre, sauf dans les cas ou l option forwarder est configurée dans named.conf du serveur. [AL01] Dans des resolveurs, c est aussi possible et nécessaire de traiter le cas où des noms sont simples qui ne contiennent pas de points en leur ajoutant un nom de domaine (souvent du réseau local). En effet les autres serveurs DNS ne savent traiter que des requêtes pour des noms complets à partir de la racine. Donc généralement une librairie est créée, elle utilise un fichier de configuration précisant la liste des serveurs à contacter, et le nom de domaine par défaut. Sous UNIX, le fichier /etc/resolv.conf qui contient des informations utiles à résoudre ce problème. domain ipv6.rennes.enst-bretagne.fr nameserver 192.108.xxx.xx [Extrait du fichier /etc/resolv.conf] Dans tous les cas précédents, nous avons parlé de moyens de trouver l'adresse d'une machine à partir de son nom, en revanche, nous avons aussi le pourvoir de faire l'inverse, c'est à dire ayant une adresse de trouver les noms qui correspondent. Mais dans ce papier nous ne détaillons pas ce processus là. - 14 -

2. DNSSEC 2.1 Extension sécurisée Puisque le DNS est la base de ce stage, nous avons fait beaucoup d efforts en expliquant la fonctionnement du DNS dans la partie précédante. Maintenant nous avançons à son extension sécurisée, DNSSEC. Comme décrit précédement, le DNS permet des machines de communiquer au travers de l Internet sans connaître leurs adresses IP respectives, mais la conception originelle de ce service n inclut aucun service sécurisé ayant pour but de protéger les transactions et les données échangées. Et par conséquent, le service DNS demeure très vulnérable aux attaques telles que la création ou modification des messages, la pollution de cache, l usurpation d identité, etc. [GC03, AA03] Dans la figure suivante, les endroits où des attaques sont possibles sont marqués par un point d interrogation. Nous pouvons voir qu il y a des faiblesses situées dans des échanges de message DNS, et aussi des intrusions potentielles dans le fichier de zone ou le cache.?? Serveur DNS 1 Cache? Fichier de zone? Resolveur? Cache Serveur DNS 2 Fichier de zone Cache? [Fig.4 Points faibles du DNS] Par exemple, il est possible d intercepter un message DNS et de le modifier. En effet, il n est pas difficile d analyser le trafic sur le réseau à l écoute d une requête DNS (ce qui est particulièrement aisé sur les réseaux locaux où un support commun est partagé par plusieurs stations). Lorsqu une requête DNS passe, l attaquant la duplique, l analyse et envoie une réponse erronée à cette requête avant que le serveur de noms n ait eu le temps de répondre [GC03]. Ou, on peut fabriquer des réponses erronées directement, si l on a deviné le ID (et autre informations) de la requête suivante - 15 -

successivement. [AA03] ENST Bretagne Campus Rennes De plus, le fonctionnement du cache, qui a pour but d améliorer les performances du DNS, c est-à-dire diminuer les temps de réponse lors d une résolution de noms, se fait une cible particulièrement intéressante pour les attaques appelé pollution de cache (ou cache poisoning), qui sont réalisés par une séries d interceptions et manipulations de message DNS. Ainsi, il est possible d utiliser un serveur DNS corrompu pour faciliter le processus d intrusion dans d autres systèmes, en modifiant le fichier de zone. En brèf, le système DNS est très vulnérable aux attaques, les problèmes de sécurité du DNS portent sur : - la sécurité des transaction de message DNS - la sécurité des données, l intégrité et l authentification - le déni de services Pour combler ce manque de sécurité, le protocole DNSSEC est proposé. DNSSEC apporte deux services de sécurité essentiels au DNS : DNSSEC garantit l intégrité des données et l authentification de la source des données. Afin de les mettre en œuvre efficacement, DNSSEC utilise une cryptographie à clef publique et des signatures numériques. Cette extension utilise de nouveaux enregistrements (RR KEY, SIG, NXT et DS) en supplément au service DNS original pour gérer des clefs et signatures nécessaire à l utilisation d une système de cryptographie à clef publique. Dans DNSSEC, chaque enregistrement est désormais signé (sauf les glues), et cette signature est stockées dans un enregistrement de type SIG spécifique [R2535]. Veuillez bien noter que la sécurisation ici est toujours au sens de la garantit de l intégrité des données et l authentification de la source des données. Ou autrement dit, le service DNSSEC est un service sécurisé et non-confidenciel, des données DNS sont toujours accessibles au public. L utilisation de SIG(0) et TSIG dans DNSSEC sont proposées par d autres chercheurs[r2845, R2931] afin de sécuriser des transaction entre serveurs DNS, mais la défense contre le déni de services n'est pas dans le domaine couvert par DNSsec. DNSSEC permet la sécurisation du DNS en se basant sur deux points : - La sécurisation d une zone - La confiance d une zone à une autre : Chaîne de confiance (Chain of Trust); - 16 -

2.2 Clef et signature DNSSEC utilise une cryptographie à clef publique et des signatures numériques pour garantir l intégrité et l authentification dans le service DNS. Au lieu d expliquer en détails la fonctionnalité de PKI et de signature numérique, nous vous présentons le schéma de signature de vérification utilisé par DNSSEC : Signature : Message Message signé Hache Fonction de hachage Chiffrement avec clef privée Signature Envoi de message Vérification : avec clef publique Hache Dechiffrement avec clef publique Signature Message signé Message Les deux hachages sont-ils identiques? Hache [Fig.5 PKI et signature dans DNSSEC] - 17 -

L idéé principale de cryptographie à clef publique est l utilisation asymétrique de clef publique et clef privée, et en revanche la signature numérique est une fonction de hachage. Le système PKI et signature numérique sont des méthodes matures et efficaces, leur emploiment dans DNSSEC est réalisé par la définition et l utilisation des nouveaux enregistrement : RR KEY et SIG. Dans chaque fichier de zone, nous allons trouver, entres autres, des enregistrements de type KEY pour stocker la partie publique des clefs capables d être utilisé à signer d autres enregistrements, ainsi que des enregistrements SIG contenant la signature de l enregistrement auquel ils font référence, et bien sûr la clef utilisée à la création de ce signature. TTL Type Drapeau Protocole Algorithme Clef publique ID de clef 60 KEY 256 3 5 (AQPY2k4P2w/fFq/mARgANC8ypQAYEkgxWhSafulQ6rX tz33kk4vojlgcea7yehsp0k0jc5mxwy/fc8ohcug+q0//) ; key id = 9524 60 SIG KEY 5 5 60 20030823093602 (20030724093602 9524 lei.enst.idsa.prd.fr. Y/0nwlvo77IuGBG62S27vqiatzSoehM3WbCqKFzmp5VV DJQ4epQwMTKdkLOI0pWE3ZgMtWKGb9ySvE/2icXsvg == )... 60 NXT chambre.lei.enst.idsa.prd.fr. NS SOA SIG KEY NXT Data fin de valadité Data début de valadité Algorithme Nom de signataire 60 SIG NXT 5 5 60 20030823093602 (20030724093602 9524 lei.enst.idsa.prd.fr. QjBIFk+yJ9rjoBc+cc81oz/EZ6A8Dig+Ii7V8C5+497r5b2 +RwON/1eIwZyHnPtEQO3uNIYKJ5ORh5zZpS0FjQ== )... Label Field [Fig.6 Extrait du fichier de zone, section clefs et signature] En effet, des enregistrements KEY et SIG font partie de la réponse DNS, à condition que le client qui envoie le requête demande l information DNSSEC en supplémentaire et le serveur a implémenté DNSSEC. De cette manière là, le client qui veut vérifier des données dans la réponse DNS qu il a obtenue d un serveur DNSSEC, il lui faut prendre la partie de signature chiffrée (dans enregistrement SIG), et re-établir la signature originale grâce à la partie publique de la clef qui est aussi inclue dans la réponse, et aussi prendre la partie de données et y faire la fonction de hachage pour créer la signature à nouveau. En comparant la signature original dechiffré de la réponse et la signature - 18 -

qu il construite, il connaîtra l intégrité de l information obtenu. ENST Bretagne Campus Rennes Pour plus d information sur la création des clefs et des signatures, vous trouverez des instructions détaillées dans [OK02], ou des aides fourni dans BIND pour la commande dnssec-keygen et dnssec-signzone. D autre part, il existe un type de RR KEY spécial qui sert à signaler des serveur DNSSEC que cette zone n est pas sécurisé, il s agit une de type NULL. Pour plus d information veuilliez voir l annexe A du rapport. Dans l extrait du fichier précedante, nous avons aussi vu l autre type d enregistrement, NXT. En fait des enregistrement d une zone signée sont triées en ordre alphabétique quand on signe une zone par la commande dnssec-signzone, des RR NXT sont ajoutés automatiquement par BIND afin de répondre à la non-existence d un nom d une manière sûre. - 19 -

2.3 Chaîne de confiance (Chain of Trust) ENST Bretagne Campus Rennes Nous avons vu qu au sein d un fichier de zone ou d une réponse DNS, il y a des enregistrements sécurisés via des signatures numériques signé par des clefs privées de la zone. Le point critique devient donc de vérifier que la clef utilisée pour créer ces signatures correspondantes est légale. Pourtant, il existe deux types de clefs : les Key Signing Key (KSK) et les Zone Signing Key (ZSK). Les ZSK sont les clefs qui signent tous les enregistrements de la zone et les KSKs sont les clefs qui signent uniquement le KEY RRset. Mais ici c est le KSK qui fait partie de l architecture hiérarchique de l arbre DNS. Afin de valider une clef KSK, Delegation Signer[OG03] spécifient qu un enregistrement DS valide pour la clef de la zone fille doit être conservé dans la zone parente, et DNSSEC l a implémenté depuis BIND 9.3 Snapshot. Cela implique que quand une zone fille veut changer de KSK, elle doit contacter sa zone parente et lui envoyer son KEY RRset pour la prévenir des changements effectués. La zone parente peut alors créer le DS correspondant ou détruire un DS devenu obsolète. Grâce au DS dans la zone parente, on peut authentifier le KEY RRset du KSK correspondant du côté de la zone fille, et une fois la KSK était vérifié, les vérifications des ZSK et d autres enregistrements vont se faire successivement. 60 DS 52262 5 1 ( 366133AB45E72465141BFD538C8F656A2C61 349B ) 60 KEY 256 3 5 ( AQPtej06bDqsYnS97ez4suIS2xqphkUePL7N nieq0+2kc4yzc3qbshee/dwsajtaiv9vnc/j zffsx0yc8kw6dsx2pqbtax/mgdsjj/puy2ct 79Znos+K7f+AI2LmoTUnyRtGsrKI7bToQDfK V9b3MGvP71B8XoeQ2Rk7s9W2PU89qw== ) ; key id = 52262 [Extrait du fichier de zone fille, section DS, et section KSK correspondante] En effef, le RR DS comporte un haché d une clef KSK de sa zone fille, sa création est automatisé dans la processus de la commande dnssec-signzone du côté de serveur de la zone parente, si le Keyset de zone fille est déjà donné. D après [OG03], le haché est calculé par : Hache = hash (FQDN du RR KEY Rdata RR KEY) où Rdata RR KEY = Drapeaux Protocole Algorithme Clef Publique et FQDN = Nom ou alias de la zone déléguée Comme dit toujours, DNSSEC utilise le modèle arborescent du DNS, donc pour valider une clef il - 20 -

faut montrer des niveaux jusqu à un certain point dont l on est sûr de la fiabilité. C est-à-dire d établir une chaîne de confiance partant de la racine de l arbre DNS, en laquelle on a confiance, ou d un point d entrée de confiance dans l arbre jusqu à la zone interrogée. Pour créer ce chaînage il faut qu il existe une relation vérifiable entre une zone fille et sa zone parente, c est le rôle de l enregistrement DS qui contient des renseignements sur la clef KSK de la zone fille. Pour pouvoir faire confiance à la racine ou à un point d entrée, il faut que les clefs correspondantes soient stockées localement comme clefs de confiance (Trusted Key). N importe lequel de ces deux modes est utilisée, il permet aux utilisateurs de créer la chaînes de confiance : quand ils font confiance à la clef d'une zone (points d'entrées sécurisés ou racine de l'arbre DNS), par le biais d'authentifications successives, descendre dans l'arbre et consulter les enregistrements des zones descendantes en toute sécurité. ; trusted-keys { domain_name flags, protocol, algorithm, string; [domain_name flags, protocol, algorithm, string;] trusted-keys { fr. 256 3 5 "AQPVBxJOwMytPgkjbYVvDXGuYMbVTvKYqj/DBKWv2Hs8+LxekRbaw9FL FaCsGw5pc1FpwEbuC82JRYqwKlt81VyYwWfmmC5IVg2frptmICFVWp0G3gJAzRFDjXe iux6uavo0w16tmeiezz62yxrot9ulcxh7gcsqhy819eun ek4qnw=="; ; [Extrait du fichier /etc/namedb/named.conf, section trusted key] L utilisation des bit de drapeaux, de protocole et d algorithme est exactement la même que celui de RR KEY normal. voici un résumé du fonctionnement de la chaîne de confiance: - les données de la zone fille sont signées par des clefs privées des ZSK de la zone fille - les ZSKs de la zone fille sont signée par des KSK de la même zone - la clef publique de KSK de la zone fille est authentifiée par le DS correspondant situé dans la zone parente - le DS est authentifié par la ZSK du parent, la ZSK est signé par KSK du parent - la clef publique de KSK de la zone parente est authentifiée par un DS dans la zone grand-parent - on remonte dans l'arbre jusqu'a rejoindre une clef de confiance stocké localement Par conséquent, on peut voir des résultats satisfaisants contre des attaques comme l interception et la modification d un message DNS, pollution de cache etc, grâce à l integrité de message et la vérifiablité de la source d origine fournis par l architecture de DNSSEC. - 21 -

Le but de ce mécanisme est de sécuriser tout l'arbre et de ne fournir aux resolveurs que quelques clefs de confiance pour assurer un point d entrée. Mais le protocole DNSSEC est relativement récent et toujours en évolution, donc il y avait de changements sur la constitution de la chaîne de confiance et il y en aura possiblement encore. En revanche, l en-tête des messages DNS ou DNSSEC n est pas sécurisé, donc des modifications sur des flags dans l en-tête de message est une façon d attaque encore efficace contre DNSSEC, donc il y a des propositions orientées à la sécurisation de transaction DNSSEC, par exemple dans [R2931], l auteur propose l utilisation d une RRset de type SIG(0) afin de signer la transaction DNS où l entête de message DNS est inclue. De plus, des attaques comme DoS (Denial of Service) sont encore fatal, car DNSSEC ne propose aucune protection supplimentaire au système DNS original sur ce genre d attaque, et en effet le processus de resolution par DNSSEC est plus lourd que celui de DNS original, donc DNSSEC se fait plus vulnérable à ce genre d attaques ou même possible d être utilisé comme un amplificateur d attaque DoS parfois. L utilisation de clef de confiance prédéfinies et de la chaîne de confiance corresponde parfaitement à l arborescence du DNS, mais le probème de l architecture hierachique est que si jamais un point de l arbre est compromis, toutes les noeuds au dessous ne sont plus fiables, autrement dit, pour attaquer une zone, toutes les zones entre root et cette zone sont les cibles potentielles et il suffit de hacker l une de ces zones... En contre-partie DNSSEC a apporté une nouvelle charge de travail aux administrateurs pour la gestion des zones, c est à dire que pour réaliser la sécurisation de la zone, il faut bien gérer les clefs nécessaires (création et renouvellement), re-signer la zone et avertir l administrateur de la zone parente des changements effectués sur les clefs afin que celle-ci puisse faire des mises à jour correspondantes. Nous allons discuter ce problème dans la partie suivante. - 22 -

III. DNSSEC Key Rollover ENST Bretagne Campus Rennes 1. Problématique Il n existe pas encore de mécanisme automatique pour effectuer l échange des clefs entre les entités du DNS, pour l instant cela se fait par un accord entre les administrateurs des deux zones via un mécanisme offline, ou par courrier éléctronique. C est-à-dire, envoyer le KEY RRset par un mécanisme hors-ligne, par exemple par fax ou envoyer une disquette par la poste, ou copier et coller le KEY RRset dans un email. Mais le moyen offline ne fournit aucune garantie sur l intégrité des données envoyées, et non plus de synchronisation entre la zone parente et la zone fille. Ainsi même si la zone parente est avertie du changement, elle peut ne résigner sa zone que bien plus tard, les changements d enregistrement DS concernant la zone fille n étant effectif qu à la re-signature de la zone parente, cela peut poser des problèmes de cohérence et ainsi empêcher la vérification de la chaîne de confiance. Par exemple dans le cas suivant : - La zone B.A change de clef - L administrateur de la zone B.A avertit l administrateur de sa zone parente A du changement - La zone B.A efface l ancienne clef AVANT que la zone A ne soit re-signée - Les enregistrements de la zone B.A ne sont plus vérifiables, la chaîne de confiance est cassé... (ici l information de la zone B.A est toujours accessible, mais n est plus sécurisé) Donc les administrateurs réseau peuvent passer beaucoup de leur temps a communiquer afin de s assurer de la synchronisation du roulement... Les moyens par email ou ftp ont leur soucis de sécurité correspondants, mais dans le cas de compromission du DNS, il est déjà difficile pour eux de fonctionner proprement, puisque ils utilisent la routine gethostbyname(), comme décrit dans le texte précédant. De plus un tel mécanisme empêche le déploiement d une solution entièrement automatisée et indépendante afin de gérer le roulement des clefs dans DNSSEC. Pour l information, le processus de Key Rollover était plus compliqué dans des premières versions de DNSSEC avant Delegation Signer. A ce moment là, pour établir la chaîne de confiance, il faut que l administrateur de la zone fils donne son keyset à la zone parent, et du côté de la zone parent, après avoir signé ce keyset avec sa clef privée, il lui faut retourner ce keyset signé au fils, et puis le fils inclut ce keyset signé dans son fichier de zone et doit re-signer.[al01,r2535] - 23 -

2. KRO 2.1 Un algorithme de Key Rollover Dans cette section, nous présentons un algorithme permettant l automatisation du roulement de clefs et la re-signature d une zone. Lors du changement de clefs, deux cas peuvent se présenter : 1, la zone fille change ses ZSKs ; 2, elle change ses KSKs. S il s agit d une ZSK, toutes les opérations sont sous la responsabilité de la zone fille qui effectue les changements, car seule les KSKs font partie de la constitution de la chaîne de confiance. En effet dans ce cas là, les seuls changements sont la création ou la suppression d une nouvelle ZSK et la re-signature de la zone. Les clefs signant le KEY RRset ne sont pas modifiées, il n y a donc pas lieu de modifier les enregistrements DS situés dans la zone parente. S il s agit d une KSK, c est à dire une des clefs qui signent le KEY RRset et donc font partie de la chaîne de confiance, il faut alors effectuer le changement sur le Keyset, créer ou détruire une clefs. Le Key RRset est modifié et des enregistrements SIG sont créées ou supprimés. Il faut alors permettre la synchronisation avec la zone parente afin d effectuer la mise à jour du ou des DS concernés par ce changement. Notre algorithme, nommé KRO, présenté par Olivier Courtay et Gilles Guette, permet la mise en place d une synchronisation automatique entre la zone parente et la zone fille, et aussi permet que, à tout moment du processus de roulement, les deux zones sont accessibles, leurs enregistrements sont vérifiables. Il garantit aussi une borne temporelle maximale après laquelle les changements sont effectués et effectifs dans les deux zones, mère et fille. Et bien sûr, l automatisation du processus dans notre solution s appuie sur des mécanismes déjà existant du DNSSEC. Le principe du KRO est suivant : L administrateur de zone met en place une politique de renouvellement de clef, et le roulement est automatisé par le programme du KRO. Quand le programme trouve que la zone fille doit modifier son KEY RRset (l ajout ou suppression d une ou plusieurs clefs), s il s agit d une ZSK, il suffit à la zone fille de créer ou de détruire la ZSK et de re-signer la zone, et le programme doit le faire. S il s agit d une KSK, c est plus délicat parce que il s agit de re-établir la chaîne de confiance. Nous vous conseillons de voir le schéma suivant pour voir entièrement le processus de roulement. - 24 -

Zone fille Zone Mère 1... 2... 3... 4... Creer/Supprimer une clef Resigner la zone Notify-query Requête et réponse de message DNSSec 5.1... 5.2... Vérifier le KEY RRset (grâce à DS et SIG RRset) Créer un Keyset correspondant 6.1... Resigner la zone, creer nouveau DS Notify-response 6.2... 7.1... Attend Max (TTL du DS de la zone mère, TTL de la cléf de la zone fille) 7.2... Non Oui LesDSs sont-ils prêts? 7.3... supprime des signatures anciennes et re-vient au debut Fin [Fig.7 Processus de l algorithme KRO] On peut voir que, ici, la zone fille envoie un message d avertissement du DNS standard, de type NOTIFY query, à sa zone parente pour lui spécifier qu il a modifié son KSK, et quand la zone parente le reçoit, il lui faut récupèrer alors les KEY RRset de la zone fille via une requête DNSSEC, et puis elle vérifie ce KEY RRset grâce aux signatures et aux clefs publiques de la zone fille, et notamment grâce aux DS anciens. Si le RRset est validé la zone parente envoie un acquittement de type NOTIFY Response à la zone fille et crée un Keyset si nécessaire. Après que la zone parente est re-signée, le DS correspondant est créé. Ensuite après avoir reçu l avertissement de la zone parente de sa re-signature, la zone fille doit attendre Max (TTL du DS - 25 -

de la zone mère, TTL de la clef de la zone fille) pour effacer les anciens enregistrements si nécessaire, et re-signer la zone pour créer des SIG correctement liées aux clefs présentes. L attente ici est en raison de l utilisation de cache, car des serveurs ou resolveurs avec cache n affichent les nouvaux changements qu après les donées dans leur cache soient éxpirées. Dans les cas où des RRset ne peuvent pas être vérifiés ou les cas où le message NOTIFY n est pas correct (message tronqué ou message émit pas un serveur non-autoritaire de la zone), comme dans le DNS original, un message du DNS de type NOTIFY réponse avec des flags indiquant des erreur est retourné à l origine de message NOTIFY. Voilà notre modèle conceptuel, l implémentation actuelle se base sur le schéma mais avec quelques adaptions vise au développement. 2.2 Justification des choix Nous avons déjà vu dans la partie précédente que notre solution s appuie beaucoup sur des mécanismes déjà existant du DNSSEC ou DNS original. De plus, le message DNS Notify se prête bien à notre algorithme car selon que le bit Q/R(Query/Response) est positionné ou non, ce message est considéré comme un avertissement de changement ou comme un acquittement à l avertissement. Pourtant afin d implémenter cet algorithme une modification du comportement du serveur primaire d une zone par rapport au message de type Notify est nécessaire. En effet il faut que le serveur primaire de la zone parente accepte le message comme un avertissement d un changement de clef. Ceci est tout à fait faisable en fixant utilisation de certaines bits de balise qui existe déjà dans DNS, mais à l instant il est plus facile pour nous de d abord modifier le traitement de tous les messages NOTIFY. Nous avons exhibés une borne temporelle maximale pour la durée du processus de changement de clef, il s agit de max(ttl du DS de la zone mère, TTL de la clefs de la zone fille). Une fois ce temps écoulé, la clef devenue obsolète peut être effacée sans danger. Ce retard ici est à cause de l utilisation de cache dans des serveurs et des résolveurs, le but de cache est d améliorer la performance de recherche mais pratiquement des serveurs ou résolveurs avec cache n affichent les nouvaux changements qu après que des donées dans leur cache aient éxpirées, c est-à-dire le temps indique par TTL, donc cette borne est inévitable et raisonnable. Le vrai souci est en cas d urgence, c est-à-dire une des clef de la zone est corrompue, il n est pas question d attendre pour éliminer cette clef, il faut refaire l algorithme tout de suite, mais tant que le DS authentifiant la clef corompue reste présent, le cache peut être pollué et la nouvelle chaîne de confiance ne peut - 26 -

pas s établir immédiatement. ENST Bretagne Campus Rennes Dynamic Update[R3007], et une autre méthode proprosée dans le draft de l IETF [StJ03] ont des approches similaires, avec l utilisation de SIG(0) afin d assurer la sécurisation de transaction. Leur proposition utilisent la méthode de Push, contrairement à ce que nous avons utilisé, l approche plutôt de Pull. La manière Push indique que des informations de KEY RR à mettre à jour sont inclues dans le message de avertissement (le message est de type Update dans [R3003] et de type Notify dans [StJ03]). La mode Push est plus facile à établir la nouvel DS, mais entre Push et Pull, nous avons choisi la mode de Pull parce qu il faut toujours faire une requête pour vérifier l origine de message est le SOA de la zone qui a lieu des changements, et aussi le mode Pull est plus résistant à l attaque de rejeu. Le message de requête produit par Pull est considéré comme un amplificateur eventuelle de l attaque DoS, il est vrai cette façon de solution est plus lourde que Push, mais nous sommes sûr qu il existe des outils plus efficaces qui servent à amplifier l attaque de type DoS. Par contre, un processus intéréssant nommé Pré-roulement décrit dans une autre draft[kg03], peut aider à l amélioration de notre algorithme. La partie essentielle de ce processus est de pré-annoncer la prochaine clef KSK à utiliser, c est-à-dire, inclue la partie publique de la prochaine KSK comme un KEY RR dans la configuration de zone, mais ne signe pas avec cette clef. De cette manière là, la zone parente peut déjà preparer le DS RR correspondant à la prochaine KSK, et dès que la zone fille a changé ses clefs est re-signé, elle ne retire pas tout de suite l ancienne KSK mais juste ne signe plus avec cette-dernière, et à ce moment de roulement, toutes les informations signées par l un de deux KSKs sont vérifiables. Cette proposition a une performance satifaisante en cas d urgence, le temps de propagation d une clef est raisonnable, mais tout est sous une condition : exposer la partie publique d une clef prévisionnelle ne risque pas de rendre la clef plus vulnérable à la cryptanalyse. - 27 -

2.3 Avantages et inconvénients ENST Bretagne Campus Rennes L algorithme que nous venons de présenter permet d automatiser complètement le processus de roulement des clefs en s appuyant sur les mécanismes existant du DNS et DNSSEC. Cet algorithme permet aussi de n avoir aucune perte de contact avec la zone fille en utilisant un recouvrement temporel des clefs lors de leur changement ainsi qu en prenant en compte l utilisation de serveurs caches dans l arborescence DNS. Notre solution peut être utilisée pour gérer plusieurs zones facilement, et une politique liée au renouvellement de ZSK, de KSK, et d intervalle de resignature est spécifiée à chacune de ces zones. Notre solution est utilisable pour un serveur qui gére plusieurs zones où se trouve la zone fille et sa zone mère à la fois. Dans ce cas là, la communication est donc restée dans ce serveur sans problème, mais le renouvellement des clefs de zone du root n était pas consideré, car notre solution fait face au renouvellement des KSKs et non au changement de clef de confiance (qui sert à proposer un point d entrée à la construction de la chaîne de confiance). Mais, notre solution est un algorithme spécifié au roulement de clef, dont la sécurisation de transaction produit par notre algorithme n est pas notre souci principal, c est-à-dire qu une fois les communications entre des serveurs sont brisées, à cause d incident ou d intrus, le processus de roulement est bloqué aussi. En revanche, ce problème n est pas un problème spécifique au notre solution, au sujet de la sécurisation de transaction du message DNSSEC, des approches comme SIG(0) et TSIG sont proposées par d autres chercheurs[r2845, R2931]. Notre solution est encore une partie indépendante serve à la gestion de renouvllement des clefs, donc ce point nous n a pas beaucoup inquiétés. Nous avons utilisé beaucoup de mécanismes, de fonctions ou de message DNS et DNSSEC, et on peut supposer qu un jour notre solution sera utilisée ou intégrée dans BIND (ou d autres programmes DNS), mais il vaut mieux traiter les transactions de clefs et DS par un mécanisme hors du système DNS [OK02]. C est une représentation d une contradiction qui est apparemment assez dur à résoudre. - 28 -

3. Implémentation 3.1 Découpage fonctionnel Ce logiciel doit être capable d automatiser le processus de Key Rollover selon les critères définis, y compris des informations suivantes : Nom et répertoire du fichier de configuration, nom de zone à gérer (et des fichiers de zone), l intervalle entre chaque signature, et une grosse partie de l information sur des clefs à utiliser pour chaque zone (ZSK et KSK séparément) : nombre de clef à utiliser, algorithme de cryptographie à utiliser, la puissance de cryptographie et la fréquence de renouvellement des clefs. Ici c est un découpage fonctionnel en générale, qui sert à mieux gérer le plan de développement. On peut découper toutes les fonctions à réaliser en deux catégories : celles qui sont restées toujours dans le même serveur DNS, appellées opérationnelle, et celles qui font des échanges entre des serveurs, on les note comme communicatives. En gros, la partie opérationnelle doit réaliser impérativement les fonctions suivantes : - Analyses des paramètres de configuration et des traitements correspondantes - Traitement d un fichier ou d un buffer (ex : analyse des RRset.) - Appel d une fonction ou commande BIND ou shell (ex : création des clefs et faire signer des zones) La partie communicative contient des fonctions servant à: - L émission et réception des messages - Vérification de message grâce au mécanisme DNSSEC - Analyse des messages et les transfert à la partie opérationnelle. La partie opérationnelle a une priorité plus haute que la partie communicative, au sens de développement. Il faut d abord garantir le bon fonctionnement de la partie opérationnelle, séparément sur la zone mère et la zone fille, ensuite la partie communicative pour lier ces zones. Une fois la partie communicative est construite correctement, il est possible de continuer à modifier des traitements concernant des données, des entrées et sorties, et d améliorer le logiciel sans toucher la partie communicative. - 29 -

3.2 Flux d exécution Traitement des paramètres, constitution d une chaîne de zones Entrée Init_conf() Init_db(){ Reload_file_db() ; Update_named_conf(); Save_file_db(); Prépare la base des données, recharge l ancienne, fait les mises à jour nécessaires et sauvegarde la base courante Fork() local_manager(){ for each zone, add keys; init_timers(){ initialize timers for each zone; signzone() ; while(1){ armed_timers(){ sleep till next action; rolling(); remote_listener(){ initialize server socket ; while(1){ listen on port; accept connection; fork(); close this socket; Message complèt? Du type Notify? Suis-je le serveur père? Emetteur est SOA? Validation grâce à DS ; Récupère des KSKs ; Insèrt des Keysets ; Signzone() ; Envoie Notify Response Ferme la socket For (each zone){ Add_key? Delete_key? Time_to_resign? DS_ready? send_notify? Signzone(); Timers updated Send_notify_from_zone(){ Get server of father zone; Build socket; Build message notify; Send message by socket; Exit [Fig.8 Flux d exécution] - 30 -

Nous avons définit une structure zone, chaque objet de ce type contient toutes les informations nécessaires liées à la zone correspondante, y compris le nom la zone, le nom de fichier de configuration de la zone, des informations de clef de la zone et la politique de renouvellement de la zone, qui est représenté par des intervalles variées des opérations sur la zone, par exemple la re-signature ou l ajout/suppréssion d une clef. Dès le début d execution, les traitements des paramètres d entrée sont faits et une chaîne d objet zone et constituée, toutes les configurations sont stockées dans des objets zone. Ensuite, l ancienne base des données est reloadée et se connecter au chaîne de zone actuelle, s il y a des configurations differentes pour une même zone, les anciennes données sont remplacées par les nouvelles. Des mises à jour nécessaires sont faites au fichier named.conf, par exemple pour changer le nom de fichier liée à une zone toto de file "master/toto"; à file "master/toto.signed"; et ensuite sauvegarde la courante base de données de KRO dans un fichier spécifique pour la prochaine execution. Correspondant au découpage fonctionnel, nous avons créé deux processus (par fork()) : local_manager() qui responsable principalement à la partie opérationnel et remote_listener() qui est le responsable de la partie communicative. Dans le local_manager, des alarmes pour chaque zone sont d abord initialisés selon le configuration indiquée par l objet de la zone, et des zones sont signées par la fonction signzone() qui fait des choses suivantes : elle trouve une zone, disons toto, regarde dans son fichier de zone appelé aussi toto, trouve et modifie le numéro de série, ajoute des $include pour des clefs, et le sauvegarde sous un autre nom de fichier toto.kro et enfin appelle la commande dnssec-signzone avec des paramètres spécifiant toto.kro comme le fichier d entrée et toto.signed comme sorti. Donc pour chaque structure zone, nous ne changeons jamais le nom ou le contenu de son fichier de configuration original correspondant à la zone, ça a beaucoup diminué des travaux liée à la suppresion de données anciennes. Depuis, le processus s endort jusqu à être reveillé par l une des alarmes, et puis il vérifie pour chaque zone s il y a des travaux à faire. S il s agit d une modification sur KSK, un message de type Notify doit être envoyé au serveur de la zone parente. Après avoir eu la réponse d acquittement, le programme attends encore une période de max(ttl du DS de la zone mère, TTL de la clefs de la zone fille) pour vérifier que le DS est bien sur place. Ensuite il le re-signe la zone et s endort encore jusqu à la prochaine action. - 31 -

Pour la partie communicative, nous avons utilisé beaucoup de fonction que M. Olivier Courtay a fourni dans DNSSEC-TOOLKIT, notamment des fonctions servent à faire le validation d une RR. Notre programe utilise à l instant la connection TCP par Socket on port 5353 du serveur pour écouter des messages envoyés. La partie d émission de message suit l approche implémentée par BIND mais en simplifié. Une fois que le processus du serveur a accepté une connexion, il créé un autre processus par fork() pour traiter cette connexion et permet lui-même de continuer à écouter d autre demandes. Après avoir reçu un message complèt et de type Notify, le processus de traitement doit encore vérifier que l emetteur du message est autoritaire sur zone indiquée dans le message, et le recepteur est bien le serveur de sa zone parente. Ensuite c est une série de requêtes et réponses DNS pour récupeérer des informations sur la zone qui change et en valider grâce à DS, si tout est légal et correct, des KSKs de la zone ou origine le message Notify sont analysées et un ou plusieurs Keyset sont insérés dans lerepertoire où se trouve la configuration de zone parente, la zone parente est re-signé et un message de DNS Notify Response doit être retourné à l origine du Notify. Si des erreurs ont eu lieu ou des vérifications n ont pas réussi, un message DNS Notify Response doit encore être envoyé mais avec des drapeaux indiquant l erreur. Dans le cas de suppresion d une clef, car nous n avons pas changé le contenu du fichier de configuration original correspondant à la zone où aucune clef n est inclue, il suffit d ajouter des clefs courantes et re-signer la zone. - 32 -

3.3 Bibliothèques utilisées Voici la liste des bibliothèques standards utilisées à la réalisation de ce logiciel : string.h, stdlib.h, stdio.h, sys/types.h, syslog.h, stdarg.h, unistd.h, getopt.h, time.h, signal.h Pour la partie communicative, sys/socket.h, netinet/in.h, arpa/inet.h et netdb.h sont utilisés. Ici l utilisation des fonctions écrit par Olivier Courtay dans DNSSEC-TOOLKIT sont significative, le fichier archivé appelé libresolvsec.a est nécessaire à la fonctionnement de ce logiciel. Ainsi, le headfile qui contient des définitions des types et des interfaces de DNSSEC, resolv_dnssec.h, est impérativement inclus dans le programme. Voilà une pièce d extrait du fichier Makefile utilisé pour compiler des code sources : kro: kro.o log.o timers.o util.o key.o sign.o kro_net.o gcc *.o -lcrypto -o kro /usr/local/lib/libresolvsec.a /usr/local/lib/libgnugetopt.a kro.o: kro.c kro.h gcc -I/usr/local/include -g -c kro.c... [Extrait du fichier Makefile] - 33 -

3.4 Interface utilisateur A l instant, ce logiciel peut être exécuté selon deux modes au choix de l utilisateur: soit par la ligne de commande avec tous les paramètres nécessaires, soit par l utilisation d un fichier de configuration comme l entrée. Ce dernier est recommandé car il nous donnera moins de travail à faire et plus de flexibilité, et aussi rendra plus facile la gestion de plusieurs zones. Par exemple, en tapant la commande suivante, vous pouvez utiliser le fichier de configuration kro.conf pour lancer le programme,./kro f kro.conf ou./kro --file kro.conf si vous avez rempli le contenu de fichier kro.conf comme la manière ci-dessous. -n./named/named.conf -k./named/kro.conf -z toto --nb_ksk 1 --nb_zsk 1 --bits_ksk 512 --bits_zsk 512 -a RSA -s 30000 --ksk_kro_time 100000 --zsk_kro_time 10000 -z tata --nb_ksk 2 --nb_zsk 2 --bits_ksk 1024 --bits_zsk 1024 -a RSA -s 10000 --ksk_kro_time 50000 --zsk_kro_time 50000 [Extrait du fichier de configuration du KRO] Ici, -n est suivi par le nom du fichier de configuration de BIND, -k signifie le fichier pour sauvegarder des configurations pour la prochaine fois, et des autres paramètres sont liés aux zones : nb_ksk et nb_zsk correspondent au nombre de KSK ou ZSK à utiliser, bits_ksk et bits_zsk sont des longueurs de clef qui signifient la puissance de cryptographie, et ksk_kro_time, zsk_kro_time sont les intervalles, en mesure de seconde, de re-signature correspondants. Le -a est l algorithme de cryptographie à utiliser, et enfin, le -s signifie la durée, toujours en seconde, entre deux - 34 -

signatures, avec ou sans roulement de clefs. ENST Bretagne Campus Rennes Et ensuite on a créé la configuration pour une autre zone tata. Il est évident que cette mode est plus facile à maintenir et nous vous informons que l utilisation de commentaires commencés par // est accepté dans ce fichier de configuration. Vous pouvez également utiliser la ligne de commande pour lancer le programme, par exemple, en tapant la commande suivante:./kro -n /etc/named/named.conf -k /etc/named/kro.db -z toto --nb_ksk 1 --nb_zsk 1 --bits_ksk 512 --bits_zsk 512 -a RSA --ksk_kro_time 100000 --zsk_kro_time 10000 -s 30000 Dans cet exemple, les deux premiers paramètres servent toujours à la localisation des fichiers, et des suivantes servent à la configuration de zone toto, de façon tout à fait comme la mode par le fichier de configuration illustré plus haut. Afin de gérer plusieurs zones, il suffit de rajouter à la fin de la ligne en haut des paramètres liées à une autre zone ( de -z à -s ). Cette manière peut être plus efficace pour gérer une seule zone ou faire des petites modifications sur une zone déjà contrôlé par notre programme, mais nous vous conseillons encore d utiliser la mode par fichier de configuration au cas où les modifications soient oubliées. Vous pouvez taper./kro -h ou./kro --help pour avoir plus d aide. Avant d utiliser notre programme, il y a quelques points à vérifier : - l utilisateur de notre programme doit avoir le droit de accès aux fichiers de configuration de système, comme named.conf. - comme décrit dans la partie 3.2, les traitements de fichier de zone se basent chaque fois sur le fichier original non signé, donc il faut bien garder tous les fichiers sur place. - à l instant notre programme fait ses communications sur la porte 5353 du TCP, il faut assurer de ne pas distribuer ce port TCP à d autre application. - 35 -

4. Résultat Nous exhibons des résultats de notre programme ici, ainsi, des fichiers de configuration et des codes sources en C sont ajoutés dans l annexe. Nous allons d abord montrer le résultat textuel du processus d exécution, qui est répresenté par des messages du log, qui détaillent toutes les étapes d exécution. [ps2] ~/mkro>./kro -f test Reading configuration file: test new zone : enst.idsa.prd.fr, filename:enst.idsa.prd.fr, directory:/homes/lei/mkro/namedb/master/ new zone : names.lei.enst.idsa.prd.fr, filename:names.lei.enst.idsa.prd.fr, directory:/homes/lei/mkro/namedb/master/ named_conf_path:./namedb/named.conf kro_db_name:./namedb/kro.conf zone: names.lei.enst.idsa.prd.fr nb of ksk: 2 nb of zsk: 2 nb of ksk bits: 1024 nb of zsk bits: 1024 ksk time: 50 zsk time: 50 algo:rsa sign time:10 zone: enst.idsa.prd.fr reading kro db file:./namedb/kro.conf saving kro db file:./namedb/kro.conf... Cette partie correspond à la construction de la chaîne d objet zone, et au rechargement et à la sauvegarde de la base de donées. En effet des messages servant uniquement à deboguer existent dans notre exemple ici, à l avenir ils pourront être cacher ou s afficher selon le niveau de débogage défini par l utilisateur. KRO server: waiting for data on port TCP 5353 call dnssec-keygen with: dnssec-keygen -r /dev/urandom -a RSA -b 1024 -n ZONE names.lei.enst.idsa.prd.fr Knames.lei.enst.idsa.prd.fr.+001+11770 new file key Knames.lei.enst.idsa.prd.fr.+001+11770 added in zone names.lei.enst.idsa.prd.fr. the ZSK:11770 adding a zsk - 36 -

call dnssec-keygen with:dnssec-keygen -r /dev/urandom -a RSA -b 1024 -n ZONE toto names.lei.enst.idsa.prd.fr adding a ksk calling dnssec-signzone with : dnssec-signzone -r /dev/urandom -s 20030828110028 -e 20030828115028 -o names.lei.enst.idsa.prd.fr.kro -f names.lei.enst.idsa.prd.fr.signed -k Knames.lei.enst.idsa.prd.fr.+005+09524 Knames.lei.enst.idsa.prd.fr.+001+11770... A part la première ligne de cette paragraphe qui signifie l ouverture du port 5353 par le processus de fonction remote_listener(), les autres notifications servent toutes au module opérationnel, dont la fonction local_manager() est en charge. Dans cette fonction, le programme appelle dnssec-keygen pour générer des clefs selon la configuration donnée, et appelle d autres fonction pour ajouter ces clefs à chaque zone, et enfin termine la procedure d initialisation par signer les zones en utilisant la fonction signzone(), où la commande de BIND dnssec-signzone est appelé pour chaque zone. Le numéro de série est changé selons la date et l heure actuelle, et des alarmes sont armées pour des prochaines actions. Ce qui faut noter ici est que pendant tout ces traitements, au lieu de changer chaque fois des fichier de zone, d y retirer des $include correspondant aux clefs qui ne sont plus valables, nous avons créé des fichiers temporaires terminiés par.kro comme entrée de dnssec-signzone. De cette manière, chaque fois quand la zone est re-signé, seule des clefs encore valables existent dans le fichier et donc quand une clef doit être détruite, il suiffit de la supprime de l objet de zone correspondante, sans modifier le fichier de la zone. +++++++++===========================+++++++++++ enst.idsa.prd.fr +++++++++===========================+++++++++++ names.lei.enst.idsa.prd.fr. nxt signature: 1062068449 calling dnssec-signzone with : dnssec-signzone -r /dev/urandom -s 20030828110028 -e 20030828115028 -o names.lei.enst.idsa.prd.fr.kro -f names.lei.enst.idsa.prd.fr.signed -k Knames.lei.enst.idsa.prd.fr.+005+09524 Knames.lei.enst.idsa.prd.fr.+001+11770 sleep for 10 secondes. KRO: Connecting to server ps2.ipv6.rennes.enst-bretagne.fr +++++++++===========================+++++++++++ - 37 -

Les messages ci-dessus sont des notifications de roulement des clefs. Le processus s endort jusqu à être reveillé par l une des alarmes armées, et puis il parcourt toutes les zone pour faire des traitements prévisionnés. Après avoir fini de traiter toutes les alarmes et mis en place les nouvelles alarmes, le processus s endort encore jusqu à la prochaine reveil. S il s agit d une modification sur KSK, un message de type Notify doit être envoyé au serveur de la zone parente, donc le message KRO: Connecting to server ici signifie que la connexion est entrain de s effectuer et aussi montre à l utilisateur le nom de serveur authoritaire de la zone parente qu il a trouve. Pour la partie communicative, nous allons utiliser quelques captures d écran pour démontrer la résultat. [Fig.9 Message du type DNS Notify] Cette image est capturée par xv, et le paquet est intercepté et analysé par Ethereal. Notre programe utilise à l instant la connection TCP par Socket on port 5353 du serveur pour écouter des messages envoyés. La partie d émission de message suit l approche implémentée par BIND mais en a simplifié. Après avoir reçu un message complet et de type Notify, le processus de traitement doit encore vérifier que l emetteur du message est autoritaire sur zone indiquée dans le message, et le recepteur est bien le serveur de sa zone parente. - 38 -

Par exemple, dans la manière suivante : ENST Bretagne Campus Rennes [Fig.10 Message du type DNS Notify Response] Ensuite c est une série de requêtes et réponses DNS pour récupérer des informations sur la zone qui change et les valider grâce à DS, si tout est légal et correct, des KSK de la zone ou origine le message Notify sont analysées et un ou plusieurs Keyset sont insérés dans le repertoire où se trouve la configuration de zone parente, la zone parente est re-signé et un message de DNS Notify Response doit être retourné à l origine du Notify. Si des erreurs ont eu lieu ou des vérifications n ont pas réussi, un message DNS Notify Response doit encore être envoyé mais avec des drapeaux indiquant l erreur. Malheureusement, à cause d une manque de temps de développement, cette partie du logiciel n est pas finalisé, donc l illustration ci-dessus est un modèle. Au fur et à mesure, notre logiciel est en train de développer et améliorer, mais c est encore un prototypage de notre solution, et nous n avons pas encore considéré des détails. Par exemple des différentes longueurs de ZSK peut être utilisée sur la même zone, et la procedure de sauvegarder et recharger peut être plus fine. - 39 -

IV. Déroulement du projet ENST Bretagne Campus Rennes Le projet s'est déroulé de la manière suivante : Une première phase de documentation sur DNS et puis DNSSEC, qui durait jusqu àu 6 juin, un premier plan prévisionnel a été fourni par moi et puis adapté à la version proposée par Olivier; La mise en place d une architecture des zones expérimentales et des études concentrées sur DNSSEC se font la deuxième phase de stage, une autre réunion s était faite, et un compte-rendu simple a été redigé en décrivant l architecture de mes zones. Mes zones étaient premièrement suivies de la configuration de DNS original et ensuite converties au DNSSEC. Des zones sont configurées séparément sur les serveurs PS2 et GAMECUBE. Ensuite, c est l'analyse des besoins, un document de spécification était rendu avec principalement des spécifications des: modèle conceptuel, besoins fonctionnels, besoins non fonctionnels, sous ensemble et priorités d'implémentation. Dans la même période, la date de soutenance était fixé au 11 septembre. Depuis, des réunions avec Olivier Courtay se sont faites régulièrement. Puis une phase de développement depuis juillet. D abord un plan de développement était rédigé, des travaux à faire sont classé par la priorité et puis distribués aux semaine suivantes, ainsi, le développement se construit suivant quatre pôles : modification sur des codes existants, réalisations des modules individuellement, l intégration et en fin, le test et déboguer. L édition du logiciel s est fait dans l environnement de Unix (FreeBSD et Solaris), en langage C. Le lieu de l édition se situé dans le laboratoire Sun de campus rennais de l ENST Bretagne. Pendant cette période là, une première version du rapport de stage était rédigée. La dernière phase est l écriture du rapport du stage et l amélioration du logiciel fourni. La durée de stage est depuis fin de mai jusqu au 30 septembre. Ce stage se déroule principalement dans le laboratoire de l ENST Bretagne, avec des réunions éventuelles avec les encadrants à l IRISA. - 40 -

V. Conclusion et perspectives ENST Bretagne Campus Rennes Le but de ce stage est de développer les outils nécessaires à une gestion automatisée des clefs de DNSSEC, afin d améliorer l efficacité du traitement des zones et des clefs qui sont changées, et de faciliter le travail de maintenance du personnel d'administration à la fois. La spécification de besoins est précisée par le modèle conceptuel du KRO, avec le découpage fonctionnel donné dans le chapitre III. Etant donné des résultats et ses explications, nous avons montré que le logiciel fournit est correspondant aux besoins et spécifications. Outre des fonctionalités de base, ce stage a d autres valeurs ajoutés. Ce stage est une approche simpliste d une pointe de vu du projet logiciel, il manque une période de test soignée et la documentation n est pas complète. Mais comme un logiciel bien structuré, la plupart de fonctions fournies dans notre logiciel sont re-utilisable, avec des interfaces claires et des commentaires du code facile à comprendre, donc l amélioration et modifications seront relativement faciles à faire, et le risque pour des developpeurs futurs est diminué. De plus, notre programme est une justification et une bonne démonstration pour le faisabilité (et certaines difficultés) de l algorithme KRO. D après le resultat obtenu par notre programme, nous avons démontré que l algorithme KRO est bien correct et faisable, mais aussi découvert certains petits défauts. Par exemple, il faut encore justifier l utilisation des bits de balise dans l entête du message Notify, si ça sera nécessaire de spécifier qu un message est de type de KRO, dans le consideration de l intégration avec autre type de Notify dans système DNS ou DNSSEC implémenté par BIND. Etant donné les défauts découverts, l amélioration de KRO sera plus facile car nous avons des cibles plus claires et des expériences plus concrètes. De DNS à DNSSEC, c est une étape importante de la sécurisation du système de nom de domaine, mais cette étape n est pas terminée et très loin d être complète. Maintenant, le protocole DNSSEC est normalisé mais le déploiement est encore facultatif, la mélange avec DNS sans protection a beaucoup baissé l efficacité du DNSSEC contre des attaques. Malgré toutes des versions du BIND et des patchs variés, l emploi de DNSSEC est encore limité. Personnellement je pense cette réalité est à cause d une manque d implémentation pratique. C est-à-dire, de nombreux algorithmes et théories sont proposés et justifiés, mais plupart entre eux sont jamais implémentés, il y a peu d outils mis en pratique, ni d outil pour justifier certains algorithme ni d outil pour automatiser le déploiement du DNSSEC. C est une cause, à mon avis, qui a gravement empéché l utilisation à grand échelle de DNSSEC. Donc on peut dire finalement, ce stage a une valeur pratique, au processus d établissement d un algorithme, et de plus, à la popularisation du DNSSEC. - 41 -

Index des matériels graphiques ENST Bretagne Campus Rennes Fig.1 Arbre des zones... 9 Fig.2 Résolution en mode itératif...13 Fig.3 Résolution en mode récursif...14 Fig.4 Points faibles du DNS...15 Fig.5 PKI et signature dans DNSSEC...17 Fig.6 Extrait du fichier de la zone, section clefs et signature...18 Fig.7 Processus de l algorithme KRO...25 Fig.8 Flux d exécution...30 Fig.9 Message du type DNS Notify...38 Fig.10 Message du type DNS NotifyResponse...39 Index des extraits du fichier Extrait du fichier /etc/namedb/named.conf, section des zones...11 Extrait du fichier /etc/namedb/named.conf, section des options... 11 Extrait du fichier de zone, section RR SOA......12 Extrait du fichier /etc/resolv.conf......14 Extrait du fichier de zone, section clefs et signature......18 Extrait du fichier de zone fille, section DS et section KSK correspondante...20 Extrait du fichier /etc/namedb/named.conf, section trusted key....21 Extrait du fichier Makefile......33 Extrait du fichier de configuration du KRO......34-42 -

Références [AA03] Threat Analysis Of The Domain Name System (draft-ietf-dnsext-dns-threats-03), D. Atkins, IHTFP Consulting, R. Austein, Grunchweather Associates, June 2003 [AL01] DNS and BIND, Paul Albitz&Cricket Liu, 4ème édition, publié par O REILLY, Avril 2001 [GC03] Les faiblesses du DNS, G.Guette and B.Cousin, 2ème rencontre francophone sur Sécurité et Architecture Réseaux (SAR 2003), Juillet 2003 [KG03] DNSSEC key operations(draft-kolkman-dnssec-operational-practices), O. Kolkman, RIPE NCC, R. Gieben, NLnet Labs, Juin 19, 2003 [OG03] Delegation Signer Resource Record, O.Gundmundsson, Draft IETF(Last Call), Juin 2003 [OK02] DNSSEC Operational HOWTO. V.1.3, Olaf M. Kolkman, RIPE NCC, Nov 2002 [StJ03] Using DNSSEC-secured NOTIFY to Trigger Parent Zone Updating (draft-stjohns-secure-notify-00), M. StJohns, Nominum, Inc. June 13, 2003 [RFC03] Le site de RFC Editor, http://www.rfc-editor.org/, 2003 [R2535] Domain Name System Security Extensions, RFC 2535, D.Eastlake, Mars 1999 [R2845] Secret Key Transaction Authentication for DNS(TSIG), RFC2845, P.Vixie, ISC, O.Gudmundsson, NAI Labs, D.Eastlake, Motorola, B.Wellington, Nominum, Mai 2000 [R2931] DNS Request and Transaction Signatures(SIG(0s),RFC2931, D. Eastlake, Sept 2000 [R3007] Secure Domain Name System(DNS) Dynamic Update, RFC 3007, B.Wellingto, Nov 2000 Autre resources : [1] Le site de DNSSEC, http://www.dnssec.net/ [2] Transactional Security in BIND 9 - Securing DNS, Cricket Liu, novembre 2001, http://www.linux-mag.com/2000-09/dns_01.html, [3] Le site de l Association Française pour le Nommage Internet en Coopération, http://www.afnic.asso.fr/, 2002 [4] The DNS Resources Directory, http://www.dns.net/dnsrd/ [5] The official BIND homepage, http://www.isc.org/products/bind/ at The Internet Software Consortium (ISC), http://www.isc.org/ - 43 -

Annexe A : Informations sur KEY, SIG et DS L utilisation de RR (Resource Records) de type KEY, SIG et DS est la partie essentielle de DNSSEC, mais ce rapport n est pas un manuel de DNSSEC donc nous n avons pas pu expliquer des détails dans le corps du rapport. En revanche, nous aimerions faire un peu plus de précisions dans cette annexe pour des lecteurs et lectrices. KEY Drapeau Protocole Algorithme 60 KEY 256 3 5 (AQPY2k4P2w/fFq/mARgANC8ypQAYEkgxWhSafulQ6rXtZ33KK4voJlGce A7YEHsP0k0jc5mXwY/fC8Ohcug+q0//); key id = 9524 Champ drapeau : 1 2 3 4 5 6 7 8 9 10 A B C D E F A /C Z XT Z Z NAMTYP Z Z Z Z SIG A/C : 0 = possiblité d être utilisé pour l authentification/confidentialité. Normalement 00. Z : Tourjours zéro. NAMTYP : 00, clef d utilisateur ; 01, clef publique d une zone ; 10, clef d un hôte ; 11, réservé. Protocole : 0 : Réservé 1 : Cette clef est utilisée par TLS (Transport Layer Security), RFC 2246 2 : Cette clef est utilisée pour courrier éléctronique, ex : clef de S/MIME 3 : Clef utilisée par DNSSEC 4 : Clef utilisée par IPSEC 255 : Tous protocole possible d utiliser RR KEY Algorithmes : 0 : Réservé 1 : RSA/MD5 2 : Diffie-Hellman 3 : DSA 4 : Réservé 5 : RSA/SHA1 NULL KEY Un type de clef spécial qui signifie qu une zone n est pas sécurisée. Exemple : KEY 49408 3 3 () Le champ drapeau ici sigifie cette clef ne serve à ni d authentification ni de confidentialité. - 44 -

SIG : ENST Bretagne Campus Rennes Algorithme Label Field 60 SIG NXT 5 5 60 20030823093602 (20030724093602 9524 lei.enst.idsa.prd.fr. QjBIFk+yJ9rjoBc+cc81oz/EZ6A8Dig+Ii7V8C5+497r5b2+RwON/1eIwZyHnPtEQO 3uNIYKJ5ORh5zZpS0FjQ== ) Algorithme La même que l algorithme de clef utilisée à la creation de cette signature. Lable field Ce chiffre indique le nombre des champs dans le nom d enregistrement signé. Dans le cas où un Wildcard est utilisé, ce chiffre peut être different du nombre des champs. DS : KEY ID Algo DigestType 60 DS 52262 5 1 (366133AB45E72465141BFD538C8F656A2C61349B ) Algorithme De 1 à 251, définit comme pour KEY Digest type 0 : Réservé 1 : SHA-1 Pour plus d informations et d actualités, veuillez visiter le site de DNSSEC : http://www.dnssec.net/ - 45 -

Annexe B : Extraits des fichiers de configuration Ici ce sont des extraits des fichiers de configuration liés à la réalisation de ce projet, pour des exemplaires de configuration complètes, il faut voir [AL01] ou [OK02]. Les deux fichiers ici sont juste une partie des zones utilisées mais ils sont complèts. Ces fichiers sont des fichier de configuration pour la même zone avant signé et après signé, nous peuvons voir des utilisations de KEY, SIG, NXT, DS, et aussi la différence de longeur du fichier. $TTL 60 $ORIGIN enst.idsa.prd.fr. lei IN SOA gamecube.ipv6.rennes.enst-bretagne.fr zhiyu\.lei.enst-bretagne.fr( 2003082501 ; serial 6 ; refresh (6 seconds) 3600 ; retry (1 hour) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS ns1.lei NS ns2.lei $ORIGIN lei.enst.idsa.prd.fr. home A 192.168.0.104 chambre CNAME home names NS ps2.ipv6.rennes.enst-bretagne.fr. ns1 A 192.108.119.87 ns2 A 192.108.119.89 ;$include Klei.enst.idsa.prd.fr.+005+09524.key;512b, zsk, or as following lei.enst.idsa.prd.fr. IN KEY 256 3 5 AQPY2k4P2w/fFq/mARgANC8ypQAYEkgxWhSafulQ6rXtZ33KK4voJlGc ea7yehsp0k0jc5mxwy/fc8ohcug+q0// $include Klei.enst.idsa.prd.fr.+005+47009.key ;1024b, ksk $include Klei.enst.idsa.prd.fr.+005+26765.key ;1024b, new ksk [Fichier de configuration de la zone lei.enst.idsa.fr, non-signé] - 46 -

; File written on Thu Aug 28 23:51:18 2003 ; dnssec_signzone version 9.3.0s20020722 ENST Bretagne Campus Rennes lei.enst.idsa.prd.fr. 60 IN SOA gamecube.ipv6.rennes.enst-bretagne.fr.enst.idsa.prd.fr. zhiyu\.lei.enst-bretagne.fr.enst.idsa.prd.fr. ( 2003082501 ; serial 6 ; refresh (6 seconds) 3600 ; retry (1 hour) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) 60 SIG SOA 5 5 60 20030927215118 ( 20030828215118 9524 lei.enst.idsa.prd.fr. tgxhlhxr+xcxpbhmgoxxsqytlgeyzqvkxpmr wuuafsylq/vux7sm3m8hyh1zkpz+wxf3vo5z XgmcCkfmS6taig== ) 60 NS ns1.lei.enst.idsa.prd.fr. 60 NS ns2.lei.enst.idsa.prd.fr. 60 SIG NS 5 5 60 20030927215118 ( 20030828215118 9524 lei.enst.idsa.prd.fr. xgd9pxhmrfqyse1ihkc4b7xx7tknxav9kq0u lcsshqblf4br+zpprp2fvhdyhl58lk8lk4ud dq+kldnwdltklg== ) 60 KEY 256 3 5 ( AQPIrKpgFPrJbXcWsAL0rwzc5KHl18nJCZj3 33phGztOW86DGD5YCPbyNjJk/O5rV50C5BKP osnyk5uxngsqgigthahmup6ovfwrtufqo45d 0Kdt4nFmM/uCSiFjpws7pYNd2EqR4N74p4q2 UCJSgLsLfrXgNP0v5y6sdMr//xxYgw== ) ; key id = 26765 60 KEY 256 3 5 ( AQPPeIcPoWAlRrMogJ/yGjy7c64Kk3eqMDTX wemnaqzyjaaxdykosd0limtoqaxxg/2k5/bg mcsiil39bmmxw9s4nxk9ksrqufmfgluxenfe se51gmzbavq3ch7zisujb2s1ztnsk1m5xkip rsg5f8+47fqsfmtyuxs1yfoonl3xiq== ) ; key id = 47009 60 KEY 256 3 5 ( AQPY2k4P2w/fFq/mARgANC8ypQAYEkgxWhSa fulq6rxtz33kk4vojlgcea7yehsp0k0jc5mx wy/fc8ohcug+q0// ) ; key id = 9524 60 SIG KEY 5 5 60 20030927215118 ( 20030828215118 9524 lei.enst.idsa.prd.fr. BS8NU0UFozLJQks0HqQzD/zOi1i1hPQ2m+h4-47 -

gmjihan7jw2fdveorox4uu2inxibqzmdydni CmQiuCxRDJ5g1Q== ) 60 SIG KEY 5 5 60 20030927215118 ( 20030828215118 26765 lei.enst.idsa.prd.fr. g3r2t2+3byia0iahcd2sccgyqbdtk3xyvvkf +zb3lngotr1gh410npxqmk+mfn8bn2kmpgjj WordCXaLTa19gkaxeip4inbrmGTd+OciZMyZ GSVzzmUBTMZsEu3I+Vr3LxmQH1hOJYl3E7HE CXD1wFOWHI95l+vljipHz7K0/Dk= ) 60 NXT chambre.lei.enst.idsa.prd.fr. NS SOA SIG KEY NXT 60 SIG NXT 5 5 60 20030927215118 ( 20030828215118 9524 lei.enst.idsa.prd.fr. DXjnBIGJyofoqD29mtOr9M4AxjOoshd99eZS 3sv1yGR1C0586cZ+7mDzgt7i3O5Evw8CoOOC vyked01rdrkcda== ) chambre.lei.enst.idsa.prd.fr. 60 IN CNAME home.lei.enst.idsa.prd.fr. 60 SIG CNAME 5 6 60 20030927215118 ( 20030828215118 9524 lei.enst.idsa.prd.fr. WuaJ2VJUKvT58DCxC02fd4d4CZZ6HXmmaxKn rp0sngy1obhncpvmghte1tm+5dn7tsp8dodm gviyvigtrbfvwa== ) 60 NXT home.lei.enst.idsa.prd.fr. CNAME SIG NXT 60 SIG NXT 5 6 60 20030927215118 ( 20030828215118 9524 lei.enst.idsa.prd.fr. xq4s8k0i3zsa90mmbmxzv0dubjf/jqqcvrl5 2DKwtNl5rtWoQ2wgor9hEteJIJP19jXUTH34 Pjo3eT6kCJP+xw== ) home.lei.enst.idsa.prd.fr. 60 IN A 192.168.0.104 60 SIG A 5 6 60 20030927215118 ( 20030828215118 9524 lei.enst.idsa.prd.fr. dpuyqv1x9i/dp+sfltvewj3ok4lbv+eqqjhi 5/uSW9VAlBxcuv5FYKlNW2MhT3Jiy0U0B/S4 Q9Ej5Gsg0LiFjQ== ) 60 NXT names.lei.enst.idsa.prd.fr. A SIG NXT 60 SIG NXT 5 6 60 20030927215118 ( 20030828215118 9524 lei.enst.idsa.prd.fr. rwpzalarasabcbxpy5e//dqqrdum+1iymapq AsiaSKjxH+9CssNMnHEV7TrW9+qzzP0HfiUy XNlN+NGnZX+zBA== ) ns1.lei.enst.idsa.prd.fr. 60 IN A 192.108.119.87 60 SIG A 5 6 60 20030927215118 ( 20030828215118 9524 lei.enst.idsa.prd.fr. BtbPaArHRsCpWGmki2ioRydn7oyqoy47uEum V+TDHGwaM9xtRyvi2xhlDzxmKYa4DUW88Lh2-48 -

BisReDo1+9FYrQ== ) 60 NXT ns2.lei.enst.idsa.prd.fr. A SIG NXT 60 SIG NXT 5 6 60 20030927215118 ( ENST Bretagne Campus Rennes 20030828215118 9524 lei.enst.idsa.prd.fr. MhKwXWskN+mgzYVYeFIJ9ZRKqAm8H39/vVjB phcbgghbj35plsp+s8nmguqpjngsbbnld/d4 8IAke9h5X5aTBw== ) ns2.lei.enst.idsa.prd.fr. 60 IN A 192.108.119.89 60 SIG A 5 6 60 20030927215118 ( 20030828215118 9524 lei.enst.idsa.prd.fr. 0XNl263PnAz52MVBVvMD4/Mx9piKybdzH9lJ dlnrlb1ihk1ieyt4ygxp5nqu3erqyskkcyf1 IHqqJ1okd+oAKw== ) 60 NXT lei.enst.idsa.prd.fr. A SIG NXT 60 SIG NXT 5 6 60 20030927215118 ( names.lei.enst.idsa.prd.fr. 60 IN NS 20030828215118 9524 lei.enst.idsa.prd.fr. n7gbmgcbohi2mkvopmwbzhnq9r8bdjlulzrn aeu30uwz4za7xdcp+tzx12f1nsv5snh9hj8b lghg0mqm6/dsea== ) ps2.ipv6.rennes.enst-bretagne.fr. 60 NXT ns1.lei.enst.idsa.prd.fr. NS SIG NXT DS 60 SIG NXT 5 6 60 20030927215118 ( 20030828215118 9524 lei.enst.idsa.prd.fr. Qb0RAdg3Ch0m0kRx730lFXBd7yb56WyeqHt8 TtzsRjTCDl5YM1DTyiVp2EJnJpgEg10mWM4w M/OeB2mp/Sq6sA== ) 60 DS 52262 5 1 ( 366133AB45E72465141BFD538C8F656A2C61 349B ) 60 SIG DS 5 6 60 20030927215118 ( 20030828215118 9524 lei.enst.idsa.prd.fr. L2P19Fu7MI4ZTRh+Ys4GmmPciDUlZHdB734k P9imZmBr3FoxS4SlcEWXZMTGAdltRlRz0gMq WtuAoL0g6r3d+Q== ) [Fichier de configuration de la zone lei.enst.idsa.fr.signed] - 49 -

Annexe C : Extraits du code source ENST Bretagne Campus Rennes Kro.h #include <string.h> #include <stdlib.h> #include <stdio.h> #include <sys/types.h> #include <syslog.h> #include <stdarg.h> #include <unistd.h> #include <getopt.h> #include <time.h> #include <signal.h> #include <resolv_dnssec.h> extern int LLV_DEBUG; extern int LLV_INFO; extern int LLV_WARNING; extern int LLV_ERROR; #define TYPE_KSK 0 #define TYPE_ZSK 1 typedef struct key { char * file_name; char * id; /* id should be a pointer on a zone of file_name */ int type; u_int32_t creation_date; struct key * nxt; key ; typedef struct zone { char * name; /* zone name */ char * directory; /* the directory where the file zone is stocked, use for put keysets files */ char * file_name; /* name of the file of zone */ int number_of_zsk; /* number of ZSK, can be null */ int number_of_ksk; /* number of KSK, cannot be null */ char * zsk_num_bits; /* number of bits fo the ZSK */ char * ksk_num_bits; /* number of bits fo the KSK */ char * algo; /* crypto algo example : RSASHA1 */ u_int32_t signature_time; /* time between two signature of the zone */ u_int32_t nxt_signature_time; /* the date of the next signature of the zone */ - 50 -

u_int32_t zsk_key_roll_over_time; /* should zsk_key_roll_over_time > signature_time */ u_int32_t nxt_zsk_key_roll_over; /* the date of the next ZSK Key Roll Over */ u_int32_t nxt_del_zsk_key_roll_over; /* the date of the destruction of the old ZSK*/ u_int32_t ksk_key_roll_over_time; /* ksk_key_roll_over_time > zsk_key_roll_over_time */ u_int32_t nxt_ksk_key_roll_over; /* the date of the next KSK Key Roll Over */ u_int32_t nxt_del_ksk_key_roll_over; /* the date of the destruction of the old KSK*/ u_int32_t wait_modified_ds; /* timers for wait that father are modified DS, using during a Key Roll Over of a KSK */ u_int32_t wait_for_resign; /* timers set by the father, because a soon has changed a KSK, but not resign ASAP but wait a little */ key * keys; struct zone * nxt; zone; typedef struct database { char * named_conf_path; char * kro_db_name; zone * zones; int launch_soon; int launch_father; database; database * db; void logger(int pri,const char *fmt,...); u_int32_t get_now(); u_int32_t init_timers(database * db); int signzone(zone * z); int dns_time32_totext(u_int32_t value,char **target); int number_of(char *buf,char c); u_int16_t get_ttl(char *name,u_int16_t type); - 51 -

Kro.c (extrait) : ENST Bretagne Campus Rennes #include "kro.h" int read_cmd_conf(int argc, char *argv[]){...//initialize from configure file int read_file_conf(char* path_file_conf){ //initialize from command line intinit_conf(int argc, char *argv[]){ //initialize, choose one of the above zone * load_zones_from_file(database * db){ //read zones into db int reload_file_db(database * db){ //prepare file then calls load_zones_from_file to initialize db int save_file_db(database * db){ //save zones and configurations... int init_db(database * db) { zone * z; int ret; ret = reload_file_db(db);//reload db backup from last time run if(ret!= 1) { logger(llv_warning,"can't read the db file\n"); ret = save_file_db(db);//save db for this time run if(ret!= 1) { logger(llv_warning,"can't save the db file\n"); return(ret); int main(int argc, char *argv[]) { int pid; int ret; ret = init_conf(argc,argv);//check entry arguments, from command line OR from a file if(ret!= 1) - 52 -

{ logger(llv_error,"error reading configuration.\n"); exit(-1); ret = init_db(db);//initialize kro's zones' database if(ret!= 1) { logger(llv_error,"db can be read or initiate\n"); exit(-1); pid = fork(); if(pid<0) { logger(llv_error,"fork\n"); exit(-1); if(pid==0) { local_manager(db);//local key rollover procedures if(pid>0) { ENST Bretagne Campus Rennes remote_listener(db);//listenning and answering communications with other hosts. Key.c (extrait) : #include "kro.h" char * call_dnssec_keygen(char * algo, char * bits,char *type, char * options, char * name) { //call dnssec keygen with all these arguments int add_key(zone *z,key *k){ int add_ksk(zone * z){... int add_zsk(zone * z){...//add a ksk or a zsk to the zone int del_key(zone *z,key *k){ int del_ksk(zone *z){... int del_zsk(zone *z){...//functions to delete a ksk or a zsk from a zone - 53 -

Sign.c (extrait) : ENST Bretagne Campus Rennes #include "kro.h" //this function set right $INCLUDE kname_zone.key in file //pls note here the new file is always a empty file, so no need to check old keys int prepare_file(zone * z){... /* The idea of the following function is to take the original zone file such as toto.db, make a copy of it to toto.db.kro(in the function above, prepare_files(zone* z)), and then add new "$INCLUDE..." lines to it, then, we sign it with the option "-o toto.db.kro" and "-f toto.db.signed" to gain toto.db.signed. */ int signzone(zone * z){ Timers.c (extrait) : #include "kro.h" //if next time to do sth is in 65535 seconds, wait that time, //if more than 65535, sleep 65535 then check again... //after done sleeping, it's time to work, so call "rollings" //to check every zone if it needs to be re-signed. Void armed_timers(){... //for each zone, scan to verify signing is needed void rollings(){ for(z = db->zones; z!= NULL; z = z->nxt) { if( now > z->nxt_signature_time z->nxt_signature_time - now < 5){ //set next re-signing time if( z->number_of_zsk!=0 && ( now > z->nxt_zsk_key_roll_over z->nxt_zsk_key_roll_over - now < 5)) { if(add_zsk(z)!=1) { should_sign_zone = 1; //add one zsk and set the time to delete it. - 54 -

if( ){ if(now > z->nxt_ksk_key_roll_over z->nxt_ksk_key_roll_over - now < 5) {... //new ksk added!! so should send notify. also set time to delete old zsk if( ){ if(should_sign_zone){ signzone(z); should_sign_zone = 0;... if(should_send_notify){ send_notify_from_zone(z); should_send_notify = 0; //end for(each zone). kro_net.c (extrait) : #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #include <stdio.h> #include <unistd.h> /* close */ #include "kro.h" int send_notify_from_zone(zone* z){ //call KRO_send_notify //The following function is a simplified copy of send_notify(), but in send_notify(), they use //res_send() which is a multicast and here we send only to the server of the parent //zone, and of course res_send() is much more robust than the one listed below. //The major catch here is to send to a port other than 53, so we made a simpler version //of send_notify() and res_send(). Instead of creating new message types we tried to keep // the structure of the message sent, so laterly maybe easier to be adopted. Int KRO_send_notify(dns_name2 * name,dns_rdata2 * rdata){ - 55 -

ENST Bretagne Campus Rennes int KRO_res_send(char* svr_name, const u_char* buf, int buflen, u_char *ans, int anssiz) {... //simplified version of res_send() int remote_listener(database * db) { //server socket here, both listenning and answering, won't end until killed for(;;) { //create a new socket for each connection, and server can listen to the next. pid = fork(); while ((n = read(sd, (char *)cp, (int)len)) > 0) { cp += n; if ((len -= n) <= 0) break; if (n <= 0) { perror("server side read TCP failed "); goto end_this_connection; //pls note that, we're in the child process, so if any error happened //we can close this socket connection and terminate this process. len = _getshort(buf);//get the length first resplen = len; //then read the message into buf cp = buf; while (len!= 0 && (n = read(newsd, (char *)cp, (int)len)) > 0) { cp += n; len -= n; if (n <= 0) { perror("server side receiving failed "); goto end_this_connection; // is it kind of notify? hp = (HEADER *)buf; if((int)hp->opcode!= (int)ns_notify_op){ perror("not a notify message "); - 56 -

goto end_this_connection; ENST Bretagne Campus Rennes hp->qr = 1;//set this to a response message cpt = buf; cpt += HFIXEDSZ; //get notifying zone's name n = dn_expand(buf, buf + len, cpt, zone_name, sizeof(zone_name)); if (n< 0 zone_name==null) { perror("failed parsing message "); goto end_this_connection; zone_dns_name2 = parent_name(name_fm_pt(zone_name,strlen(zone_name))); z=db->zones; while(z!=null){ if(strcmp(z->name,zone_dns_name2->pt)==0)break; z=z->nxt; //and am I the father zone? if(z==null){ //not my child zone, set rcode hp->rcode = REFUSED; perror("this notify should be sent to others "); goto end_this_connection; //no such zone in my db... else{ //then make a query to that zone who had sent the notify message zone_dns_name2 = name_fm_pt(zone_name,strlen(zone_name)); rdata = cache_get_section(zone_dns_name2, C_IN, dns_rdatatype_soa,0,1); if(rdata == NULL){ perror("can't get info about this zone "); goto end_this_connection; zone_soa =(char*) cmp_to_pt(rdata->data, strlen(rdata->data)); h = gethostbyname(zone_soa); if(h==null) { perror("kro:notify from unknown soa host "); goto end_this_connection; if((char *)cliaddr.sin_addr.s_addr!=h->h_addr_list[0])// that sender not is SOA of this - 57 -

zone? hp->rcode = NOTAUTH; else{//query full info to do validation ENST Bretagne Campus Rennes n= getrrsetbyname2(zone_name, C_IN, dns_rdatatype_sig, 0, &response); if(n!=0 response == NULL) { n = perror("can't get info about this zone "); goto end_this_connection; validator(response->query->name,response->query->class,response->query->type,response); if(n == 1){ { n= getrrsetbyname2(zone_name, C_IN, dns_rdatatype_key, 0, &resp2); if(n!=0 resp2 == NULL) perror("can't get key info about this zone "); goto end_this_connection; n = validator(response->query->name,response->query->class,response->query->type,response); //tostruct_ds(dns_rdata2 *rdata, dns_rdata_ds2 * ds); //then now we have both sigs and keys, find first ksk then save them as keysets. //response validated, so add new ds keyset file into directory //maybe make a new zone from the response then build key* chain for it? signzone(z); else{ hp->rcode = NOTAUTH; //end of if validated or not //end of if sender is soa or not free_dns_response(response); //end of if i'm not server zone end_this_connection: //all done? send a notify_response, the same message with modified flags //indicating reception of notify and other info, ex, sender is not soa. //for(;;) Autres fonctions utilitaires existent dans log.c et utils.c - 58 -