Les Journes Nationales de scurit : premire dition (Le 11 et l 12 Mars)

Tutoriel de la scurisation des services rseau : DNSSEC (DNS SECURITY)

Ralis par : -Mokhtar AIT EL MRABTI. -Ghait YOUSSEF.

I.

Maquette gnrale de travaille :

Pour une premire initiation au service DNS, nous allons travailler sur larchitecture suivante :

Figure 1: Maquette de travaille.

En ce qui concerne loutil avec lequel on va travailler, nous avons opt pour NETKIT qui est un simulateur simple dutilisation et facile exploiter, au niveau du NETKIT, larchitecture configurer est la suivante :

Figure 2: Architecture simul sur NETKIT.

1. Configurations
Dans cette section, nous allons dfinir nos fichiers de configurations, afin de rendre notre architecture DNS fonctionnelle.

1.1.

Configuration du serveur racine :

Pour commencer on doit modifier le fichier : /etc/bind/named.conf, comme suit :

Figure 3: configuration du fichier:/etc/bind/named.conf pour le serveur racine

Dans ce fichier de configuration on a chang le type du serveur . de hint master afin dindiquer que notre serveur est le serveur maitre de la zone . => Cest le serveur autoritaire de la zone . . En deuxime lieu il faut se charger de la modification du fichier de la base de donnes, exceptionnellement, pour le serveur racine, la base de donnes est indiqu dans le fichier : /etc/bind/db.root. Pour vous simplifier la tache, au lieu de taper tout le texte de la base de donnes, il suffit dexcuter la commande suivant : cp db.local db.root

Le fichier db.local contient le format de base de la configuration de la base de donnes. Suivant notre architecture, on doit indiquer dans notre fichier de base de

donnes, ladresse IP du serveur qui gre cette zone, ainsi que les adresses des serveurs DNS de premier niveau, savoir le serveur ma .

Et donc le fichier de la base de donnes contiendra les informations suivantes :

Figure 4: configuration du fichier db.root, pour le serveur racine.

Et comme dernire modification de notre serveur racine, il suffit de modifier le fichier : /etc/resolv.conf, et y mettre ladresse IP du serveur courant savoir : 10.10.10.1.

1.2.

Configuration du serveur de la zone ma. :

Pour configurer le serveur de la zone ma ainsi que les serveurs qui vont suivre, il faut configurer les quartes fichiers suivant : Le fichier : /etc/bind/named.conf Le fichier de la base de donnes. Le fichier : /etc/resolv.conf. Le fichier: /etc/bind/db.root.

Dans la suite, nous allons analyser ce que lon va mettre dans ces fichiers :

Configuration du fichier : /etc/bind/named.conf. Dans ce fichier, on spcifie le nom de la zone sur lequel notre serveur est autoritaire et aussi le fichier de base de donnes qui contiendra les donnes concernant la zone gr par le serveur DNS.

Figure 5: configuration du fichier:/etc/bind/named.conf pour le serveur ma

Dans la suite, nous allons configurer le fichier de la base de donnes, qui va contenir lensemble des informations concernant les serveur grant les zones suivantes :

La zone ma. La zone grt. La zone grs.

Figure 6:Configuration du fichier: ma.db

Puis, il faut modifier le fichier : /etc/bind/db.root afin dy indiquer ladresse du serveur responsable de la zone racine (ce sont les deux dernires lignes ajout dans notre fichier). Cette modification devrait tre rapporte tous les serveurs part le serveur racine, dans la suite, on supposera que cest une tape comprise et qui sera toujours faite.

Figure 7: configuration du fichier: /etc/resolv pour le serveur ma

1.3.

Configuration de la zone grt.ma. :

Sans trop sattarder sur ces configurations, on va suivre les mme tapes que pour la configuration du serveur ma. : Dans le fichier : /etc/bind/named.conf, on va mettre :

Figure 8: Configuration du fichier: /etc/bind/named.conf pour le serveur grt

Puis on va configurer le fichier de la base de donnes :

