Le Domain Name System (ou DNS, système de noms de domaine) est un service permettant d'établir une correspondance entre une adresse IP et un nom de domaine.
Pour ce TP, nous utiliserons la commande dig.
Exemple d'utilisation simple de type 'a' (nom vers adresse) :
vanvincq@CP2L /media/Emulation/Master-2-ISIDIS/CPLL/JournalDeBord $ dig batman.org
; <<>> DiG 9.7.3 <<>> batman.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53878
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;batman.org. IN A
;; ANSWER SECTION:
batman.org. 3600 IN A 168.161.242.18
;; Query time: 122 msec
;; SERVER: 80.10.246.2#53(80.10.246.2)
;; WHEN: Sat Mar 3 10:20:35 2012
;; MSG SIZE rcvd: 44
Autre exemple du type 'mx' (récupération du serveur de mail) :
vanvincq@CP2L /media/Emulation/Master-2-ISIDIS/CPLL/JournalDeBord $ dig mx batman.org
; <<>> DiG 9.7.3 <<>> mx batman.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30848
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;batman.org. IN MX
;; AUTHORITY SECTION:
batman.org. 3562 IN SOA ns.warnerbros.com. named-mgr.warnerbros.com. 2007032200 3600 1800 604800 3600
;; Query time: 24 msec
;; SERVER: 80.10.246.2#53(80.10.246.2)
;; WHEN: Sat Mar 3 10:25:56 2012
;; MSG SIZE rcvd: 91
vanvincq@CP2L /media/Emulation/Master-2-ISIDIS/CPLL/JournalDeBord $ dig eof.eu.org
; <<>> DiG 9.3.1 <<>> eof.eu.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62239
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;eof.eu.org. IN A
;; ANSWER SECTION:
eof.eu.org. 259200 IN A 195.115.89.182
;; AUTHORITY SECTION:
eof.eu.org. 259200 IN NS ns.eof.eu.org.
eof.eu.org. 259200 IN NS ns2.eof.eu.org.
;; Query time: 26 msec
;; SERVER: 172.16.0.42#53(172.16.0.42)
;; WHEN: Mon Aug 22 10:02:51 2005
;; MSG SIZE r
Interpréter ce résultat. Qui est en charge de servir la zone eof.eu.org ?
Les serveurs autoritaires d'un domaine sont marqués par le type NS. Dans la section autoritaire du résultat, on peut constater que ceux en charge du domaine eof.eu.org sont ns.eof.eu.org et ns2.eof.eu.org. On peut également utiliser la commande dig avec le paramètre 'ns' pour obtenir les serveurs autoritaire en charge d'un quelconque domaine.
Mettez-vous à la place d'un serveur DNS et indiquez toutes les requêtes DNS effectuées pour résoudre eof.eu.org en utilisant dig.
Pour suivre en détail les requêtes DNS effectuées, on peut employer l'option +trace de la commande dig. Elle permet de suivre la résolution de nom à partir des serveurs racines (root) vers le serveur recherché.
vanvincq@CP2L ~ $ dig eof.eu.org +trace
; <<>> DiG 9.7.3 <<>> eof.eu.org +trace
;; global options: +cmd
. 345240 IN NS i.root-servers.net.
. 345240 IN NS m.root-servers.net.
. 345240 IN NS e.root-servers.net.
. 345240 IN NS c.root-servers.net.
. 345240 IN NS k.root-servers.net.
. 345240 IN NS a.root-servers.net.
. 345240 IN NS d.root-servers.net.
. 345240 IN NS f.root-servers.net.
. 345240 IN NS l.root-servers.net.
. 345240 IN NS h.root-servers.net.
. 345240 IN NS g.root-servers.net.
. 345240 IN NS b.root-servers.net.
. 345240 IN NS j.root-servers.net.
;; Received 228 bytes from 80.10.246.2#53(80.10.246.2) in 23 ms
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS a2.org.afilias-nst.info.
org. 172800 IN NS b0.org.afilias-nst.org.
org. 172800 IN NS b2.org.afilias-nst.org.
org. 172800 IN NS c0.org.afilias-nst.info.
org. 172800 IN NS d0.org.afilias-nst.org.
;; Received 433 bytes from 128.63.2.53#53(h.root-servers.net) in 102 ms
eu.org. 86400 IN NS ns-slave.free.org.
eu.org. 86400 IN NS ns-v6.eu.org.
eu.org. 86400 IN NS ns1.pasteur.fr.
eu.org. 86400 IN NS ns0.pasteur.fr.
eu.org. 86400 IN NS dns3.gandi.net.
eu.org. 86400 IN NS auth1.dns.elm.net.
;; Received 250 bytes from 199.19.57.1#53(d0.org.afilias-nst.org) in 40 ms
eof.eu.org. 259200 IN NS NS.eof.eu.org.
eof.eu.org. 259200 IN NS NS2.eof.eu.org.
;; Received 95 bytes from 157.99.64.65#53(ns0.pasteur.fr) in 34 ms
eof.eu.org. 86400 IN A 86.64.63.108
eof.eu.org. 86400 IN NS ns.eof.eu.org.
eof.eu.org. 86400 IN NS ns2.eof.eu.org.
;; Received 111 bytes from 86.64.63.108#53(NS.eof.eu.org) in 59 ms
La première réponse reçue émane du serveur DNS primaire d'Orange (DNS réglé dans mon fichier /etc/resolv.conf) qui indique les serveurs racines. Ensuite le serveur h.root-servers.net envoit les adresses des serveurs faisant autorités pour le nom de domaine .org. Puis vient au tour de d0.org.afilias-nst.org de répondre pour le nom de domaine eu.org. L'enchainement s'effectue jusqu'à trouver l'adresse exacte (ici 86.64.63.108).
Ainsi, on peut résumer le trajet par :
80.10.246.2 (dns-abo-static-a.wanadoo.fr).
128.63.2.53 (h.root-servers.net)
199.19.57.1 (d0.org.afilias-nst.org)
157.99.64.65 (ns0.pasteur.fr)
86.64.63.108 (NS.eof.eu.org)
Parmi les serveurs DNS trouvés précédemment, est-ce qu'il y en a qui supporte le protocole IPv6 ?
Contrairement aux requêtes de type "A" pour les adresses IPv4, il faut employer le type "AAAA" pour vérifier le support d'IPv6 (ou vérifier les sections additionnels). Nous allons vérifier le support de l'IPv6 sur les serveurs trouvés précédemment :
cvanvinc@pinson ~ $ dig AAAA NS.eof.eu.org
; <<>> DiG 9.7.3 <<>> AAAA NS.eof.eu.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15658
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;NS.eof.eu.org. IN AAAA
;; AUTHORITY SECTION:
eof.eu.org. 10750 IN SOA NS.eof.eu.org. olivier.ricou.eu.org. 2011082201 21600 3600 3600000 86400
;; Query time: 7 msec
;; SERVER: 195.220.130.2#53(195.220.130.2)
;; WHEN: Tue Mar 13 09:02:53 2012
;; MSG SIZE rcvd: 81
cvanvinc@pinson ~ $ dig AAAA ns0.pasteur.fr
; <<>> DiG 9.7.3 <<>> AAAA ns0.pasteur.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17394
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ns0.pasteur.fr. IN AAAA
;; AUTHORITY SECTION:
pasteur.fr. 808 IN SOA ns0.pasteur.fr. hostmaster.pasteur.fr. 2012031209 28800 7200 86400 7200
;; Query time: 7 msec
;; SERVER: 195.220.130.2#53(195.220.130.2)
;; WHEN: Tue Mar 13 09:03:13 2012
;; MSG SIZE rcvd: 79
cvanvinc@pinson ~ $ dig AAAA d0.org.afilias-nst.org
; <<>> DiG 9.7.3 <<>> AAAA d0.org.afilias-nst.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19495
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6
;; QUESTION SECTION:
;d0.org.afilias-nst.org. IN AAAA
;; ANSWER SECTION:
d0.org.afilias-nst.org. 86400 IN AAAA 2001:500:f::1
;; AUTHORITY SECTION:
org.afilias-nst.org. 9780 IN NS d0.org.afilias-nst.org.
org.afilias-nst.org. 9780 IN NS b0.org.afilias-nst.org.
org.afilias-nst.org. 9780 IN NS a2.org.afilias-nst.info.
org.afilias-nst.org. 9780 IN NS c0.org.afilias-nst.info.
org.afilias-nst.org. 9780 IN NS a0.org.afilias-nst.info.
org.afilias-nst.org. 9780 IN NS b2.org.afilias-nst.org.
;; ADDITIONAL SECTION:
a0.org.afilias-nst.info. 20908 IN A 199.19.56.1
a2.org.afilias-nst.info. 4056 IN A 199.249.112.1
b0.org.afilias-nst.org. 4056 IN A 199.19.54.1
b2.org.afilias-nst.org. 9780 IN A 199.249.120.1
c0.org.afilias-nst.info. 7138 IN A 199.19.53.1
d0.org.afilias-nst.org. 4056 IN A 199.19.57.1
;; Query time: 48 msec
;; SERVER: 195.220.130.2#53(195.220.130.2)
;; WHEN: Tue Mar 13 09:03:36 2012
;; MSG SIZE rcvd: 283
cvanvinc@pinson ~ $ dig AAAA h.root-servers.net
; <<>> DiG 9.7.3 <<>> AAAA h.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56901
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 12
;; QUESTION SECTION:
;h.root-servers.net. IN AAAA
;; ANSWER SECTION:
h.root-servers.net. 603960 IN AAAA 2001:500:1::803f:235
;; AUTHORITY SECTION:
root-servers.net. 263617 IN NS m.root-servers.net.
root-servers.net. 263617 IN NS l.root-servers.net.
root-servers.net. 263617 IN NS k.root-servers.net.
root-servers.net. 263617 IN NS c.root-servers.net.
root-servers.net. 263617 IN NS a.root-servers.net.
root-servers.net. 263617 IN NS g.root-servers.net.
root-servers.net. 263617 IN NS h.root-servers.net.
root-servers.net. 263617 IN NS e.root-servers.net.
root-servers.net. 263617 IN NS b.root-servers.net.
root-servers.net. 263617 IN NS j.root-servers.net.
root-servers.net. 263617 IN NS f.root-servers.net.
root-servers.net. 263617 IN NS i.root-servers.net.
root-servers.net. 263617 IN NS d.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net. 603957 IN A 198.41.0.4
a.root-servers.net. 603957 IN AAAA 2001:503:ba3e::2:30
b.root-servers.net. 603964 IN A 192.228.79.201
c.root-servers.net. 603959 IN A 192.33.4.12
d.root-servers.net. 603962 IN A 128.8.10.90
d.root-servers.net. 11096 IN AAAA 2001:500:2d::d
e.root-servers.net. 263617 IN A 192.203.230.10
f.root-servers.net. 603956 IN A 192.5.5.241
f.root-servers.net. 603956 IN AAAA 2001:500:2f::f
g.root-servers.net. 603961 IN A 192.112.36.4
h.root-servers.net. 603960 IN A 128.63.2.53
i.root-servers.net. 603963 IN A 192.36.148.17
;; Query time: 7 msec
;; SERVER: 195.220.130.2#53(195.220.130.2)
;; WHEN: Tue Mar 13 09:04:38 2012
;; MSG SIZE rcvd: 498
cvanvinc@pinson ~ $ dig AAAA dns-abo-static-a.wanadoo.fr
; <<>> DiG 9.7.3 <<>> AAAA dns-abo-static-a.wanadoo.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42869
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;dns-abo-static-a.wanadoo.fr. IN AAAA
;; AUTHORITY SECTION:
wanadoo.fr. 600 IN SOA ns.wanadoo.fr. postmaster.wanadoo.fr. 2012030802 21600 3600 604800 600
;; Query time: 33 msec
;; SERVER: 195.220.130.2#53(195.220.130.2)
;; WHEN: Tue Mar 13 09:05:28 2012
;; MSG SIZE rcvd: 95
Pour résumer la situation :
NS.eof.eu.org : IPv6 -> KO
ns0.pasteur.fr : IPv6 -> KO
d0.org.afilias-nst.org : IPv6 -> OK (2001:500:f::1)
h.root-servers.net : IPv6 -> OK (2001:500:1::803f:235)
dns-abo-static-a.wanadoo.fr : IPv6 -> KO
Examiner ces deux différents requêtes :
$ dig -x 195.115.89.182
; <<>> DiG 9.3.1 <<>> -x 195.115.89.182
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20866
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;182.89.115.195.in-addr.arpa. IN PTR
;; ANSWER SECTION:
182.89.115.195.in-addr.arpa. 86390 IN PTR pegase.aelif.org.
;; AUTHORITY SECTION:
89.115.195.in-addr.arpa. 86390 IN NS ns1.irisnet.fr.
;; ADDITIONAL SECTION:
ns1.irisnet.fr. 86390 IN A 195.115.88.35
;; Query time: 10 msec
;; SERVER: 172.16.0.42#53(172.16.0.42)
;; WHEN: Mon Aug 22 10:36:13 2005
;; MSG SIZE rcvd: 119
$ dig ptr 195.115.89.182
; <<>> DiG 9.3.1 <<>> ptr 195.115.89.182
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29005
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;195.115.89.182. IN PTR
;; AUTHORITY SECTION:
. 10787 IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2005082801 1800 900 604800 86400
;; Query time: 13 msec
;; SERVER: 172.16.0.42#53(172.16.0.42)
;; WHEN: Mon Aug 22 10:36:11 2005
;; MSG SIZE rcvd: 107
Pourquoi est-ce que les résultats sont différents ? Comment corriger la deuxième requête ?
En jetant un coup d'oeil dans le manuel DIG on peut lire :
"Reverse lookups — mapping addresses to names — are simplified by the -x option. addr is an IPv4 address in dotted-decimal notation, or a colon-delimited IPv6 address. When this option is used, there is no need to provide the name, class and type arguments. dig automatically performs a lookup for a name like 11.12.13.10.in-addr.arpa and sets the query type and class to PTR and IN respectively."
Ainsi, l'option -x permet d'effectuer une requête de PTR de façon simpliste sans devoir ajouter manuellement in-addr.arpa, ni retourner l'adresse. Si l'on souhaite quand même faire une requête PTR, cela donnerait :
$ dig ptr 182.89.115.195.in-addr.arpa
et NON pas :
$ dig ptr 195.115.89.182
D'ailleurs, on pourrait également se servir de la commande host pour effectuer une résolution inverse. Cette commande s'utilise très simplement de la manière suivante :
$ host 195.115.89.182
Host 182.89.115.195.in-addr.arpa not found: 2(SERVFAIL)
Expliquer ce résultat :
$ dig @172.16.0.42 +norecurse +short gluck.debian.org $ dig @172.16.0.42 +short gluck.debian.org 192.25.206.10 $ dig @172.16.0.42 +norecurse +short gluck.debian.org 192.25.206.10
Tout d'abord, analysons les différents arguments transmis à la commande dig :
@172.16.0.42 : l'adresse ip du serveur à qui l'on transmet la requête. En cas d'absence de cet argument, dig consulte le fichier /etc/resolv.conf et effectue les requêtes à partir des serveurs de nom qu'il trouvera listés.
+norecurse : ici, on ne souhaite pas de requête récursive. Par défaut, les requêtes sont récursives, autrement dit, si le serveur de nom ne possède pas l'information demandée, il posera la question à un autre serveur de nom responsable, et ainsi de suite. Sans récursivité, le serveur doit répondre immédiatement ce qu'il est en mesure de répondre.
+short : permet d'afficher le résultat de manière très concise, contrairement à l'affichage standard qui lui est explicite.
Maintenant que cela a été expliqué, nous pouvons analyser ces commandes.
La première commande demande au serveur 172.16.0.42 de résoudre le nom gluck.debian.org sans récursivité. La seule possibilité pour le serveur de nom est donc de consulter le cache. Manque de chance, il n'y a rien qui puisse satisfaire la résolution de nom, d'où l'absence de réponse.
La deuxième commande, effectue sensiblement la même chose que la première, si ce n'est qu'on autorise la récursivité. Ainsi, le serveur 172.16.0.42 est en mesure de demander de l'aide au serveur de nom concerné par le domaine. Une fois qu'il obtient la réponse, il nous le fait savoir via la sortie standard du terminal (192.25.206.10).
La dernière commande et la première sont identiques. Néanmoins, grâce à la deuxième commande effectuée, le serveur 172.16.0.42 a pu conserver en cache la résolution du nom gluck.debian.org. Voilà pourquoi, bien que l'option +notrace soit active, il est en mesure de répondre directement.
$ dig mx eof.eu.org
; <<>> DiG 9.7.3 <<>> mx eof.eu.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41260
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;eof.eu.org. IN MX
;; ANSWER SECTION:
eof.eu.org. 86385 IN MX 5 mail.eof.eu.org.
;; AUTHORITY SECTION:
eof.eu.org. 86385 IN NS ns.eof.eu.org.
eof.eu.org. 86385 IN NS ns2.eof.eu.org.
;; ADDITIONAL SECTION:
mail.eof.eu.org. 86385 IN A 86.64.63.108
;; Query time: 7 msec
;; SERVER: 195.220.130.2#53(195.220.130.2)
;; WHEN: Tue Mar 13 10:36:28 2012
;; MSG SIZE rcvd: 100
Le paramètre "mx" permet de connaître l'adresse ip du serveur chargé de gérer les emails. Ce genre de requête est principalement utilisé par les différents serveurs SMTP afin de savoir à qui s'adresser et à qui transmettre les emails.
Vous êtes l'administrateur principal d’une très grosse entreprise internationale, chaque succursale possède un administrateur expérimenté en charge de toutes les machines clientes et des divers services de chaque agence (serveur Web, etc.). Toutefois, le traitement des mails entrants doit obligatoirement passer par la maison-mère. Imaginez un plan de délégation de ce réseau. Votre réponse devra détailler votre solution et expliquer chaque point. Vous êtes totalement libres des choix techniques à faire, la seule contrainte est que le système soit efficace et propre.
Pour répondre à cette question, une des solutions serait de déléguer la résolution DNS en fonction du découpage des filiales. Pour ce faire, nous allons prendre pour illustrer notre exemple le nom, très original je l'admets, de multinationale pour la maison-mère. Les filiales, quant-à elles, seront représentées par le nom filiale.
Concrètement, voici comment la délégation des zones sera effectuée :
TO DO