Retour à la liste

Consultation DNSSEC

mercredi 22 décembre 2010 00:00:00

Dans le cadre de l'ouverture de son service d'enregistrement à DNSSEC, l'AFNIC souhaite recueillir vos commentaires et contributions sur certaines options du service. À chaque fois, la consultation "pose" une alternative ou une proposition et indique parfois le scénario préférentiel pour l'AFNIC à ce stade de la réflexion. Cette consultation sert de première phase de recueil d'avis. Une seconde phase aura lieu lors du Groupe de Travail Technique qui se tiendra le mardi 25 janvier 2011 à l'AFNIC. Enfin les spécifications définitives seront publiées le 3 février 2011. Nous vous rappelons que l'agenda prévisionnel de déploiement du service est le suivant : 5 avril 2011 : mise en production sur le sandbox (banc de test) 21 juin 2011 : mise en production définitive. Veuillez nous excuser du côté très technique de cette consultation qui s'adresse plutôt aux Bureaux d'Enregistrement qui pratiquent déjà ou ont une expertise de DNSSEC. Pour tous les autres, nous mettrons bien entendu en place des formations et de la documentation avant le déploiement du service. Si vous souhaitez participer à la consultation, merci de nous retourner vos réponses à support@afnic.fr avant le 17 janvier 2011. Consultation DNSSEC [...]

