La faiblesse dans les logiciels de serveur DNS

Télécharger le fichier pdf d’un mémoire de fin d’études

Menace pour le DNS

Pour comprendre le protocole DNSSEC (sur quoi il peut et ne peut pas fournir de garantie), une compréhension basique sur les menaces pour le DNS est importante à connaître (cf [B7]).

Menace sur la plateforme

La disposition du service moderne de DNS est beaucoup plus différente que l’ancien service (un serveur, une adresse IP, service d’unicast). Aujourd’hui, les services du DNS sont fournis dans un environnement géographiquement dispersé et topologiquement complexe d’anycast. En dépit de ceci, les plateformes fondamentales demeurent vulnérables aux problèmes liés au système d’exploitation fondamental, à la pile de réseau soutenant les serveurs, au logiciel de DNS lui-même et au stockage des données qui servent d’outil de configuration ou de fichier de zone.
Aux fins d’une discussion de DNSSEC, les menaces pour l’actuelle plateforme de serveur sont hors de portée. La plupart de ces menaces ne sont pas spécifiques au DNS, mais sont communes à tous les hôtes sur l’Internet.
Les deux menaces principales de plateforme qui sont spécifiques au DNS sont les attaques sur le logiciel de DNS elle-même et sur les dépôts ou stockages d’information que le DNS emploie pour fournir ses services.
Les opérateurs de service de DNS font attention pour s’assurer que le logiciel de DNS qu’ils emploient sur les plateformes peut les mettre à l’abri des accès non autorisés. Les plateformes doivent être fortes contre les attaques brutales de déni de service tout en restant robustes et disponibles.

Menace pour le DNS dans contexte d’hôte

La faiblesse dans les logiciels de serveur DNS

Tous les logiciels souffrent sur des problèmes potentiels avec leurs configurations et opérations. Les logiciels des serveurs DNS ont historiquement combattu contre les problèmes tels que les surcharges d’informations qui conduisent au déni de service ou à l’accès vers les contrôles privilégiés du serveur DNS elle-même.

Attaque de déni de service (DoS)

Parmi les fameux types d’attaque sur le DNS, cette attaque vise à mettre hors service un serveur DNS, un groupe de serveurs, ou un serveur autoritaire. Le résultat de cette attaque pourrait être plus critique pour tous les services, en particulier pour les serveurs DNS qui sont autoritaires en les mettant hors service pour une durée plus longue. La majorité des serveurs DNS modernes et leurs plateformes d’hôtes sont fortement configurées pour contrer ce type d’attaque.

Menaces relatives aux requêtes DNS et transactions

DNS Cache Poisoning

Bien que ce soit une menace bien connue depuis longtemps pour le DNS, DNSSEC est conçu pour interdire carrément le Cache Poisoning. Le DNS a été établi pour rappeler ou stocker les réponses des requêtes dans le but d’améliorer la performance du serveur. Si le Cache est sujet d’une attaque de manière à ce que le Cache permet d’être corrompu par des données malicieuses mais bien formées alors le Cache compromis sera utilisé jusqu’à l’expiration des données falsifiées. Si un « hacker » met une valeur large et inhabituelle sur le TTL d’un RR, l’information compromise demeurera dans le Cache en attendant d’être utilisée pour une victime inconsciente du danger pendant une durée significative.

Interception de Paquet

Si un serveur malveillant peut s’insérer dans la circulation de données entre le client et le serveur, il est capable d’écouter les requêtes du client et d’envoyer clandestinement des réponses malveillantes en prétendant d’être un serveur de nom autoritaire avant que le serveur légitime puisse répondre.

Effacement d’un RR

Un « hacker »pourrait également se mettre dans la circulation de données entre le client et le serveur et, plutôt qu’en injectant des réponses forgées, il enlève simplement les RRs qui forment la réponse.
Le résultat peut être un échec de la résolution du requête DNS et un déni de service possible sur les ressources qui sont questionnées pour la résolution.

