Browsing HTTPS
from the network WAN with the address 18.207.255.67

SSH, OpenSSL, Iptables, RSYNC, RAID, VPN

Security

Prev Next

How to protect a network, transmission, data?

Use a firewall, an anti-virus, back up your system regularly, use a secure disk system for your data. Use secure protocols such as HTTPs, FTPs, IMAPs, POPs, SMTPs

ZW3B
Authentification

Site user blocks : Account info / user rights / summary

Etat du déploiement (2016/12/31) de DNSSEC

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

Informations :

Dates

Publish : : Friday 04 august 2017
Modification : Friday 04 august 2017

433 views

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

89% des zones de domaines de premier niveau (TLD) signées.
- ~ 47% des TLD de code de pays (ccTLD) signés.
Les domaines de second niveau (SLD) varient considérablement:
Plus de 2,5 millions de domaines .nl signés (~ 45%) (Pays-Bas). [1]
~ 88% des zones mesurées en .gov sont signées.
Plus de 50% des domaines .cz (République tchèque) ont été signés.
~ 24% des domaines .br signés (Brésil). [2]
Alors que seulement environ 0,5% des zones dans .com sont signées, ce pourcentage représente ~ 600 000 zones.
Les principaux logiciels et bibliothèques de serveurs authentiques DNS prennent en charge DNSSEC et ont plusieurs années d'expérience de déploiement.
Les outils de gestion ont commencé à être en ligne pour faciliter le déploiement, par exemple, le déploiement et le renversement des clés.
Algorithmes de cryptage et longueurs de clés
- L'écrasante majorité des TLD utilisent RSA / SHA-256 avec des clés de 2048 bits pour la clé de signature (KSK) et des clés de 1024 bits pour la clé de signature de zone (ZSK).
- Un nombre significatif de zones mesurées utilisent encore le SHA-1.
- L'utilisation de ECDSA est de 5% et se développe.
En 2016, la clé de signature de zone (ZSK) pour la zone racine a été migrée avec succès sur une clé RSA de 2048 bits.
2017 sera une année importante pour DNSSEC avec le renversement planifié de la Key Signing Key (KSK) dans la zone racine du DNS.

Validation

Tous les résolveurs récursifs DNS majeurs prennent en charge la validation DNSSEC.
~ 80% des clients demandent des enregistrements de signature numérique DNSSEC dans leurs requêtes DNS (par recherche APNIC).
26% des environnements utilisateurs finaux utilisent des résolveurs de validation DNSSEC, mais transmettent également des requêtes aux résolveurs non valides si la validation entraîne une erreur de validation.
Bien que seulement ~ 14% des clients utilisent exclusivement des résolveurs DNS DNS valant DNSSEC, les chiffres varient considérablement d'une région à l'autre.
- Plus de 50% des clients dans la plupart des pays scandinaves utilisent exclusivement des résolveurs DNS valides par DNSSEC.
Un grand FAI permettant la validation DNSSEC sur ses résolveurs récursifs peut avoir un impact important sur les numéros d'utilisation d'un pays (par exemple, Comcast USA, Claro au Brésil).
Le service public Google Public DNS (PDNS) pour la validation DNSSEC rend la validation disponible à l'échelle mondiale (lorsque la loi l'autorise).

(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 :

Existence d'au moins un DNSKEY RR pour un ZSK et un KSK [12] pour la zone.
Existence de RRSIG RR pour les RRsets dans la zone signée par l'un des ZSK.
Existence des enregistrements RRSIG pour le DNSKEY RRset signé par le KSK si différentes touches sont utilisées pour la fonction ZSK et KSK.

Dans la zone parentale :

Existence d'un enregistrement DS pour KSK de la zone.
Existence d'un RRSIG pour l'enregistrement DS pour la zone signée par le ZSK de la zone parentale.
Chaîne de confiance (DS RR) à la clé de signature racine DNS

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:

Must Supprt EDNS0
Doit avoir les enregistrements RRSIG attachés aux ensembles d'enregistrements de ressource (RRsets)
Ne doit pas avoir de CNAME pour le nom de domaine de la zone
Doit fournir des enregistrements NSEC pour déni d'existence

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:

Génération de clés pour la signature (DNSKEY)
Signatures DNSSEC (RRSIG)
Chaîne de confiance (DS Record)
Génération de réponses NSEC / NSEC3 par serveurs DNS autorisés
Validation des enregistrements DNSSEC par résolveurs.

Zone racine :

Depuis la première signature de la zone racine (2010) jusqu'en 2016, la zone racine a été signée avec RSA / SHA-256 (8) avec une longueur de clé de signature de zone de 1024 bits.
En septembre 2016, Verisign a introduit des clés de signature de zone de 2048 bits dans le cadre de son processus trimestriel de retournement ZSK (à ne pas confondre avec le routage racine KSK). €€ la fin de décembre 2016, ce processus devrait être complété.
La clé de signature de la zone racine a une longueur de 2048 bits et RSA / SHA-256 est utilisé pour la signature. [26]

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] :

BIND (à partir de la version 9.9.x)
NSD (à partir de la version 3.2.11)
PowerDNS (à partir de la version 3.0)
Microsoft DNS (à partir de Windows Server 2016)
Knot DNS (à partir de la version 1.0.4)
YADIFA (à partir de la version 2)

Les serveurs de messagerie supportant DANE incluent :

Prise en charge de Postfix depuis 2014 (3.1 ou ultérieur recommandé)
Prise en charge de Halon depuis 2015
Exim 4.85 (expérimental)
Sendmail - aucun support (patch disponible [32])
Exchange Server - aucun support (solution tierce: XWall / CryptoFilter [33])

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 :

OpenSSL (DANE à partir de 1.1.0) (ECDSA à partir de 0.9.8)
Gnutls (à partir de 3.1.3)

(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:

ICANN (en tant qu'opérateur de fonctions IANA)
Verisign (en tant que responsable de la zone racine)
NTIA (en tant qu'administrateur de la zone racine. Notez que ce rôle a pris fin le 1er octobre 2016.)

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:

Février 2017 : Nouveau KSK publié dans le fichier XML Trust Anchor à http://data.iana.org/root-anchors/
Juillet 2017 : Nouveau KSK publié dans la zone racine dans le cadre de DNSKEY RRset signé par l'ancien KSK.
Septembre 2017 : Augmentation de la taille pour la réponse DNSKEY des serveurs de noms racine.

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

Octobre 2017 : Commencez à signer la zone racine DNSKEY RRset avec le nouveau KSK (événement de renversement réel).
Janvier 2018 : Le vieux KSK est publié dans la zone racine DNSKEY RRset avec le jeu de bits révoqué. DNSKEY RRset comprend un nouveau KSK.
Mars 2018 : Supprimez l'ancien KSK de la zone racine.
Mai / Août 2018 : Ancien KSK et toutes les sauvegardes supprimées

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 :

InterNet Society : State of DNSSEC Deployment 2016 (31 Dec 2016)
- Date: 31 Dec 2016
- Document Type: Reports
- Tags: DANE , DNS, DNS Security, DNSSEC

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 ou supérieur (compilé avec le support RSASHA256)
L'ancre DNS Root Trust (the DNS Root Trust Anchor)

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.