Figure 9: configuration du fichier de la base de donnes: /etc/bind/grt.db

Figure 10: configuration du fichier: /etc/bind/db.root pour le serveur grt

Il ne faut tout de mme pas oublier de configurer le fichier : /etc/resolv.conf, et y mettre ladresse IP du serveur racine. 1.4. Configuration du serveur grs.ma :

Configuration du fichier : /etc/bind/named.conf :

Figure 11: Configuration du fichier: /etc/bind/named.conf pour le serveur grs.ma

Configuration du fichier de la base de donnes : /etc/bind/grs.db :

Figure 12: configuration du fichier de la base de donnes: /etc/bind/grs.db

Configuration du fichier : /etc/bind/db.root :

Figure 13: Configuration du fichier: /etc/bind/db.root

1.5.

Configuration de PC1, PC2, PC4 et PC5 :

Dans PC1 et PC2, une seule configuration mettre en uvre. Il sagit de changer le fichier : /etc/bind/resolv.conf et y mettre ladresse IP du serveur qui gre, la zone grt.ma., savoir : 10.10.10.3.

Figure 14: Configuration du fichier: /etc/resolv.conf pour PC2

Figure 15: Configuration du fichier: /etc/resolv.conf pour PC1

Remarque :

Avant de terminer avec la configuration, il faut redmarrer le service Bind, sur tous les serveurs avec la commande suivante : /etc/init.d/bind9 start/restart.

Figure 16: configuration du fichier: /etc/resolv.conf pour la machine PC4.

Figure 17: configuration du fichier: /etc/resolv.conf pour PC5.

1.6.

Configuration de la machine rseau :

On configure, le fichier : /etc/bind/db.root comme suit :

Figure 18: configuration du fichier: /etc/bind/db.root.

Figure 19: configuration de: /etc/bind/named.conf pour reseau.

Figure 20: Configuration du fichier: /etc/bind/reseau.db.

1.7.

Configuration de la machine securite :

Pour se faire on va configurer le fichier : /etc/bind/securite.db :

Figure 21: configuration du fichier: /etc/bind/securite.db

Figure 22: configuration du fichier: /etc/bind/db.root pour securite.

Figure 23: Configuratio du fichier: /etc/bind/named.conf pour securite.

1.8.

Configuration de la machine securite2 :

Figure 24: configuration du fichier: /etc/bind/named.conf de securite2.

II.

Test de configuration :

Afin de tester que notre architecture est oprationnelle, il suffit de Pinger, dun PC un autre, en utilisant non pas son adresse IP, mais son nom.

Figure 25: Test de Ping depuis PC1.

Figure 26: Test de Ping depuis PC2.

III.

Configuration dun serveur Secondaire :

Pour configurer un serveur secondaire, il suffit de modifier le fichier : /etc/bind/named.conf comme suit :

Figure 27: Configuration d'un serveur secondaire.

Dans ces configurations, on a indiquladresse IP du serveur primaire, responsable de la zone : grt.ma , et aussi, on a spcifi le chemin vers lesquels on va rcuprer le fichier de la base de donne depuis le serveur primaire. Avant de lancer notre serveur, on doit lancer la capture de paquet sur le domaine de collision que lon vient de dfinir dans notre architecture, la commande excuter sur la machine rel est la suivant :

vdump dc1 | wireshark i - -k

La dernire commande :

chose faire, cest de redmarrer le service bind grce la

/etc/init.d/bind9 restart/start

Figure 28: Capture des paquets chang entre le serveur primaire et le serveur secondaire.

On vrifie que notre serveur secondaire bien rcuprer le fichier de la base de donnes depuis le serveur primaire :

Figure 29: Le fichier de la base de donnes dans le serveur secondaire

On arrte le fonctionnement du serveur primaire grce la commande : /etc/init.d/bind9 stop Avant la vrification du Ping entre PC1 et PC2, il faut modifier le contenu du fichier : /etc/resolv.conf et y mettre ladresse IP du serveur secondaire :