DNS Spoofing

Le DNS a un mécanisme intégré qui permet à des serveurs de faire des multiples requêtes ascendantes afin de résoudre une requête DNS. Si le serveur de DNS est dupé de croire qu’il reçoit une réponse d’un serveur de DNS de confiance quand, en fait, il est sujet d’une attaque, nous nous référons à cette attaque comme celle de « Spoofing». La technique utilisée est de faire écouter les requêtes par le serveur malveillant et de deviner les paramètres requis pour insérer une réponse de son propre choix. Dans des versions plus anciennes de logiciel de serveur de DNS, l’estimation a été facilitée parce que le logiciel lui-même choisit des nombres séquentiels pour les numéros d’identification des requêtes. Dans les logiciels modernes, le numéro du port et le numéro de séquence sont désignés par hasard par le logiciel lui-même pour éviter cette attaque.

Attaque Kaminsky

Une attaque récente très célèbre qui tire profit du fait que le DNS emploie seulement 65.536 IDs possibles de transactions, une quantité insignifiante à injecter vers un serveur DNS valide. Kaminsky n’était pas seulement la première à exploiter ou identifier la stratégie d’attaque, mais était aussi la première à décrire une attaque qui a dévié toutes les défenses courantes. La plupart des défenses employées par des serveurs de DNS aujourd’hui contre le Kaminsky sont assez fragiles. Kaminsky lui-même soutient l’utilisation de DNSSEC comme défense contre cette attaque sophistiquée.

But des attaques des serveurs de noms

Le DNS est une pièce critique dans l’infrastructure de l’internet et constitue une cible naturelle pour des personnes et organisations qui visent à abuser de l’internet. La menace pour le DNS se présente sous plusieurs formes. Certaines menaces sont des attaques sur les fichiers de zone et les serveurs qui composent l’infrastructure du DNS. Les autres menaces sont des attaques sur l’information qui circulent entre le résolveur et les serveurs dans le DNS.
Alors, les serveurs DNS sont sujets à des attaques dans le but de :
· Perturber ou bloquer le service DNS ;
· Empêcher l’accès à certains équipements :raisons économiques, politiques ou malicieuses ;
· Rediriger les utilisateurs à leur insu : préambule à une attaque plus grave ;
· Récupérer des informations critiques (mots de passe, emails, …).

Sécurisation du DNS par le protocole DNSSEC

La sécurisation du DNS assure :
la sécurité des données ;
la sécurité des transactions ;
l’architecture de distribution des clefs :
– Clés utilisées par DNSSEC,
– Clés stockées dans le DNS sécurisé utilisées pour d’autres applications (IPsec, SSH).
Ces outils sont basés sur la cryptographie.

Service apporté par le DNSSEC

La sécurité est un terme générique, et peut être implémentée par plusieurs mécanismes. Les mécanismes en question sont :
Authentification:L’authentification permet au destinataire de s’assurer de la provenance de l’information. L’authentification nécessite dans la plupart des cas l’utilisation de la cryptographie asymétrique. En effet, une donnée chiffrée par la clé privée d’une entité ne sera déchiffrée que par les entités possédant la clé publique associée. L’authentification d’une donnée se fait généralement par l’intermédiaire des signatures qui correspondent au chiffrement par une clé privée d’un résumé (ou hash) de la donnée. L’authentification procure la non-usurpation de l’identité de l’émetteur. Intégrité: Cette caractéristique permet de s’assurer que la donnée n’a pas été changée entre le moment où elle a été émise par l’entité source, et reçue par l’entité destinataire. C’est-à- dire, elle garantit la non-altération des données. On utilise souvent pour cela un mécanisme de hachage qui permet, à partir d’une donnée quelle que soit sa taille initiale, de fournir un certain nombre d’octets appelé« hash ». Une propriété essentielle du « hash » est que deux données initiales doivent avoir, en termes de probabilité, des « hash » différents.
Confidentialité: cette caractéristique permet de rendre toute donnée chiffrée inexploitable par une quelconque entité n’ayant pas la clé nécessaire au déchiffrement. Les opérations de chiffrement peuvent impliquer aussi bien de la cryptographie symétrique que de la cryptographie asymétrique. En d’autre terme, cette caractéristique garantit le secret des données transmises.
Protection contre le déni d’existence : cette caractéristique permet de prouver la non-existence d’une donnée dans le serveur.

