5. Serveurs et clients DNS
Cette section définit les termes utilisés pour les systèmes qui agissent comme clients DNS, serveurs DNS, ou les deux.
Resolver (Résolveur): Un programme "qui extrait des informations des serveurs de noms en réponse aux demandes des clients." (Cité de [RFC1034], Section 2.4) "Le résolveur est situé sur la même machine que le programme qui demande les services du résolveur, mais il peut avoir besoin de consulter des serveurs de noms sur d'autres hôtes." (Cité de [RFC1034], Section 5.1) Un résolveur effectue des requêtes pour un nom, un type et une classe, et reçoit des réponses. La fonction logique est appelée "résolution" (resolution). En pratique, le terme fait généralement référence à un type spécifique de résolveur (dont certains sont définis ci-dessous), et la compréhension de l'utilisation du terme dépend de la compréhension du contexte.
Stub resolver (Résolveur stub): Un résolveur qui ne peut pas effectuer toute la résolution lui-même. Les résolveurs stub dépendent généralement d'un résolveur récursif pour entreprendre la fonction de résolution réelle. Les résolveurs stub sont discutés mais jamais complètement définis dans la Section 5.3.1 de [RFC1034]. Ils sont entièrement définis dans la Section 6.1.3.1 de [RFC1123].
Mode itératif (Iterative mode): Un mode de résolution d'un serveur qui reçoit des requêtes DNS et répond avec une référence à un autre serveur. La Section 2.3 de [RFC1034] décrit ceci comme "Le serveur réfère le client à un autre serveur et laisse le client poursuivre la requête". Un résolveur qui fonctionne en mode itératif est parfois appelé "résolveur itératif" (iterative resolver).
Mode récursif (Recursive mode): Un mode de résolution d'un serveur qui reçoit des requêtes DNS et soit répond à ces requêtes à partir d'un cache local, soit envoie des requêtes à d'autres serveurs afin d'obtenir les réponses finales aux requêtes originales. La Section 2.3 de [RFC1034] décrit ceci comme "Le premier serveur poursuit la requête pour le client auprès d'un autre serveur". Un serveur opérant en mode récursif peut être considéré comme ayant un côté serveur de noms (qui répond à la requête) et un côté résolveur (qui effectue la fonction de résolution). Les systèmes opérant dans ce mode sont communément appelés "serveurs récursifs" (recursive servers). Parfois ils sont appelés "résolveurs récursifs" (recursive resolvers). Bien que strictement la différence entre ces deux soit que l'un d'eux envoie des requêtes à un autre serveur récursif et l'autre non, en pratique il n'est pas possible de savoir à l'avance si le serveur que l'on interroge effectuera également la récursivité; les deux termes peuvent être observés en utilisation interchangeable.
Full resolver (Résolveur complet): Ce terme est utilisé dans [RFC1035], mais il n'y est pas défini. RFC 1123 définit un "full-service resolver" qui peut être ou non ce qui était prévu par "full resolver" dans [RFC1035]. Ce terme n'est pas correctement défini dans aucun RFC.
Full-service resolver (Résolveur à service complet): La Section 6.1.3.1 de [RFC1123] définit ce terme pour signifier un résolveur qui agit en mode récursif avec un cache (et répond à d'autres exigences).
Priming (Amorçage): Le mécanisme utilisé par un résolveur pour déterminer où envoyer les requêtes avant qu'il n'y ait quoi que ce soit dans le cache du résolveur. L'amorçage est le plus souvent effectué à partir d'un paramètre de configuration qui contient une liste de serveurs autoritaires pour la zone racine.
Negative caching (Mise en cache négative): "Le stockage de la connaissance que quelque chose n'existe pas, ne peut pas donner de réponse, ou ne donne pas de réponse." (Cité de [RFC2308], Section 1)
Serveur autoritaire (Authoritative server): "Un serveur qui connaît le contenu d'une zone DNS à partir de connaissances locales, et peut donc répondre aux requêtes sur cette zone sans avoir besoin d'interroger d'autres serveurs." (Cité de [RFC2182], Section 2.) C'est un système qui répond aux requêtes DNS avec des informations sur les zones pour lesquelles il a été configuré pour répondre avec le drapeau AA dans l'en-tête de réponse mis à 1. C'est un serveur qui a autorité sur une ou plusieurs zones DNS. Notez qu'il est possible pour un serveur autoritaire de répondre à une requête sans que la zone parente ne délègue l'autorité à ce serveur. Les serveurs autoritaires fournissent également des "référals" (références), généralement vers des zones enfants déléguées à partir d'eux; ces références ont le bit AA mis à 0 et viennent avec des données de référence dans les sections Authority et (si nécessaire) Additional.
Serveur autoritaire uniquement (Authoritative-only server): Un serveur de noms qui sert uniquement des données autoritaires et ignore les demandes de récursivité. Il "ne génère normalement aucune requête de lui-même. Au lieu de cela, il répond à des requêtes non récursives de résolveurs itératifs cherchant des informations dans les zones qu'il sert." (Cité de [RFC4697], Section 2.4)
Transfert de zone (Zone transfer): L'acte d'un client demandant une copie d'une zone et d'un serveur autoritaire envoyant les informations nécessaires. (Voir Section 6 pour une description des zones.) Il existe deux méthodes standard courantes pour effectuer des transferts de zone: le mécanisme AXFR ("Authoritative Transfer") pour copier la zone complète (décrit dans [RFC5936]), et le mécanisme IXFR ("Incremental Transfer") pour copier uniquement les parties de la zone qui ont changé (décrit dans [RFC1995]). De nombreux systèmes utilisent des méthodes non standard pour le transfert de zone en dehors du protocole DNS.
Serveur secondaire (Secondary server): "Un serveur autoritaire qui utilise le transfert de zone pour récupérer la zone" (Cité de [RFC1996], Section 2.1). [RFC2182] décrit les serveurs secondaires en détail. Bien que les premiers RFC DNS tels que [RFC1996] se référaient à cela comme un "slave" (esclave), l'usage commun actuel s'est déplacé vers l'appellation "secondary" (secondaire). Les serveurs secondaires sont également discutés dans [RFC1034].
Serveur esclave (Slave server): Voir serveur secondaire.
Serveur primaire (Primary server): "Tout serveur autoritaire configuré pour être la source de transfert de zone pour un ou plusieurs serveurs [secondaires]" (Cité de [RFC1996], Section 2.1) ou, plus spécifiquement, "un serveur autoritaire configuré pour être la source de données AXFR ou IXFR pour un ou plusieurs serveurs [secondaires]" (Cité de [RFC2136]). Bien que les premiers RFC DNS tels que [RFC1996] se référaient à cela comme un "master" (maître), l'usage commun actuel s'est déplacé vers "primary" (primaire). Les serveurs primaires sont également discutés dans [RFC1034].
Serveur maître (Master server): Voir serveur primaire.
Maître primaire (Primary master): "Le maître primaire est nommé dans le champ SOA MNAME de la zone et optionnellement par un RR NS". (Cité de [RFC1996], Section 2.1). [RFC2136] définit "primary master" comme "Serveur maître à la racine du graphe de dépendance AXFR/IXFR. Le maître primaire est nommé dans le champ SOA MNAME de la zone et optionnellement par un RR NS. Il n'y a par définition qu'un seul serveur maître primaire par zone." L'idée d'un maître primaire n'est utilisée que par [RFC2136], et est considérée comme archaïque dans d'autres parties du DNS.
Serveur furtif (Stealth server): C'est "comme un serveur esclave sauf qu'il n'est pas listé dans un RR NS pour la zone." (Cité de [RFC1996], Section 2.1)
Maître caché (Hidden master): Un serveur furtif qui est un maître pour les transferts de zone. "Dans cette configuration, le serveur de noms maître qui traite les mises à jour n'est pas disponible pour les hôtes généraux sur Internet; il n'est pas listé dans le RRset NS." (Cité de [RFC6781], Section 3.4.3.) Un RFC antérieur, [RFC4641], disait que le nom du maître caché apparaît dans le champ MNAME des RR SOA, bien que dans certaines configurations, le nom n'apparaît pas du tout dans le DNS public. Un maître caché peut être soit un secondaire soit un maître primaire.
Forwarding (Transfert): Le processus d'un serveur envoyant une requête DNS avec le bit RD mis à 1 à un autre serveur pour résoudre cette requête. Le transfert est une fonction d'un résolveur DNS; c'est différent de simplement relayer aveuglément les requêtes.
[RFC5625] ne donne pas de définition spécifique pour le transfert, mais décrit en détail quelles fonctionnalités un système qui transfère doit prendre en charge. Les systèmes qui transfèrent sont parfois appelés "proxies DNS" (DNS proxies), mais ce terme n'a pas encore été défini (même dans [RFC5625]).
Forwarder (Transmetteur): La Section 1 de [RFC2308] décrit un transmetteur comme "un serveur de noms utilisé pour résoudre les requêtes au lieu d'utiliser directement la chaîne de serveurs de noms autoritaires". [RFC2308] dit en outre "Le transmetteur a typiquement soit un meilleur accès à internet, soit maintient un cache plus grand qui peut être partagé entre de nombreux résolveurs." Cette définition semble suggérer que les transmetteurs interrogent normalement uniquement les serveurs autoritaires. Dans l'usage actuel, cependant, les transmetteurs se tiennent souvent entre les résolveurs stub et les serveurs récursifs. [RFC2308] est silencieux sur la question de savoir si un transmetteur est itératif uniquement ou peut être un résolveur à service complet.
Résolveur implémentant des politiques (Policy-implementing resolver): Un résolveur agissant en mode récursif qui modifie certaines des réponses qu'il retourne en fonction de critères de politique, tels que pour empêcher l'accès aux sites de malware ou au contenu répréhensible. En général, un résolveur stub n'a aucune idée si les résolveurs en amont implémentent une telle politique ou, s'ils le font, la politique exacte sur les changements qui seront effectués. Dans certains cas, l'utilisateur du résolveur stub a sélectionné le résolveur implémentant des politiques avec l'intention explicite de l'utiliser pour implémenter les politiques. Dans d'autres cas, les politiques sont imposées sans que l'utilisateur du résolveur stub en soit informé.
Résolveur ouvert (Open resolver): Un résolveur à service complet qui accepte et traite les requêtes de n'importe quel (ou presque n'importe quel) résolveur stub. Ceci est parfois aussi appelé "résolveur public" (public resolver), bien que le terme "résolveur public" soit davantage utilisé avec les résolveurs ouverts qui sont censés être ouverts, par rapport à la grande majorité des résolveurs ouverts qui sont probablement mal configurés pour être ouverts.
View (Vue): Une configuration pour un serveur DNS qui lui permet de fournir des réponses différentes en fonction des attributs de la requête. Typiquement, les vues diffèrent par l'adresse IP source d'une requête, mais peuvent également être basées sur l'adresse IP de destination, le type de requête (tel que AXFR), si elle est récursive, etc. Les vues sont souvent utilisées pour fournir plus de noms ou des adresses différentes aux requêtes provenant de "l'intérieur" d'un réseau protégé qu'à celles "à l'extérieur" de ce réseau. Les vues ne font pas partie standardisée du DNS, mais elles sont largement implémentées dans les logiciels serveurs.
DNS passif (Passive DNS): Un mécanisme pour collecter de grandes quantités de données DNS en stockant les réponses DNS des serveurs. Certains de ces systèmes collectent également les requêtes DNS associées aux réponses; cela peut soulever des problèmes de confidentialité. Les bases de données DNS passives peuvent être utilisées pour répondre à des questions historiques sur les zones DNS telles que quels enregistrements étaient disponibles pour elles à quels moments dans le passé. Les bases de données DNS passives permettent de rechercher les enregistrements stockés sur des clés autres que simplement le nom, telles que "trouver tous les noms qui ont des enregistrements A d'une valeur particulière".
Anycast: "La pratique consistant à rendre une adresse de service particulière disponible dans plusieurs emplacements discrets et autonomes, de sorte que les datagrammes envoyés sont acheminés vers l'un des plusieurs emplacements disponibles." (Cité de [RFC4786], Section 2)