Figure 30: Modification du fichier: /etc/resolv.conf pour PC2.

Figure 31:Modification du fichier: /etc/resolv.conf pour PC1.

Et on vrifie que PC2 arrive pinger sur PC1 :

Figure 32: Test de Ping aprs prise de fonctionnement par le slave

On remarque via loutil wireshark , que le pc1 lorsquil veut pinger consulte bel et bien le serveur secondaire, ayant ladresse IP, 10.10.10.4 :

Figure 33: vrification du serveur secondaire.

IV.

Exemple de configuration dune ACL :

Dans notre serveur secondaire, nous allons ajouter une instruction :

Figure 34: Utilisation d'une ACL.

Ici nous avons dfinit une ACL appel limited, et quidentifie le PC1 (adresse IP 10.10.10.6). On relance notre serveur DNS, grce la commande : /etc/init.d/bind9 restart

Figure 35: Test aprs l'utilisation d'une ACL.

On remarque que e le PC1, arrive accder aux donnes offert par le serveur alors que PC2 ny arrive pas pars quil nest pas identifier par lACL limited .

V.

Configuration des vues :

Pour se faire, on va configurer un nouveau domaine dit grt3.ma : Dans le fichier : /etc/bind/named.conf, nous allons mettre en place deux vues : Une vue LAN, dans laquelle on va spcifier lensemble des adresses locales 10.10.9/24 . Une vue WAN, dans laquelle on va spcifier lensemble des adresses diffrentes de 10.10.9.0/24. Dans le premier cas, ces machines auront accs au fichier : /etc/bind/grt3.db :

Figure 36: configuration du fichier: /etc/bind/grt3.db.

Et dans le deuxime cas la base de donnes utilise ne contiendra que les informations quon dcide que a soit visible pour lextrieur :

/etc/bind/grt3.limited.db :

Figure 37: configuration du fichier: /etc/bind/grt3.limited.db

Le fichier : /etc/bind/named.conf de notre machine grt3 contiendra donc les informations suivantes :

Figure 38: Utilisation d'une vue: configuration du fichier: /etc/bind/namde.conf

Remarque : Dans toutes les machines, vues dans la section prcdente, il faut excuter la commande : Route add default gw @IP_Du_routeur (10.10.10.8). Dans les machines grt3 et pc3, on doit ajouter la commande : Route add default gw @IP_Du_routeur (10.10.9.1).

Figure 39: Test du fonctionnement des configurations avant lutilisation de la vue.

Figure 40: Test aprs l'utilisation de la vue.

Figure 41: Test de configuration avant utilisation de la vue

Figure 42: Test de configuration aprs utilisation de la vue.

VI.

Partage de charge entre serveurs

En pratique, pour viter des congestions au niveau de serveur, on doit partager la mme tche entre plusieurs serveurs a laide de DNS. On peut le considrer comme une solution temporaire contre une attaque de dni de service mais pas efficace. Lorsquun serveur DNS rpond un client, il peut non pas fournir tout simplement une seule adresse IP, mais une liste dadresse IP, dans un ordre donn. Dans le fichier de la zone de securite db.securite , on ajoute : ....... securite.grs.ma. IN IN NS NS securite.securite.grs.ma. securite2.securite.grs.ma.

securite.securite.grs.ma. IN securite2.securite.grs.ma.

A IN

10.10.10.5 A 10.10.10.55

www.securite.grs.ma. www.securite.grs.ma. .......

IN IN

A A

10.10.10.5 10.10.10.55

Je re jjjjjjjjjj Voici ce quil faut ajouter dans le fichier named.conf.options rrset-order { class IN type A name "www.securite.grs.ma" order random; class IN type NS name "securite.securite.grs.ma" order cyclic; };

La premire ligne est ncessaire pour dclarer un partage entre les serveurs. Deuxime ligne signifie lenvoie dune adresse IP alatoire parmi une liste des adresses IP prdfinie dans le fichier de la zone correspondant

