DNSSEC

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

Les Zones incluent

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
  • Signer ces zones.
  • Publier l'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é dans les zones RDNS de l'AFRINIC et aux membres de publier des enregistrements DS pour construire la chaîne de confiance pour leurs zones RDNS. Le déploiement DNSSEC est un projet coordonné par le 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 pour un déploiement soigneusement progressif de DNSSEC à l’AFRINIC.

Plan de déploiement

Une fois la phase de test terminée, l'AFRINIC intégrera le signataire dans le système de provisioning 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

  • Installez les outils (Opendnssec, NSD, BIND, DSC, etc.)

  • Générer des clés pour les zones - KSK RSA 2048 / ZSK RSA 1024

  • Obtenir la zone non signée dans OpenDNSSEC et signer

  • Publiez les zones sous les serveurs DNS locaux

  • Interrogez et analysez les tailles de réponse sur UDP et TCP

  • Validation à l'aide de clés en tant que clés trusted

  • Plannifier des rollover clés et urgents

  • 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. AFRIQUE évaluer le fonctionnement du signataire et le système de provisionnement à à jour. Le DNSSEC interroge les zones signées Contrôle de cohérence pour le contenu des zones: DNSSEC DNSSEC interroge les zones signées


Phase 2 - Publier les zones signées

Avec une étape précédente réussie, la prochaine étape sera publiée dans les zones signées au lieu de zones non signées. Dans cette phase, le système d'approvisionnement DNS inverse commence à publier les 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.

Test

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 Rollback 

  1. Le rollback de la phase où l'AFRiNIC publie des zones signées sans DS dans les zones parentes est la suivante:
  2. Une fenêtre de maintenance pour l'annulation est ouverte.
  3. Avis de la maintenance imminente, avec une description technique du changement, sera envoyé à la communauté.
  4. Au cours de la fenêtre de maintenance, l'AFRINIC commencera à desservir une zone non signée, dépouillée de toutes les informations DNSSEC.
  5. La série SOA augmente afin de déclencher la distribution de la zone non signée.
  6. Un rapport technique détaillé sur les circonstances ayant conduit à la restauration et l'exécution de la restauration elle-même sont envoyés à la communauté.

Phase 3 -  Publication DS dans les zones parent 

Avec la publication des zones signées complétées, les zones RDNS AFRINIC ne sont pas encore sécurisées par 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.

L'approvisionnement 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 normales d'AFRINIC. La surveillance et la mesure du rendement seront des activités constantes.

Tests

  • Requête pour l'enregistrement de tout ip6.arpa et in-addr.arpa dans les servers
  • DNSSEC validation of signed RRs in AFRINIC signed zones with root key as trusted key
  • Validation DNSSEC des RR signés dans les zones signées AFRINIC avec clé racine comme clé de confiance

Plan Rollback 

Le rollback de la phase où l'AFRINIC publie des zones signées avec DS dans les zones parentes est la suivante:

  1. Une fenêtre de maintenance window du rollback est ouvert.
  2. Avis des circonstances et les mesures correctives prévues, avec des détails techniques, seront envoyés à la communauté.

  3. AFRINIC exécutera un rollover KSK en urgence pour supprimer les enregistrements DS des zones parents. La communication publique avec la communauté se poursuivra, dans le but de s'assurer que les nouvelles de la situation et les actions entreprises sont communiquées à un public aussi large que possible.
  4. Suivant le délai de publication approprié, tel que spécifié par le DPS, l'AFRINIC exécutera une transition vers des zones non signées comme décrit dans la phase où l'AFRINIC publie des zones signées sans DS dans les zones parents.

Publication des enregistrements DS pour nos membres

Tests

  • Gestion des enregistrements DS et leurs signatures
  • Chaine de confiance pour la validation DNSSEC depuis la racine jusqu'au zone enfant (avec publications des enregistrements DS)
  • Conclusions et leçons

Enonce de pratique DNSSEC - DPS (en anglais)

