ZW3B :-: API Client * Contents * Docs by LAB3W.ORJ

Translate this page

Name : BETA-TESTERS

Project name : ZW3B-API-BETA-TESTERS

Authorized. - 200 - Client API Name and Origin Wildcard OK

¿Comment? 'Ou' ¿Que faire?, OS GNU/Linux, Sécurité, Etat du déploiement (2016/12/31) de DNSSEC

Domain Name System Security (DNSSEC) : Déploiement rapport du 31 Dec 2016

Author : O.Romain.Jaillet-ramey

Cette page est en cours de rédaction...

Ce rapport fournit un aperçu de l'état de déploiement de DNSSEC à la fin de 2016.

Signature de domaines avec DNSSEC

Points forts

Validation

(3) État de la signature DNSSEC

La signature des zones DNS et la chaîne de confiance associée à la racine est le coeur de DNSSEC, permettant la validation. Cette section ne traite pas tous les cas d'angle (par exemple, avoir un sous-ensemble de RRsets signé, chaîne de confiance non enracinée dans la zone racine DNS). La nature hiérarchique du DNS passe à DNSSEC où la chaîne de confiance requiert une signature valide des zones de la zone cible jusqu'à la racine. Si une zone de niveau supérieur n'est pas signée, ses zones enfants ne seront pas en mesure d'établir une chaîne de confiance même s'ils sont signés.

Aux fins du présent document, une zone est considérée comme signée par DNSSEC si les conditions suivantes sont remplies:

Dans la zone :
Dans la zone parentale :

En 2010, la zone racine DNS a été signée permettant une chaîne de confiance ancrée dans la racine DNS. Cela a permis aux opérateurs TLD de commencer à signer leurs zones et de placer leurs enregistrements DS dans la racine. Cela, à son tour, a permis aux opérateurs de domaine de second niveau de commencer à signer leurs zones, et ainsi de suite dans la chaîne.

�€ compter de 2012, ICANN a demandé des applications pour les nouveaux TLD génériques (gTLD) [13] pour soutenir DNSSEC dès le début. L'ICANN a également mis à jour son Accord d'agrément de registraire en 2013 afin d'obliger les bureaux d'enregistrement à permettre aux clients d'utiliser DNSSEC (s'il est pris en charge par le Registre sous-jacent). Ces actions ont permis à un nombre accru d'opérateurs de zone de signer leurs zones avec une chaîne de confiance à la racine DNS. Notez que l'exigence de 2012 sur les nouveaux gTLD à l'appui de DNSSEC ne s'applique pas aux ccTLD. Ni l'exigence 2012 ni l'exigence 2013 ne s'appliquent aux gTLD précédents ou aux registres fonctionnant selon des accords antérieurs. Cela aide à expliquer le saut dans la signature de la zone de TLD en 2013 et la disparité entre les gTLD et les ccTLD dans la signature de leurs zones. Bien que les accords ci-dessus ne soient pas requis, les gTLD créés avant 2012 ont presque tous signé leurs zones (deux exceptions étant .tel et .aero).

La signature des zones de domaine de second niveau (SLD) (et leurs zones enfants) est généralement laissée aux opérateurs de la zone.

(3.2) Domaines de second niveau (SLD)

Les statistiques pour la signature des SLD (et ci-dessous) sont plus difficiles à suivre avec la même précision et la même cohérence que les TLD, en raison du grand nombre de zones et de leur dynamique. Les différents efforts pour mesurer l'état de la signature des zones sous le niveau TLD peuvent afficher différents nombres en fonction des critères qu'ils utilisent, de leur sondage, de l'intervalle d'interrogation et du temps, etc.

Verisign Labs�€� SecSpider mesure un ensemble d'environ 2 à 2,5 millions de zones collectées à partir de différentes sources (par exemple, données volontaires, zones explorées par des sondages, des zones de randonnée via NSEC).

Le tableau 5 montre les chiffres actuels. [16]

1.949.282 : Zones surveillées
1 629 021 : zones habilitées DNSSEC
1 621 499 : zones utilisent les KSK et les ZSK
1 621 499 : Zones desservent des clés révoquées
1 525 050 : zones vérifiées DNSSEC
1 612 034 : Zone de production DNSSEC activée

Tableau 5 - Zones signées DNSSEC

L'effort SecSpider considère une zone sécurisée si elle répond aux critères suivants:

La figure 8 illustre la croissance des zones DNSSEC depuis 2005, mesurée par l'effort de SecSpider.

