IUT Montpellier - Architecture (DU) V.

Poupet

TD no 8 - Domain Name System (DNS)

Dans ce TD nous allons nous intresser au fonctionnement du Domain Name System (DNS), puis pour
illustrer son fonctionnement, une faille de scurit dcouverte par Dan Kaminsky en 2008 permettant
dempoisonner le cache dun serveur DNS afin de prendre le contrle dun domaine.

Exercice 1. Fonctionnement gnral

DNS est un acronyme signifiant Domain Name System. Cest un protocole permettant dassocier des
noms de domaine (par exemple www.chezmoi.fr) une adresse IP (par exemple 140.78.132.45). Les
machines se connectent entre-elles laide dadresses IP, mais les noms de domaine servent faciliter la
mmorisation et lutilisation pour les humains et permettent galement de structurer hierarchiquement
lensemble du rseau (en domaines, sous-domaines, etc.).
Lorsquun utilisateur veut contacter la machine nomme www.banque.net, il doit obtenir son adresse
IP. Ceci se fait en plusieurs tapes (illustres sur la Figure 1) :
a. le client demande lIP de www.banque.net au serveur DNS de son fournisseur daccs Internet
(FAI) ;
b. le serveur DNS du FAI ne connat pas ladresse. Il demande alors au serveur DNS responsable de
tous les noms de domaines 1 (a.root-servers.net) ladresse de www.banque.net ;
c. bien videmment, ce serveur ne connat pas toutes les adresses. Mais il sait que le serveur res-
ponsable du domaine .net est b.gtld.servers.net. Il renvoie alors le nom et ladresse IP de
ce serveur ;
d. le FAI demande alors ce serveur ladresse de www.banque.net ;
e. le DNS du domaine .net renvoie alors le nom et ladresse du serveur DNS responsable du do-
maine .banque.net ;
f. le FAI interroge ce dernier serveur DNS, qui connat ladresse de la machine www.banque.net
et la lui envoie ;
g. le serveur DNS du FAI peut finalement renvoyer ladresse IP de la machine demande par luti-
lisateur.
En pratique les serveurs DNS des FAI mmorisent les rponses aux questions quils ont poses dans
un cache, ce qui leur permet dviter de faire certaines requtes sils connaissent dj la rponse.
1. Quels sont les avantages apports par lutilisation dun cache pour le FAI, les serveurs DNS (parti-
culirement ceux de haut niveau et ceux correspondant des domaines trs demands, par exemple
google.com) et lutilisateur ?
R. Le cache permet de limiter le nombre de requtes effectues sur les serveurs les plus demands et
dacclrer la rponse. Pour le FAI, il y a moins de traffic avec lextrieur puisque les rponses aux
requtes DNS les plus frquentes (par exemple ladresse du domaine .fr ou dun domaine comme
google.com) sont dj connues (dans le cache) et quil nest donc pas ncessaire daller demander
aux domaines concerns.
Pour les domaines les plus demands, le fait que les FAI utilisent des caches permet de ne pas
surcharger leurs serveurs (imaginez si chaque fois quun personne voulait accder un lment
quelconque du domaine .com il fallait faire une requte sur le serveur !). En pratique, les serveurs
de plus haut niveau (les serveurs racines, et les serveurs des domaines .com, .fr, etc.) sont assez
peu sollicits puisque seuls les FAI les interrogent directement et comme leur IP ne change presque
jamais, la rponse est garde dans le cache pendant longtemps.
Enfin, mme les utilisateurs en profitent puisque les rponses leurs requtes sont plus rapides si
elles sont connues par leur FAI.
1. Parce quil faut bien pouvoir commencer quelque part, tous les FAI connaissent les adresses des serveurs
DNS de plus haut niveau. Ces serveurs sont trs importants et leurs adresses ne changent pas.

1
 F IGURE 1 Exemple de communications lors dune requte DNS.

2. Nimporte qui peut crer un serveur DNS qui prtend connatre les adresses IP des machines
dun domaine donn (et qui pourrait donc donner de fausses adresses IP). Pourquoi nest-ce pas un
problme ?

