Résumé

Dans cet article, nous discutons de l’implémentation de DNSEC (Extensions de sécurité du système de noms de domaine) par le service public DNS de Google. DNSSEC est une technologie qui ajoute des signatures cryptographiques sécurisées dans le DNS pour atténuer les vulnérabilités et assurer l’intégrité de la résolution DNS. Alors que DNSSEC existe depuis de nombreuses années, son adoption a été relativement faible. Le DNS public de Google effectue désormais la validation DNSSEC pour toutes les requêtes par défaut, améliorant la sécurité de son service de résolution DNS.

Points clés:

1. DNSSEC est une technologie critique qui ajoute des signatures cryptographiques au DNS pour protéger contre les attaques DNS.
2. DNSSEC assure l’intégrité et l’authenticité de la résolution DNS, empêchant les utilisateurs d’être redirigées vers des sites Web malveillants.
3. Le DNS public de Google est un résolveur DNS largement utilisé qui effectue désormais la validation DNSSEC par défaut pour toutes les requêtes.
4. En mettant en œuvre le DNSEC, le DNS public de Google améliore la sécurité et la fiabilité de son service de résolution DNS.
5. L’adoption du DNSSEC a été lente en raison de divers facteurs, notamment le manque de motivation parmi les administrateurs de noms de domaine et les auteurs de navigateur.
6. Des services comme SecSpider suivent la progression du déploiement DNSSEC en comptant le nombre de noms de domaine avec des informations d’identification DNSSEC.
7. APNIC Labs a effectué des mesures pour quantifier l’étendue de la validation DNSSEC par les applications utilisateur final.
8. Dans leurs mesures initiales, environ 9% des clients semblaient utiliser des résolveurs DNS qui ont effectué la validation DNSSEC.
9. Une mesure plus récente a montré qu’environ 1.6% des clients ont exclusivement utilisé des résolveurs DNS qui ont systématiquement effectué la validation DNSSEC.
10. Ces résultats mettent en évidence les niveaux relativement faibles d’adoption du DNSSEC et la nécessité d’une sensibilisation et d’un déploiement accrus de la technologie.

Questions uniques:

1. Pourquoi le DNSSEC est-il important pour la sécurité de la résolution DNS?
   DNSSEC ajoute des signatures cryptographiques au DNS, assurant l’intégrité et l’authenticité de la résolution DNS. Sans DNSEC, les utilisateurs sont vulnérables aux attaques DNS où leurs applications sont dirigées vers des sites Web malveillants au lieu de la destination prévue.
2. Quelle est la signification de la mise en œuvre du DNS publique de Google par défaut de la validation DNSEC par défaut?
   Le DNS public de Google est un résolveur DNS largement utilisé, et sa mise en œuvre de la validation DNSSEC améliore par défaut la sécurité et la fiabilité de son service de résolution DNS. Cela garantit que les utilisateurs sont protégés contre les attaques DNS et peuvent avoir plus de confiance dans la précision des résolutions DNS fournies par le DNS public de Google.
3. Pourquoi l’adoption de DNSSEC a-t-elle été lente?
   L’adoption de DNSSEC a été lente en raison de divers facteurs. Un facteur important est le manque de motivation parmi les administrateurs du nom de domaine et les auteurs de navigateur pour signer des noms de domaine avec des informations d’identification DNSSEC. De plus, les faibles niveaux de déploiement DNSSEC le rendent moins convaincant pour les outils clients afin d’incorporer la validation DNSSEC dans la résolution DNS.
4. Quel est le rôle des services comme SecSpider dans le suivi du déploiement DNSSEC?
   Des services comme SecSpider suivent la progression du déploiement DNSSEC en comptant le nombre de noms de domaine qui incluent les informations d’identification DNSSEC. Cela permet de mesurer dans quelle mesure les noms de domaine sont signés à l’aide de signatures DNSSEC et donne un aperçu de l’adoption globale du DNSSEC.
5. Comment les laboratoires apniques ont-ils quantifier l’étendue de la validation DNSSEC par les applications utilisateur final?
   APNIC Labs a effectué des mesures pour déterminer dans quelle mesure les clients utilisent la validation DNSSEC en conjonction avec la résolution du nom. Ces mesures consistaient à observer le journal de requête DNS dans les serveurs de noms faisant autorité et à analyser la séquence et les horaires des requêtes DNS pour déduire les capacités DNSEC des résolveurs DNS visibles.
6. Quels ont été les résultats des mesures initiales d’Apnic Labs?
   Les mesures initiales d’Apnic Labs ont montré qu’environ 9% des clients semblaient utiliser des résolveurs DNS qui effectuaient une certaine forme de validation DNSSEC.
7. Quelles limites ont été observées dans l’approche de mesure initiale?
   L’approche de mesure initiale a utilisé la génération dynamique d’étiquettes DNS uniques et une chaîne de signature DNSSEC partagée. Cette approche reposait sur la mise en cache DNS Resolver, ce qui a affecté la précision des résultats. Des mesures ultérieures ont été effectuées pour répondre à ces limitations.
8. Quel a été le résultat de la mesure plus récente par les laboratoires apniques?
   La mesure la plus récente a montré qu’environ 1.6% des clients ont exclusivement utilisé des résolveurs DNS qui ont systématiquement effectué la validation DNSSEC. Cela indique que l’adoption de la validation DNSSEC par les applications utilisateur final est encore relativement faible.
9. Qu’est-ce que le faible niveau d’adoption DNSSEC implique?
   Le faible niveau d’adoption DNSSEC suggère la nécessité d’une sensibilisation et d’un déploiement accrus de DNSEC. Sans adoption plus large, les avantages du DNSSEC, tels que le nom de domaine sécurisé à la cartographie d’adresses IP et la disposition des clés du TLS publique à travers des technologies comme Dane, restent sous-utilisées.
10. Quel est l’impact potentiel de l’adoption plus large du DNSSEC?
    L’adoption plus large du DNSSEC améliorerait la sécurité et la fiabilité de la résolution DNS pour tous les utilisateurs. Cela réduirait le risque d’attaques basées sur DNS et fournirait une cartographie plus sécurisée entre les noms de domaine et les adresses IP, renforçant la sécurité globale d’Internet.

Réponses:

1. DNSSEC est important pour la sécurité de la résolution DNS parce que
   DNSSEC ajoute des signatures cryptographiques au DNS, assurant l’intégrité et l’authenticité de la résolution DNS. Sans DNSEC, les utilisateurs sont vulnérables aux attaques DNS telles que l’usurpation DNS ou l’intoxication au cache, où leurs applications sont redirigées vers des sites Web malveillants au lieu de la destination prévue. En validant les réponses DNS à l’aide de DNSSEC, les utilisateurs peuvent avoir plus de confiance que les adresses IP résolues sont en effet associées aux noms de domaine prévus.
2. L’importance du DNS publique de Google implémentant la validation DNSSEC par défaut est
   Le DNS public de Google est l’un des résolveurs DNS les plus utilisés, et sa mise en œuvre de la validation DNSSEC améliore la sécurité et la fiabilité de son service de résolution DNS. Avec la validation DNSSEC, le DNS public de Google peut vérifier l’authenticité et l’intégrité des réponses DNS, protégeant les utilisateurs contre les attaques basées sur le DNS. Cette validation par défaut garantit que toutes les requêtes faites via le DNS publique de Google sont soumises à des contrôles DNSSEC, offrant une couche supplémentaire de sécurité pour les utilisateurs.
3. La lente adoption du DNSSEC peut être attribuée à
   Divers facteurs contribuent à la lente adoption du DNSSEC. Un facteur est le manque de motivation parmi les administrateurs de noms de domaine pour signer leurs noms de domaine avec des informations d’identification DNSSEC. L’effort et la complexité supplémentaire impliqués dans la gestion des clés et des signatures DNSEC peuvent décourager les administrateurs de domaine de l’adoption de DNSSEC. En outre, les auteurs de navigateur peuvent avoir hésité à implémenter la validation DNSSEC en raison du nombre limité de noms de domaine signés. La faible demande de validation DNSSEC des utilisateurs pourrait également influencer la motivation à déployer des outils clients qui prennent en charge DNSSEC. Ces facteurs créent un cycle de faible adoption et des incitations limitées pour un déploiement ultérieur.
4. Des services comme SecSpider Track DNSSEC Déplacement par
   Des services tels que SecSpider surveillent la progression du déploiement DNSSEC en comptant le nombre de noms de domaine qui incluent les informations d’identification DNSSEC. En numérisant régulièrement les zones DNS et en analysant les signatures DNSSEC, SecSpider peut fournir des informations sur la prévalence des noms de domaine signés et l’adoption globale du DNSSEC. Ce suivi aide à sensibiliser les taux d’adoption du DNSSEC et encourage les administrateurs de noms de domaine à envisager la mise en œuvre du DNSSEC pour leurs domaines.
