Étude du support de DNSsec côté serveur

Sous-Projet 2 Livrable 2.2 Étude du support de DNSsec côté serveur Partenaire responsable : AFNIC Auteurs : Bertrand Léonard (bertrand.leonard@nic.fr), Olivier Courtay (olivier.courtay@enst-bretagne.fr) Date : 02/02/04 Version : 1.1 Contact : idsa-tech@nic.fr Résumé/Abstract : Ce document décrit l évolution du support DNSsec dans les serveurs DNS, et plus spécifiquement BIND9 qui est la seule implémentation supportant la méthode de sécurisation des délégations DS (BIND9.3snapshots). Le projet IDsA a notamment contribué, lors de ses expérimentations, à corriger un bug d implémentation et fournir le patch adéquat. This document describes the evolution of DNSsec support in DNS servers. BIND9 snapshots are at the moment the only implementations providing conformity to DS-style secured delegations. IDsA project has provided a patch to correct an implementation bug existing in these snapshots. 1

Table des matières 1 Avant-propos 3 2 Le support DNSsec dans les serveurs 4 2.1 Serveurs récursifs et autoritaires.................................... 4 2.2 Etat de l art des principales implémentations.............................. 5 3 Apports du projet IDsA 6 4 Bibliographie et Copyright 9 2

1 Avant-propos Ce livrable est un compte rendu de la tâche 2B du projet IDsA : "Implémentations des fonctionnalités manquantes pour le support de DNSsec dans les serveurs". En effet, lors de la spécification du projet et de son découpage en sous-parties au premier semestre 2002, il n existait pas d implémentation de serveur conforme aux dernières versions du protocole DNSsec, et notamment en ce qui concerne la méthode de sécurisation des délégations. On pourra trouver les informations concernant le sécurisation des délégations dans le livrable 2.1 du projet [11] et dans les spécifications officielles [3]. D autre part, on se reportera à l annexe technique du projet IDsA pour les détails concernant les objectifs du sous-projet 2B (SP2B)[10]. En juin 2002, la première version de BIND9 intégrant le support de la méthode de délégation sécurisée DS[3] (Delegation Signer) voyait le jour (premier snapshot de la série BIND9.3s : bind9.3s20020618). La première version stable bind-9.3.0s20020722 était opérationnelle fin juillet 2002. Le projet IDsA débutait en septembre 2002, et de fait, la tâche 2B était en partie rendue obsolète. Néanmoins, de part l utilisation de ces snapshots dans le cadre du déploiement de la plateforme IDsA et du développement de certains outils[12], des bugs ont été mis en évidence dans le code du serveur, et les patchs adéquats ont été proposés à l ISC 1. Nous aborderons ces apports du projet IDsA en partie 3. Nous ferons dans un premier temps un état de l art des serveurs supportant DNSsec dans la partie 2. Ci-après nous donnons un récapitulatif de l évolution des documents de référence concernant DNSsec, ainsi que l évolution du support DNSsec dans l implémentation BIND9. 1 Internet Software Consortium, concepteurs du logiciel BIND, http ://www.isc.org 3

