La seule composante de centralisation dans le système DNS est le point d'entrée dans la base défini par la zone "Racine". Ceci garantit l'unicité globale de la base DNS.
Au dessus de la notion de TYPE, le DNS définit aussi une
notion de CLASSE, mais seule la classe IN (INternet)
est réellement utilisée en pratique. Le système de nommage Hesiod
du projet Athena de l'université CMU utilisait la classe HS...
Les types et l'arbre de nommage sont potentiellement différenciés pour
chaque CLASSE mais la racine reste commune pour toutes les CLASSES.
L'ensemble des informations de la base de données DNS est structuré autour des Resource Records. Un RR est un quintuplet de la forme :
NBs :
- Les valeurs de TYPE et de CLASSE sont des IANA Assigned
Numbers sur 2 octets chacun. La réference normative est
http://www.iana.org/assignments/dns-parameters.
- Le champ TTL a une valeur initiale définie statiquement à
la source de l'information mais qui évolue dynamiquement avec la vie du RR.
Exemple :
La base de données DNS est constituée de l'ensemble des
RRs qui sont définis sur l'ensemble des serveurs DNS.
Une requête DNS est un triplet de la forme
Question =
Réponses =
altavista.com. 389 IN A 209.73.164.91 altavista.com. 389 IN A 209.73.164.92 altavista.com. 389 IN A 209.73.164.93 altavista.com. 389 IN A 209.73.164.94 altavista.com. 389 IN A 209.73.164.95 altavista.com. 389 IN A 209.73.180.1 altavista.com. 389 IN A 209.73.180.2 altavista.com. 389 IN A 209.73.180.3 altavista.com. 389 IN A 209.73.180.4 altavista.com. 389 IN A 209.73.164.90
On appelle RRset l'ensemble des RRs de même nom, classe et type. Il s'agit bien d'un ensemble et non d'une liste, c'est-à-dire que les RRs d'un même RRset sont équivalents et non ordonnés.
Le système DNS réalise ainsi naturellement une politique de load balancing équilibré entre machines. D'autres stratégies de redondance peuvent être mises en oeuvre grace à l'utilisation du DNS. Cela passera alors par des types de RR spécifiques comme par exemple le MX pour la messagerie SMTP, ou le SRV dans un cadre plus générale.
Pour notre approximation du DNS, on considère qu'il y a un serveur DNS pour chaque domaine DNS. C'est-à-dire que l'architecture des serveurs DNS correspond directement à l'arbre de nommage du DNS avec un serveur dédié pour chaque noeud interne de l'arbre. En réalité, on verra ensuite qu'un seul serveur peut couvrir plusieurs noeuds et que plusieurs serveurs peuvent couvrir un seul noeud.
Un serveur DNS pour un domaine XXX, gère alors localement l'ensemble des informations de ce domaine. Cela comprend l'ensemble des RRs avec des noms label.XXX (feuilles de l'arbre) et les références pour les sous-domaines .label.XXX (fils dans l'arbre). Ces références qui donnent le nom et l'adresse du serveur DNS du sous-domaine sont aussi gérées par des RRs particuliers du type NS. On notera de façon plus générale que le DNS utilise la même structure générique de Resource Record pour les informations "utilisateur" et pour les informations de gestion du système distribué lui-même.
Les serveurs ne gèrent que la relation parent->enfant, donc pour trouver de manière générale le serveur d'un domaine donné, la seule solution est de partir de la Racine du DNS et de demander itérativement à chaque niveau de l'arbre le serveur du sous-domaine recherché. On a par exemple la résolution par étape suivante :
En réalité, c'est toujours la question initiale qui sera posée à chaque étape. Ce que l'on a indiqué ici, c'est la manière dont la question est interprétée par chaque serveur (ou la meilleur reponse que peut faire le serveur).
Pour la résolution, on aura donc besoin des références du serveur Racine, qui gère le domaine .. et connaît les TLDs. C'est le point d'entrée dans la base DNS qui en assure l'unicité.
Le premier service que l'on a introduit, consiste à exporter les informations d'un domaine DNS donné. On parlera de serveur Authoritative pour qualifier cette fonction.
La deuxième fonction importante va consister à mettre en
oeuvre l'algorithme de résolution à la place des clients terminaux sur
chaque machine de l'Internet. Ceci permet de concentrer la complexité
de la résolution et la connaissance de la Racine au niveau
de serveurs DNS qui jouent un rôle de proxy et d'avoir
des clients DNS beaucoup plus légers sur chaque machine. Cela deviendra
un élément fondamental d'efficacité et de performance par la suite.
Ces serveurs DNS "de résolution" doivent être appelés serveurs récursifs.
Les clients DNS légers sur chaque machine sont appelés stub resolver.
Le processus de résolution peut alors se décliner sous la forme :
Le mode récursif consiste à demander à un serveur de résoudre complètement la requête et de renvoyer uniquement la réponse finale.
Le mode itératif consiste à demander à un serveur la meilleure information dont il dispose par rapport à la question, c'est-à-dire soit la réponse soit la référence d'un serveur "plus proche" de la réponse. On itére ensuite de serveur en serveur.
En terme châtié, un serveur DNS peut faire 2 types de réponses :
Les requêtes DNS contiennent le type de réponse souhaitée, mais un serveur peut décider de ne faire que des réponses itératives. C'est par exemple, le cas des serveurs authoritatives pour des domaines sensibles (Racine, TLD,..) qui limitent leur activité de résolution aux informations qu'ils gèrent directement.
Pour un serveur DNS qui accepte de faire des réponses récursives, il peut réaliser la résolution soit en utilisant le schéma itératif, c'est le cas le plus fréquent, soit en utilisant le schéma récursif. Dans ce dernier cas, on parlera de serveur forwarder.
En pratique, la résolution complete d'une requête DNS se réalise donc en général par une phase récursive pour le client et les éventuels forwaders, et se termine par une phase itérative.
L'algorithme simplifié précédent s'adapte simplement en considérant maintenant qu'il y a un serveur DNS pour chaque Zone DNS qui gère simultanément l'ensemble des noms de domaine de cette zone et gère les délégations des sous-zones rattachées. Ce qui est nouveau dans la résolution, c'est que l'on peut éventuellement descendre plusieurs niveaux de l'arbre de nommage DNS en une seule itération de résolution.
NB: Une machine physique faisant serveur DNS peut aussi gérer simultanément plusieurs zones DNS connexes ou non. En principe, cela n'influence pas la résolution et le système DNS dans le mesure où chaque zone sera traitée de manière complètement autonome avec des délégations indépendantes. Dans certains cas très particuliers, cela peut toutefois être source de complications (cf. traitement du RR DS dans DNSSEC)
Le mécanisme de cache couvre ainsi les réponses aux questions posées, mais aussi les références des serveurs des zones intermédiaires apprises lors de la résolution itérative. Toutes ces informations sont structurées sous une même forme de RR. Le mécanisme de cache sera alors contrôlé par le TTL de chaque RR qui définit la durée de vie maximale de l'information dans un cache.
Il est important de noter que cette durée de vie dans les caches est définie par la
source de l'information, et non pas par l'entité qui réalise le cache comme
c'est souvent le cas. Le gestionnaire de chaque information du DNS garde ainsi une
maîtrise sur la politique de cache de cette information.
NB : Ceci n'interdit malheureusement pas aux systèmes d'exploitations (Windows
ou Unix avec nscd) d'ajouter un cache local aux différents services de noms.
La politique locale de ce cache n'est pas toujours claire ou bien configurée, mais ignore
dans tout les cas la politique issue du cache DNS.
Le mécanisme de cache s'applique aussi aux réponses négatives, c'est-à-dire aux réponses de la forme "il n'existe pas de tels RRs". La définition du cache négatif était "incertaine" dans la RFC1035, mais est complètement spécifiée par le RFC2308. La durée de vie pour les réponses négatives, Negative Cache TTL, est une valeur commune à "tous les RRs inexistants" d'une zone. Il ne sera pas donné par le TTL d'un RR, mais par un paramètre particulier dans les RDATAs du RR SOA qui est record obligatoire et unique dans chaque zone DNS.
Une information du DNS (un RR) est dite Authoritative si elle provient directement d'un serveur qui gère localement cette information. Ce serveur est dit Authoritative pour la Zone DNS. Une information Non Authoritative provient alors du cache d'un autre serveur. Son TTL sera décrémenté régulièrement par le serveur cache et sera différent du TTL d'origine obtenu par une réponse Authoritative.
L'algorithme de résolution précédent demande maintenant une réécriture un peu plus lourde pour prendre en compte le mécanisme de cache mais la logique reste la même en considérant qu'un serveur recherche toujours la "meilleure" information dont il dispose en incluant les informations du cache et itére si nécessaire en utilisant les "meilleurs" serveurs connus (les plus proches ancêtres de la cible).
Le DNS donne la priorité à l'efficacité et au faible volume de transfert par rapport à la dynamicité de la mise à jour des bases. D'autre part, c'est par principe la responsabilité des secondaires d'assurer la cohérence de leur copie de la base. En cas de modification d'une information, il peut donc y avoir un certain temps (contrôlé pas des TTLs) avant que les différents serveurs d'une zone soient cohérents. Une extension du DNS, le NOTIFY, optimise eventuellement ce processus.
Notons que rien n'oblige un serveur de Zone à appartenir à cette zone; il est même de bon goût pour assurer la fiabilité d'avoir des serveurs appartenant à des domaines différents et à des réseaux physiques non connexes.
La notion de primaire et secondaire concerne uniquement le mécanisme de redondance et n'a aucune implication sur le reste du système DNS. Le primaire et les secondaires sont Authoritatives sans distinction et sans préférence. Dans l'absolu, le serveur primaire pourrait même ne pas faire serveur DNS (i.e. hidden primary).
Concernant l'algorithme de résolution précédent, l'introduction de la redondance va consister à ne plus avoir un unique serveur authoritative pour chaque zone, mais une liste de serveurs pour chaque zone. Par principe, ces serveurs sont équivalents et le choix d'un des serveurs doit être équipondéré. Pour ceux qui suivent, il faut evidement lire "un ensemble" et pas "une liste" !
Il existe aussi une version optimisée IXFR qui transfert de manière incrémentale uniquement les modifications de la base. Cela reduit le traffic mais nécessite une journalisation de la base.
Le SOA d'une zone contient :
Le numéro de série d'une zone identifie la version de la base de données et doit être modifié sur le serveur primaire à chaque modification des données. Un serveur secondaire de zone sait qu'il doit mettre à jour sa copie de la base quand il trouve un numéro de série supérieur au sien dans un record SOA fourni par un autre serveur de la zone. Il realisera alors le transfert, soit complet avec une requête AXFR, soit partiel avec une requête IXFR qui contient un numéro de série pour identifier l'increment à transferer.
Les 3 temporisateurs vont fixer avec quelle régularité au maximum, un secondaire doit :
Le mecanisme additionnel du NOTIFY permet quand un serveur fait une mise à jour de sa base, d'informer les autres serveurs de la zone en "pushant" le nouveau RR SOA. A la reception d'un NOTIFY, un serveur est libre d'anticiper l'opération de refresh définie par défaut.
Exercice : Le nom du serveur primaire dans les données du
SOA est dit "informatif" et n'est pas utilisable pour gerer
la redondance. Pourquoi ?
NB: Cette donnée du SOA est uniquement utilisée par l'extension DNS dynamic update
Pour une zone donnée, les NS associés au nom de la zone doivent appartenir à la base de données de cette zone. D'abord parce que le principe de nommage et de partitionnement de la base l'impose, et aussi parce que cela est nécessaire pour la gestion de la réplication des bases. Mais ces NS doivent aussi exister dans la zone parente, car ils mettent en oeuvre la délégation entre zone et sont la base de l'algorithme de résolution. Ceci constitue une exception importante au principe d'autonomie de gestion des zones. Dans les standards, le DNS ne fournit pas de moyens pour assurer le maintien de la cohérence des informations de délégation et laisse cela sous la responsabilité commune des deux administrateurs de la zone enfant et de la zone parent. En pratique, de nombreuses délégations sont incorrectement maintenues avec en conséquence un fonctionnement dégradé du DNS (l'INT a été un "bon exemple" entre 2000 et 2005, cf. exemple dig n.4).
Précisions: On peut distinguer trois listes des serveurs pour une zone : la liste des serveurs définis dans la zone mère, la liste des serveurs définis dans la zone elle-même, et la liste de tous les serveurs authoritatives de la zone. En général, ces 3 listes sont égales mais le standard impose uniquement l'inclusion entre ces 3 listes. Un serveur authoritative qui n'apparaît pas dans la zone mère sera un serveur qui ne participe pas au processus d'itérations descendantes dans l'arbre de nommage mais sera tout à fait authoritative pour le reste de l'algorithme de résolution. Si il n'apparaît pas dans la zone elle-même, il ne servira alors que les requêtes de clients l'utilisant directement comme serveur récursif (/etc/resolv.conf); par défaut, il n'aura pas non plus accès au mécanisme de NOTIFY. On appelle ces derniers serveurs des serveurs furtifs (stealth server). Cela peut être fort utile pour augmenter les performances DNS en interne dans un site sans augmenter le nombre de serveurs utilisables de l'extérieur ou modifier les données dans la zone mère.
Dans la base d'une Zone mère, les RRs de délégation {Sous_Zone TTL IN NS Nom_Serveur} ne sont pas toujours suffisants pour réaliser le rattachement de la Sous_Zone. En effet, pour utiliser le RR NS, il va falloir obtenir une adresse associée à Nom_Serveur. Dans le cas où Nom_Serveur appartient lui-même à la sous-Zone, on est dans une situation bloquante car pour obtenir l'adresse il faut envoyer une requête DNS à cette adresse !!
Dans le cas où un NS dans une zone mère référence un nom de serveur qui appartient à la sous-zone ou à sa descendance, il faut rajouter dans la base mère, au moins un RR d'adresse IP associé au nom de serveur. Ce RR d'adresse ,qui s'appelle la GLUE, doit rester cohérent entre la base mère et la base fille !
;; délégation de sous-zone : "sub" sub.example. 7200 IN NS titi.sub.example. sub.example. 7200 IN NS toto.other.test. titi.sub.example. 14400 IN A 157.159.10.10 ;!!! GLUE !!! ;; sous-domaine sans délegation : "autre" toto.autre.example. 14400 IN A 157.159.100.1
sub.example. 3600 IN SOA ......; infos sur la zone sub.example. 7200 IN NS toto.other.test. sub.example. 7200 IN NS titi.sub.example. sub.example. 7200 IN NS tutu.sub.example. titi.sub.example. 7200 IN A 157.159.10.10 ;!!!Ne pas Modifier !!! tutu.sub.example. 7200 IN A 157.159.10.11
Step 1 searches the cache for the desired data. If the data is in the cache, it is assumed to be good enough for normal use. Some resolvers have an option at the user interface which will force the resolver to ignore the cached data and consult with an authoritative server. This is not recommended as the default. If the resolver has direct access to a name server's zones, it should check to see if the desired data is present in authoritative form, and if so, use the authoritative data in preference to cached data.
Step 2 looks for a name server to ask for the required data. The general strategy is to look for locally-available name server RRs, starting at SNAME, then the parent domain name of SNAME, the grandparent, and so on toward the root. Thus if SNAME were Mockapetris.ISI.EDU, this step would look for NS RRs for Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root). These NS RRs list the names of hosts for a zone at or above SNAME. Copy the names into SLIST. Set up their addresses using local data. It may be the case that the addresses are not available. The resolver has many choices here; the best is to start parallel resolver processes looking for the addresses while continuing onward with the addresses which are available. Obviously, the design choices and options are complicated and a function of the local host's capabilities. The recommended priorities for the resolver designer are:
If the search for NS RRs fails, then the resolver initializes SLIST from the safety belt SBELT. The basic idea is that when the resolver has no idea what servers to ask, it should use information from a configuration file that lists several servers which are expected to be helpful. Although there are special situations, the usual choice is two of the root servers and two of the servers for the host's domain. The reason for two of each is for redundancy. The root servers will provide eventual access to all of the domain space. The two local servers will allow the resolver to continue to resolve local names if the local network becomes isolated from the internet due to gateway or link failure.
In addition to the names and addresses of the servers, the SLIST data structure can be sorted to use the best servers first, and to insure that all addresses of all servers are used in a round-robin manner. The sorting can be a simple function of preferring addresses on the local network over others, or may involve statistics from past events, such as previous response times and batting averages.
Step 3 sends out queries until a response is received. The strategy is to cycle around all of the addresses for all of the servers with a timeout between each transmission. In practice it is important to use all addresses of a multihomed host, and too aggressive a retransmission policy actually slows response when used by multiple resolvers contending for the same name server and even occasionally for a single resolver. SLIST typically contains data values to control the timeouts and keep track of previous transmissions.
Step 4 involves analyzing responses. The resolver should be highly paranoid in its parsing of responses. It should also check that the response matches the query it sent using the ID field in the response.
The ideal answer is one from a server authoritative for the query which either gives the required data or a name error. The data is passed back to the user and entered in the cache for future use if its TTL is greater than zero.
If the response shows a delegation, the resolver should check to see that the delegation is "closer" to the answer than the servers in SLIST are. This can be done by comparing the match count in SLIST with that computed from SNAME and the NS RRs in the delegation. If not, the reply is bogus and should be ignored. If the delegation is valid the NS delegation RRs and any address RRs for the servers should be cached. The name servers are entered in the SLIST, and the search is restarted.
If the response contains a CNAME, the search is restarted at the CNAME unless the response has the data for the canonical name or if the CNAME is the answer itself.
Détails and implementation hints can be found in [RFC-1035].