Comprendre les résolutions DNS

La résolution d’un nom d’hôte complet (FQDN), par exemple www.google.fr, est basée sur un principe de récursivité. La machine cliente qui tente cette opération interroge son serveur DNS de résolution. Il s’agit le plus souvent de celui de votre votre fournisseur d’accès ou de services. Ce dernier devra à son tour effectuer diverses interrogations avant de retourner le résultat.

Afin de comprendre les échanges entre le serveur DNS de résolution (serveur de DNS cache) qui vous répond et le reste de l’Internet, nous allons analyser chaque étape et reproduire les questions/réponses à l’aide de la commande dig.

Scénario de résolution du nom “www.google.fr”

Quand le serveur de résolution reçoit votre demande (ici “www.google.fr”), il doit d’abord trouver les serveurs DNS gère le TLD (top-level-domain), soit ici l’extension: “.fr”.
Pour cela, il doit interroger un des 13 serveurs DNS racines disponibles sur Internet. Le serveur chargé de la résolution possède cette liste dans sa configuration (liste au format Bind installé par défaut).

Dans notre exemple nous demanderons au serveur racine J :

[root@www /]# dig -t ns fr @j.root-servers.net  |grep -v "^;"

fr.                     172800  IN      NS      e.ext.nic.fr.
fr.                     172800  IN      NS      d.ext.nic.fr.
fr.                     172800  IN      NS      f.ext.nic.fr.
fr.                     172800  IN      NS      g.ext.nic.fr.
fr.                     172800  IN      NS      d.nic.fr.
fr.                     172800  IN      NS      c.nic.fr.
fr.                     172800  IN      NS      a.nic.fr.

a.nic.fr.               172800  IN      A       192.93.0.129
a.nic.fr.               172800  IN      AAAA    2001:660:3005:3::1:1
c.nic.fr.               172800  IN      A       192.134.0.129
c.nic.fr.               172800  IN      AAAA    2001:660:3006:4::1:1
d.ext.nic.fr.           172800  IN      A       192.5.4.2
d.ext.nic.fr.           172800  IN      AAAA    2001:500:2e::2
d.nic.fr.               172800  IN      A       194.0.9.1
d.nic.fr.               172800  IN      AAAA    2001:678:c:1::1
e.ext.nic.fr.           172800  IN      A       193.176.144.6
e.ext.nic.fr.           172800  IN      AAAA    2a00:d78:0:102:193:176:144:6
f.ext.nic.fr.           172800  IN      A       194.146.106.46
g.ext.nic.fr.           172800  IN      A       204.61.216.39
g.ext.nic.fr.           172800  IN      AAAA    2001:500:14:6039:ad::1

A ce stade, nous avons obtenu la liste des serveurs ayant l’autorité sur les “.fr”. Il s’agit des 7 serveurs de l’Afnic, l’organisme de gestion des noms de domaines .FR (entre autre). Il est a noter que les entrées A correspondent à des IPv4 et les entrées AAAA a des IPv6.

L’étape suivante consiste donc a en contacter un afin d’obtenir la liste des serveurs ayant cette-fois authorité sur le domaine : “google.fr”.

[root@www /]# dig -t ns google.fr @e.ext.nic.fr  |grep -v "^;"                  

google.fr.              172800  IN      NS      ns1.google.com.
google.fr.              172800  IN      NS      ns4.google.com.
google.fr.              172800  IN      NS      ns3.google.com.
google.fr.              172800  IN      NS      ns2.google.com.

D’après le résultat, 4 serveurs DNS (de zone et non de cache) sont capables de répondre aux requêtes concernant le domaine en question.
L’étape suivante consiste donc maintenant a demander au premier serveur de la liste de nous indiquer le résultat pour l’entrée complète “www.google.fr”.

[root@www /]# dig www.google.fr @ns1.google.com  |grep -v "^;"

www.google.fr.          345600  IN      CNAME   www.google.com.
www.google.com.         604800  IN      CNAME   www.l.google.com.
www.l.google.com.       300     IN      A       209.85.227.99
www.l.google.com.       300     IN      A       209.85.227.105
www.l.google.com.       300     IN      A       209.85.227.106
www.l.google.com.       300     IN      A       209.85.227.104
www.l.google.com.       300     IN      A       209.85.227.103
www.l.google.com.       300     IN      A       209.85.227.147

Nous obtenons à cette étape le résultat final :

- “www.google.fr” est donc un CNAME vers “www.google.com”
- “www.google.com” est donc un CNAME vers “www.l.google.com”
- “www.l.google.com” correspond aux 6 IP énumérées

C’est bien cette réponse qui sera transmise au client final.