Chronologie Evolution des Standards Implémentations de BIND9 Mars 1999 RFC 2535[1] : premières spécifications de DNSsec Août 1999 RFC 2671[2] : indication du support DNSsec possible grâce au bit DO (DNSsec OK) Septembre 2000 Mai 2001 Remise en cause de la méthode de délégation sécurisée conforme à la RFC2535 : élaboration de la méthode DS (draft-ietf-dnsext-delegation-signer- 00.txt) A partir de 2001 Mise en place d une collection d Internet-Drafts visant à mettre à jour le protocole DNSsec et à remplacer à terme la RFC 2535 : draft-ietf-dnsext-dnssec-intro-00 (août 2001) draft-ietf-dnsext-dnssec-threats-00 (nov 2001) draft-ietf-dnsext-dnssec-records-00 (fev 2002) draft-ietf-dnsext-dnssec-protocol-00 (oct 2002) Ces documents sont disponibles en [13] 2001-2003 Evolution de ces drafts Juin 2002 Février 2003 Septembre 2003 Les RRs utilisés par DNSsec sont renommés (RR- SIG, DNSKEY, NSEC) Première version de BIND9 (BIND9.0.0) : support DNSsec conforme aux RFC 2535 et 2671, c est la première implémentation d un serveur DNS supportant DNSsec Premier snapshot BIND9.3s avec support de la méthode de délégation DS. En parallèle, la version stable (BIND9.2.1) utilise toujours la méthode conforme à la RFC 2535 BIND9.2.2 supprime la méthode de délégation conforme à la RFC 2535. La méthode DS n est toujours disponible que dans les versions snapshots (le dernier en date BIND9.3s20021217) Decembre 2003 DS passe en Proposed Standard, RFC 3658 Janvier 2004 Premier snapshot de la série 9.4 (bind- 9.4.0s20040114055632) incluant le support des nouveaux RRs (RRSIG, DNSKEY, NSEC) 2004?? La collection d Internet Drafts évoquée plus haut (souvent désignée RFC2535bis) devrait passer à l état Proposed Standard 2004?? La prochaine version stable de BIND9 devrait sortir dès que la RFC2535bis sera prête. Aucune nouvelle version n est attendue jusque là 2 Le support DNSsec dans les serveurs 2.1 Serveurs récursifs et autoritaires Si on s intéresse au support DNSsec dans les serveurs, on peut considérer séparément les deux grandes familles fonctionnelles de serveurs DNS (récursifs et autoritaires). les serveurs autoritaires : (i) Ils doivent comprendre les nouveaux RRs utilisés par DNSsec (KEY, SIG, NXT). (ii) Ils doivent comprendre EDNS0[2] et notamment le bit DO pour être capable de distinguer les entités supportant ou ne supportant pas DNSsec. 4

(iii) Ils doivent répondre aux requêtes portant sur les informations pour lesquelles ils sont autoritaires en distinguant les cas où ils doivent inclure les RRs de sécurité et les cas où ils ne doivent inclure que les RRs traditionnels. (iv) Ils doivent être associés à des outils permettant de mettre en place une zone sécurisée : outils de génération de clefs et de signatures de zone. les serveurs récursifs (caches) : (i) idem serveurs autoritaires. (ii) idem serveurs autoritaires. (iii) Ils doivent pouvoir effectuer la validation des informations qui leur sont demandées : vérifier les signatures des enregistrements, remonter les chaînes de confiance jusqu au point d entrée sécurisé le plus proche. (iv) Pour effectuer le travail précédent, on doit pouvoir les configurer avec des clefs de confiance qui serviront de points d entrée sécurisés pour leur travail de validation. 2.2 Etat de l art des principales implémentations Parmi les implémentations de serveur DNS majoritairement déployées : BIND 8 & 9, NSD, PowerDNS, Windows Server, nous indiquons l état actuel du support DNSsec : BIND 8 : BIND 8 (dernière version stable 8.4.4) supporte DNSsec conformément à la RFC 2535, à la fois serveur autoritaire et récursif. L évolution de la branche 8 de BIND est donnée ici : http ://www.isc.org/products/bind/docs/bind8.2_highlights.html BIND9 : BIND 9 (dernière version stable 9.2.3) supporte DNSsec mais a retiré le support de la méthode de délégation conforme à la RFC 2535 ; d autre part le support de DS n est pas encore intégré. En attendant la prochaine version stable (probablement BIND9.4), le support DNSsec est donc partiel puisque toute la partie sécurisation globale et chaîne de confiance est provisoirement inexistante. En tant que serveur autoritaire, on n a donc plus de délégation sécurisée ; en tant que serveur cache, on ne peut plus effectuer de validation par le biais de chaînes de confiance reliant plusieurs zones. L évolution de la branche 9 de BIND est donnée ici : http ://www.isc.org/products/bind/bind9.html BIND9.3snapshots : les snapshots de BIND sont les seules implémentations existantes supportant DS. Le dernier en date remonte au 17 décembre 2002. Ces snapshots ont un support total de DNSsec (méthode DS) à la fois pour les serveurs autoritaires et récursifs. Il est à noter qu un nouveau snapshot (BIND9.4.0s20040114055632) est disponible depuis peu ; il présente bien sûr le support DNSsec. Les derniers snapshots sont disponibles ici : ftp ://ftp.isc.org/isc/bind9/snapshots NSD : NSD n intègre pas encore de support DNSsec dans sa version courante (NSD 1.4.x). Néanmoins, cela est prévu pour les futures versions (NSD 2.x.x) attendues pour 2004. La roadmap est donnée ici : http ://www.nlnetlabs.nl/nsd/roadmap.html On rappelle que NSD est exclusivement un serveur autoritaire (la récursivité n est pas implémentée). PowerDNS : PowerDNS ne supporte pas DNSsec ; ce support n est pas à l ordre du jour actuellement. http ://downloads.powerdns.com/documentation/html/changelog.html Windows serveur : ce serveur (utilisable exclusivement sur une plateforme Windows) supporte DNSsec dans sa version RFC 2535. On trouvera les informations associées à l adresse suivante : http ://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ windowsserver2003/proddocs/standard/sag_dns_pro_modifydnssec.asp 5