5. Les laboratoires apniques ont quantifié l’étendue de la validation DNSSEC par
   APNIC Labs a quantifié l’étendue de la validation DNSSEC en effectuant des mesures sur les applications utilisateur final. Ces mesures consistaient à observer le journal de requête DNS dans les serveurs de noms faisant autorité et à analyser la séquence et les horaires des requêtes DNS. En examinant les réponses et les modèles de synchronisation, les laboratoires apniques pourraient déduire si les résolveurs DNS utilisés par les utilisateurs finaux ont effectué une validation DNSSEC. Ces données ont fourni des informations sur la proportion d’applications utilisateur final qui utilisent activement la validation DNSSEC pendant la résolution du nom.
6. Dans les mesures initiales d’Apnic Labs, environ 9% des clients semblaient
   Dans les mesures initiales d’Apnic Labs, environ 9% des clients semblaient utiliser des résolveurs DNS qui ont effectué une certaine forme de validation DNSSEC. Cette constatation suggère un niveau modeste d’adoption DNSSEC parmi une partie des applications utilisateur final. Bien que 9% puissent être considérés comme un chiffre relativement bas, cela indique qu’un nombre important d’utilisateurs ou d’organisations ont choisi d’activer la validation DNSSEC, priorisant la sécurité améliorée qu’il offre.
7. Les limitations observées dans l’approche de mesure initiale par les laboratoires apniques étaient
   L’approche de mesure initiale utilisée par les laboratoires apniques avait certaines limites. Une limitation était la dépendance à la mise en cache DNS Resolver. L’expérience impliquait une campagne publicitaire en ligne qui a inscrit des millions de clients finaux pour effectuer des tâches de récupération d’objets DNS. La chaîne de signature DNSSEC partagée à travers l’expérience signifiait qu’une fois qu’un résolveur DNS a récupéré les enregistrements de ressources DNSSEC (RRS), des requêtes ultérieures pour les mêmes RR DNSSEC ont été servies à partir du cache local du résolveur. Ce comportement de mise en cache a rendu difficile d’évaluer avec précision les capacités réelles DNSSEC de chaque résolveur et a entraîné une surestimation potentielle de l’adoption du DNSSEC.
8. Dans une mesure plus récente, environ 1.6% des clients ont exclusivement utilisé des résolveurs DNS
   Dans une mesure plus récente par les laboratoires apniques, environ 1.6% des clients ont exclusivement utilisé des résolveurs DNS qui ont systématiquement effectué la validation DNSSEC. Cela indique que l’adoption de la validation DNSSEC par les applications utilisateur final est encore relativement faible. Bien qu’il y ait eu une augmentation mineure par rapport aux mesures précédentes, il met en évidence la nécessité d’une adoption plus généralisée du DNSSEC parmi les résolveurs DNS et les applications utilisateur final.
9. Le faible niveau d’adoption DNSSEC implique que
   Le faible niveau d’adoption de DNSSEC implique que le plein potentiel du DNSSEC n’a pas encore été réalisé. Avec seulement un petit pourcentage de clients et d’administrateurs de noms de domaine activement à l’aide de DNSSEC, les avantages du nom de domaine sécurisé à la cartographie d’adresses IP et de l’approvisionnement public de clés TLS par le biais de technologies comme Dane restent sous-utilisées. L’adoption plus large du DNSSEC contribuerait à une infrastructure Internet plus sécurisée en réduisant le risque d’attaques basées sur le DNS et en assurant des communications sécurisées entre les clients et les serveurs.
10. L’impact potentiel de l’adoption plus large du DNSSEC comprend
    L’adoption plus large du DNSSEC améliorerait considérablement la sécurité et la fiabilité de la résolution DNS pour tous les utilisateurs. Cela réduirait le risque d’attaques basées sur le DNS telles que l’empoisonnement du cache DNS et le détournement du DNS, protégeant les utilisateurs contre la rediffusion vers des sites Web malveillants. De plus, DNSSEC fournit un mappage sécurisé entre les noms de domaine et les adresses IP, garantissant que les utilisateurs se connectent aux serveurs prévus. Cela renforce la sécurité globale d’Internet et favorise la confiance dans les interactions en ligne.

Confirmé – Google’S public DNS effectue désormais une validation DNSSEC pour toutes les requêtes par défaut

Google a beaucoup investi dans la sécurité informatique et, je pense, a fait un travail décent. Tous les services sont par défaut TLS, l’identité et l’autorisation sont bien traitées.

DNSSEC et Google’S Service DNS public

Le système de noms de domaine, ou DNS, est un composant critique, mais quelque peu invisible d’Internet. Le monde d’Internet est un monde de symboles et de mots. Nous invoquons des applications pour interagir avec des services tels que Google, Facebook et Twitter, et l’interaction est formulée dans des symboles lisibles par l’homme. Mais l’interaction avec le réseau est entièrement dans un format binaire. Donc, notre vision symbolique d’un service, comme www.Google.com, doit être traduit dans une adresse de protocole, comme 74.125.237.144. La cartographie des symboles aux adresses de protocole est l’une des fonctions critiques du DNS. Nous comptons non seulement sur la présence continue du DNS, mais aussi son fonctionnement correct. Entrer Mybank.com.L’UA dans un navigateur ne garantit pas nécessairement que votre interaction sera avec votre service prévu. L’un des vecteurs d’attaque les plus insidieux pour Internet est de corrompre délibérément le fonctionnement du DNS, et ainsi dupe l’application de l’utilisateur pour ouvrir une session avec la mauvaise destination. La réponse la plus robuste que nous avons réussi à concevoir pour atténuer cette vulnérabilité de longue date dans le DNS a été d’ajouter des signatures cryptographiques sécurisées dans le DNS, en utilisant une technologie appelée DNSSEC. Mais utilisons-nous DNSSEC aujourd’hui’s Internet?

L’histoire de DNSSEC présente de fortes similitudes avec celle de l’IPv6. Comme IPv6, DNSSEC existe depuis de nombreuses années, mais sa langage. Comme IPv6, le DNSSEC est le plus efficace lorsque tout le monde l’utilise, et les rendements marginaux de l’adoption fragmentaire sont extrêmement faibles. Et comme IPv6, les niveaux relativement faibles de déploiement et d’utilisation du DNSSEC ne reflètent pas l’effort de longue date pour soulever la visibilité de la technologie et des efforts concertés pour faire connaître les avantages clairs à long terme dans l’utilisation de cette technologie.

Même lorsque les dangers insidieux d’une attaque contre l’intégrité du DNS et l’infrastructure de certificat de nom de domaine largement utilisé ont été clairement démontrés dans l’incident de Diginotar en 2011, les avantages potentiels de l’utilisation de DNSSEC et l’adoption d’une liaison sécurisée du nom de domaine à l’adresse IP par le biais d’identification numérique placée dans un cadre DNS sécurisé ont échoué à la traction dans Internet sur Internet. À certains égards, il y a une forme de blocage mutuel en cours: Bien que si peu de clients utilisent le DNSSEC, il semble y avoir peu de motivation de la part des administrateurs de noms de domaine pour utiliser DNSSEC pour signer les noms de domaine. Et bien qu’il y ait si peu de noms de domaine signés, il y a peu de motivation à déployer des outils clients pour incorporer la validation DNSSEC dans la résolution DNS. Et bien que les noms de domaine ne soient largement pas signés et que peu de clients utilisent DNSSEC pour valider les résultats de résolution du nom DNS, il n’y a aucune motivation pour les administrateurs de domaine ou les auteurs de navigateur pour utiliser la technologie Dane pour fournir une forme sécurisée de mappage à partir d’un nom de domaine à l’adresse IP et à une clé TLS publique.

Pouvons-nous quantifier dans quelle mesure DNSSEC a été déployée et utilisée aujourd’hui’s Internet? Une façon consiste à mesurer dans quelle mesure les noms de domaine sont signés à l’aide de signatures DNSSEC. Des services tels que SecSpider suivent la progression de la signature de domaine dans les différentes zones DNS de niveau supérieur et deuxième niveau en comptant le nombre de noms de domaine qui incluent les informations d’identification DNSSEC. Mais l’autre moitié de la question est également pertinente ici. Dans quelle mesure les applications utilisateur finales utilisent les résolveurs DNS qui effectuent la validation DNSSEC lors de la résolution d’un nom? Et, surtout, dans quelle mesure les applications de l’utilisateur mettront fin à l’utilisation d’un résultat de résolution du nom DNS si le nom de domaine est signé DNSSEC et que la validation de signature DNSSEC associée échoue?

Chez Apnic Labs nous’Ve examine cette deuxième question, tentant de quantifier dans quelle mesure les clients utilisent la validation DNSSEC en conjonction avec la résolution du nom. Nos premiers efforts ont été entrepris en octobre et novembre 2012. Le premier exercice de mesure en octobre 2012 a souligné que 9% des clients qui semblaient utiliser des résolveurs DNS qui ont été considérés comme effectuant une forme de validation DNSSEC. Une réévaluation de l’expérience en novembre 2012 a donné le résultat que quelque 1.6% des clients qui semblaient utiliser exclusivement des résolveurs DNS qui ont systématiquement effectué la validation DNSSEC.