R. Si quelquun met en place un serveur DNS qui prtend donner des adresses IP correspondant
un domaine dj existant, aucun des serveurs DNS ne renverra les utilisateurs sur ce nouveau
serveur et donc aucune requte narrivera sur ce faux serveur.
Lorsque lon achte un nom de domaine, on dclare le serveur DNS qui lui est associ afin quil soit
connu des serveurs du niveau suprieur. Un serveur qui nest pas rfrenc par le niveau suprieur
nest jamais atteint.

Exercice 2. Dtail des communications

Les messages DNS sont changs selon le protocole User Datagram Protocol (UDP). Les commu-
nications UDP sont beaucoup plus simples quen TCP car elles ne ncessitent pas louverture dune
communication entre les deux participants, le message est directement envoy son destinataire sans
que celui-ci ait rpondre. Bien que plus simple, UDP prsente deux inconvnients par rapport TCP :
dune part il nest pas tolrant aux erreurs et dautre part il nest pas possible de sassurer de ladresse
IP dont provient un message.
Une communication DNS contient entre autres les informations suivantes :
les adresse IP et port de lmetteur ;
les adresse IP et port du destinataire ;
le numro de requte ;
la question pose et les rponses ventuelles ( Quelle est ladresse de la machine xxx.yyy.
zzz ? , Demander au serveur xxx.yyy.zzz. ou encore Ladresse de xxx.yyy.zzz est aa.
bb.cc.dd. )
Le numro de requte est fix par la machine qui met une requte DNS. Cela permet en particulier de
savoir quelle question correspond une rponse reue. Lorsque le message est une rponse, on rappelle

2
galement la question qui avait initialement t pose.
1. Les adresses qui apparaissent dans le message sont crites par lmetteur du message. En par-
ticulier, ladresse de lmetteur peut tre falsifie. Pourquoi est-il absurde de falsifier ladresse du
destinataire ?

R. Un paquet UDP est transmis de serveur en serveur jusquau destinataire qui est indiqu sur le
paquet. Sil est vrai quon peut mettre nimporte quelle adresse dmetteur (en faisant croire quon ne
fait que transmettre un paquet qui provient de quelquun dautre), changer ladresse du destinataire
revient changer le destinataire.
La situation est identique celle du courrier papier : on peut mettre nimporte quelle adresse dmet-
teur au dos de lenveloppe, mais ladresse sur la face principale est forcment celle du vrai destina-
taire puisque cest lui que sera transmise lenveloppe.
Lorsquun serveur DNS indique une adresse dans une rponse, cette rponse est accompagne dune
dure appele Time to Live (TTL) qui correspond la dure de validit de linformation transmise. Le
serveur qui reoit linformation ne doit donc la conserver dans son cache que pendant la dure indique.
2. Pourquoi est-il important de limiter la dure de vie des informations dans le cache ? Expliquez
pourquoi certaines adresses IP peuvent tre gardes en mmoire plus longtemps que dautres. Pour-
quoi est-il important de bien estimer lordre de grandeur des TTL ? (quels sont les inconvnients
dun TTL trop petit ou trop grand)

