Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

Service DNSSEC d'AFRINIC

AFRINIC gère et publie les données de zone DNS inversé (RDNS) pour l'espace IP que nous allouons ou attribuons aux membres.

Les Zones comprend

IPv4

  • 41.in-addr.arpa.
  • 196.in-addr.arpa.
  • 197.in-addr.arpa.
  • 102.in-addr.arpa.
  • 105.in-addr.arpa.
  • 154.in-addr.arpa.

IPv6

  • 0.c.2.ip6.arpa.
  • 3.4.1.0.0.2.ip6.arpa.
  • 2.4.1.0.0.2.ip6.arpa.
Objectif

Le déploiement de DNSSEC à AFRINIC vise à

  • Signer ces zones.
  • Publier un enregistrement DS dans les zones parentes
  • Accepter les enregistrements DS de nos membres

Il permet à la communauté de valider les données DNS faisant autorité des zones RDNS d'AFRINIC et aux membres de publier des enregistrements DS pour construire la chaîne de confiance pour leurs zones RDNS.

Le déploiement de DNSSEC est un projet coordonné par NRO car les blocs ERX nécessitent des actions coordonnées. Toutes les communications concernant ces projets doivent être envoyées à dnssec-ops [at] afrinic [dot] net

Nous avons adopté un plan de déploiement progressif de DNSSEC chez AFRINIC. 

Plan de déploiement

Une fois la phase de test terminée, AFRINIC intégrera le Signataire dans le système d'approvisionnement en 3 phases. Dans cette phase, le système d'approvisionnement continue de fonctionner tel quel. Lorsque de nouvelles zones sont générées, des copies des zones non signées distribuées sont transmises au signataire pour produire une zone signée.

Phases de test de déploiement

  • Installer les outils (Opendnssec, NSD, BIND, DSC, etc.)
  • Générer des clés pour les zones - KSK RSA 2048 / ZSK RSA 1024
  • Obtenez une zone non signée dans OpenDNSSEC et signez
  • Publier les zones signées sous les serveurs DNS locaux
  • Recherchez et analysez les tailles de réponse sur UDP et TCP
  • Validation à l'aide de clés comme clés de confiance
  • Test des clés de roulement: ZSK et KSK
  • Rollover de clés programmé et roulement de clé d'urgence
  • Conclusions et leçons apprises

Phase 1 - Zones non signées publiées

La zone signée est vérifiée et chargée sur un serveur DNS public. Tous les tests sont effectués autour du serveur DNS public. AFRINIC évaluera ici le fonctionnement du signataire et le système d'approvisionnement mis à jour. 

  • Le nouveau système d'approvisionnement: génération cohérente de zones signées
  • Contrôle de cohérence du contenu des zones: requêtes non DNSSEC sur les deux (non signé et signé)
  • DNSSEC interroge les zones signées
  • Conclusions et leçons apprises

phase 2 - Publier les zones signées

Avec une étape précédente réussie, la prochaine étape sera de commencer à publier des zones signées au lieu de zones non signées. Dans cette phase, le système d'approvisionnement DNS inversé commencera à publier des zones signées avec une notification adéquate et un plan de restauration. Seules les zones produites par le signataire sont distribuées aux serveurs NS.

Teste

  • Les zones transfèrent la cohérence maître / esclaves
  • Requêtes non dnssec sur tous les NS
  • Requêtes DNSsec sur tous les NS
  • Conclusions et leçons apprises

Plan de restauration

La restauration de la phase où AfriNIC publie des zones signées sans DS dans les zones parentes est la suivante:

  1. Une fenêtre de maintenance pour la restauration est ouverte.
  2. Un avis de maintenance imminente, avec une description technique du changement, sera envoyé à la communauté.
  3. Pendant la fenêtre de maintenance, AfriNIC commencera à desservir une zone non signée, débarrassée de toutes les informations DNSSEC. La série SOA augmente afin de déclencher la distribution de la zone non signée.
  4. Un rapport technique détaillé des circonstances ayant conduit à la restauration et de l'exécution de la restauration elle-même est envoyé à la communauté.

Phase 3 - Publication DS dans les zones parentes