Aucun de ces résultats n’a été si satisfaisant, et la cause de ce niveau d’inquiétude avec les résultats tentait de prendre en compte les effets de la mise en cache du résolveur DNS dans les résultats de l’expérience. Dans ces deux expériences, nous avons utilisé une campagne publicitaire en ligne pour inscrire des millions de clients finaux pour effectuer une collection d’objets à récupérer, et dans les deux cas, nous avons utilisé les wildcards dans le DNS et la génération dynamique d’étiquettes DNS uniques pour présenter à chaque client un ensemble de noms DNS uniques pour résoudre. Cependant, la faiblesse exposée dans cette approche, dans la mesure où une seule chaîne de signature DNSSEC a été partagée à travers l’expérience. This meant that once a DNS resolver had retrieved the DNSSEC Resource Records (RRs) for the experiment’s DNS names (the DNSKEY and DS RRs of the signed zone containing the wildcard entry) it served all subsequent DNSSEC RR queries from its local cache, only refreshing the cached data upon expiry of the cache lifetime of the stored records (which was set to one hour). Étant donné que notre point d’observation pour l’expérience était le journal des requêtes DNS au serveur de noms faisant autorité, nous avons été obligés de déduire les capacités DNSSEC de chacune des résolveurs DNS visibles en fonction de la séquence des requêtes DNS comme le montrent le serveur de noms autoritaires et les requins entre les requêtes. Ces expériences ont trouvé une limite supérieure approximative d’environ 9% des clients utilisant des résolveurs de validation DNSSEC en utilisant un test plutôt libéral pour la validation DNSSEC, et une limite inférieure approximative de 1.6% des clients qui ont utilisé des résolveurs de validation de DNSEC en utilisant un ensemble beaucoup plus stricte de contraintes de règles d’inférence. De toute évidence, nous sommes intéressés à réduire l’incertitude de ces mesures si nous pouvons.

En examinant les expériences précédentes, nous avons noté qu’une façon de supprimer la nécessité de déduire le comportement de résolveur DNS était d’utiliser une configuration DNS qui a supprimé, autant que possible, les effets du comportement du cache DNS. Plutôt que d’utiliser un simple wildcard dans un domaine signé DNSSEC commun, si nous pouvions présenter à chaque client un domaine unique signé DNSSEC, alors l’étiquette unique obligerait n’importe quel résolveur de validation DNSSEC pour récupérer le DNSSEC RRS du serveur de noms autoritaire pour cette zone DNS unique pour la zone DNS unique. En d’autres termes, si les résolveurs du client effectuaient une validation DNSSEC, le serveur de noms faisant autorité recevrait non seulement les requêtes A pour l’adresse du nom de domaine, mais recevrait également les requêtes DNSKEY et DS dans le cadre de la phase de validation DNSSEC DNSSEC. Cette approche nous permettrait de déterminer avec un plus grand niveau de précision combien de clients utilisaient DNSSEC pour valider les noms DNS. Cette structure de nom DNS est illustrée à la figure 1.

Figure 1: Structure du nom de domaine utilisé pour mesurer le comportement de validation DNSSEC

Nous avons dirigé cette version de l’expérience de mesure DNSSEC du 8 au 18 mars 2013.

Le 19 mars, Google a annoncé que leur Google Public DNS résolverait la validation DNSSEC. Dans leur annonce, Google a rapporté que:

“Actuellement, Google Public DNS pose en moyenne plus de 130 milliards de requêtes DNS (culminant à 150 milliards) à partir de plus de 70 millions d’adresses IP uniques chaque jour. Cependant, seulement 7% des requêtes du côté client sont compatibles DNSSEC (environ 3% de la validation et 4% de demande de données DNSSEC mais pas de validation) et environ 1% des réponses DNS du côté serveur du nom sont signées.”

Cette annonce semblait présenter une opportunité idéale pour un “avant et après” Exercice, en effectuant l’exercice de mesure DNSSEC dans la période immédiatement suivant Google’S PAPIER PAPIER à ses résolveurs pour effectuer la validation DNSSEC. Quel impact ce commutateur aurait-il sur l’image globale des clients effectuant la validation DNSSEC? Nous avons recommandé la même expérience du 22 mars au 1er avril 2013 afin de mesurer la mesure que cette annonce d’un changement par Google’S Les serveurs DNS publics ont changé l’image globale des clients qui utilisent la validation DNSSEC.

À l’heure actuelle, Google n’a pas allumé la validation DNSSEC inconditionnellement. Pour citer un matériel supplémentaire publié par Google:

Google public DNS prend-il en charge le protocole DNSSEC?
Oui. Google Public DNS est un résolveur valident et conscient de la sécurité. Il s’agit actuellement d’une fonctionnalité d’opt-in: pour les requêtes provenant de clients demandant la validation (l’annonce et / ou l’indicateur DO est défini), Google Public DNS vérifie que les enregistrements de réponse sont correctement authentifiés. Validation par défaut (i.e. pour toutes les requêtes) sera bientôt activée.

Quel client résolvera actuellement DNSSEC?
Malheureusement, la plupart des résolveurs standard du client ne permettent pas la vérification complète du DNSSEC et ne peuvent pas être facilement reconfigurés pour le faire. Nous avons décidé de faire en sorte que notre lancement initial ne cède que des résolveurs qui demandent explicitement la vérification du DNSSEC afin que nous prenions conscience de tout problème avant d’exposer nos utilisateurs à d’éventuelles échecs DNS à grande échelle en raison des erreurs de configuration ou des pannes DNSSEC. Une fois que nous sommes heureux que nous puissions activer en toute sécurité le DNSSEC pour tous les utilisateurs, sauf ceux qui se déshabillent explicitement, nous le ferons.

L’implication est que, à l’heure actuelle, si la requête DNS du client ne demande pas la validation DNSSEC, alors le DNS public Google renverra un résultat sans effectuer aucune forme de validation DNSSEC de la réponse. Le matériau Google indique qu’une demande de validation DNSSEC est marquée par une requête DNS ayant l’annonce ou le jeu DO.

Quels sont ces drapeaux de requête DNS?

DNSSEC et DNS Requête des drapeaux

Le protocole DNS, tel que défini dans RFC 1034 et RFC 1035, n’a inclus aucune disposition spécifique pour la validation des réponses DNS. Le protocole est un simple protocole de requête / réponse. Le client génère une requête DNS composée d’un en-tête terminé et d’une section de requête, et la réponse contient les mêmes sections d’en-tête et de requête avec une réponse, une autorité et des sections supplémentaires.

DNSEC est une extension compatible en arrière du protocole DNS, défini dans RFCS RFC 4033, RFC 4034, RFC 4035, RFC 5155 et RFC 6840. Il y a trois drapeaux dans une requête DNS qui contiennent des instructions DNSSEC explicites à un résolveur.

Le drapeau do
Le premier fait partie des mécanismes étendus pour DNS (EDNS0), défini dans RFC 2671. Si le dnssec ok (FAIRE) Le bit est défini dans une requête, alors ceci est interprété comme un signal que la réponse doit inclure les données DNSSEC dans sa réponse. Si la réponse est un enregistrement de ressource d’une zone signée DNSSEC, la réponse doit inclure la signature de l’enregistrement des ressources (RRSIG RR) en plus de la réponse des enregistrements de ressources. S’il n’y a pas de domaine de ce type, la réponse devrait inclure NSEC ou NSEC3 RRS dans sa réponse.

Le drapeau du CD
Le second est le drapeau de vérification des personnes handicapées (CD). Si ce drapeau est défini dans une requête, le résolveur doit retourner les informations demandées, y compris les enregistrements RRSIG, le cas. En définissant le bit de CD dans sa requête, le résolveur d’origine indique qu’il assume la responsabilité d’effectuer l’authentification de la réponse et que le serveur de nom récursif interrogé ne doit pas interférer avec cette fonction.

Le drapeau de l’annonce
Le dernier drapeau est le drapeau de données authentifiées (AD). Ce drapeau a un sens un peu peu clair. Jusqu’au début de 2013, le document des normes était RFC4035:

4.6. Manipulation des bits CD et AD
& nbs [;
Un résolveur de la sécurité doit effacer le bit AD lors de la composition des messages de requête pour protéger contre les serveurs de noms de buggy qui copient aveuglément des bits d’en-tête qu’ils ne comprennent pas du message de requête au message de réponse.

En février 2013, RFC6840 a été publié, avec la définition RE suivante du bit publicitaire:

5.7. Définition du bit d’annonce sur les requêtes
La sémantique du bit de données authentiques (AD) dans la requête n’était précédemment non définie. Section 4.6 de [RFC4035] a demandé aux résolveurs de toujours effacer le bit AD lors de la composition des requêtes.

Ce document définit la définition du bit AD dans une requête en tant que signal indiquant que le demandeur comprend et s’intéresse à la valeur du bit publicitaire dans la réponse. Cela permet à un demandeur d’indiquer qu’il comprend le bit AD sans également demander des données DNSSEC via le bit Do

5.8. Définir le bit d’annonce sur les réponses
Section 3.2.3 de [RFC4035] décrit dans quelles conditions un résolveur de validation doit définir ou effacer le bit AD dans une réponse. Afin d’interopérer avec les résolveurs de stub hérités et les boîtes intermédiaires qui ne comprennent ni ne ignorent le bit publicitaire, la validation des résolveurs ne devrait définir le bit AD que lorsqu’une réponse remplit les deux conditions énumérées dans la section 3.2.3 de [RFC4035], et la demande contenait soit un ensemble de bit ou un bit d’annonce.

Paramètres de drapeau combiné

L’effet de diverses combinaisons paramètres du drapeau dans les requêtes envoyées aux résolveurs est indiquée dans le tableau suivant.

 Do CD AD Effect 0 0 0 Le résolveur peut ou non effectuer la validation DNSSEC. Aucun DNSSEC RRS n'est ramené dans la réponse. 0 0 1 Le résolveur doit effectuer la validation. Aucun DNSEC RRS n'est ramené dans la réponse 0 1 0 Le résolveur ne doit pas effectuer la validation DNSSEC. Aucun DNSSEC RRS n'est remis dans la réponse 0 1 1 Signaux mixtes! Les actions du résolver ne sont pas définies. 1 0 0 Le résolveur doit effectuer la validation et retourner dnssec rrs dans sa réponse 1 0 1 Le résolveur doit effectuer la validation et retourner dnSsec rrs dans sa réponse 1 1 0 Le résolveur ne doit pas effectuer la validation dnssec, mais il doit retourner DNSSEC RRS dans sa réponse 1 1 1 1 signaux mixtes, mais il doit être rendu! Les actions du résolveur ne sont pas définies. 

Tableau 1: Paramètres de l’indicateur DNSSEC dans les requêtes DNS

Il convient de noter que lorsque le résolveur est ordonné de ne pas effectuer la validation DNSSEC, le résolveur doit répondre avec les enregistrements de ressources demandés, même dans le cas où les enregistrements de ressources sont signés par DNSSEC et que la signature n’est pas valide.

DNS Resolver Comportement et DNSSEC

Le modèle conceptuel le plus simple de la résolution DNS impliquant un client, un résolveur DNS et une collection de serveurs de noms faisant autorité, comme le montre la figure 2.

Figure 2 – modèle simple de la résolution DNS pour le nom de domaine “X.y.z”

Lorsque le client interroge son résolveur DNS pour la résolution d’un nom de domaine, comme x.y.z, alors le résolveur DNS, en supposant qu’il a un état de cache effacé, enverrait d’abord cette requête à un serveur de noms racine. Le serveur répondrait avec l’ensemble des serveurs de noms faisant autorité pour le domaine de niveau supérieur Z.. Le résolveur DNS enverrait alors la même requête à l’un de ces serveurs de noms pour z., qui répondrait avec les serveurs de noms pour le domaine y.z.. Le résolveur DNS interrogera alors l’un de ces serveurs de noms pour le nom DNS x.y.z., Et il passera ensuite la réponse qu’il récupère au client. La séquence de requêtes DNS envoyées par ce résolveur DNS après avoir reçu la requête initiale du client serait la suivante:

 # Requête RR Nom du serveur Réponse 1. A X.y.z. . Ns pour "z."2. A X.y.z. z. Ns pour "y.z."3. A X.y.z. y.z. A pour "x.y.z." 

Figure 3 – Requêtes DNS sans validation DNSSEC

Et si ce résolveur DNS était un résolveur de validation DNSSEC? Cela impliquerait des requêtes DNS supplémentaires, car le résolveur DNS doit valider l’enregistrement RRSIG pour l’enregistrement des ressources récupérées. Cette validation implique un “trace arrière” En haut de la hiérarchie de délégation DNS, suivant la chaîne de DNSKEY et DS RRS jusqu’à ce qu’elle atteigne un point de confiance, qui, dans ce cas, est la clé de signature de la zone racine. L’ensemble équivalent de requêtes DNS pour un résolveur de validation de DNSEC, après avoir reçu la requête initiale du client, serait la suivante:

 # Requête RR Nom du serveur Réponse 1. Un edc x.y.z. . Ns pour "z."+ Rrsig 2. Un edc x.y.z. z. Ns pour "y.z."+ Rrsig 3. Un edc x.y.z. y.z. A pour x.y.z. + Rrsig 4. Dnskey edc y.z. y.x dnskey pour la zone "y.z "+ rrsig 5. Ds edc y.z. z. Ds pour la zone "y.z "+ rrsig 6. DNSKEY ECD Z. z. Dnskey pour la zone "z."+ Rrsig 7. Ds edc z. . Ds pour la zone "z."+ Rrsig 8. Dnskey edc . . Dnskey pour zone ".un" 

Figure 4 – Requêtes DNS avec validation DNSSEC

Les 3 requêtes initiales sont similaires, mais maintenant les requêtes émises par ce résolveur DNS validant DNSSEC incluent l’EDNS0 (E) Extension, et le dnssec ok (D) et la vérification désactivée (C) drapeaux. Dans chaque cas le FAIRE Les signaux du drapeau que les réponses des serveurs faisant autorité doivent inclure les RRSIG RR, si les zones sont en effet signées DNSSEC.

Si nous devions regarder les transactions sur le serveur faisant autorité pour la zone Y.z. Nous verrions une requête A suivie d’une requête DNSKEY. Si nous regardons les transactions sur le serveur faisant autorité pour la zone parentale Z., Il y aurait une requête, suivie d’une requête DS et d’une requête DNSKEY. Et si nous devions utiliser le même serveur de noms faisant autorité pour les deux Z. et x.z. Ensuite, ce serveur de nom verrait une requête A pour x.y.z., suivi des requêtes dnskey et ds pour y.z.

À partir de cet exemple, il semblerait possible de catégoriser les résolveurs DNS dans des résolveurs de validation DNSSEC et non validants en fonction de l’observation des requêtes DNSKEY et DS au serveur de noms faisant autorité. Si nous observons les requêtes comme dans la figure 3, alors le résolveur DNS est un résolveur non validant, et s’ils sont comme sur la figure 4, alors le résolveur est un résolveur de validation DNSSEC. Malheureusement, cette forme simple qu’une catégorisation n’est pas possible, car l’image de la résolution DNS peut être beaucoup plus complexe que l’image simple de la figure 2.

Un résolveur DNS peut être configuré pour utiliser un “redirecteur”. Dans ce cas, le résolver DNS ne demandera pas directement aux serveurs de noms faisant autorité, mais canalisez ses requêtes via un autre résolver DNS. L’avantage de l’utilisation d’un transfert est de tirer parti de l’efficacité de la mise en cache des résultats DNS. Les variantes de cette configuration de résolveur permettent de limiter la fonction de transfert à la résolution de zones DNS spécifiques plutôt que de l’appliquer à toutes les requêtes. Un résolveur peut également être configuré pour retomber à une résolution récursive si les transitaires ne parviennent pas à fournir une réponse. Il y a aussi “Resolver Farms” dans le DNS, où un seul transfert logique peut accepter les requêtes DNS, mais utilisez ensuite une collection de résolveurs DNS esclaves pour entreprendre les requêtes. L’image idéalisée de la résolution DNS de la figure 2 doit être quelque peu augmentée pour illustrer le niveau de complexité potentielle impliquée dans la résolution DNS. La figure 5 montre certaines des configurations possibles.

Figure 5 – Quelques structures de résolution DNS avec des transitaires

Dans le contexte de l’expérience que nous entreprenons ici, nous n’avons instrumenté que le serveur de noms faisant autorité, et nous ne voyons que les requêtes DNS soumises par”visible” DNS résolve à ce serveur. Ainsi, en termes de résolveurs directement visibles, la vue de l’infrastructure de résolution DNS est plus proche de celle comme le montre la figure 6. Ici, la structure interne des transitaires DNS est effectivement occluse du serveur de noms faisant autorité, et le serveur ne peut voir que les résolveurs qui y adoptent des requêtes.

Figure 6 – Structures de résolution DNS

L’implication ici est que si cette approche expérimentale peut fournir une bonne vue des capacités de validation DNSSEC des clients, elle nécessite un certain niveau d’inférence et un niveau associé d’incertitude des règles d’inférence de l’application, pour déduire le comportement de validation DNSSEC des résolveurs DNS. Par exemple, si un résolveur de validation DNSEC utilise un transfert non validant, le serveur de noms faisant autorité verra une séquence de requêtes du redirecteur avec les indicateurs DO et CD qui sont cohérents avec la validation DNSSEC DNSSEC. Si un résolveur de validation non-DNSSEC utilise en tant que transfert d’un résolveur de validation DNSSEC, alors le serveur de noms faisant autorité peut voir précisément la même séquence de requêtes de ce transfert.

L’expérience de mesure DNSSEC

Dans cette expérience, un objet Adobe Flash est intégré dans une annonce en ligne. Le code est exécuté lors de la présentation de la publicité et ne nécessite pas que l’utilisateur clique sur l’impression publicitaire.

Le code amène le client à récupérer un objet d’un contrôleur d’expérience, qui alimente le client avec 4 URL. Les trois premières URL doivent être récupérées immédiatement, tandis que la quatrième URL doit être récupérée une fois que les trois premiers objets ont été récupérés, ou à l’expiration d’un minuteur de 10 secondes, selon la première étude. Toutes ces URL incluent une étiquette DNS unique. Un exemple d’ensemble des quatre URL est illustré ci-dessous. Le générateur URL génère un ensemble de valeurs uniques pour chaque expérience. Ces champs uniques sont mis en évidence en couleur.

 d http: // d.U7280280162.S1364784185.V6022.69da1.z.dotnxdomain.net / 1x1.PNG?d.U7280280162.S1364784185.V6022.69da1.z.dotnxdomain.filet e http: // e.U7280280162.S1364784185V6022.69da1.z.dashnxdomain.net / 1x1.PNG?e.U7280280162.S1364784185.V6022.69da1.z.dashnxdomain.filet F http: // f.U7280280162.S1364784185.V6022.69da2.z.dotnxdomain.net / 1x1.PNG?F.U7280280162.S1364784185.V6022.69da2.z.dotnxdomain.filet résultat Http: // Résultats.U7280280162.S1364784185.V6022.69da1.X.rand.apnique.net / 1x1.PNG?résultats.U7280280162.S1364784185.i767.V6022.69da1& r = 

Comme le montre l’exemple ci-dessus, trois URL partagent une étiquette DNS hexadécimale, “69da1 ″ dans ce cas, tandis que l’autre URL comprend une étiquette qui est plus grande en valeur, “69da2” dans ce cas. La première URL, en commençant par l’étiquette D, utilise une combinaison d’un enregistrement générique et d’un domaine signé DNSSEC. Dans ce cas, la signature DNSSEC de l’enregistrement des ressources A est valide. La deuxième URL, en commençant par l’étiquette E, utilise la même combinaison, mais dans ce cas, le domaine n’est pas signé DNSSEC. La troisième URL, en commençant par l’étiquette F, utilise également une combinaison d’un domaine générique et d’un domaine signé DNSEC. Cependant, dans ce cas, la signature DNSSEC n’est pas valide, en ce qui concerne le DS Record pour la zone 69DA2.z.dotnxdomain.Net ne correspond pas aux records DNSKEY correspondants. L’URL des résultats n’est pas signée DNSEC. L’ordre de la présentation des URL dans le script est fixé comme la séquence avec l’URL finale retardée soit de 10 secondes, soit la récupération réussie des trois premières URL, selon la première éventualité. Le client est invité à démarrer les minuteries pour la récupération des URL D, E et F, et de signaler les valeurs de la minuterie dans l’URL des résultats.

Notre intention était de nous assurer que chaque client a été présenté avec une étiquette DNS signée unique, garantissant qu’il n’y avait pas d’état mis en cache dans aucun résolveur DNS ou dans un serveur de proxy Web. Le résultat est que chaque expérience provoque un ensemble de transactions DNS et HTTP avec les serveurs DNS faisant autorité et les serveurs Web pour ces noms de domaine.

L’expérience utilise un seul serveur, qui contient à la fois un serveur de noms DNS (exécuter Bind 9.9.2-P1), et un serveur Web (exécutant Apache v2.2.23). Ce serveur est le seul serveur de noms faisant autorité pour les domaines utilisés dans ces quatre URL, et le point A RRS uniquement vers ce serveur. Dans cette expérience, nous avons délibérément configuré toute l’expérience en utilisant IPv4, laissant l’étude de IPv6 et DNSSEC à d’autres expériences.

Bien que les capacités de validation DNSSEC des résolveurs DNS individuels soient quelque peu difficiles à déduire de cette forme d’expérience, nous prenons du recul et posons la question de savoir si l’utilisateur final utilise la validation DNSSEC via ses résolveurs DNS configurés, alors cela est possible de déduire du journal des requêtes DNS et HTTP à l’atte. Un exemple d’extrait des journaux DNS et HTTP du serveur, concernant une seule expérience (U5158122700.S1364428847 dans ce cas) est illustré ci-dessous.

 Requête du serveur DNS -ed dans un e.U5158122700.S1364428847.V6022.5e3bf.z.dashnxdomain.Net DNS -ed dans un F.U5158122700.S1364428847.V6022.5e3c0.z.dotnxdomain.Net DNS -ed dans un D.U5158122700.S1364428847.V6022.5e3bf.z.dotnxdomain.net http get / crossdomain.xml e.U5158122700.S1364428847.V6022.5e3bf.z.dashnxdomain.net http get / 1x1.png e.U5158122700.S1364428847.V6022.5e3bf.z.dashnxdomain.net http get / crossdomain.XML D.U5158122700.S1364428847.V6022.5e3bf.z.dotnxdomain.net http get / 1x1.PNG D.U5158122700.S1364428847.V6022.5e3bf.z.dotnxdomain.net http get / crossdomain.xml f.U5158122700.S1364428847.V6022.5e3c0.z.dotnxdomain.net http get / 1x1.png f.U5158122700.S1364428847.V6022.5e3c0.z.dotnxdomain.Net DNS -ed dans les résultats.U5158122700.S1364428847.V6022.5e3bf.X.rand.apnique.net http get / crossdomain.Résultats XML.U5158122700.S1364428847.V6022.5e3bf.X.rand.apnique.net http get / 1x1.PNG?résultats.U5158122700.S1364428847.i767.V6022.5E3BF & R = ZD-1923.ze-1578.ZF-1578 

Figure 7 – Journaux des serveurs à partir d’une expérience qui n’a pas effectué la validation DNSSEC

Cette expérience a généré 4 requêtes DNS et 8 requêtes HTTP. Les requêtes DNS ont toutes utilisé le drapeau DNSSEC OK (DO) (“-Élégant” Dans le journal indique que la résolution récursive de la requête a été désactivée (-), EDNS0 était utilisé (e) et des enregistrements de ressources de signature DNSSEC ont été demandés, si disponibles (d))). Cependant, le résolveur DNS demande un RRS mais ne demande pas DNSKEY ou DS RRS. Il apparaît que même si le résolver a réglé le drapeau DNSSEC OK, il n’effectue aucune forme de validation DNSSEC sur la valeur renvoyée dans le RRSIG RRS.