R. Indpendamment de problmes dempoisonnement que nous allons voir par la suite, les infor-
mations dans le cache ne doivent pas tre ternelles parce que les adresses IP des machines changent
au cours du temps.
Ainsi, si un FAI apprend que ladresse du serveur responsable du domaine youpi.tralala.fr
est 138.67.123.43 et quil dcide de stocker cette adresse pendant 10 jours (si le TTL indiqu par
le serveur au moment de la premire rponse est de 10 jours), mais que le lendemain ladresse IP
du serveur responsable du domaine change, alors pendant 9 jours le FAI aura une adresse errone
dans son cache. Si lancienne adresse nest plus utilise du tout, le FAI se rendra compte de lerreur
et redemandera probablement ladresse du serveur au niveau suprieur. Mais si cette adresse IP
correspond une machine diffrente, alors le serveur du FAI renverra toutes les requtes concernant
le domaine youpi.tralala.fr cette machine, ce qui peut entraner des risques de scurit, ou
une surcharge sur la machine cible.
Il est donc important de bien estimer le TTL dun serveur en fonction du temps quil reste avant un
changement. Si lon choisit un TTL trop court sur un domaine trs demand, il recevra normment
de requtes (une nouvelle de la part de chaque FAI lexpiration du TTL). Mais si on choisit un
TTL trop long et que ladresse change avant la fin du TTL, cel provoque une priode intermdiaire
pendant laquelle les informations contenues dans le cache du FAI sont fausses.
En pratique, les serveurs des domaines trs demands changent trs rarement dadresse ce qui per-
met dattribuer des TTL assez longs (de plusieurs jours) aux rponses envoyes. Lorsque lon sait
lavance quon va devoir changer un serveur on attend lexpiration de tous les TTL des rponses
qui ont t donnes renvoyant sur ce serveur avant de larrter (pendant la priode intermdiaire,
on renvoie toutes les nouvelles requtes sur un serveur diffrent).
De plus, lorsquon interroge un serveur qui ne connat pas directement ladresse demande, il renvoie
non seulement le nom du nouveau serveur interroger mais galement son adresse IP. Ces informations
supplmentaires (liste de noms de serveurs et adresses associes) sont appeles glue records et servent
viter les boucles infinies de requtes.
3. Expliquez sur lexemple du dbut de lexercice ce qui se passerait sil ny avait pas de glue record,
cest--dire si les serveurs DNS se contentaient de donner le nom du serveur suivant interroger,
sans donner son adresse.
Indication : le serveur b.gtld.servers.net appartient lui-mme au domaine dont il est respon-
sable...

3
 R. Lorsque lon demande ladresse de la machine recherche, et quun serveur DNS nous indique
quil faut interroger le serveur b.gtld.servers.net qui est responsable de ce domaine, sil ne
nous donne pas ladresse IP de cette machine, il faut faire une requte DNS pour obtenir lIP du ser-
veur. Or cette requte DNS va de nouveau nous rediriger vers ce mme serveur (puisquil appartient
un domaine dont il est responsable), ce qui entranerait une nouvelle requte DNS pour la mme
information...
Afin dviter cette boucle infinie, certains serveurs connaissent directement les IP des serveurs sur
lesquels ils renvoient et peuvent les ajouter leurs rponses.

Exercice 3. Lattaque simple

Le but de lattaque consiste envoyer un serveur DNS des informations fausses afin dempoisonner
son cache. Par exemple, quelquun essaiera de faire croire au DNS du FAI que ladresse de la machine
www.banque.net est 140.10.11.12 alors quen ralit cette adresse est ladresse dune machine quil
contrle.
1. Pourquoi quelquun voudrait-il empoisonner le cache dun serveur DNS ?

R. Falsifier des donnes de DNS peut permettre une personne de prendre le contrle dun do-
maine. En effet, si un utilisateur parvient faire croire un certain FAI que le serveur responsable
de toutes les adresses sur un domaine donn est une machine lui appartenant, et que cette adresse
est enregistre dans le cache du FAI, toutes les requtes effectues par des clients du FAI sur le
domaine en question seront renvoyes vers la machine de lattaquant. Si cette machine envoie des
rponses qui ressemblent assez au site (ou nimporte quel autre service informatique) que les utili-
sateurs attendent, ils ne se rendront pas compte quils ne sont pas en train de communiquer avec le
bon domaine.
Lattaquant peut alors obtenir des informations confidentielles (que seul le serveur que le client
voulait atteindre devrait connatre) ou bien donner de fausses informations au client en se faisant
passer pour le domaine usurp.

2. Quelles sont les personnes affectes par lattaque ?

R. Les personnes qui sont affectes par un empoisonnement de cache DNS sont les personnes qui
effectuent des requtes DNS sur le serveur empoisonn. Ainsi, si lon arrive falsifier lentre du
cache dun FAI contenant ladresse du serveur dun certain domaine, tous les utilisateurs de ce FAI
qui feront des requtes DNS sur ce domaine recevront de fausses informations.
Il est important de voir que la dure de lattaque correspond au TTL de linformation falsifie. Mais
comme cette dernire information est donne par lattaquant, le TTL est en gnral trs long afin
daugmenter la dure.