Fonctionnement du DNSSEC

Essentiellement, DNSSEC utilise la cryptographie pour fournir l’authenticité et l’intégrité de l’information dans la donnée du DNS.
Une des clés utilisée pour établir des communications privées et fiables entre des personnes, des entreprises et des organismes sur l’Internet est l’utilisation de la cryptographie. Beaucoup de types de cryptographie sont utilisés dans l’Internet, mais DNSSEC emploie un type très spécifique de cryptographie: la cryptographie à« clé publique ».

La cryptographie à clé publique

Essentiellement, la cryptographie à « clé publique » a été prévue pour être une méthode sécurisée et facile à déployer afin d’assurer que les messages et les transactions peuvent être changés en une forme qui ne peut être lue uniquement que par le destinataire prévu.
Chaque personne, société ou organisation possède deux clés. L’une, « la clé publique », est donnée à tous les destinataires possibles et rendue publique, tandis que l’autre, « la clé privée », est tenue secrète et disponible seulement dans les mains de l’expéditeur. Des messages chiffrés avec la « clé publique » peuvent seulement être déchiffrés avec la « clé privée » assortie. Ainsi, quand je veux envoyer un message secret pour une destinataire, je dois chiffrer simplement le message utilisant sa« clé publique ». Puisque la seule personne qui peut déchiffrer le message est la personne qui a la « clé privée » assortie, cela n’importe pas si des individus interceptent le message. Même si quelqu’un pourrait obtenir une copie du message chiffré, il ne pourrait pas le décoder parce qu’il n’a pas la « clé privée » assortie.
Cette stratégie pour protéger les messages sur Internet a une large utilisation dans les technologies telles que le SSL, le TLS, le PGP et le VPN. Mais elle dispose également deux autres dispositifs qui sont d’une importance particulière pour DNSSEC.

Signature digitale

Un des dispositifs de la cryptographie à « clé publique » qui est d’une importance particulière est la signature digitale. Si on emploie la « clé privée » pour générer la signature d’un document ou pour chiffrer un message, on peut vérifier qu’il était vraiment un message ou document validé en vérifiant la signature avec la « clé publique ». Afin d’assurer la confidentialité des messages, la signature digitale se fonde sur la propriété essentielle des paires de clés : des messages signés avec la « clé privée »ne peuvent être vérifiés qu’en utilisant uniquement la « clé publique » assortie.

Installation du protocole DNSSEC et configuration BIND

BIND ( Berkeley Internet Name Daemon, parfois Berkeley Internet Name Domain) est le serveur DNS le plus utilisé sur Internet, spécialement sur les systèmes de type UNIX et est devenu de facto un standard. La première version de BIND a été conçue par quatre étudiants diplômés de l’Université de Californie (Berkeley) sur la base du système d’exploitation BSD 4.3. En 1988, c’est Paul Vixie qui reprenait la maintenance du projet. Le logiciel est actuellement développé par l’Internet Systems Consortium.
La version 9 de BIND (BIND 9), disponible depuis 2000, a été réécrite afin de résoudre certains problèmes architecturaux du code initial et d’ajouter la prise en charge de DNSSEC. D’autres points importants ont été inclus dans cette version : TSIG (Transaction SIGnature), notification DNS, nsup date, IPv6, support Multiprocesseur ainsi qu’une meilleure portabilité. C’est actuellement un logiciel très répandu au sein des systèmes Linux.
Pour configurer le protocole DNSSEC sur BIND, il faut donc avoir au moins la version 9.
Pour la pratique, on utilisera la distribution Ubuntu 11.10 de linux que l’on installera dans une machine virtuelle. La machine virtuelle doit être aussi connectée à internet pour pouvoir installer BIND et tous ces composants dans Ubuntu. Voici alors toutes les étapes à suivre pour implémenter DNSSEC :

