Article publié en 2002 dans MISC 4, co-écrit avec Eric Detoisien.

L'un des services à la fois le moins visible et le plus important d'Internet est le Domain Name System, ou tout simplement DNS. Du fait de son omniprésence, c'est une cible de choix pour un certain nombre d'attaques. Nous ne reviendrons pas ici sur le principe du DNS. Pour une rapide présentation, le lecteur se reportera à l'article L'homme du milieu[1] dans ce même numéro, et pour une étude plus approfondie, à l'excellent ouvrage DNS et BIND[2]. Nous allons en revanche présenter un peu plus en détails certains aspects du protocole qu'il est important de bien visualiser pour comprendre les différentes attaques possibles.

Un peu de théorie

Format des messages

La plupart du temps, les messages DNS sont contenus dans un paquet UDP unique au format de la figure 1. L'en-tête précise quels autres champs (question, réponse, ...) sont présents dans le message. Pour une description complète des différents éléments du message, on se reportera à la RFC 1035[3].

msgdns.png

Fig. 1 : Format d'un message DNS
Les champs réponse, autorité et compléments sont au même format. Ils contiennent tous des enregistrements de ressources (ou RR, pour Resource Records), et correspondent respectivement à la réponse à la question posée, à des serveurs de noms faisant autorité, et à des enregistrements liés à la question, mais n'étant pas strictement une réponse directe. Ces champs sont des listes concaténées (potentiellement vides) d'enregistrements de ressources, le nombre d'enregistrements présents dans une section donnée étant indiqué dans l'en-tête. Le format d'un enregistrement est celui de la figure 2.

rr.png

Fig. 2 : Format d'un enregistrement (RR)
Le champ de données d'une réponse dépend du type et de la classe. Par exemple, pour un enregistrement de type A et de classe IN, la réponse est une adresse IP. Par ailleurs, l'en-tête du message est illustrée par la figure 3 .

hdrdns.png