3. Le phishing est une technique visant attirer un utilisateur vers un site qui ressemble un site sen-
sible (banque, achat en ligne, etc.) pour lui faire envoyer ses informations bancaires ou personnelles.
En gnral, on utilise des liens hyper-texte pour amener lutilisateur sur le faux site.
La plupart des attaques de phishing reposent sur le fait que ladresse relle du faux site ressemble
fortement ladresse du site imit.
En quoi lempoisonnement de cache DNS est-il similaire du phishing ? En quoi lattaque DNS est-
elle plus puissante que les techniques de phishing ?

R. Sur le principe, les deux attaques sont similaires : diriger un utilisateur vers un site contrl
par lattaquant, se faisant passer pour le site sensible afin dobtenir des informations confidentielles.
Toutefois lempoisonnement de cache DNS est plus subtile et bien plus difficile dtecter (quasiment
impossible du point de vue de lutilisateur).
La plupart des attaques de fishing peuvent tre vites par un utilisateur attentif qui vrifie les
adresses des liens avant de cliquer. Dans le cas du DNS cest le FAI qui envoie une information
fausse (alors que lutilisateur fait confiance au FAI) et il ny a aucun moyen de savoir que cette
information est fausse ( moins de connatre toutes les distributions dadresses IP, ou bien de faire
toutes les requtes DNS en double diffrents serveurs...).

4
 Pour russir empoisonner le cache DNS, il faut envoyer une rponse au serveur de telle sorte quil
croie que cest une rponse une question quil a pose... Pour quune rponse soit accepte par le
serveur qui a pos la question il faut :
quelle arrive sur le bon port de communication ;
que la question rappele dans le message corresponde une question pose par le serveur ;
que le numro de requte corresponde celui qui avait t dcid par le serveur dans la question ;
que les adresses donnes dans la rponse (glue records) correspondent toutes des noms de ma-
chines se trouvant dans le mme domaine que le nom demand initialement (si lon demande
ladresse de www.banque.net on nacceptera pas les messages qui prtendent donner ladresse
de la machine www.google.com).
4. Expliquez lintrt de la dernire contrainte.
Indication : Nimporte qui peut ouvrir un nom de domaine quelconque puis contrler totalement
le serveur DNS correspondant ce nom de domaine. Que se passerait-il alors si cette personne
demandait au DNS de son FAI ladresse dune machine se trouvant dans son domaine ?

R. Il est capital de ne pas accepter dinformations sous forme de glue records concernant des domaines
extrieurs au domaine demand. En effet, sinon il suffirait un utilisateur quelconque possdant un
nom de domaine (ce qui est la porte de nimporte qui) de dire son serveur DNS que lorsque
lon effectue une requte sur son domaine, il renvoie sous forme de glue record une fausse adresse
IP correspondant un domaine important (par exemple le domaine dune banque). Il est normal
que le FAI fasse confiance au serveur de lutilisateur pour tout ce qui concerne son domaine (il na
aucun intrt donner de fausses adresses concernant son propre domaine) mais il ne faut surtout
pas faire confiance nimporte quel serveur DNS en ce qui concerne des informations sur les autres
domaines.
Dans lexemple prcdent, si le FAI ne tient compte que des glue records concernant le domaine
demand, la fausse adresse du domaine de la banque sera ignore.
La seule information difficile deviner est le numro de requte. Cependant, beaucoup de serveurs
DNS se contentent dincrmenter dun le numro chaque requte quils envoient, il est donc trs facile
de deviner un numro de requte si lon en reoit une...
5. Comment un utilisateur malveillant peut-il obtenir le numro de requte courant du serveur DNS
de son FAI ? (utiliser lindication de la question prcdente)