Le client a récupéré les trois URL (D, E et F). Étant donné que l’URL F a une signature DNSEC non valide, cela confirme que le résolveur DNS utilisé par ce client n’effectue aucune validation DNSSEC. La ligne de résultat comprend également un résultat de la minuterie côté client, et le client rapporte que l’expérience D a pris le chargement du client à 1 923 ms, E a pris 1 578 ms et F a pris 1 578 ms. Le temps légèrement plus long pour effectuer la récupération de l’URL par rapport à la récupération de l’URL pourrait être due à la mise en cache du résolver de la résolution de Z.dotnxdomain.net tout en résolvant l’URL D et en utilisant les valeurs mises en cache lors de la résolution de l’URL F.

Maintenant, en revanche, ce qui suit est un extrait des mêmes journaux qui montrent les requêtes DNS reçues par le serveur de noms faisant autorité d’un résolveur DNS qui semble effectuer la validation DNSEC.

 Requête du serveur DNS A -edc dans un D.U94278337.S1364428957.V6022.5e4e3.z.dotnxdomain.net dns a -edc dans un e.U94278337.S1364428957.V6022.5e4e3.z.dashnxdomain.net dns a -edc dans dnskey 5e4e3.z.dotnxdomain.net dns a -edc dans ds 5e4e3.z.dotnxdomain.net dns a -edc dans un f.U94278337.S1364428957.V6022.5e4e4.z.dotnxdomain.net dns a -edc dans dnskey 5e4e4.z.dotnxdomain.net dns a -edc dans ds 5e4e4.z.dotnxdomain.net dns b -edc dans un f.U94278337.S1364428957.V6022.5e4e3.z.dotnxdomain.Net DNS B -EDC dans DNSKEY 5E4E4.z.dotnxdomain.Net DNS B -EDC dans DS 5E4E4.z.dotnxdomain.net http get / crossdomain.XML D.U94278337.S1364428957.V6022.5e4e3.z.dotnxdomain.net http get / 1x1.PNG D.U94278337.S1364428957.V6022.5e4e3.z.dotnxdomain.net http get / crossdomain.xml e.U94278337.S1364428957.V6022.5e4e3.z.dashnxdomain.net http get / 1x1.png e.U94278337.S1364428957.V6022.5e4e3.z.dashnxdomain.net dns a -edc dans un résultat.U94278337.S1364428957.V6022.5e4e3.X.rand.apnique.net http get / crossdomain.Résultats XML.U94278337.S1364428957.V6022.5e4e3.X.rand.apnique.net http get / 1x1.PNG?résultats.U94278337.S1364428957.i767.V6022.5E4E3 & R = ZD-1572.ze-1269.zf-null 

Figure 8 – Journaux des serveurs à partir d’une expérience qui a effectué la validation DNSSEC

Dans ce cas, le client a récupéré deux URL (D et E) et n’a pas récupéré l’URL associée au nom de domaine F qui a échoué la validation DNSSEC.

Le résolveur DNS effectue une validation DNSSEC, comme en témoigne la récupération des RR DNSKEY et DS pour les zones de domaine D et F. La première résolution DNS pour le nom de domaine F a échoué la validation DNSSEC, et le client semble avoir reçu une réponse de servfail. Le client a ensuite essayé son deuxième résolveur configuré, qui effectue également une validation DNSSEC. À ce stade, le client a renoncé à tenter de résoudre le nom de domaine F. Après l’expiration du temporisateur de 10 secondes, le client a récupéré l’URL du résultat. La ligne de résultat comprend également un résultat de la minuterie côté client et que le client rapporte que l’URL D a pris le client de 1 572 ms, E a pris 1 269 ms et F n’a pas été récupéré. The slightly longer time to perform the d fetch as compared to the e fetch could be due in part to the resolver’s retrieval of the DNSKEY and DS RRs for the d domain, and the associated DNSSEC validation operation that was performed by the validating resolver, as the client would not receive the result of the d DNS query until and the additional queries associated with DNSSEC validation had been completed.