Fig. 3 : En-tête d'un message DNS
L'ID du message est un identifiant généré par l'émetteur de la requête, qui sera également présent dans toute réponse à cette requête. Nous reviendrons sur son importance plus tard. Les autres éléments de l'en-tête servent principalement à décrire le contenu du message :
  • QR : précise si le message est une requête (0) ou une réponse (1).
  • Opcode : type de la requête, standard (0), inverse (1) ou statut du serveur (2).
  • AA : précise si le serveur fait autorité pour la réponse.
  • TC : indique que le message est tronqué.
  • RD : demande de récursivité pour une requête.
  • RA : indique dans une réponse si la récursivité est disponible.
  • Z : non utilisé, doit être à 0.
  • RCODE : code de la réponse (0 s'il n'y a pas eu d'erreur).

Requêtes récursives et itératives

Les deux types de requête gérés par le DNS, récursives et itératives, diffèrent considérablement dans leur mode de résolution.
  • Lors d'une requête récursive à un serveur DNS, celui-ci va interroger lui-même d'autres serveurs, jusqu'à obtenir une réponse (ou échouer dans la résolution), et renvoie au client une réponse complète (ou une erreur s'il n'a pas pu résoudre le nom). À chaque fois qu'un serveur de noms effectue une requête récursive, il peut recevoir de nombreuses informations, qu'il va stocker dans son cache. Imaginons par exemple un utilisateur du domaine misc.fr, désireux de compléter son éducation, qui cherche à joindre la machine www.education.gouv.fr (figure 4)

    recursive.png

    Fig. 4 : Les requêtes récursives
    Il est à noter que dans ce cas, le serveur DNS local connaît déjà vraisemblablement le serveur faisant autorité pour la zone .fr, et qu'il n'a donc pas besoin de passer par un serveur racine pour obtenir cette information.
  • Dans le cas d'une requête itérative, le serveur ne va pas faire de nouvelles requêtes, et se contentera de fournir une réponse basée sur les informations dont il dispose déjà. Cela peut consister en une redirection vers des serveurs de noms plus appropriés (autorités du domaine concerné par la requête).
Notons qu'un serveur peut être configuré pour refuser les requêtes récursives.

Un problème courant : les fuites d'informations

Un serveur de noms est installé dans le seul but de fournir des informations à des clients. Cependant, il est courant qu'un serveur DNS fournisse trop d'informations, pouvant ainsi parfois faciliter la tâche d'un éventuel pirate.

Le transfert de zone

Le transfert de zone est une fonction normalement utilisée pour fournir à un serveur de noms esclave toutes les données concernant la ou les zones qu'il doit servir. Cependant, cette fonctionnalité peut également être utilisée par un pirate, fournissant de précieuses informations sur la zone servie. Dans certains cas, il se peut que le pirate n'apprenne rien d'intéressant. Dans d'autres, cela peut permettre la découverte de machines sur un réseau, machines qui pourraient par exemple être dissimulées par le biais de filtres divers. Par exemple, prenons le domaine fictif misc.fr, défini uniquement sur un serveur de noms local. La commande host va nous permettre de demander un transfert de zone (on pourrait aussi utiliser nslookup) :
$ host -l misc.fr localhost
misc.fr.            	NS	ambre.misc.fr.
elendil.misc.fr.    	A	172.16.1.13
ambre.misc.fr.      	A	172.16.1.11
On peut également obtenir des informations sur la configuration des zones :
misc.fr.            	SOA	ambre.misc.fr. dpo.ambre.misc.fr. (
                          1	;serial (version)
                          10800	;refresh period (3 hours)
                          3600	;retry interval (1 hour)
                          604800	;expire time (1 week)
                          86400	;default ttl (1 day)
                        )
misc.fr.                NS	ambre.misc.fr.
elendil.misc.fr.        A	172.16.1.13
www.misc.fr.            CNAME	elendil.misc.fr.
ambre.misc.fr.          A	172.16.1.11
La directive allow-transfer { none; }; dans la déclaration d'une zone dans le fichier named.conf (Bind 8.x) permet d'interdire totalement les transferts de zones. La déclaration none peut être remplacée par une liste d'adresses correspondant aux serveurs esclaves autorisés à faire ce type de requêtes.
$ host -l misc.fr localhost misc.fr AXFR record query refused by localhost No nameservers for misc.fr responded

Les zones internes

De nombreux réseaux connectés à internet utilisent des adresses dites privées[4], théoriquement non routables sur internet, par exemple 192.168.1.0/24. Cependant, si le serveur de noms de ce réseau est accessible de l'extérieur, et s'il propose des tables inverses (dans notre exemple, 1.168.192.in-addr.arpa.), il est possible de découvrir assez rapidement quelles adresses privées sont utilisées en effectuant une série de requêtes sur les plages les plus classiques. A partir de là, un attaquant pourrait utiliser ces informations pour par exemple créer des paquets spoofés à destination du réseau interne.

Le serveur DNS, un outil de déni de service

Les attaques par réflexion

Les attaques par réflexion sont une catégorie de déni de service dont le principe est simple : le ou les attaquants ne contactent jamais directement la victime, se contentant de générer des paquets spoofés avec comme adresse source celle de la victime, et d'envoyer ces paquets à des serveurs légitimes, qui répondront ensuite directement à la victime (figure 5)).

reflection.png

Fig. 5 : Principe d'une attaque par réflexion
Ce type d'attaque peut se faire en se basant sur des protocoles de bas niveau. Le site de Steve Gibson en a fait l'expérience, sa bande passante noyée sous un flux de SYN/ACK TCP, envoyés en réponse aux paquets SYN spoofés émis par l'attaquant. Cependant, il est beaucoup plus rentable d'utiliser ce type d'attaque au niveau applicatif, où un petit paquet émis peut générer une réponse beaucoup plus volumineuse, par un effet similaire à celui d'un bras de levier. Cela peut permettre la création d'un déni de service sans avoir ni une bande passante démesurée, ni tout un réseau de machines piratées (couramment appelées zombies, dans ce contexte) prêtes à saturer la victime. On se reportera à l'article Application-Level Reflection Attacks[5] pour approfondir ce sujet.

Le cas du DNS

Une requête DNS fera toujours un minimum de 18 octets : 12 octets d'en-tête, et un minimum de 6 octets pour le champ 'question'. Une requête sur ambre.misc.fr, par exemple, sera représentée par un message de 32 octets. La réponse à cette requête, quant à elle, constitue un message de 77 octets. Avec une simple requête, nous obtenons une réponse deux fois plus grosse. Si l'on considère maintenant une demande de transfert de la zone misc.fr, la requête représente 27 octets et la réponse 312 octets, ce qui fait un rapport de un pour dix, dans le cas peu favorable d'une toute petite zone. En rajoutant une dizaine d'enregistrements dans la zone, on arrive à un rapport 25 entre la requête et la réponse, et il s'agit encore d'une petite zone. En rassemblant une liste modérée de serveurs de noms supportant le transfert de zone, on peut donc très simplement monter une attaque d'une amplitude de plus de 25 fois la bande passante de l'attaquant. En prenant l'exemple d'un simple particulier utilisant le câble, il y a de quoi saturer une ligne de 12 Mbit/s. Pour un étudiant disposant d'une bande passante de plusieurs Mbit/s, il devient possible d'attaquer de très gros sites, par exemple.

Attaques liées au protocole DNS

Le principe des attaques liées au protocole DNS est relativement simple. Il consiste à corrompre la correspondance entre le nom d'une machine et l'adresse IP qui lui est normalement associée, typiquement pour rediriger du trafic initialement destiné à un serveur légitime vers une machine contrôlée par le pirate. Pour cela il existe deux grands types d'attaque, le DNS ID Spoofing qui agit directement au niveau de la communication DNS et le DNS Cache Poisoning qui exploite le cache des serveurs DNS ou des clients DNS.

DNS ID Spoofing

Lors de la description de l'en-tête du protocole DNS, il a été vu qu'un identifiant est utilisé pour la corrélation entre la question émise et la réponse reçue. La capture suivante montre ce processus :
192.168.0.2.32769 > 192.168.0.1.domain:  64561+ A? www.toto.com.
192.168.0.1.domain > 192.168.0.2.32769:  64561 q: A? www.toto.com.
1/0/0 www.toto.com. A 123.123.123.123
L'identifiant de cette requête DNS est 64561 et une réponse provenant du serveur DNS parvient avec ce même numéro. Par conséquent un moyen de corrompre la correspondance nom/ip est d'envoyer une réponse falsifiée à une requête légitime. Pour mener à bien cette opération et forger le paquet adéquate, l'identifiant est un des éléments indispensables. Le DNS ID Spoofing est réalisable à la foiscontre une machine cliente ou un serveur DNS. A partir de là, deux cas d'attaque sont possibles. Attaque sur un réseau local Sur un LAN cette attaque est triviale puisqu'il est possible de capturer le trafic via un quelconque sniffer. Afin de ne pas être gêné par un switch une attaque de type ARP Cache Poisoning fera en sorte de rediriger le trafic vers la machine de l'attaquant. Une analyse des requêtes DNS aboutit à la récupération de l'adresse IP source, du port UDP source, de l'identifiant DNS et de la question. La réponse est forgée en fonction de la requête et elle indique une fausse adresse IP. Il existe plusieurs outils automatisant cette attaque sur une réseau local comme dnsspoof (package dnsiff), ADMsniffID ou WinDNSSpoof (pour Windows). A noter qu'il est indispensable de répondre avant le serveur DNS carseule la première réponse est prise en compte. Pour s'en assurer les requêtesDNS rédirigées normalement par le pirate sont bloquées par un firewall. Il estpossible de ne laisser sortir que les requêtes qui ne sont pas destinées à êtrespoofées afin de ne pas bloquer l'intégralité des flux DNS de la victime. Une extension NetFilter sous Linux (patch 'string' d'Emmanuel Roger) analysant le contenu du paquet est une solution, de même sous Windows cette fonctionalité est incluse dans WinDNSSpoof couplé à un simple firewall personnel. L'exemple d'utilisation de WinDNSSpoof suivant illustre cette attaque en local : la machine du pirate lance WinDNSSpoof afin qu'il intercepte une requête sur le nom www.supersecret.fr pour le rediriger vers l'adresse IP 123.123.123.123
D:\>wds -n www.supersecret.fr -i 123.123.123.123 -g 00-C0-24-EE-49-EF
+ listening [www.supersecret.fr] DNS query
+ DNS query [www.supersecret.fr] from 192.168.0.2
+ DNS response [123.123.123.123] to 192.168.0.2
Du côté de la victime, la commande host montre le résultat.
[victime@chezlui]# host www.supersecret.fr www.supersecret.fr has address 123.123.123.123
Une victime utilisant un navigateur pour surfer sur le site www.supersecret.fr se retrouve alors sur un faux site capable de récupérer des informations confidentielles. Attaque depuis une machine distante Une attaque non locale est nettement plus difficile à mettre en oeuvre. Dans le cas d'un client DNS, le moment de la requête doit être connu ainsi que l'adresse IP du serveur DNS utilisé, le port source UDP et l'identifiant DNS. Et seulement avec ces informations, une requête forgée est possible. Cette attaque contre un client DNS n'est pas envisageable dans cette situation au vu de la difficulté à récupérer ces informations. En ce qui concerne le serveur DNS les conditions de l'attaque sont moins contraignantes. Soit mechant qui est propriétaire du domaine mechant.org et qui a de plus la main sur le serveur DNS associé à celui-ci. La victime est le serveur DNS du domaine victime.org. La première étape est l'envoi d'une requête sur www.mechant.org par mechant sur le serveur DNS de victime.org. A noter que cela n'est possible que si le serveur DNS de victime.org accepte les requêtes récursives. La figure 6 illustre cette étape :