www.securite.grs.ma . Deuxime ligne signifie lenvoie de nom serveur DNS correspondant

securite.securite.grs.ma dune faon cyclique Il y a trois options possibles : fixed : Retourne toujours les enregistrements correspondants dans le mme ordre. random : Retourne les enregistrements correspondants dans un ordre alatoire. cyclic : Retourne les enregistrements correspondants dans un ordre cyclique (round-robin). Pour vrifier la configuration, il suffit de lancer le wireshark ou tester avec la commande nslookup (pour NS type=ns, et A type=A).

VII.

Implmentation de DNSSEC

On va travailler sur la mme plateforme utilise prcdemment, en particulier nous allons travailler sur la partie suivante :

On doit au pralable installer le package dnssec-tools

1. La cinmatique de cette partie

On va commencer tout dabord par la gnration des cls pour chaque zone, dans notre cas, cela concerne les zones : ma , grs.ma , securite.grs.ma Par la suite on signe les zones par les cls gnres prcdemment. Cest ce quon appelle une scurisation locale. Aprs on cre ce quon appelle une chaine de confiance entre les zones parents et filles ; scurisation globale. reseau.grs.ma ,

On partage une cl de confiance entre le serveur grt et le serveur grs pour vrifier les rponses DNS. Aussi, on va scuriser le transfert de la zone entre un serveur principal et un serveur secondaire.

2. Etapes de scurisation de service DNS avec loutil DNSSEC 2.1 Gnration des cls de scurit

Loutil dnssec-keygen permet de gnrer des clefs cryptographiques de diffrents types et diffrentes longueurs. On utilise deux cls pour la signature: ZSK (Zone Signing Key) et KSK (Key Signing Key). Ses rles sont : ZSK : Cl qui signe les enregistrements dune zone. C'est une cl de taille rduite que l'on changera frquemment. KSK : Cl qui fait office de maillon de confiance. Elle ne signe que le DNSKEY RRset donc elle peut tre de taille plus longue, ce qui permet de limiter sa frquence de renouvellement (roulement). On va donc gnrer des cls de taille diffrente. On commence par la ZSK :

# dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom n ZONE grs.ma

Cette commande cre deux fichiers : Kgrs.ma.+005+15230.key (partie publique) Kgrs.ma.+005+15230.private (partie prive) De la mme manire, on gnre la KSK de la zone : # dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom n ZONE grs.ma

Deux fichiers sont nouveau crs : Kensa.ma.+005+54272.key (partie publique). Kensa.ma.+005+54272.private (partie prive). On donnera les droits 0444 (-r--r--r--) aux parties publiques et 0400 (-r--------) aux parties prives. On fait la mme chose pour les autres zones cites prcdemment.

2.2

Signature des zones scurit local

On utilise loutil dnssec-signzone qui renvoie une zone signe partir dune zone non-signe. Pour plus dinformation sur cet outil, il suffit de taper la commande suivante : dnssec-signzone h Avant de signer la zone, il faut insrer les cls dans le fichier de la zone. Deux mthodes sont possibles :

#cat Kgrs.ma.+005+15230.key >>db.grs #cat Kgrs.ma.+005+54272.key >>db.grs

O db.grs est le nom du fichier de la zone de ensa.ma . On peut le faire galement avec la directive $INCLUDE en ajoutant cette ligne la fin du fichier de la zone.

$INCLUDE Kgrs.ma.+005+15230.key $INCLUDE Kgrs.ma.+005+54272.key

Remarque : Il faut incrmenter le serial avant de signer la zone Maintenant on passe la procdure de signature en rassemblant dans le mme rpertoire la zone signer, ainsi que les clefs servant la signer ; il sagit de rpertoire /etc/bind . On lance la commande suivante : #dnssec-signzone p t k Kgrs.ma.+005+54272.private o grs.ma db.ensa Kgrs.ma.+005+15230.private