Installation de BIND

Par défaut, une version du serveur Bind est déjà installée avec Ubuntu 11.10. Par contre, si on veut installer Bind ou mettre à niveau une version antérieure du serveur, on utilise la commande suivante : « sudoapt-getinstall bind9 dnsutils ».

Modification du fichier named.conf.local

Le fichier /etc/bind/named.conf.local correspond au fichier qui va contenir la définition de l’ensemble des domaines locaux que l’on appellera aussi zone. Comme nous allons créer notre zone locale, on devra donc éditer ce fichier où l’on va définir notre domaine ainsi que le fichier contenant nos enregistrements DNS.

Les barrières au déploiement du DNSSEC

Quand des modifications sont apportées vers une infrastructure majeure, il y a toujours un niveau de souci. Avant que les serveurs de noms racine soient signés en juin 2010, il y avait des soucis sur la façon dont l’infrastructure existante pourrait supporter l’augmentation de la longueur de réponse et du nombre de requête sur le protocole TCP. Comme nous avions vu, DNSSEC exige des données significatives et additionnelles à transférer dans les paquets de DNS (par exemple, les RRSIG et DNSKEY). Cependant, une fois que les serveurs de noms racine étaient signés et commençaient à envoyer des réponses vérifiables, la crainte initiale a été apaisée. Ceci signifie que l’objectif a été modifié vers la mise en place d’une chaîne complète de confiance depuis la racine, par l’intermédiaire du domaine de l’opérateur du TLD, vers leurs clients. Ceci a été nécessaire et par conséquent, les utilisateurs peuvent profiter pleinement des avantages que DNSSEC leurs apportent.
Chaque étape exige un processus d’éducation, ayant pour résultat une compréhension claire de quoi DNSSEC peut ou ne peut pas fournir. L’éducation est également cruciale en surmontant les vraies barrières visibles au déploiement du DNSSEC.

Barriere au déploiement au niveau des compagnies hôtes et les prestataires de service internet (ISP)

Les avantages potentiels que DNSSEC peut fournir entreront en vigueur entièrement quand toutes les parties concernées jouent leurs rôles. Après avoir vu DNSSEC déployé à la racine et également à la croissance du nombre des opérateurs de TLD, il est impératif que les compagnies hôtes et les ISPs jouent leur rôle dans la sécurisation du DNS. La confiance a été établie dans la partie supérieure de la chaîne de confiance dans le DNS. Maintenant, ceux qui sont responsables des parties plus inférieures de la chaîne de confiance doivent commencer l’exécution de DNSSEC pour que la sécurisation soit réalisée.
Afin de comprendre les vraies barrières à l’adoption de DNSSEC, il est nécessaire de considérer chaque barrière potentielle plus en détail et évaluer l’impact que chaque acteur est susceptible d’avoir après l’adoption de DNSSEC.

Barrières techniques (barrière relative au protocole)