dns1.jpg

Fig. 6 : DNS ID Spoofing - Etape 1
Le serveur DNS de mechant.org a sniffé l'identifiant de la requête du serveur DNS de victime.org. Pour la suite mechant émet une requête sur www.supersecret.fr à destination du serveur DNS de victime.org. La difficulté de l'attaque réside dans l'aptitude de mechant à forger une réponse DNS qui semblera valide au serveur de victime.org c'est à dire avec l'adresse IP du serveur DNS supersecret.fr) et le bon identifiant DNS. Il est donc impératifde trouver, de connaître ou de prédire celui-ci. La figure 7 expose cette partie de l'attaque :

dns2.jpg

Fig. 7 : DNS ID Spoofing - Etape 2
Afin de trouver le bon identifiant, la première idée est de se dire qu'un brute force sur l'identifiant est une solution satisfaisante. L'identifiant DNS est codé sur 16 bits, il y a donc 65535 possibilités. Une attaque par brute force est difficilement envisageable même avec un bon débit. A moins d'avoir beaucoup de chance, cette technique est à oublier, sans parler de sa discrétion très relative. Mieux vaut se reporter sur une éventuelle prédiction de l'identifiant.Le principe de la prédiction consiste à obtenir le prochain identifiant à partir d'une série de ces numéros récupérés au préalable. Une étude très intéressante a été effectuée par Michal Zalewski sur la prédiction des numéros de séquence TCP[6]. Celle-ci est facilement transposable aux identifiants DNS (comme mentionné dans cette même étude). Ce qu'il faut retenir est que si ces identifiants DNS sont facilement prédictibles, la probabilité d'usurper une requête avec le bon identifiant DNS est d'autant plus forte. A titre d'illustration voici quelques informations sur le niveau de prédictibilité des ID DNS d'un serveur DNS Windows 2000 et d'un serveur Bind :