R. Pour avoir le numro de requte courant dun serveur, il faut recevoir une requte de la part de
ce serveur (puisque si on reoit une requte, cette requte contiendra le numro). Il est trs facile
pour un utilisateur de forcer le serveur DNS de son FAI lui envoyer une requte : il suffit de
contrler un domaine personnel sur lequel on contrle le serveur DNS et de faire une requte sur
une machine quelconque de ce domaine. Pour obtenir ladresse IP du serveur demand, le FAI va
faire des requtes DNS en descendant dans la hirarchie jusqu ce quon le redirige vers le DNS
du serveur demand (contrl par lutilisateur), qui recevra donc le numro de requte courant du
serveur DNS de son FAI.
Si lutilisateur veut de nouveau trouver le numro courant du serveur du FAI alors que ladresse de
la machine quil avait demande est dans le cache du serveur (dans ce cas il ny aurait pas de nou-
velle requte), il suffit de demander ladresse dune autre machine dans le mme domaine (mme si
cette machine nexiste pas, il faut une requte DNS pour que le FAI sache quelle nexiste pas).

6. Que se passe-t-il si lutilisateur malveillant demande son FAI ladresse de www.banque.net

R. Au moment o le FAI reoit la requte de lutilisateur, il va effectuer une requte DNS pour
obtenir ladresse de la machine www.banque.net (quil ne connat pas puisquelle nest pas dans
son cache). Lutilisateur connat alors tous les paramtres de la requte (il sait quelle est la machine

5
 demande, le port sur lequel communique le serveur de son FAI, le numro de requte, etc.) et peut
donc crire et envoyer au serveur DNS de son FAI une fausse rponse. Si cette rponse arrive avant la
rponse du vrai serveur DNS qui a t interrog pendant ce temps, le serveur du FAI la considrera
comme correcte et enregistrera la nouvelle information dans son cache.
La rponse du vrai serveur arrivera galement par la suite, mais comme elle rpond une question
pour laquelle le serveur du FAI a dj eu une rponse elle sera ignore.
En pratique, cette attaque est trs difficile raliser car il faut la fois que le cache du FAI ne contienne
pas ladresse demande et que la rponse envoye arrive avant celle du vritable DNS du site attaqu
(par ailleurs il faut deviner du premier coup le bon numro de requte ce qui nest pas si facile si lon
considre des gros FAI qui reoivent normment de requtes DNS)...

Exercice 4. La version amliore

On peut cependant amliorer grandement les chances de russir lattaque en falsifiant non plus
ladresse dune machine, mais en prenant le contrle de tout le domaine correspondant laide des
glue records...
1. Que se passe-t-il si un utilisateur demande au DNS de son FAI ladresse de la machine bidon01.
banque.net, puis envoie immdiatement une rponse contenant la bonne question, un numro de
requte qui a de fortes chances dtre correct et qui prtend que le serveur responsable du domaine
.banque.net est ns.banque.net et que son adresse est ladresse dune machine quil contrle ?

R. Toute lastuce de cette nouvelle attaque est dutiliser les glue records en envoyant de fausses infor-
mations concernant le domaine demand (donc la diffrence de ce qui a t discut la question
10, ici les informations donnes correspondent ce que le serveur attend et seront donc prises en
compte).
Si la rponse envoye par lattaquant arrive avant la vraie rponse du serveur DNS de banque.net,
elle sera considre comme vraie. Le serveur du FAI va non seulement considrer que ladresse
donne pour la machine bidon01.banque.net est correcte (mais cette machine est sans intrt,
et nexiste mme probablement pas), mais surtout il va tenir compte des glue records et considrer
que ces informations quil vient de recevoir sont justes et plus rcentes que celles qui sont dans le
cache. Le serveur du FAI va donc mettre jour son cache en changeant ladresse quil connaissait du
serveur de banque.net.
Ainsi, si lattaquant parvient envoyer sa rponse avant le vritable serveur DNS (ce qui nest pas si
difficile tant donn quil peut envoyer la rponse avant mme que la requte soit arrive au serveur
DNS cibl) et quil connat le numro de requte (cest moins facile, mais faisable, et comme on va le
voir dans la question suivante, on peut recommencer lattaque autant de fois que ncessaire), il aura
effectivement empoisonn lentre DNS du FAI concernant tout le domaine banque.net.
Notons qu ce stade, il ny a plus de raison que lerreur soit corrige. partir de l toutes les re-
qutes faites par le FAI vers le domaine banque.net seront envoyes la machine de lattaquant et
plus aucune natteindra le vrai serveur DNS du domaine. Il ny a donc aucune raison quun nouveau
glue record vienne craser linformation falsifie.