Le but de cette expérience est d’échantillonner un grand ensemble aléatoire de clients de partout sur Internet et d’amener leur navigateur à exécuter cette expérience. Si l’ensemble des transactions sur le serveur ressemble au premier ensemble de transactions indiqué ci-dessus, nous pouvons conclure et que le client n’utilise pas DNSSEC, tandis que si l’ensemble des transactions ressemble au deuxième ensemble indiqué ci-dessus, le client utilise DNS Resolvers qui effectuent la validation DNSSEC pour protéger sa fonction de résolution de nom de nom.

Dans cette configuration expérimentale, le seul composant accessible que nous pouvons équiper d’instrumentation est le serveur faisant autorité pour le domaine “dotnxdomain.filet.”. Si le résolveur DNS n’effectuait pas de validation DNSSEC, nous nous attendrions à voir une seule requête pour un A RR fait au serveur faisant autorité, tandis que si le résolveur DNS était un résolveur de validation DNSSEC, nous nous attendrions à voir une requête A RR, suivie d’un DNSKE et d’une question DS DS.

Et c’est ce qui est vu. Les requêtes suivantes ont été enregistrées par le serveur de noms faisant autorité à partir d’un résolveur DNS non validant:

 22-mars-2013 01:46:34.209 10.0.0.1 # 59296: Requête: E.U3435434437.S1363916793.V6022.58cb7.z.dashnxdomain.net dans un 22 mars 2013 01:46:34.311 10.0.0.1 # 57571: Requête: D.U3435434437.S1363916793.V6022.58cb7.z.dotnxdomain.net dans un 22 mars 2013 01:46:34.245 10.0.0.1 # 6322E: Requête: F.U3435434437.S1363916793.V6022.58cb8.z.dotnxdomain.net dans un -ed 

Les requêtes suivantes ont été enregistrées par le serveur de noms faisant autorité à partir d’un ensemble de résolveurs DNS qui semblent effectuer la validation DNSSEC:

 22-mars-2013 01:40:48.029 10.0.0.2 # 17283 Requête: D.U2867716218.S1363916447.V6022.58721.z.dotnxdomain.net dans un 22 mars 2013 01:40:48.038 10.0.0.2 # 22572 Requête: 58721.z.dotnxdomain.net dans ds -ed 22-mars-2013 01:40:48.056 10.0.0.2 # 54384 Requête: 58721.z.dotnxdomain.net dans dnskey -ed 22-mars-2013 01:40:48.229 10.0.0.3 # 18024 Query: E.U2867716218.S1363916447.V6022.58721.z.dashnxdomain.net dans un 22 mars 2013 01:40:48.024 10.0.0.4 # 19869 Requête: F.U2867716218.S1363916447.V6022.58722.z.dotnxdomain.net dans un 22 mars 2013 01:40:48.032 10.0.0.4 # 52521 Requête: 58722.z.dotnxdomain.net dans ds -ed 22-mars-2013 01:40:48.049 10.0.0.4 # 35302 Requête: 58722.z.dotnxdomain.net dans dnskey -ed 22-mars-2013 01:40:48.084 10.0.0.5 # 44543 Requête: F.U2867716218.S1363916447.V6022.58722.z.dotnxdomain.net dans un 22 mars 2013 01:40:48.092 10.0.0.5 # 46424 Requête: 58722.z.dotnxdomain.net dans ds -ed 22-mars-2013 01:40:48.109 10.0.0.5 # 17802 Requête: 58722.z.dotnxdomain.net dans dnskey -ed 22-mars-2013 01:40:48.139 10.0.0.6 # 24334 Requête: F.U2867716218.S1363916447.V6022.58722.z.dotnxdomain.net dans un 22 mars 2013 01:40:48.147 10.0.0.6 # 18014 Requête: 58722.z.dotnxdomain.net dans ds -ed 22-mars-2013 01:40:48.164 10.0.0.6 # 43916 Requête: 58722.z.dotnxdomain.net dans dnskey -ed 22-mars-2013 01:40:48.197 10.0.0.6 # 51221 Requête: F.U2867716218.S1363916447.V6022.58722.z.dotnxdomain.net dans un 22 mars 2013 01:40:48.230 10.0.0.7 # 58295 Requête: F.U2867716218.S1363916447.V6022.58722.z.dotnxdomain.net dans un 22 mars 2013 01:40:48.239 10.0.0.7 # 34658 Requête: 58722.z.dotnxdomain.net dans ds -ed 22-mars-2013 01:40:48.255 10.0.0.7 # 31055 Requête: 58722.z.dotnxdomain.net dans dnskey -ed 

Dans ce cas, l’URL F, qui contient une signature DNSEC non valide, génère apparemment une réponse d’erreur de servfail à partir de la requête DNS initiale qui, à son tour, déclenche le processus de résolution du nom du client pour réessayer l’intégralité de la requête DNS en utilisant un résolveur différent différent. Une répétition du même échec fait effectuer un troisième et final réessayer sur un autre résolveur configuré.

Résultats de l’expérience

La première série de cette expérience a eu les résultats suivants:

 Expériences présentées: 2 802 390 expériences présentées avec des récupérations Web: 2 632 322 expériences ont présenté des résultats avec le résultat: 2 142 141 

Tableau 2 – Expérimentez un compte

Cela montre le “déposer” taux dans l’expérience. Lorsque l’annonce est présentée à l’utilisateur (un “impression”) l’utilisateur final’Le navigateur est passé un objet flash. L’exécution de l’objet Flash provoque le navigateur de l’utilisateur final à collecter les paramètres de l’expérience, qui se compose des trois URL de l’expérience et de l’URL du résultat. Le navigateur commencera ensuite les récupérations des trois URL en résolvant les noms DNS pour les URL. La première mesure de “Expériences présentées” Au serveur de noms faisant autorité se trouve le nombre total du nombre d’identifiants uniques qui ont généré des requêtes DNS. Le navigateur d’utilisateur final effectuera alors des récupérations des URL. La différence entre le nombre de requêtes DNS et le dénombrement de la fetch Web montre que quelque 6% des exécutions d’expérience sont interrompues avant de passer à la partie de la réaction Web de l’expérience. Lorsque les trois URL ont été récupérées ou que 10 secondes se sont écoulées, le navigateur de l’utilisateur final effectuera ensuite une requête de résolution DNS pour l’URL du résultat, puis récupérera l’URL. Un autre 19% des cours d’expérience n’atteignent pas cette phase de récupération de résultat. Afin de s’assurer que l’effet de l’avortation de l’expérience est minimisé, le résumé suivant concerne uniquement ces 2 142 141 expériences qui ont terminé la récupération de l’URL du résultat.

L’expérience consiste à récupérer les URL D, E et F. Le tableau suivant montre le nombre de clients qui ont récupéré diverses combinaisons de ces URL (et ont également récupéré l’URL du résultat).

 d e f count no no 4,325 0.20% oui non non 1 024 0.05% Non Oui Non 2 627 0.12% oui oui non 60 988 2.85% non non oui 1 045 0.05% oui non oui 6 108 0.29% non oui oui 3 291 0.15% oui oui oui 2 059 990 96.17% 

Tableau 3 – Expérimentez les combinaisons de récupération d’URL

Il y avait un total de 60 998 expériences qui ont récupéré d et e, mais non F. Il est possible que cela soit dû au fait que le client ne peut pas valider les signatures DNSSEC sur le F nom de domaine, mais il est également possible que le client n’ait tout simplement pas récupéré F en raison d’une forme de fin prématurée de l’expérience’s exécution, même si l’URL du résultat avait été récupéré. Il est possible d’utiliser les journaux DNS pour confirmer si le client a tenté de valider le nom de domaine F en recherchant les clients qui ont récupéré les RR DS et DNSKEy pour les deux d et F, Mais seulement est venu d et e. Comme le montre le tableau ci-dessous, il y avait 58 303 de ces cours d’expérience, ou 2.72% du total.

Nous sommes également intéressés par le nombre de clients qui utilisent plusieurs résolveurs DNS où seuls certains résolveurs effectuent une validation DNSSEC. Dans le cas où un résolveur de validation DNSSEC renvoie le code d’erreur Servfail, il est probable qu’un client passera ensuite la requête à d’autres résolveurs. Si ces résolveurs n’effectuent pas la validation DNSSEC, le client recevra une réponse pour le nom de domaine F. La catégorie suivante est donc le nombre de clients qui ont récupéré D, E et F, et ont récupéré les RR DS et DNSKEy pour D et F. Ces utilisateurs semblent utiliser un mélange de clients validant DNSEC-validation et non DNSEC. Comme le montre le tableau ci-dessous, il y avait 52 713 de ces cours d’expérience, ou 2.46% du total.