Consultation DNSSEC 1. Quelle mise en oeuvre pour la manipulation de la clef ? Nous ne fournissons pas de liste exhaustive de scénarios possibles car ils sont très nombreux. L'AFNIC préconise l'intégration des champs à recueillir dans l'opération d'update[tech]. Ceci reste cohérent avec notre mode de fonctionnement actuel et ne rajoute pas de tests ZoneCheck sur de nouvelles opérations. Ceci constitue une évolution de la fonction update[tech] avec uniquement des champs optionnels et n'impacte donc pas la mise en oeuvre actuelle du serveur EPP ni le workflow global pour les Bureaux. Vos commentaires : [ ] 2. Quels types de données doivent être fournies par le Bureau d'Enregistrement dans le cadre d'un domaine signé et comment le serveur doit-il réagir à ces données ? Pour rappel, la base de travail est le RFC 5910. Nous avons identifié trois scénarios plausibles : S1 - recueillir uniquement l'enregistrement DS (interface dsData), sans informations relatives à la clef associée (pas de inclus); en présence de cette dernière, le serveur EPP renvoie une erreur. S2 - recueillir l'enregistrement DS (interface dsData), et accepter de manière optionnelle les informations relatives à la clef associée ( optionnel); si cette dernière est présente, elle est stockée, si elle est absente elle ne génère pas d'erreur. S3 - recueillir l'enregistrement DS (interface dsData) et rendre obligatoire la présence des informations relatives à la clef associée ( obligatoire) ; en l'absence de cette dernière le serveur EPP renvoie une erreur. L'AFNIC préconise le scénario S1. Le scénario S3 nous semble plus lourd pour les Bureaux. Le scénario S2 nous semble générer de la complexité avec des situations non homogènes suivant les données envoyées et donc plus délicat à gérer pour les Bureaux comme pour le registre. Dans ces deux derniers cas, se pose par ailleurs la question de la cohérence entre l'enregistrement DS et l'enregistrement DNSKEY et de sa vérification par l'AFNIC. Votre scénario préféré : [ ] Vos commentaires : [ ] 3. Impact de la gestion des clés sur la procédure transfer L'opération transfer pose la question de la continuité de signature d'un Bureau à l'autre et notamment dans le cas d'un transfer d'un Bureau gérant DNSSEC vers un Bureau ne gérant pas DNSSEC. Afin de préserver un mode de fonctionnement du transfer ne rendant pas les titulaires "tributaires" d'un Bureau d'Enregistrement offrant DNSSEC, l'AFNIC propose que par défaut les enregistrements DS soient supprimés lors d'un transfer. L'AFNIC préconise de laisser le choix aux Bureaux d'enregistrement souhaitant offrir DNSSEC en leur offrant dans la nouvelle version du serveur la possibilité de choisir de conserver les enregistrements DS en place pendant le transfer. Cette option devrait être activée par tous les Bureaux offrant DNSSEC lors du transfer et soucieux de préserver la configuration actuelle de leur titulaire en attendant d'avoir pu activer la nouvelle. Cette mise en oeuvre aurait lieu sous forme d'un paramètre supplémentaire booléen dans la future extension frnic-1.1 de l'AFNIC. Ce champ serait obligatoire uniquement si le client utilise l'extension frnic-1.1 (ce champ est interdit avec l'actuelle extension frnic-1.0). L'extension frnic-1.1, ainsi que l'extension secDNS-1.1 seront mises en oeuvre dans une nouvelle version du serveur EPP supportant DNSSEC. En ce qui concerne les transfer vers les Bureaux d'enregistrement qui n'auraient pas mis en oeuvre EPP, la configuration DNSSEC serait désactivée. Les deux cas qui nous semblent pouvoir poser problèmes dans ce scénario sont : Un titulaire ayant activé DNSSEC et choisissant un Bureau entrant qui ne mettrait pas en oeuvre DNSSEC ou un Bureau entrant gérant DNSSEC mais ayant incorrectement mis en oeuvre cette option pourrait voir sa configuration DNSSEC désactivée. Ceci nous semble préférable à une résolution invalide. Un titulaire et un Bureau entrant faisant tout dans les règles restent soumis à la possible désactivation trop rapide de l'ancienne clé par le Bureau sortant. Cette situation est similaire au risque actuel de désactivation d'une configuration lors d'un transfer côté Bureau sortant. Les points positifs sont : Pas de blocage des titulaires par les Bureaux offrant DNSSEC. La possibilité de maintenir une configuration stable lors des transfer pour les Bureaux d'enregistrement souhaitant offrir ce service. Vos commentaires : [ ] 4. Impact sur les autres procédures Les opérations de trade, recover fonctionneraient de façon similaire au transfer. L'opération create ne permet pas de donner des informations relatives à DNSSEC (comme elle ne permet pas de renseigner les serveurs de noms). La gestion des erreurs correspondant aux options non implémentées de la RFC renverra les codes erreurs prévus par la RFC. Vos commentaires : [ ] 5. Tests ZoneCheck Les tests ZoneCheck liés à DNSSEC ne sont effectués que si l'enregistrement DS est fourni. L'AFNIC envisage principalement deux scénarios relatifs au cas des algorithmes de signature non reconnus. L'AFNIC considère a priori les tests suivants dans tous les cas : Présence d'un enregistrement DNSKEY : Fatal - test si au moins un enregistrement DNSKEY est présent sur la zone. Présence de plusieurs enregistrements DNSKEY : Warning - test si au moins 2 enregistrements DNSKEY sont présents. Dépendance avec le test précédent. Présence d'une KSK et d'une ZSK : Warning - test s'il y a au moins une ZSK et une KSK en regardant le bit SEP de toutes les clés Taille des clés: Warning - dépend de l'algorithme choisi Présence d'un enregistrement RRSIG pour l'enregistrement SOA : Fatal - test si au moins une signature pour l'enregistrement SOA est présente sur la zone Algorithme de la signature de l'enregistrement SOA : Warning - test si l'algorithme de la signature de l'enregistrement SOA est connu. Expiration de la signature de l'enregistrement SOA : Fatal - test si la signature n'est pas expirée ou ne sera pas expirée dans un temps de maintenant + 10% de la durée de validité de la signature. Durée de validité de la signature : Warning - test si la durée de validité de la signature n'est pas trop courte (< à 3 jours) ou trop longue (> à 6 mois).  Les deux scénarios concernent ces deux tests : Validité de la signature : Dépend de l'algorithme utilisé. Test si la signature est valide : si la signature est bien générée avec la clé et le bon algorithme Scénario 1 : Fatal si algorithme connu, Warning sinon Scénario 2 : Warning DS/DNSKEY correspond à un enregistrement DNSKEY dans la zone : Exécuté si l'algorithme de hachage est connu. Test si l'enregistrement DS est bien le hash d'un enregistrement DNSKEY de la zone. Scénario 1 : Fatal si algorithme connu, Warning sinon Scénario 2 : Warning Votre scénario préféré : [ ] Vos commentaires : [ ] Nous vous remercions d'avoir pris le temps de lire cette consultation et peut-être d'y avoir répondu.  
Haut de page

A propos de l'AFNIC

Créée en 1997, l’Afnic - Association Française pour le Nommage Internet en Coopération - est une association à but non lucratif. Désignée par l'État pour gérer les noms de domaine en .fr, elle en assure la promotion auprès des entrepreneurs et des particuliers. Gestionnaire historique du .fr avec plus de 3,2 millions de noms de domaine à ce jour, elle se positionne également comme fournisseur de solutions techniques et de services de registre : elle accompagne ainsi 14 projets de nouveaux domaines Internet de premier niveau dont le .paris et le .bzh. L’Afnic est implantée à Saint-Quentin en Yvelines : 80 personnes travaillent ainsi à ce bien commun qu’est l’Internet français. L’Afnic reverse 90% des bénéfices du .fr à la Fondation Afnic pour la solidarité numérique, qui finance des projets internet solidaire sur l’ensemble du territoire français. www.afnic.fr.