Cette commande renvoie db.grs.signed . Il faut ajouter dans loption dans le fichier named.conf.options : options{ dnssec-enable yes ; }; Il ne reste plus qu recharger la zone dans le serveur BIND, en appliquant la commande suivante: #/etc/init.d/bind9 restart Il suffit maintenant de refaire la mme procdure dans les zones scuriser afin de passer ltape suivante qui est intressante pour achever le dploiement de DNNSEC. Chaque fois quil y a un changement dans les fichiers concernant DNS, il est ncessaire dexcuter la commande : #/etc/init.d/bind9 restart

Rsum sur les options de la commande dnssec-signzone

-p : Utiliser des donnes pseudo-alatoire lors de la signature de la zone. C'est plus rapide, mais moins sr, que l'utilisation relle des donnes alatoires. Cette option peut tre utilise lors de la signature de grandes zones ou lorsque la source dentropie est limit. -r randomdev : Indique la source d'ala. Si le systme d'exploitation ne fournit pas de /dev/urandom ou un dispositif quivalent, la source par dfaut de l'alatoire est entre au clavier. randomdev spcifie le nom d'un priphrique en mode caractre ou un fichier contenant des donnes alatoires pour tre utilis au lieu par dfaut. -t : Affiche des statistiques lachvement. -k key : Traiter cl spcifie en tant que cl de signature de cls sans tenir compte des drapeaux cls. Cette option peut tre spcifie plusieurs fois. -o origin : L'origine de zone. S'il n'est pas spcifi, le nom du fichier de zone est suppos tre l'origine. -f output-file : Le nom du fichier de sortie contenant la zone sign. La valeur par dfaut consiste ajouter .signed l'entre de nom de fichier. -e end-time : Prciser la date et l'heure o les documents gnrs RRSIG expire Comme pour start-time, un temps absolu est indiqu dans la notation YYYYMMDDHHMMSS. Une heure par rapport l'heure de dbut est indique par + N, qui est N secondes de l'heure de dbut. Une heure par rapport l'heure actuelle est indique par now + N. Si aucune end-time est spcifi, 30 jours compter de l'heure de dbut est utilis par dfaut.

2.3

Scurit globale

Maintenant, la zone grs.ma est scurise localement, cest--dire que les enregistrements signs de cette zone peuvent tre vrifis par quiconque est en possession de la KSK de cette zone et la configure comme clef de confiance. Cest envisageable lchelle dun rseau local, mais il est difficilement envisageable de transmettre cette KSK grande chelle ; il est donc ncessaire dinsrer cette zone dans un modle scuris global en la reliant par le biais de chanes de confiance des points dentre scuriss situs plus haut dans larbre. Dans larbre DNS scuris, la zone grs.ma a pour zone parente la zone ma et pour zones filles les zones reseau.grs.ma et securite.grs.ma . Maintenant ces 4 zones sont scurises localement. On doit maintenant tablir des dlgations scurises entre ma et grs.ma et entre grs.ma et ses deux zones filles reseau.grs.ma et securite.grs.ma .

Loutil dnssec-signzone permet de raliser la scurisation globale: une zone fille transmet son keyset sa zone parente ; Le keyset contient toutes les KSK actives dans la zone fille (les clefs qui signent le keyset ), la zone parente va gnrer autant de DS que de KSK prsentes dans le keyset transmis. Avant de lancer dnssec-signzone , on place tous les keysets transmis par les zones filles dans un rpertoire que lon spcifiera laide de loption -d . Le keyset dune zone est en fait un simple fichier nomm keyset<zone> qui contient la(les) clef(s) que la zone fille souhaite faire authentifier.

