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.