2. En supposant que la tentative dcrite dans la question prcdente choue (la rponse du vrai
serveur arrive avant la fausse), comment peut-on rpter lattaque mme si le serveur a enregistr la
rponse prcdente dans son cache ?

R. Il suffit de refaire une requte vers une autre machine du mme serveur (par exemple bidon02.
banque.net) qui elle nest pas dans le cache du FAI. Cela provoque une nouvelle requte ce qui
donne une nouvelle chance dinsrer une fausse rponse avant celle du vritable serveur.

3. Lorsque lattaquant a finalement russi faire passer sa rponse pour une vraie rponse DNS, que
se passe-t-il si un autre utilisateur du mme FAI essaie de se connecter la machine www.banque.
net ?

6
R. Si la vritable adresse de www.banque.net est encore dans le cache du FAI, il ne se passera
rien. Mais cette information finira bien par expirer. Et comme cest lattaquant qui a fix le TTL de la
fausse information quil a transmise au serveur du FAI, la fausse information durera plus longtemps
que les informations correctes.
Une fois que ladresse de www.banque.net expire du cache du FAI, lorsquun utilisateur essaie de
contacter cette machine, le FAI fait une requte DNS au serveur du domaine banque.net. Comme
ladresse de ce serveur est dans son cache, le FAI sadresse directement au serveur indiqu par le
cache, qui est une machine contrle par lattaquant. Ainsi, la rponse la requte de lutilisateur
est totalement contrle par lattaquant, qui peut facilement rediriger lutilisateur vers une machine
(et donc un site) quil contrle entirement. Ladresse de cette machine sera donc enregistre dans le
cache du FAI (probablement avec un TTL trs long puisquil est fix par lattaquant) et tous les autres
utilisateurs qui demandent cette machine seront galement redirigs vers la machine de lattaquant.

4. Proposez quelques solutions pour limiter le risque dune telle attaque.

R. La premire solution est dutiliser des numros de requte alatoires au lieu de les prendre dans
lordre. En effet, toute lattaque repose sur le fait que lattaquant parvient envoyer au serveur du
FAI une rponse contenant le bon numro de requte, alors quil na jamais reu la requte (puis-
quelle est envoye au vrai serveur DNS du domaine attaqu). En prendant des numros de requte
alatoirement, il devient plus difficile de fabriquer une rponse valide. Toutefois, comme lattaque
peut tre rpte autant de fois que voulu, il est envisageable quelle finisse par fonctionner. Les
numros de requte sont cods sur 16 bits (donc 65536 possibilits), ce qui nest pas norme et on
finirait par deviner le bon force dessayer.
On pourrait envisager daugmenter le nombre de numros diffrents (en passant par exemple sur 32
bits) ce qui diminuerait considrablement les chances de russite de lattaque, mais cela ncessiterait
de changer le protocole DNS ce qui nest pas ralisable en pratique car tout Internet repose sur
ce protocole (et le changer correspond une quantit de mise jours trop importante et surtout
provoquerait des pannes bien trop importantes).
Une autre solution consiste utiliser une plus grande plage de ports diffrents pour les requtes
et rponses. En gnral, un serveur DNS utilise toujours le mme port, ce qui rend lattaque facile
puisquil est facile de dcouvrir le port utilis. Si toutefois on dcide dutiliser une plus grande
plage de ports, slectionns alatoirement pour chaque requte, le nombre de combinaisons devient
bien plus grand (avec 2500 ports ouverts, ce qui correspond ce que peuvent utiliser certains DNS
couramment utiliss, le nombre de combinaisons de port et numro de requte est denviron 130
millions).