Il est noter que le fait de signer une zone avec loutil dnssec-signzone gnre automatiquement le keyset correspondant cette zone. Pour insrer grs.ma dans la chane de confiance, on suivra donc les tapes suivantes : 1) Les zones filles reseau.grs.ma et securite.grs.ma signent leurs zones laide de dnssec-signzone , et gnrent ainsi leur keysets . 2) On rcupre les keysets transmis par les zones filles ( keysetreseau.grs.ma. et keyset-securite.grs.ma. ) et on les place dans le rpertoire /etc/bind /dnssec/keyset par exemple. 3) On lance la commande suivante qui tient compte de lexistence de ces keysets :
# dnssec-signzone -r /dev/urandom -o db.grs -f db.grs.signed -d dnssec/keyset -e +1296000 -k Kgrs.ma+005+54272.private grs.ma Kgrs.ma+005+15230.private

4) les dlgations scurises vers nos deux zones filles sont en place. 5) dnssec-signzone a galement gnr keyset-grs.ma. et la plac dans le rpertoire dnssec/keyset spcifi plus haut. 6) On peut maintenant transmettre ce keyset la zone parente ma qui en signant sa zone de la mme manire que ci-dessus va gnrer DNSKEY et ainsi mettre en place notre dlgation scurise. Il suffit donc maintenant pour un serveur davoir la clef de ma comme clef de confiance pour vrifier toutes les donnes contenues dans les zones grs.ma , reseau.grs.ma et securite.grs.ma. Cest le sujet du paragraphe suivant.

2.4

Ajout de cl de confiance chez le client

Au niveau de serveur grt , on ajoute dans le fichier named.conf.options

forwarders { 10.10.10.5; }; dnssec-enable yes;

On intgre maintenant le keyset de cette zone dans le serveur grt dans le fichier named.conf dans loption trusted-keys :
Trusted-keys { grs.ma 256 3 Awaddfejfidjsfnskfkjshjfhjsdfjsdfjcbxnbvnxb.; }; 5

2.5

Vrification de la configuration DNSSEC

On vrifie la configuration de DNSSec par la commande : dig +dnssec

2.6

Scurisation de la liaison entre le serveur principal et le serveur secondaire en utilisant TSIG

Dans certains cas, ce ne sont pas les donnes DNS qui ont besoin dtre scurises, mais les transactions DNS, cest le cas de transfert de zone entre un serveur principal et un serveur secondaire. Nous allons utiliser une mthode base sur la cryptographie symtrique: TSIG.

TSIG est une mthode de scurisation qui peut tre utilise de manire indpendante DNSSec et la scurisation des zones voque dans les parties prcdentes. TSIG et DNSsec sont donc complmentaires pour assurer une scurisation complte au DNS (scurit des donnes et des transactions) mais il est tout fait possible dutiliser TSIG sur une zone non signe (pour scuriser un transfert de zone par exemple). On utilise loutil dnssec-keygen pour gnrer la cl TSIG .
On lance la commande suivante : #dnssec-keygen -a securite-securite2 hmac-md5 -b 128 -n HOST

Cette commande retourne : Ksecurite-securite2.+157+51370. Elle gnre aussi deux fichiers Ksecurite-securite2.+157+51370.key et Ksecurite-securite2.+157+51370.private , Ces deux fichiers

doivent tre dots des droits 400 (lecture seule uniquement pour le propritaire de la clef) et tre conservs dans un endroit sr. Ces deux fichiers contiennent le mme secret et cest ce secret qui sera utilis par TSIG . On doit mettre une commande include dans le fichier named.conf.
Le fichier en question, qu'on pourrait nommer securite-securite2_tsigkey , aura comme contenu:

key securite-securite2 { algorithm hmac-md5 ; secret "bWEgcGhyYXNlCg=="; };

Il suffit de copier lun des fichiers gnrs

prcdemment dans securite-