Le travail technique sur le protocole de DNS qui doit faciliter l’introduction de DNSSEC a été longtemps accompli. Nous avons vu que des nouveaux types d’enregistrements de ressource ont été ajoutés dont le « Ressource Record Signature » (RRSIG), la clé publique de DNS (DNSKEY), le« Délégation Signer » (DS) et « Next Secure » (NSEC, RFC 4034), aussi bien que l’addition de deux nouveaux drapeaux d’en-tête de DNS. Des modifications ont été également apportées pour le mécanisme du protocole pour le DNS afin de soutenir les réponses de grandes tailles de message (RFC 2672) comprenant le DNSKEY et le RRSIG. Des fonctions de soutien additionnel pour les résolveurs avertis de sécurité ont été également ajoutées (RFC 3225).
En raison de ces changements de protocole et de l’addition des signatures d’enregistrement, il y a une augmentation de la taille de message : des données additionnelles sont ajoutées à chaque réponse toutes les fois qu’un serveur répond. Toutes les fois que la taille maximum d’un paquet d’UDP est surpassée, il place un drapeau tronqué de réponse qui a comme conséquence la répétition de la requête en utilisant le TCP. Ce fait exige la capacité additionnelle de mémoire et de calcul dans les clients et les serveurs. La quantité de la capacité additionnelle dépend de la taille principale de la clef mais il a été estimé par l’ISC (Internet Systems Consortium) qu’une zone signée par DNSSEC peut varier entre 4 à 14 fois la taille de la zone originale. La recherche récente indique que la capacité exigée pour manipuler la charge du travail additionnelle est proportionnelle à la taille de la clé signée pour chaque unité d’activité de DNSSEC.
Un autre dispositif du DNS est la capacité de synthétiser des réponses en marche plutôt que de prendre les réponses au fichier de zone autoritaire. De telles réponses synthétisées sont des tentatives fréquentes pour « cacher » des erreurs envers les utilisateurs de l’Internet. Dans un tel cas, les domaines inexistants d’une zone sont cachés de la vue en renvoyant une adresse IP d’un moteur de recherche pour un objectif spécial.
Cette approche, appelée « wildcarding » est établie dans la norme pour le DNS. Cependant, puisque les enregistrements retournés au client sont synthétisés, ils ne peuvent pas être signés. DNSSEC ne fonctionne pas dans les zones où un serveur est utilisé pour synthétiser des réponses aux requêtes DNS.

Barrières économiques

Le fait que DNSSEC peut fournir la sécurité additionnelle dans le cas où certains types d’attaques seraient effectués sur le réseau, cela rend difficile la mesure de sa valeur de sorte qu’un coût définitif de l’évaluation de ses avantages puisse être défini.
Sans doute, la mise en place du DNSSEC impose des coûts additionnels et exige un certain nombre d’acteur s’étendant à des programmeurs de logiciel et des fournisseurs d’infrastructure, à des administrateurs de zone, aux clients DNS et à ceux qui utilisent les serveurs et les applications DNS.
Pour les programmeurs de logiciel, l’issue est plus simple que pour les autres : le travail initial de standardisation a été accompli et elles semblent être satisfaisantes pour la demande, que ce soit en termes de mises à niveau du logiciel de serveur DNS, au niveau du résolveur que pour les fonctions de gestion des clés. L’inclusion des possibilités de DNSSEC dans de futurs progiciels sera déterminée par la demande perçue qui émane des communautés de fournisseur et d’utilisateur.
Les personnes qui implémentent dans les zones font faces à deux cas de coût avec le DNSSEC. La mise en œuvre de DNSSEC dans une zone a un premier coût de déploiement dans le matériel, le logiciel, les ressources de réseau et la main d’œuvre. Mais une fois que le déploiement initial est complet, il y a des frais généraux continus de DNSSEC. Ce n’est pas simplement le coût payé d’avance qui doit être considéré. Par exemple, il est impératif que des signatures de zone soient maintenues. Des décisions doivent être prises sur la longueur des clés utilisées et sur les valeurs du « Time to Live » liées à elles. Tous les deux sont les éléments critiques d’une implémentation réussie de DNSSEC. Une fois le délai des clés signées expire, à moins qu’elles « soient régénérés » (re-signed), des échecs de message se produiront au niveau du client ou du résolveur. De nouvelles procédures devront également être mises en place pour traiter des urgences imprévues telles que la régénération urgente des clés ou d’autres activités de soutenance requises.
Comme avantages gagnés à l’introduction de DNSSEC, là où ce sont des utilisateurs qui tirent bénéfice de l’assurance que les réponses à leurs requêtes sont bien fondées, je cite les avantages réels des activités additionnelles et les activités continues de soutenance entreprises par des administrateurs de zone qui sont principalement réalisés par l’utilisateur. Cette situation ne fournit pas une conséquente incitation aux administrateurs de zone pour qu’ils prennent la charge administrative et les dépenses additionnelles sans avoir été demandées par l’utilisateur.
Le secteur de corporation est susceptible de déployer DNSSEC plus tôt, en particulier ces organismes dont des opérations commerciales et des réseaux tireraient bénéfice clairement de la sécurité augmentée. Par exemple, quelques parties du secteur de services financiers ont déjà indiqué qu’elles sont très impatientes pour être le premier à adopter DNSSEC. Cependant, le secteur de services financiers attend également des conseils clairs des « registrars » et des fournisseurs de réseau sur la synchronisation pour l’implémentation de DNSSEC.
Il y a également des avantages sur la capacité à authentifier des individus dans une organisation et DNSSEC peut faciliter ceux-ci. Quelques organismes tireront bénéfice de déployer DNSSEC dans leurs environnements propres et privés, en assurant que leurs communications internes sont restées bloquées et authentifiées. Il semble probablement que quelques entreprises pourront accroître DNSSEC, dans les arrangements privés, de façon qu’il dépasse l’authentification simple des résultats d’une requête RR.