[thomas@www ~]$ ping www.google.fr
PING www.l.google.com (209.85.227.99) 56(84) bytes of data.
64 bytes from wy-in-f99.1e100.net (209.85.227.99): icmp_seq=1 ttl=51 time=27.2 ms

La gestion du cache :

Les réponses sont stockées par les serveurs de résolutions (serveurs DNS cache) le temps du TTL. Pour le vérifier il suffit de lancer une opérations de résolution plusieurs fois de façon consécutive et de regarder le temps de réponse. Particulièrement explicite pour la zone .pf !

[root@www /]# time host www.mana.pf
www.mana.pf             A       202.3.227.100

real    0m1.762s
user    0m0.000s
sys     0m0.010s

[root@www /]# time host www.mana.pf
www.mana.pf             A       202.3.227.100

real    0m0.003s
user    0m0.000s
sys     0m0.000s

La seconde opération est exécutée en 3ms au lieu de 1,7 seconde initialement. La réponse était donc stockée dans le cache de mon serveur DNS de résolution. Théoriquement (sans intervention manuelle), la réponse sera donc conservée 23H (le TTL est 85889 secondes). Passé ce délais, le serveur DNS cache recommencera son cycle de résolution. C’est bien sûr cette valeur qui est responsable du fameux temps de propagation imposé à chaque édition de zone (en + des délais de traitement du prestataire).

A l’inverse, les noms d’hôtes dynamiques (DynDNS) sont donc des entrées dans un domaine avec un TTL très bas, généralement 60 secondes.

[root@www ~]# dig 123.dyndns.org |grep -v "^;"

123.dyndns.org.		60	IN	A	188.228.46.255

Outre l’ensemble des entrées possibles dans une zone, il est aussi possible de paramétrer des entrées non publiques (IP privées par exemple).

[root@www ~]# dig mysql.zdnet.fr |grep -v "^;"

mysql.zdnet.fr.		118	IN	A	10.18.34.148

Quels serveurs DNS cache utiliser ?

Outre ceux de votre fournisseur d’accès, il est possible d’utiliser des serveurs de résolutions mis à disposition publiquement. Par exemple, ceux de google (8.8.8.8 et 8.8.4.4) ou OpenDNS. Dans le cas d’un serveur dédié, il est aussi possible d’installer un serveur DNS cache en local et de résoudre les requêtes directement soit-même.

Dans le cas de clients ADSL, certains FAI forcent l’utilisation de leurs serveurs de résolutions en modifiant les résultats de résolution. Dans certains cas, l’IP obtenue peut être différente entre leurs clients et le reste du monde (cf: Orange et leur SMTP pour ne pas les citer).

Quels sont les logiciels utilisés ?

Je ne vous apprends sûrement rien en vous indiquant “Bind” ! Faisons donc un tour d’horizon de quelques serveurs DNS (connus ou pas), avec l’outils fpdns.

fingerprint (a.nic.fr, 192.93.0.129): ISC BIND 9.2.3rc1 -- 9.4.0a0
fingerprint (dns.ovh.net, 213.186.33.102): ISC BIND 9.2.3rc1 -- 9.4.0a0
fingerprint (dns0.gandi.net, 217.70.177.39): ISC BIND 9.2.3rc1 -- 9.4.0a0
fingerprint (ns1.hostingfrance.com, 80.245.58.3): DJ Bernstein TinyDNS 1.05
fingerprint (auth1.DNS.cogentco.com, 66.28.0.14): ISC BIND 9.2.3rc1 -- 9.4.0a0
fingerprint (ns2.mpl1.ovea.net, 80.245.57.2): PowerDNS PowerDNS 2.9.4 -- 2.9.11
fingerprint (ns1.wordpress.com, 72.233.69.14): bboy MyDNS

Quelques précisions sur les serveurs racines

Le site internet dédié www.root-servers.org est clairement la source d’information la plus complète. Afin de bien saisir certains aspects du réseau mondial, il est toujours interessant aussi de visualiser les localisations géographiques de ces machines et quels organismes/sociétés en occupent la gestion. Il faut quand même préciser que depuis le passage à l’Anycast ces serveurs sont en fait des clusters répartis sur plusieurs continents. Ce procédé permet notamment d’éviter les attaques distribuées (DDoS) comme ce fut le cas en 2002.

A noter aussi le déploiement du protocole DNSSEC sur l’ensemble des serveurs racines qui rentrera en production cet été.

Liste des serveurs racines par TLD à l’IANA : http://www.iana.org/domains/root/db/

Baucoup d’articles à lire et relire sur le portail Wikipedia/DNS.