Parmi les expériences restantes, nous avons extrait ces exécutions d’expérience où seuls un RRS a été interrogé, ce qui représentait 2 026 014 exécutions d’expérience, soit 94 58% du total.

Ce qui reste est quelque 2 368 exécutions d’expérience, ce qui semble récupérer des RR DNSSEC, mais n’a pas pu être classé dans l’une ou l’autre des deux catégories ci-dessus.

 DNSSEC utilisé Resolveurs: 58 303 2.72% ont utilisé un mélange de résolveurs de validation et non validante: 52 713 2.46% ont récupéré DNSSEC RRS.11% n'ont récupéré aucun DNSSEC RRS: 2 026 014 94.58% 

Tableau 4 – Expérimentez les capacités des clients pour DNSSEC

Le résultat de cette expérience montre que certains 2.72% de tous les clients semblent utiliser exclusivement les résolveurs de validation DNSEC et ne seront pas en mesure de résoudre un nom DNS lorsque la signature DNSSEC est invalide. Un autre 2.46% des clients utilisent un mélange de résolveurs de validation et de validation de DNSEC et non de validation, de sorte qu’ils ne dérivent aucun tangible “protection” à partir de cette configuration mixte.

Ce qui a changé à la suite de l’annonce de la validation DNSSEC à partir de Resolvers DNS public de Google? Ce qui suit est les mêmes données de l’expérience qui a été menée au 22 mars au 1er avril.

 Expériences présentées: 2 590 330 expériences présentées avec des récupérations Web: 2 421 138 Expériences présentées avec le résultat Fetch Web: 1 930 180 

Tableau 5 – Expérience B compte

 d e f count no no 3 471 0.18% oui non non 797 0.04% Non Oui Non 2 698 0.14% oui oui non 67 487 3.50% non non oui 832 0.04% Oui Non Oui 4 027 0.21% non oui oui 3 352 0.17% oui oui oui 1844 790 95.58% 

Tableau 6 – Expérimentez les combinaisons de récupération d’URL

 DNSSEC utilisé Resolveurs: 64 690 3.35% ont utilisé un mélange de résolveurs de validation et non validante: 43 657 2.26% ont récupéré DNSSEC RRS une partie du temps: 2 652 0.11% n'ont récupéré aucun DNSEC RRS: 1 816 968 94.13% 

Tableau 7 – Expérience B Capacités du client pour DNSSEC

Le résultat de cette deuxième série de l’expérience montre que certains 3.35% de tous les clients semblent utiliser exclusivement les résolveurs de validation de DNSEC et, correctement, ne seront pas en mesure de résoudre un nom DNS lorsque sa signature DNSSEC est invalide. Un autre 2.26% des clients utilisent un mélange de résolveurs de validation et non validants de DNSEC. Le niveau des clients validants DNSSEC semble avoir augmenté d’un peu plus de 0.5%.

Ce changement positif des niveaux de clients qui effectuent une validation DNSSEC attribuable à un changement dans le comportement des serveurs DNS publics de Google?

Les serveurs DNS publics de Google

Cette augmentation de 0.5% dans le nombre de clients effectuant la validation DNSSEC de l’expérience A à l’expérience B pourraient éventuellement être attribués à Google qui tournait la validation du DNSSC dans ses serveurs DNS publics au moment de l’annonce, ou il pourrait être dans les limites de l’erreur expérimentale, ou il pourrait être le résultat d’un autre ensemble de résolvants qui tournent sur la validation DNSSEC à cette période dans cette période dans cette période dans cette période pour cette période pour cette période pour cette période dans cette période pour cette période dans cette période pour cette période dans cette période pour cette période dans cette période pour cette période dans cette période pour cette période pour cette période dans cette période pour cette période pour cette période dans cette période pour cette période pour cette période dans cette période de cette période. Il’s une question raisonnable pour se demander si les ensembles de données des requêtes DNS des serveurs DNS de Google avant et après l’annonce de Google montrent une différence dans la mesure dans laquelle ils effectuent une validation DNSSEC.

Le DNS public de Google est un transfert DNS, donc en regardant le profil des requêtes DNS générées par Google Resolvers, il peut être utile d’examiner l’ensemble des transformations entre les requêtes envoyées à Google et les questions que les résolveurs Google DNS feront aux serveurs autoritaires des serveurs autoritaires. (En supposant un ensemble de noms de domaine uniques qui ne sont pas déjà chargés dans le cache DNS local de Google).

 Requête originale de la requête correspondante de Google | Validation non validante | | | A a a a (cd) a a a (do) a (do) a (do), ds (do), dnskey (do) a (do, cd) a (do) a (do) ds (cd) ds (do) ds (do) dnskey (do, cd) dnskey (do) dnskey (do) dnske mettre en place 

Tableau 8 – Les requêtes DNS se transforment telles qu’elles sont effectuées par les transitaires DNS publics de Google

Les résolveurs DNS publics de Google ne définissent pas l’indicateur CD sur aucune des requêtes qu’ils font aux serveurs de noms faisant autorité (contrairement aux conseils explicites de la section 5.9 de RFC6840, mais comme le serveur est un serveur de noms faisant autorité, les conseils dans ce RFC dans ce cas particulier sont d’une valeur douteuse! Les résolveurs DNS de Google ne semblent pas modifier aucun comportement de résolution DNS pour ne pas définir l’indicateur de CD lors de la requête en serveurs de noms faisant autorité).

Aside from this change to the query profile, the only other change we would expect to see from the perspective of the queries received at an authoritative name server between a Google resolver that did not perform DNSSEC validation and one that did perform validation is that the proportion of queries for an A RR with the DNSSEC OK flag set should be slightly lower, while the proportion of queries for the sequence of A, DS and DNSKEY RRs, all with the DNSSEC Ok flag should rise. Le raisonnement est que si Google reçoit une requête avec l’ensemble du drapeau DO et le drapeau du CD, alors il effectuera lui-même la validation DNSSEC sur le résultat, et ce faisant, générera les requêtes A, DS et DNSKEY. Si Google reçoit une requête avec l’ensemble des drapeaux DO et CD, il enverra la requête au serveur de noms faisant autorité avec le jeu de drapeau DO, mais ne fera aucune validation DNSSEC à part entière, car le drapeau du CD l’a dirigé pour ne pas le faire.

Voici donc les résultats des deux séries de cette expérience de mesure. L’expérience A est la période du 8 au 18 février 2013, et l’expérience B est la période du 22 mars au 1er avril 2013.

 Expérimentez une expérience B Nombre total de requêtes: 309 043 328 059 . Single une requête: 256 708 83.07% 289 428 88.22% Single une requête avec DO Set: 23 134 7.48% 20,119 6.13% multiples A Requêtes: 11 700 3.79% 7 916 2.41% multiples A Requêtes, tout avec DO Set: 1 179 0.38% 578 0.18% multiples A requêtes, certaines avec set DO: 1 194 0.39% 877 0.27% Séquence de requête DNSSEC-VALADIDE unique: 5 904 1.91% 3 196 0.97% d'autres séquences de requête: 7 482 2.42% 4 706 1.43% 

Tableau 9 – Google’S Public DNS Resolvers DNS Requête Profil: Total

Ce résultat n’est pas très éclairant. La proportion d’une seule séquence de requête DNSSEC-validation (une requête A suivie par DS et DNSKEY Queries dans l’un ou l’autre ordre) est en fait tombée dans l’expérience B. Cela conduit à la conclusion provisoire selon laquelle, dans les limites de la variation des données dans cette expérience, il semble que les serveurs DNS publics de Google aient effectué la validation DNSEC depuis un certain temps, et la validation du DNSEC n’a pas simplement été activée au moment de l’annonce de Google le 19 mars 2013.

Il existe un autre moyen potentiel de détecter le résolveur DNS de Google effectuant la validation DNSSEC. If you query for an A RR from Google’s public DNS servers with the DNSSEC OK bit set, and the domain name is DNSSEC signed, and the DNSSEC signature is valid, then while the first query will cause the DNS resolvers to query the authoritative name servers, subsequent queries for the same name will be answered from the DNS resolvers’ cache, and will not cause any queries to be sent to the authoritative name servers. D’un autre côté, si la signature DNSSEC du nom de domaine n’est pas valide, alors les requêtes ultérieures pour le même nom de domaine (avec le jeu de bits DNSSEC OK) fera que les résolveurs DNS remettent la requête des serveurs de noms faisant autorité. Cette expérience a des signatures DNSSEC-VALID et DNSSEC-invalid avec les noms de domaine D et F. Sont les différences visibles dans les modèles de requête des résolveurs publics publics de Google?

 Catégorie Expérience A Experiment B Valide (%) Invalide (%) valide (%) invalide (%) Nombre total de requêtes: 153 540 154 907 164 043 165 623 Faire une requête: 127,366 82.95% 128 134 82.72% 144 561 88.12% 145 725 87.99% unique une requête avec DO Set: 5 465 3.56% 5 386 3.48% 6 308 3.85% 6 259 3.78% multiple A Requêtes: 5 557 3.62% 5 789 3.74% 3 780 2.30% 4 038 2.44% multiples A Requêtes, tout avec DO Set: 245 0.16% 248 0.16% 226 0.14% 236 0.14% multiples A requêtes, certaines avec set DO: 202 0.13% 222 0.14% 231 0.14% 224 0.14% Séquence de requête DNSSEC-VALADIDE unique: 10 818 7.05% 5 904 3.81% 6 434 3.92% 3 196 1.93% DNSSEC Valider plus les requêtes supplémentaires: 1 864 1.21% 7 482 4.83% 1,124 0.69% 4 706 2.84% autres 2 023 1.32% 1 742 1.12% 1,379 0.84% 1 239 0.74% 