Figure 8 - SecSpider Measured Growth of DNSSEC Deployment

(3.3) Algorithmes et tailles de clés

DNSSEC dépend des algorithmes cryptographiques pour les opérations suivantes:

Zone racine :
TLD :

Le tableau 7 illustre la répartition des algorithmes et des longueurs de clés pour les clés de signature de TLD. L'écrasante majorité (~ 99%) des TLD utilisent des clés de 2048 bits. ~ 75% des TLD utilisent RSA / SHA-256 pour la signature suivie de RSA / SHA-1.

Le tableau 8 illustre la répartition des algorithmes et des longueurs de clés pour les clés de signature de la zone TLD. Les algorithmes utilisés suivent approximativement les clés de signature; Cependant, la longueur de clé dominante pour les ZSK est de 1024 bits suivie de 1280 bits. Comme les ZSK sont roulés plus fréquemment, la pratique générale consiste à utiliser une longueur de clé plus courte que pour le KSK.

(4) État de déploiement de DNS-Based Authentication of Named Entities (DANE)

Les exigences pour l'authentification par DNS des entités nommées (DANE) ont été publiées en 2011 [RFC6394] avec des enregistrements TLSA définis en 2012 [RFC6698] et des directives opérationnelles en 2015 [RFC7671]. DANE définit une façon d'utiliser l'infrastructure DNSSEC pour stocker et signer des clés et des certificats utilisés par TLS, ainsi que des données de clés publiques contraignantes à des noms DNS. Alors que le déploiement de DANE a été lent, il a récupéré un support récent, en particulier pour sécuriser les transferts entre les serveurs de messagerie [RFC7672]. Cette croissance récente se reflète dans la croissance récente du nombre de zones déployant TLSA mesurée par Verisign Labs (voir la figure 14).

Verisign Labs fournit également une répartition des services pour lesquels il existe un enregistrement TLSA :

Number of Zones Service (Port number)
732 : Secure SMTP (Port 465)
235 : Secure POP3 (Port 995)
897 : SMTP with STARTTLS (Port 587)
63 : Alternate SMTP (Port 2525)
5,980 : HTTPS (Port 443)
3,931 : SMTP (Port 25)
129 : POP3 (Port 110)
528 : Secure IMAP (Port 993)
348 : IMAP (Port 143)

DANE (similaire à DNSSEC) nécessite l'assistance de serveurs DNS pour contenir les enregistrements TLSA et les clients (y compris les résolveurs) pour utiliser les enregistrements TLSA.

Les serveurs DNS supportant DANE (enregistrements TLSA) comprennent [31] :
Les serveurs de messagerie supportant DANE incluent :
Navigateurs Web :

Aucun navigateur Web majeur ne supporte DANE, bien que cz.nic ait développé un complément de navigateur DNSSEC / TLSA Validator.

Bibliothèques :

(5) Root Key Signing Key (KSK) Rollover

Alors que le renversement ZSK de la racine est un événement trimestriel régulier, la pratique de l'ICANN pour le renversement KSK racine est tous les 5 ans, ou selon les besoins. [40] En raison de son potentiel de perturbation, les plans KSK Rollover sont soigneusement développés par Root Zone Management Partners:

Le premier processus de survoltage de la racine KSK a commencé le 27 octobre 2016 lorsque ICANN a généré le nouveau KSK [41].

Le processus de renversement se poursuivra jusqu'en 2018, lorsque l'ancien KSK et les sauvegardes devraient être supprimés de tous les systèmes.

Le projet de calendrier pour les étapes restantes du renversement est:

Les serveurs de noms racine comprennent l'ancien et le nouveau KKEK DNSKEY dans les réponses.

Le nouveau KSK maintiendra le même algorithme (RSA / SHA-256) et la longueur de la clé (2048 bits) que le précédent KSK.

Pour plus d'informations, consultez le site Web de la zone racine KSK Rollover de l'ICANN.

7. Conclusion

Comme la zone racine DNS a été signée en 2010, le déploiement de DNSSEC a fait des progrès constants. La quasi-totalité des gTLD sont maintenant signés et environ la moitié des ccTLD, dont plus de 90% des ccTLD des pays de l'OCDE. Les progrès entre les domaines de deuxième niveau ont été plus lents à l'échelle mondiale, mais avec des domaines de plus grand déploiement en fonction du TLD et de la région (par exemple, .nl, .cz, .se, .gov). La plupart des principaux logiciels serveurs autorisés supporte désormais DNSSEC avec de meilleurs outils de gestion du déploiement et de l'exploitation.