DNSSEC CAPEX et OPEX

Les « Capital Expenditure» (CAPEX) liées à DNSSEC sont liées à l’investissement pour les futurs bénéfices. Habituellement, ce sont des fonds dépensés pour acheter des capitaux ou pour ajouter à un inventaire existant des capitaux. Pour les « registrars » qui veulent fournir DNSSEC à leurs clients, le service est souvent un simple service additionnel (« add-on » sur un achat d’un client). Incluant ce dispositif dans une brochure du « registrars » est la seule action qu’un « registrars » typique doit investir afin d’offrir DNSSEC à leurs clients.
Contrairement à CAPEX, les «Operational Expense » (OPEX) sont des coûts continus pour faire fonctionner un service ou des affaires. Dans notre aperçu, l’OPEX principal lié à DNSSEC était un coût de la bande passante.

Barrière au déploiement à l’emplacement des utilisateurs

Pour que les utilisateurs tirent bénéfice de DNSSEC, ils devront utiliser le logiciel client qui implémente DNSSEC. Ceci imposera inévitablement des coûts additionnels pour les premiers « adopteurs » du DNSSEC. La majorité d’utilisateurs elles-mêmes sont peu susceptibles d’exiger un logiciel utilisant DNSSEC et, à moins que techniquement astucieux, la plupart des utilisateurs restent dans l’ignorance sur les avantages que le logiciel pourrait apporter et sur les menaces potentielles qui ont mené à son développement. Ils prennent seulement la décision pour adopter DNSSEC quand ces possibilités sont incluses comme dispositif additionnel pendant une mise à niveau du logiciel.
Pour ceux qui utilisent les serveurs récursifs pour des clients (par exemple accueillant des compagnies hôtes ou des fournisseurs de bande passante), DNSSEC pose également de nouveaux problèmes. Comme par exemple, ils devront traiter des situations où ils peuvent actuellement fournir des recherches automatiques quand leurs utilisateurs entrent une adresse invalide dans un navigateur ;cet arrangement ne facilitera pas la validation de la clef et DNSSEC ne fonctionnera pas. Ils devront savoir répondre aux échecs de signature, quelle que soit la raison.

Barrières au déploiement dans les réseaux du consommateur