3 Apports du projet IDsA Le projet IDsA a utilisé, pour le déploiement de son architecture ainsi que pour les tests associés, les versions snapshots de BIND9 (puisque ce sont les seules qui implémentent DS). Lors des tests du dernier snapshot de BIND (20021217), nous avons diagnostiqué un problème au niveau de la validation de certaines informations. Après investigation au niveau du code source du programme, nous avons decouvert la raison de ce problème et nous la décrivons ci-dessous. Le RR NXT sert à prouver la non-existence d un nom ou d un type d enregistrement dans une zone existante. Sa structure est donnée ci-après : 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Next Domain Name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Type Bit Map / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Le bitmap sert à indiquer quels types de RRs sont présents pour le nom associé. ex : considérons le point de délégation de la zone afnic.idsa.prd.fr situé dans sa zone parente idsa.prd.fr ; si cette délégation n est pas sécurisée, nous avons : afnic.idsa.prd.fr. 172800 IN NS ns1.afnic.idsa.prd.fr. 172800 IN NS ns2.afnic.idsa.prd.fr. 172800 NXT ftp.idsa.prd.fr. NS SIG NXT 172800 SIG NXT 5 4 172800 20040118031730 ( 20040103031730 15230 idsa.prd.fr.[...] Si l on sécurise cette délégation, on crée un enregistrement DS associé au point de délégation qui authentifie la clef de la zone fille. Donc on tient compte de ce nouveau type de RR dans le bitmap du NXT du point de délégation. afnic.idsa.prd.fr. 172800 IN NS ns1.afnic.idsa.prd.fr. 172800 IN NS ns2.afnic.idsa.prd.fr. 172800 NXT ftp.idsa.prd.fr. NS SIG NXT DS 172800 SIG NXT 5 4 172800 20040118031730 ( 20040103031730 15230 idsa.prd.fr.[...] 172800 DS 26750 5 1 ( 9F7CBA63A867095B8C4252180AAAEF115F67 C4B9 ) 172800 SIG DS 5 4 172800 20040118031730 ( 20040103031730 15230 idsa.prd.fr.[...] Le problème des snapshots de Bind 9.3 est que l outil de signature dnssec-signzone rajoutait le type DS dans le bitmap mais signait l enregistrement NXT dans son état précédent (sans DS dans le bitmap). Cette signature devenait donc erronée. Il en résultait que lors de la vérification de la non-existence de certaines zone il etait impossible de verifier le NXT car la signature n etait pas valide. Dans signname, une fonction de l outil de signature des zones dnssec-signzone, le code (simplifié) est le suivant : 6

/* si nous sommes dans une delagation */ if (isdelegation) { /* on essaye de trouver le keyset pour un DS */ result = loadds(name, &dsset); if (result == ISC_R_SUCCESS) { /* si oui on rajoute le DS */ result = dns_db_addrdataset(gdb, node, gversion, 0, &dsset, 0, NULL); /* et on positionne un boolean a vrai */ hasds = ISC_TRUE; result = dns_db_allrdatasets(gdb, node, gversion, 0, &rdsiter); while (result == ISC_R_SUCCESS) { /* pour tous les RRset pour cette zone */ dns_rdatasetiter_current(rdsiter, &rdataset); /* s il s agit d un NXT */ if (rdataset.type == dns_rdatatype_nxt) { if (!nokeys) /* on rajoute le bit SIG dans le NXT pour le SIG DS */ nxt_setbit(name, &rdataset, dns_rdatatype_sig,1); if (hasds) /* on rajoute le bit DS dans le NXT */ nxt_setbit(name, &rdataset, dns_rdatatype_ds,1); /* on signe ce RRset */ signset(&diff, node, name, &rdataset); Le problème est dans la fonction nxt_setbit qui ne fait pas ce que le codeur croit! En effet elle rajoute bien les bits qu il faut dans le bitmap du NXT, et elle va ensuite remplacer dans la base le noeud correspondant au RR par le nouveau noeud. Mais le pointeur rdataset n est pas modifié, on signe donc le RR dans son ancien état, alors que l on va utiliser le nouveau. Le patch permettant de corriger le problème a été envoyé à l ISC. Nous le donnons ci-après à titre indicatif : --- dnssec-signzone.c Tue Dec 3 06:01:34 2002 +++ dnssec-signzone.c-modif Tue Apr 1 15:38:56 2003 @@ -809,9 +809,41 @@ 1); + skip: + dns_rdataset_disassociate(&rdataset); + result = dns_rdatasetiter_next(rdsiter); + + if (result!= ISC_R_NOMORE) 7

+ fatal("rdataset iteration for name %s failed: %s", + namestr, isc_result_totext(result)); + + result = dns_rdatasetiter_first(rdsiter); + while (result == ISC_R_SUCCESS) { + dns_rdatasetiter_current(rdsiter, &rdataset); + + /* If this is a SIG set, skip it. */ + if (rdataset.type == dns_rdatatype_sig) + goto skip2; + + /* + * If this name is a delegation point, skip all records + * except NXT and DS sets. Otherwise check that there + * isn t a DS record. + */ + if (isdelegation) { + if (rdataset.type!= dns_rdatatype_nxt && + rdataset.type!= dns_rdatatype_ds) + goto skip2; + else if (rdataset.type == dns_rdatatype_ds) { + char namebuf[dns_name_formatsize]; + dns_name_format(name, namebuf, sizeof(namebuf)); + fatal(" %s : found DS RRset without NS RRset\n", + namebuf); + + signset(&diff, node, name, &rdataset); - skip: + skip2: dns_rdataset_disassociate(&rdataset); result = dns_rdatasetiter_next(rdsiter); ------------------------------------------------------------- 8

4 Bibliographie et Copyright Références RFCs et Internet Drafts [1] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [2] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [3] Gudmundsson, O, "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003. [4] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name System", draft-ietf-dnsext-dns-threats-0 (work in progress), October 2003. [5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Resource Records for DNS Security Extensions", draft-ietf-dnsext-dnssec-records-05 (work in progress), October 2003. [6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Protocol Modifications for the DNS Security Extensions", draft-ietf-dnsext-dnssec-protocol-03 (work in progress), October 2003. [7] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure Entry Point Flag", draft-ietf-dnsext-keyrr-keysigning-flag-11 (work in progress), October 2003. Ouvrages et documents [8] AFNIC. Formation-DNS, 2001. http ://www.nic.fr/formation/supports/formation-dns/ [9] Léonard, B. DNSsec : Theoretical and Practical Aspects, Mai 2003. [10] Equipe IDsA, annexe technique au projet IDsA, May 2002 [11] Léonard, B. livrable L2.1 : Etude et résolution des problèmes de délégation DNSsec, projet IDsA (SP2), 2003. [12] Courtay, O. livrable L1.2 : Maquette du résolveur enrichi, projet IDsA (SP1), 2003. Ressources Web [13] DNSEXT wg (DNS Extensions working group) at the IETF. http ://www.ietf.org/html.charters/dnsext-charter.html [14] Projet IDsA, (Infrastructure DNSsec et Applications). plate-forme de test DNSsec, développement d outils DNSsec, et étude des applications possibles de l utilisation d une infrastructure DNS sécurisée (mobilité IPv6, interactions DNSsec-IPsec,...). http ://www.idsa.prd.fr & ftp ://ftp.irisa.fr/local/idsa/ [15] DNSsec, securing the domain name system. Collection de ressources Web traitant de DNSsec. http ://www.dnssec.net Copyright Ce document est la propriété des partenaires du projet RNRT IDsA (Infrastructure DNSsec et applications, http ://www.telecom.gouv.fr/rnrt/projets/res_02_22.htm, http ://www.idsa.prd.fr). L utilisation de ce document doit être précédée par l accord explicite des partenaires IDsA suivants et qui sont joignables sur idsa-tech@nic.fr : - AFNIC - France Télécom R&D - ENST-Bretagne (Rennes) - IRISA Toute exploitation de ce document dans un but commercial est réservée. 9

English version : Copyright (C) IDsA (Infrastructure DNS sec et applications, http ://www.telecom.gouv.fr/rnrt/projets/res_02_22.htm) Project partners. Use of this document must be preceded by an explicit agreement of the following IDsA partners (email idsatech@nic.fr) : - AFNIC - France Telecom R&D - ENST-Bretagne (Rennes) - IRISA Any commercial use of this document is reserved. 10