securite2_tsigkey et faire les changements possibles. La configuration sur les serveurs primaire et secondaire est alors la suivante: sur le primaire : ... include /etc/bind/securitesecurite2_tsigkey; ... zone securite.grs.ma { type master ; file /etc/bind/db.securite.signed; allow-transfer { key securite-securite2. ; }; La commande allow-transfer permet de spcifier une liste dentits ayant le droit deffectuer un transfert de zone ; ici ce seront les utilisateurs de la clef securite-securite2 , savoir securite2.securite.grs.ma . sur le secondaire : ... include /etc/bind/securitessecurite2_tsigkey; ... zone securite.grs.ma { type slave ; file /var/cache/bind/db.securite.signed; masters { 10.10.10.5;} ; }; ... server est utilise pour spcifier que la clef securiteLa commande server 10.10.10.5 { keys { securite- securite2. ; } ; securite2 doit tre utilise pour toute communication avec ce serveur ; ici cela signifie que securite2 devra utiliser la clef securite- securite2 chaque fois quil communiquera avec securite.securite.grs.ma . Tout transfert de zone commence par une question du secondaire au primaire portant sur le SOA de la zone en question. Il est donc ncessaire que le secondaire puisse effectuer cette requte : si le primaire a mis en place une access-list pour la commande allowquery , alors le secondaire doit faire partie de cette access-list .

Il suffit par la suite de redmarrer le service DNS dans les deux serveurs.

2.7

Vrification de mise jour scurise entre le serveur principal et le serveur secondaire

Avec loutil Wireshark , on vrifie le transfert de fichier de la zone du serveur principal au serveur secondaire aprs la vrification davoir la cl de confiance entre ces deux serveurs : securite-securite2

IV.

Enregistrement SRV

Les enregistrements SRV (dits aussi Service Record) dsigne un enregistrement gnrique qui dfinit le service fournir par un hte dtermin. Le fonctionnement thorique du SRV est simple : grce un enregistrement SRV, il est possible de localiser, via une demande DNS, le serveur (nom dhte) fournissant un service dtermin (service web, http) pour un domaine spcifique (ensa2011.ac.ma.) Dans notre cas, on peut faire indiquer plusieurs services fournis par un hte spcifique. Dans le fichier de la zone db.grt , on ajoute.

_sip._tcp.grt.ma. _sip._tcp.grt.ma. _sip._tcp.grt.ma. _sip._tcp.grt.ma. sipserver.grt.ma. moyen-sip1.grt.ma. moyen-sip1.grt.ma. petit-sip.grt.ma.

IN IN IN IN IN IN IN IN

SRV 10 SRV 10 SRV SRV

50 5060 gros-sipr.grt.ma. 25 5060 moyen-sip1.grt.ma. moyen-sip2.grt.ma. petit-sip.grt.ma.

10 25 5060 15 10 5060

A 10.10.10.3 A 10.10.10.6 A 10.10.10.7 A 10.10.10.33 ; il suffit de crer une autre machine qui a

Le premier enregistrement pointe vers un serveur nomm gros-sip.grt.ma qui attend des connexions SIP sur le port TCP numro 5060. Ici, la priorit indique est de 10, et le poids est de 50. Les trois premiers enregistrements ont tous une priorit de 10. Les clients vont donc devoir utiliser le champ poids afin de dterminer quel serveur contacter. Pour ce champ, la somme des trois valeurs est 100, donc gros-sip.grt.ma sera utilis 50% du temps, et chacun des deux autres (moyen-sip1 et moyen-sip2) sera utilis 25% du temps. Si, gros-sip devenait indisponible, les deux autres serveurs "moeyn-sip1/2", se partageraient alors la charge, ayant un poids identique. Par ailleurs, si ces serveurs de priorit 10 deviennent tous trois indisponibles, l'enregistrement l'occurrence de priorit immdiatement Il suprieure s'agir sera d'une choisi, en

petit-sip.grt.ma .

peut

machine

gographiquement loigne des trois autres, donc a priori non touche par la cause de l'indisponibilit de celles-ci. On peut faire la mme chose avec les autres services : _http._tcp.grt.ma. IN www.grt.ma. SRV 0 5 80 www.grt.ma. IN A 10.10.10.3

_ftp._tcp.grt.ma. ftp.grt.ma.

IN IN

SRV A

1 10 21 ftp.grt.ma.

10.10.10.3

La vrification peut tre faite aussi par nslookup et aussi par wireshark .