Plusieurs des barrières au déploiement dans des réseaux du consommateur font écho sur l’émergence des autres paramétrages (par exemple par les fournisseurs et les administrateurs de DNS, le client, le logiciel, et les fournisseurs de réseau).
Tous auront un impact sur la façon dont DNSSEC est livré à l’utilisateur de la bande passante. Le comportement humain peut jouer un rôle plus en avant dans ce contexte car le niveau de la compréhension du sujet est souvent très bas. Il est plus probable que les consommateurs avec moins de connaissance de l’Internet ignorent tous les messages d’avertissement qui disent que les certificats ou les signatures sont invalides ou expirés. L’explication des avantages potentiels serait plus difficile, en particulier si la majorité des sites qu’ils ont visités n’utilisait pas DNSSEC.
Dans les navigateurs modernes, le logiciel effectue des vérifications pour s’assurer que le certificat digital du serveur web est valide. Quand ce n’est pas le cas, le navigateur affiche un message d’erreur que l’utilisateur doit reconnaître. Beaucoup d’utilisateurs cliquent simplement sur n’importe quel lien afin devoir le contenu qu’ils ont demandé à l’origine. DNSSEC peut être concerné par ce même cas pour les consommateurs : selon la façon dont l’interface utilisateur est construite, les protections que DNSSEC assure pourraient être évitées par le comportement de l’utilisateur.

Table des matières

Introduction
Partie I : Contexte Général
L’Association NIC-MG et son secteur d’activité
Partie II : Le protocole DNSSEC
I- Rappel sur le DNS
I.1-Historique
I.2- Définition
I.3- Rôle d’un serveur de noms
I.4- Flux information du protocole DNS
II-Menace pour le DNS
II.1 Menace sur la plateforme
II.2 Menace pour le DNS dans contexte d’hôte
II.2.1 La faiblesse dans les logiciels de serveur DNS
II.2.2 Attaque de déni de service (DoS)
II.3 Menaces relatives aux requêtes DNS et transactions
II.3.1 DNS Cache Poisoning
II.3.2 Interception de Paquet
II.3.3 Effacement d’un RR
II.3.4 DNS Spoofing
II.3.5 Attaque Kaminsky
II.4 But des attaques des serveurs de noms
II.5 Vulnérabilité du protocole DNS
III Le protocole DNSSEC
III.1 Vue d’ensemble de DNSSEC
III.2 Sécurisation du DNS par le protocole DNSSEC
III.3 Service apporté par le DNSSEC
III.4 Fonctionnement du DNSSEC
III.4.1 La cryptographie à clé publique
III.4.2 Signatures digitales
III.4.3 Extensions du DNS
III.4.3.1 Le RR KEY ou DNSKEY
III.4.3.2 Le RR SIG
III.4.3.3 Le RR NSEC (Next Secure)
III.4.3.4 Le RR DS (Delegation Signer)
III.4.4 Exemple de fonctionnement du protocole DNSSEC
III.4.5 Classification des informations DNS
III.5 Installation du protocole DNSSEC et configuration BIND
Partie III : Déploiement du DNSSEC
I- Historiques
II Les barrières au déploiement du DNSSEC
II.1 Barrière au déploiement au niveau des compagnies hôtes et les prestataires de service internet (ISP)
II.1.1Barrières techniques (barrière relative au protocole)
II.1.2 Barrières économiques
II.2 Barrière au déploiement à l’emplacement des utilisateurs
II.3 Barrières au déploiement dans les réseaux du consommateur
III Statistique du déploiement du DNSSEC
Conclusion
ANNEXES
RFCs relatives au DNSSEC
Systèmes d’exploitation utilisés pour le DNS
– Inventaire des logiciels serveurs DNS
– Compatibilité entre serveur DNS et les Systèmes d’exploitation
– Licence des serveurs DNS
Exemple de fichier de zone
Ligne contenant le domaine « .mg » dans le fichier de zone de la racine
GLOSSAIRE
Liste des figures
Liste des tableaux
REFERENCES
Bibliographie

Télécharger le rapport complet