Zone Signing parameters - Key Lengths and Algorithms

  • Key Signing Key: We use a key length of 2048 bits with RSA as the generation algorithm.
  • Zone Signing Key: We use a key length of 1024 bits with RSA as the generation algorithm.
  • Authenticated Denial of Existence: Authenticated denial of existence will be provided through the use of NSEC records as specified in RFC 4034.
  • Signature Format: Our signatures are created with the SHA2-256 hash using RSA.
  • Zone Signing Key Roll-over: We will roll the ZSK on a monthly basis with a pre-publishing scheme as described in RFC 4641, section 4.2.1.1.
  • Key Signing Key Roll-over: We will roll the KSK on a yearly basis with a double-signing scheme as described in RFC 4641, section 4.2.1.2.
  • Signature Life-time and Re-signing Frequency: We re-sign our zones once a new zone are generated with a signature lifetime of 15 days.

Resource Records Time-to-live - Record type TTL

  • DNSKEY: Equal to the TTL used for the SOA record
  • NSEC: Equal to the minimum field of the SOA record
  • RRSIG: Equal to the lowest TTL of the record set covered
  • DS: Equal to the TTL used for the NS record

DNSSEC delegations

Procedure for Requesting DNSSEC Delegations (Date: April 2012 - Version:1.0)

This section describes how to request DNSSEC Delegations. It is in addition to the existing procedure for requesting reverse delegations.

Please note that until further notice from AfriNIC, DS RECORDS will not be visible in the DNS. Watch out for upcoming news from us.

1 - The DOMAIN Object

You can request reverse delegation by submitting domain objects via auto-dbm(e-mail) or via MyAFRINIC, which is the recommended method[1]. DNSSEC will not mean any change to the existing authorization mechanisms. To enable the DNSSEC delegation, the domain object now includes a "ds-rdata:" attribute.

domain: [mandatory] [single] [primary/look-up key]
descr: [mandatory] [multiple] [ ]
org: [optional] [multiple] [inverse key]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
zone-c: [mandatory] [multiple] [inverse key]
nserver: [optional] [multiple] [inverse key]
ds-rdata: [optional] [multiple] [inverse key]
sub-dom: [optional] [multiple] [inverse key]
dom-net: [optional] [multiple] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [optional] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
refer: [optional] [single] [ ]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

 2- The "ds-rdata:" Attribute

In DNSSEC, the Delegation Signer (DS) Resource Record is created from a DNSKEY Resource Record by comparing it with the public key. The parent publishes and signs the DS Resource Record. The "ds-rdata:" attribute contains the RDATA of the DS Resource Records related to the domain (as shown in the "domain:" attribute).

Ds-rdata: 55555 8 2 CABC3A8AF15E93741BF45096DB1D3451D93B2F541166EA44F2D4781753328CB8

 3- Delegation Checks

When you submit your update through MyAFRINIC, the update engine will perform a number of check as shown by the picture below.

dnssec FlowchartDSValidation

  • Keep all the default checks MyAfrinic does on the reverse delegation
  • Syntax check is done to ensure the DS entered is in the correct format:
  • keytag: {0-65535}; Algorithm:{3|5|6|7|8|10|12|253|254}; Digest type:{1-3}; Digest:{alphanumeric}
  • Digest length depends on digest type as follows: Type 1 (Sha1): 160 bit (40 Characters) / Type 2 (Sha256) or 3(gost): 256 bit (64 Characters)
  • Check if a key exists in child zone with the key tag in the DS record
  • Check if the algorithm of the key matches the key algorithm in the DS attributes
  • Check if the digest matches the Key with the corresponding tag in child zone
  • Check if there an RRSIG covering the DNSKEY corresponding to the DS submitted and is valid.

[1] Currently there is no check and validation for DS submitted through auto-dbm


Plan de communication DNSSEC d'AFRINIC

Une communication efficace est essentielle pour le 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 permet de communiquer l'heure de 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 web 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 au courant des développements. L'adresse e-mail dnssec-ops [at]afrinic.net permettra à toute personne 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

Slides d'atelier

  1. DNSSEC AFRINIC
  2. DNSSEC-Tutorial-Crypto-Defs
  3. Introduction-DNSSEC
  4. Short-Cryptography-Overview

 

 

Date de modification