Tableau 10 – Google’S Public DNS résolve le profil de requête DNS: totaux valides et non valides

Ce tableau ne montre aucun changement appréciable du volume de requête entre les noms DNS valides et non valides. Il est probablement dû à la nature de cette expérience, où l’utilisation d’étiquettes DNS uniques dans chaque expérience a été délibérément conçue pour contourner la mise en cache.

Il y a cependant un cas où il existe des preuves de requêtes DNS répétées. La baisse de la proportion relative de séquences de requête de validation DNSSEC unique entre les noms de domaine valides et non valides illustre une forme de comportement du client où une réponse d’erreur de Servfail de la requête DNS initiale fait réessayer le client de la même requête sur le résolveur suivant dans sa liste locale de résolveurs de noms DNS. La partie peut-être ironique de ce comportement particulier est que ce que nous voyons ici dans ce tableau est le résultat des cas où un certain nombre de résolveurs DNS dans la liste des résolveurs disponibles du client finissent par transférer ces requêtes supposées distinctes sur le point commun des serveurs DNS publics de Google.

Nous pouvons donc dire avec une certaine certitude que Google n’a pas activé la validation DNSSEC au moment de son annonce publique le 19 mars 2013, et Google avait effectué la validation DNSSEC depuis un certain temps avant l’annonce. Il semblerait que le 0.Une variation de 5% du niveau de l’utilisation finale du client de la validation DNSSEC est plus probablement le résultat de la variabilité de l’expérience.

Les résultats – utilisation de DNSSEC par les utilisateurs finaux

Cette expérience montre qu’au début de 2013 3% de tous les clients semblent utiliser exclusivement les résolveurs de validation de DNSEC et, de manière appropriée, ne seront pas en mesure de résoudre un nom DNS lorsque sa signature DNSSEC n’est pas valide. Un plus loin 2% des clients utilisent un mélange de résolveurs de validation DNSSEC et non validants.

Confirmé – Google’S public DNS effectue désormais une validation DNSSEC pour toutes les requêtes par défaut

Il’S OFFICIEL… Google’S Le service DNS public effectue désormais une validation DNSSEC pour tous Requêtes DNS par défaut!

Lorsque la nouvelle a éclaté le 19 mars que Google avait permis de valider la validation DNSEC sur son service DNS public, il y avait une préoccupation initiale après que les gens ont remarqué que Google ne faisait que la validation DNSSEC lorsqu’il est demandé. Cela a conduit à une clarification quelques jours plus tard sur Google que son déploiement initial exigeait qu’un client demande la validation DNSSEC afin qu’il puisse tester le service – et cette validation complète arrivera bientôt.

Le mot officiel

Hier, Google’S Warren Kumari a publié dans la liste de diffusion DNSSEC-déploiement que la validation complète se produit maintenant:

Nous avons récemment activé la validation par défaut dans le monde entier, et vous devriez maintenant obtenir des échecs de validation pour les échecs de validation. Excuses à nouveau pour l’annonce originale et peu claire.

Le blog / la documentation n’a pas encore été mis à jour (cela se produira probablement dans les prochains jours) mais nous voulions vous donner la bonne nouvelle dès que possible.

Et en effet un test rapide pour voir si je pouvais obtenir les enregistrements DNS pour un domaine de test connu pour avoir une mauvaise signature DNSSEC a produit le “Servfail” message et correctement fait pas Renvoyez tous les enregistrements DNS:

$ DIG @ 8.8.8.8 www.dnsec-failled.org; > Creu 9.8.3-P1> @ 8.8.8.8 www.dnsec-failled.org; (1 serveur trouvé) ;; Options globales: + CMD ;; J'ai une réponse: ;; - >> En-Headerservfail, ID: 60286 ;; Flags: QR RD RA; Requête: 1, Réponse: 0, autorité: 0, supplémentaire: 0 ;; Section de questions :; www.dnsec-failled.org. DANS UN

C’est une excellente nouvelle pour ceux d’entre nous qui sont des défenseurs de DNSSEC et signifie que quiconque utilise Google’S Les serveurs DNS publics pour la résolution du nom DNS reçoivent désormais automatiquement la plus grande sécurité du DNSSEC. Quiconque utilise ces serveurs saura que (pour les domaines signés), les informations qu’ils retirent du DNS sont les mêmes informations que l’opérateur de domaine a mis dans DNS – et non celle d’un attaquant cherchant à vous faire aller sur un autre site.

Si vous souhaitez également accéder à la sécurité accrue de DNSSEC, tout ce que vous avez à faire est de configurer votre ordinateur ou votre routeur domestique pour avoir comme serveurs DNS les serveurs DNS Google public:

Déplacer la validation DNSSEC encore plus près

Aussi génial que cette décision de Google (et c’est est Génial), vous pouvez toujours augmenter un peu plus la sécurité fournie par DNSSEC. Parce que Google’S Les serveurs DNS publics ne sont pas sur votre réseau local et sont plutôt quelque part sur Internet, il y a toujours Une chance qu’un attaquant puisse s’insérer entre vous et Google’Serveurs DNS S. L’attaquant pourrait alors faire semblant de vous renvoyer les informations correctes et de se déguiser en tant que Google’S Serveurs DNS publics.

Pour obtenir le plus haut niveau de sécurité DNSSEC, vous voulez idéalement effectuer la validation DNSSEC sur au moins votre réseau local et potentiellement même votre ordinateur local. Là’s un grand livre blanc des gens de Surfnet appelés “Déploiement de DNSEC: Validation sur les serveurs de noms de mise en cache récursifs” Cela explique comment vous pouvez simplement activer la validation DNSSEC pour trois des serveurs DNS communs utilisés par les entreprises et les réseaux aujourd’hui.

Hé, si Google peut activer la validation DNSSEC, pourquoi peut’t toi?

Si vous le pouvez’t DNSSEC Validation localement (par exemple, si vous n’avez qu’un routeur WiFi à domicile qui ne fait pas’T effectuer la validation) puis faire effectuer la validation à votre FAI peut être la prochaine étape… et si votre FAI a gagné’t DNSSEC Validation alors vous n’avez vraiment pas d’autre choix que d’utiliser un service comme Google’S Services DNS publics. Leur validation DNSSEC est définitivement une bien meilleure protection que aucune du tout!

Encore une fois, bravo à Google’S Équipe publique DNS pour avoir fait cette étape et nous nous réjouissons du jour où tous DNS résolveurs effectuent simplement la validation DNSSEC automatiquement.

Avertissement: les points de vue exprimés dans ce post sont ceux de l’auteur et peuvent ou non refléter des postes officiels de la société sur Internet.

Google utilise-t-il dnssec

Google publie-t-il des statistiques en direct sur l’état de son réseau DNS?

Je suis très heureux que vous alliez à pleine vapeur dans le déploiement des meilleures pratiques DNSEC et d’autres meilleures pratiques de sécurité DNS, et que vous souhaitez défendre Google DNS à d’autres personnes, mais hélas, vous n’êtes pas réellement conforme aux spécifications DNSSEC en ce moment pour la raison simple que si le bit n’est pas défini dans les requêtes, vous ne faites aucune validation pour la validation. C’est tout simplement faux; vous devez retourner servfail pour toute panne de validation, à tout client.

C’est vraiment une information formidable et utile.
Je suis convaincu que vous avez simplement partagé ces informations utiles avec nous.
S’il vous plaît restez-nous informé comme ça. Merci pour le partage d’informations.

Y a-t-il quelqu’un chez Google affecté à faire le travail pour obtenir le google.COM Domain DSNSEC Signé? Nous avons un problème de poulet et d’oeuf où les utilisateurs finaux ne prennent pas le temps de s’engager avec DNSSEC si les sites auxquels ils accèdent fréquemment ne sont pas signés. Si quelqu’un y travaille, quelle est la date de déploiement cible / trimestre?

Google: où’s votre dnssec?

Google a beaucoup investi dans la sécurité informatique et, je pense, a fait un travail décent. Tous les services sont par défaut TLS, l’identité et l’autorisation sont bien traitées.

J’ai donc été quelque peu surpris que ce soit pour voir que Google’est propre .com (et .CA) ne sont pas la configuration DNSSEC. Je me demande pourquoi, il doit y avoir une raison.

DNSSEC aide à éviter l’usurpation du domaine, qui à son tour peut être utilisé pour tricher et obtenir des certifications TLS. je’Je suis sûr que c’était une décision consciente. Leur 8.8.8.8 serveur fait la validation DNSSEC. C’est une option dans leurs domaines Google gérés. Leur DNS Cloud le prend en charge. Tout simplement pas entrant dans leur domaine d’entreprise.