La publication des zones signées étant terminée, les zones AFRINIC RDNS ne sont pas encore sécurisées DNSSEC. Les enregistrements DS des KSK doivent être publiés dans les zones parentes. Les enregistrements DS seront générés et envoyés à l'IANA via leur système de gestion RDNS. 

Le provisionnement sera configuré pour traiter les enregistrements DS pour les sous-domaines. Le signataire et la publication des zones ne sont pas modifiés. Avec un système DNSSEC complet testé et lancé avec des mesures en place pour fonctionner selon le DPS, le projet passera aux opérations AFRINIC normales. La surveillance et la mesure du rendement seront des activités constantes.

Tests

  • Requête pour l'enregistrement DS sur tous les serveurs ip6.arpa et in-addr.arpa
  • Validation DNSSEC des RR signés dans les zones signées AFRINIC avec la clé racine comme clé de confiance
  • Conclusions et leçons apprises

Plan de restauration

La restauration de la phase où AfriNIC publie des zones signées avec DS dans les zones parentes est la suivante:

  1. Une fenêtre de maintenance pour la restauration est ouverte.
  2. Un avis des circonstances et des mesures correctives prévues, avec des détails techniques, sera envoyé à la communauté.
  3. AfriNIC exécutera un basculement KSK d'urgence pour supprimer les enregistrements DS des zones parentes.
  4. La communication publique avec la communauté se poursuivra, dans le but de veiller à ce que les nouvelles de la situation et les mesures prises soient communiquées au plus large public possible.
  5. Après le délai de publication approprié, tel que spécifié par le DPS, AfriNIC exécutera une transition vers des zones non signées comme décrit dans la phase où AfriNIC publie des zones signées sans DS dans les zones parentes.

Publication des enregistrements DS des membres

Tests

  • Traitement DS et signature DS RR
  • Validation de la chaîne de confiance de la racine à la zone enfant (avec les enregistrements DS publiés)
  • Conclusions et leçons apprises 

Énoncé de pratique DNSSEC - DPS

Paramètres de signature de zone - longueurs de clé et algorithmes

  • Clé de signature de clé: nous utilisons une longueur de clé de 2048 bits avec RSA comme algorithme de génération.
  • Clé de signature de zone: Nous utilisons une longueur de clé de 1024 bits avec RSA comme algorithme de génération.
  • Déni d'existence authentifié: le déni d'existence authentifié sera fourni par l'utilisation d'enregistrements NSEC comme spécifié dans la RFC 4034.
  • Format de signature: Nos signatures sont créées avec le hachage SHA2-256 en utilisant RSA.
  • Changement de clé de signature de zone: Nous roulerons la ZSK sur une base mensuelle avec un schéma de pré-publication tel que décrit dans la RFC 4641, section 4.2.1.1.
  • Key Signing Key Roll-over: Nous roulerons la KSK sur une base annuelle avec un schéma de double signature comme décrit dans la RFC 4641, section 4.2.1.2.
  • Durée de vie de la signature et fréquence de re-signature: Nous re-signons nos zones une fois qu'une nouvelle zone est générée avec une durée de vie de signature de 15 jours.

Durée de vie des enregistrements de ressources - Type d'enregistrement TTL

  • DNSKEY: égal au TTL utilisé pour l'enregistrement SOA
  • NSEC: égal au champ minimum de l'enregistrement SOA
  • RRSIG: égal au TTL le plus bas du jeu d'enregistrements couvert
  • DS: égal au TTL utilisé pour l'enregistrement NS

Délégations DNSSEC

Procédure de demande de Délégations DNSSEC (Date: Avril 2012 - Version: 1.0)

Cette section décrit comment demander des délégations DNSSEC. Elle s'ajoute à la procédure existante pour demander des délégations inversées.

Veuillez noter que jusqu'à nouvel ordre d'AfriNIC, DS RECORDS ne sera pas visible dans le DNS. Méfiez-vous des nouvelles à venir de notre part.

1 - L'objet DOMAIN

Vous pouvez demander une délégation inversée en soumettant des objets de domaine via auto-dbm (e-mail) ou via MyAFRINIC, qui est la méthode recommandée[1]. DNSSEC n'entraînera aucune modification des mécanismes d'autorisation existants. Pour activer la délégation DNSSEC, l'objet domaine inclut désormais un attribut "ds-rdata:".