Du côté du résolveur, tous les logiciels de résolution majeurs prennent en charge la validation DNSSEC. Les études d'APNIC ont montré que les résolveurs utilisés par plus de 80% des clients dans leur étude demandent déjà des enregistrements DNSSEC, même s'ils n'ont pas activé la validation. Comme l'illustrent Claro et Comcast, un seul grand fournisseur qui active la validation pour ses clients peut modifier considérablement le niveau de validation dans un pays.

Un exemple de déploiement d'un service de déploiement dans une communauté particulière est l'utilisation de DANE pour sécuriser le courrier électronique entre les serveurs. La communauté de courrier électronique allemande a pris l'initiative d'utiliser DANE pour sécuriser la communication entre les fournisseurs de courrier électronique et le support se propage à d'autres fournisseurs européens.

Le développement continue d'évoluer au fur et à mesure que DNSSEC est plus largement déployé et gagne plus d'expérience opérationnelle et que les attaques basées sur DNS continuent d'être préoccupantes (par exemple, les attaques d'amplification, DNSChanger). �€ titre d'exemple, ECDSA a été proposé comme moyen de réduire les attaques d'amplification et d'utiliser la fonctionnalité intégrée de DNSSEC pour identifier les domaines inexistants via les enregistrements NSEC pour mettre fin au trafic d'attaque au résolveur. [AGGNSEC] En outre, des travaux sont en cours pour Protéger le lien entre le client et le résolveur de validation.

Nous encourageons tous les lecteurs de ce rapport, au minimum, à déployer la validation DNSSEC pour commencer à vérifier les signatures, puis à comprendre leurs options pour signer leurs domaines. Ensemble, nous pouvons créer un DNS plus fort et plus fiable.

Veuillez télécharger le rapport complet (ISOC-State-of-DNSSEC-Deployment-2016-v1 ) pour afficher toutes les informations, les graphiques et les conclusions.

Rapport (US) de IETF :

Validation

Symptôme: Maintenant (à partir du 15 juillet 2010), la zone DNS racine est signée DNSSEC.
Problème: Comment configurer le serveur DNS BIND pour résoudre le serveur DNS pour utiliser les informations DNSSEC et valider les requêtes DNS ?

Exigences :

BIND 9.6.2 (and all 9.6 Version above 9.6.2)

Script avec 11 lignes

001trusted-keys {
002  . 257 3 8 
003  "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
004     FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
005     bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
006     X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
007     W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
008     Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
009     QxA+Uk1ihz0=";
010
011};
Retirer les numéros de lignes

Script avec 3 lignes

001options 
002  dnssec-validation yes;
003};
Retirer les numéros de lignes

BIND 9.7.x

Starting with BIND 9.7.0, the trusted keys can be managed by RFC 5011 (RFC 5011 - Automated Updates of DNS Security (DNSSEC) Trust Anchors)

Script avec 10 lignes

001managed-keys {
002   "." initial-key 257 3 8
003    "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
004     FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
005     bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
006     X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
007     W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
008     Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
009     QxA+Uk1ihz0=";
010};
Retirer les numéros de lignes

Verification manuelle des clefs

Vous ne devriez jamais avoir confiance aveugle sur les clés cryptographiques publiées sur des sites Web comme celui-ci (l'éditeur de la page Web aurait pu créer une faute de frappe, le serveur hébergeant le site pourrait être piraté ...).

Pour vérifier le matériel de la clé, utilisez la séquence ci-dessous :

dig dnskey . @a.root-servers.net +noall +answer > root-zone-dnssec.key

Cette commande vous donnera les zones racines DNSKEY dans le fichier "root-zone-dnssec.key". Comparez la clé dans le fichier avec le matériel de clé dans votre fichier de configuration BIND. Il devrait correspondre.

dnssec-dsfromkey -2 root-zone-dnssec.key

Cette commande (vous avez besoin de "dnssec-dsfromkey" version 9.6.2 ou supérieure) générera l'enregistrement "DS" du signataire de délégation pour DNSKEY à partir de la zone racine. Le DS Record est un hash sur DNSKEY. Comparez cet enregistrement DS avec le hash disponible sur le site officiel IANA (http://data.iana.org/root-anchors )

Le hash que vous trouvez dans le (s) fichier (s) pour l'ancrage du site IANA doit correspondre aux données d'enregistrement DS générées à partir des zones racines DNSKEY.

Source :

Liens Web :

Liens InterNet Society :

Liens DNSSEC :