w2k-id.jpg

Fig. 8 : Générateur d'ID DNS - Windows 2000 SP2 DNS Server

bind-id.jpg

Fig. 9 : Générateur d'ID DNS - Bind 9.2.1 DNS Server
Les attracteurs sont des concentrations de points (représentant les identifiants) plus ou moins forts. Plus les points sont dispersés plus l'aléa de l'algorithme degénération des identifiants est fort. Ces représentations graphiques montre que sous Windows 2000 les attracteurs sont très forts (peu de dispersions) et par conséquent la prédictabilité aussi. Le Bind possède un aléa partiel comme le montre la dispersion des points mais non suffisant puisque des attracteurs forts apparaissent (sous la forme de lignes constituant un cube vide). Ainsi quand un identifiant se trouve au niveau d'un attracteur il est plus simple de prédire le prochain qui se trouvera dans la même zone d'attraction.En conclusion ce DNS ID Spoofing va servir dans le second type d'attaque qu'est le DNS Cache Poisoning.

DNS Cache Poisoning

La RFC 1035 préconise l'utilisation d'un cache DNS. Sa fonction est de garder en "mémoire" les couples nom/ip que le serveur DNS ou un client DNS aurait déjà récupéré lors de requêtes précédentes. Ainsi, il n'est pas obligé d'émettre à nouveau une requête s'il est interrogé sur une correspondance déjà présente dans son cache. Une attaque de type Cache Poisoning consiste donc à corrompre ce cache avec des couples nom/ip falsifiés. Pour cela deux techniques sont utilisables. Prédiction des identifiants Cette attaque est celle décrite dans la partie consacrée au DNS ID Spoofing. Si la prédiction des identifiants DNS est simple, le nombre de réponses forgées est plus faible et la probabilité d'obtenir le bon identifiant très forte. Ainsi, si une de ces réponses est valide, la fausse adresse IP DNS est mise en cache. Celui-ci est alors corrompu par un couple nom/ip falsifié (www.supersecret.fr avec l'adresse IP 66.66.66.66). Lorsque des clients font des requêtes sur le nom www.supersecret.fr à partir du serveur DNS victime.org, la fausse adresse IP est renvoyée. Enregistrements de ressource forgés Pour cette attaque il est inutile de prédire l'identifiant DNS. Néanmoins, le serveur cible doit accepter la récursivité et le pirate posséder son propre serveur DNS et son nom de domaine. mechant toujours propriétaire de mechant.org envoie une requête sur www.mechant.org sur le serveur DNS de victime.org. Le serveur DNS de mechant.org va alors renvoyer une réponse avec en plus un champ Additional record particulier :
HEADER:
    opcode = QUERY, id = 7337, rcode = NOERROR
    header flags: reply, auth. answer, recursion avail.
    questions = 1, answers = 1, auth. records = 0, additional = 1
QUESTIONS:
    www.mechant.org., type = XX, class = 1
ANSWERS:
->  www.mechant.org.
    type = A, class = 1, ttl = 3355566, dlen = 4
    IP address = 123.123.12.12
ADDITIONAL RECORDS:
->  www.supersecret.fr.
    type = A, class = 1, ttl = 3355566, dlen = 4
    IP address = 66.66.66.66
Ce RR contient la fausse information indiquant l'association entre www.supersecret.fr et l'adresse IP 66.66.66.66. Si le serveur DNS n'est pas protégé contre ce type d'attaque il garde en cache tous les RR contenus dans la réponse. Un serveur Bind (à partir de la 4.9.7 et de la8.1.2) ne garde aucun RR de type Additional record ainsi que ceux ne concernant pas le domaine de la question. Seul un RR Authority record est falsifiable mais l'information est un nom de machine et non une adresse IP. Cependant les serveur DNS Windows mettent en cache les Additional record par défaut[8]. Après avoir aborder le cas des serveurs DNS, quelques mots sur le DNS Cache Poisoning des clients DNS sont indispensables. Les systèmes d'exploitation Windows NT/2000/XP possèdent leur propre cache DNS, son contenu est visualisé par la commande : ipconfig /displaydns. Il possède la particularité de prendre en compte tous les types RR. Il est donc possible possible d'attaquer directement une machine cliente si le serveur DNS qu'il utilise a la récursivité d'activé. L'exemple suivant illustre plus clairement ce cas. Dans un premier temps mechant doit forcer la victime à émettre une requête DNS sur www.mechant.org. Pour cela une simple page HTML, avec un tag quelconque prenant en paramètre une URL, envoyé par e-mail suffit. Cette requête est transmise par le serveur DNS victime.org, à noter que c'est un serveur interne et donc qu'il est forcément récursif. Le faux serveur DNS de mechant.org envoie alors une réponse avec de faux RR :
HEADER:
    opcode = QUERY, id = 7416, rcode = NOERROR
    header flags: reply, auth. answer, recursion avail.
    questions = 1, answers = 1, auth. records = 0, additional = 2
QUESTIONS:
    www.mechant.org., type = XX, class = 1
ANSWERS:
->  www.mechant.org.
    type = A, class = 1, ttl = 3355566, dlen = 4
    IP address = 172.18.100.33
ADDITIONAL RECORDS:
->  www.supersecret.fr
    type = A, class = 1, ttl = 3355566, dlen = 4
    IP address = 66.66.66.66->  www.vraimentsupersecret.fr
    type = A, class = 1, ttl = 3355566, dlen = 4
    IP address = 77.77.77.77
La figure 10 illustre cette attaque :

dns3.jpg

Fig. 10 : DNS Cache Poisoning du client
Par conséquent, si le serveur DNS de victime.org transmet la réponse à la victime sans ôter les RR indésirables à l'instar des serveur DNS Windows NT/2000 et de certains Bind, le cache du client est corrompu. La commande ipconfig /displaydns est là pour le prouver :
Configuration IP de Windows 2000
www.supersecret.fr.
------------------------------------------------------
  Nom Enregistrement  . : www.supersecret.fr
  Type Enregistrement . : 1
  Durée de vie  . . . . : 86393
  Longueur Données  . . : 4
  Section . . . . . . . : Answer
  Enregistr. A (Hôte) . :
                          66.66.66.66
www.vraimentsupersecret.fr.
------------------------------------------------------
  Nom Enregistrement  . : www.vraimentsupersecret.fr.
  Type Enregistrement . : 1
  Durée de vie  . . . . : 8393
  Longueur Données  . . : 4
  Section . . . . . . . : Answer
  Enregistr. A (Hôte) . :
                         77.77.77.77
Ainsi quand la victime va surfer sur le site www.supersecret.fr, le navigateur regarde d'abord le cache local et utilise l'adresse IP 66.66.66.66 sans passer par le serveur DNS de victime.org. Et au pire ce server DNS a aussi son cache de corrompu.

Conclusion

DNSSEC : une extension de DNS

Les problèmes de sécurité du DNS sont connus depuis longtemps. En1997, la RFC 2065 (actuellement RFC 2535) a commencé à formaliser des extensions de sécurité pour le protocole, en se basant sur des fonctionnalités cryptographiques. Ces extensions permettent d'une part de garantir l'intégrité et l'authentification des informations retournées par un serveur DNS, parle biais de signatures des RR d'une zone par une clé privée propre à l'autorité de cette zone, et d'autre part de garantir l'intégrité des transactions en elles-mêmes, et en particulier de vérifier qu'une requête n'a pas été altérée avant d'atteindre le serveur DNS (qui pourrait alors retourner une réponse valide, mais ne correspondant pas à la vraie question). Pour plus de détails sur ces extensions, le lecteur se reportera aux RFC appropriées, notamment les RFC 2535[9] et 3007[10]. Malheureusement, malgré une base installée de serveurs supportant DNSSEC (en particulier toutes les versions de Bind depuis la 8.2), l'utilisation reste anecdotique, probablement à cause des problèmes de distribution des clés, et il faudra sans doute attendre encore quelque temps avant l'adoption massive de ce système. D'ici là, quelques règles d'hygiène vous permettront de limiter les risques ...

Recommandations

Le protocole DNS tel qu'on l'utilise aujourd'hui n'est pas fiable et comporte des failles. Il est donc important d'en prendre conscience et de sécuriser son réseau et ses machines en conséquence. Concernant le DNS ID Spoofing en local, seul une surveillance accrue du réseau (détection de sniffer, protection contre l'ARP Cache Poisoning,...) est efficace. Un proxy minimise cette attaque car c'est lui qui effecte les requêtes DNS à condition qu'il ne soit pas dans le même réseau que les machines clientes. Contre le DNS Cache Poisoning au niveau des serveurs DNS publics, la récursivité doit être désactivée et des versions récentes utilisées. Pour les serveurs Windows NT/2000 le cache doit être sécurisé :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters Value Name: SecureResponses Data Type: REG_DWORD Value: 1
Enfin pour le cache DNS des machines Windows NT/2000/XP, la commande ipconfig /flushdns vide le cache et doit être utilisée régulièrement (en l'automatisant à chaque connexion de l'utilisateur par exemple).

Références

[1] L'homme du milieu, P. Prados, MISC 4 [2] DNS et BIND, Paul Albitz & Cricket Liu, éditions O'Reilly [3] RFC 1035 : Domain Names - Implementation and Specification [4] RFC 1918 : Address Allocation for Private Internets [5] Application-Level Reflection Attacks, Tom Vogt, http://web.lemuria.org/security/application-drdos.ps [6] Strange Attractors and TCP/IP Sequence Number Analysis, Michal Zalewski, http://razor.bindview.com/publish/papers/tcpseq.html [7] DNS ID Hacking, ADM, http://packetstormsecurity.nl/groups/ADM/ADM-DNS-SPOOF/ADMID.txt [8] Windows NT/2000 DNS server cache poisoning vulnerability, CERT, http://www.kb.cert.org/vuls/id/109475 [9] RFC 2535 : Domain Name System Security Extensions [10] RFC 3007 : Secure Domain Name System (DNS) Dynamic Update