domaine: [obligatoire] [unique] [clé primaire / de recherche]
descr: [obligatoire] [multiple] []
org: [facultatif] [multiple] [touche inverse]
admin-c: [obligatoire] [multiple] [touche inverse]
tech-c: [obligatoire] [multiple] [touche inverse]
zone-c: [obligatoire] [multiple] [touche inverse]
nserver: [facultatif] [multiple] [clé inverse]
ds-rdata: [facultatif] [multiple] [clé inverse]
sous-dom: [facultatif] [multiple] [touche inverse]
dom-net: [facultatif] [multiple] []
remarques: [facultatif] [multiple] []
notifier: [facultatif] [multiple] [touche inverse]
mnt-by: [facultatif] [multiple] [touche inverse]
mnt-lower: [facultatif] [multiple] [touche inverse]
voir: [facultatif] [unique] []
modifié: [obligatoire] [multiple] []
source: [obligatoire] [unique] []

 2- L'attribut "ds-rdata:"

Dans DNSSEC, l'enregistrement de ressource du signataire de délégation (DS) est créé à partir d'un enregistrement de ressource DNSKEY en le comparant à la clé publique. Le parent publie et signe l'enregistrement de ressources DS. L'attribut "ds-rdata:" contient le RDATA des enregistrements de ressources DS liés au domaine (comme indiqué dans l'attribut "domain:").

Ds-rdata: 55555 8 2 CABC3A8AF15E93741BF45096DB1D3451D93B2F541166EA44F2D4781753328CB8

 3- Contrôles de délégation

Lorsque vous soumettez votre mise à jour via MyAFRINIC, le moteur de mise à jour effectuera un certain nombre de vérifications comme le montre l'image ci-dessous.

Organigramme dnssecDSValidation

  • Conserver toutes les vérifications par défaut MyAfrinic fait au verso la délégation
  • La vérification de la syntaxe est effectuée pour s'assurer que la DS saisie est au format correct:
  • keytag: {0-65535}; Algorithm:{3|5|6|7|8|10|12|253|254}; Digest type:{1-3}; Digest:{alphanumeric}
  • La longueur du résumé dépend du type de résumé comme suit: Type 1 (Sha1): 160 bits (40 caractères) / Type 2 (Sha256) ou 3 (gost): 256 bits (64 caractères)
  • Vérifiez s'il existe une clé dans la zone enfant avec le tag de clé dans l'enregistrement DS
  • Vérifiez si l'algorithme de la clé correspond à l'algorithme de clé dans les attributs DS
  • Vérifiez si le résumé correspond à la clé avec la balise correspondante dans la zone enfant
  • Vérifiez s'il existe un RRSIG couvrant la DNSKEY correspondant à la DS soumise et valide.

[1] Actuellement, il n'y a pas de vérification et de validation pour DS soumis via auto-dbm


Plan de communication DNSSEC de l'AFRINIC

Une communication efficace est essentielle au succès de cet effort, la transition entreprise ayant un impact potentiel sur les services RDNS d'AFRINIC. La communication avec les membres d'AFRINIC et la communauté dans son ensemble est importante. La stratégie de déploiement par étapes laisse le temps de communiquer l'impact de ces étapes incrémentielles à l'équipe qui les exécute. Pour que les bonnes décisions soient prises, il est essentiel que les canaux appropriés soient en place pour encourager cette communication.

Les annonces, communiqués et autres informations pertinentes seront publiés sur le site Internet d'AFRINIC. Des mises à jour périodiques de l'état technique seront envoyées à diverses listes de diffusion afin de tenir les communautés techniques et opérationnelles informées des développements.

L'adresse e-mail dnssec-ops [at] AFRINIC.net permettra à toute partie intéressée de communiquer directement avec l'équipe du projet. Une liste de diffusion dnssec-discuss [at] afrinic.net sera utilisée pour discuter du déploiement et des services DNSSEC d'AFRINIC 

Diapositives des ateliers

  1. DNSSEC AFRINIC
  2. DNSSEC-Tutoriel-Crypto-Defs
  3. Présentation-DNSSEC
  4. Présentation courte de la cryptographie

 

 

Print Friendly, PDF & Email
Dernière modification le -