introduction
Le DNS, ou système de nom de domaine, fait partie intégrante de la façon dont les systèmes se connectent pour communiquer sur Internet. Sans DNS, les ordinateurs et les personnes qui les utilisent doivent se connecter en utilisant uniquement des adresses numériques, appelées adresses IP.
Outre le problème évident de devoir retenir un grand nombre de nombres complexes pour des tâches simples, la communication via des adresses IP pose également des problèmes supplémentaires. Déplacer votre site Web vers un autre fournisseur d'hébergement ou déplacer vos serveurs vers différents emplacements nécessiterait que vous informiez chaque client du nouvel emplacement.
Les serveurs DNS, c’est-à-dire les ordinateurs qui forment ensemble le système nous permettant d’utiliser des noms au lieu d’adresses, peuvent gérer de nombreuses fonctions différentes, chacune d’elles pouvant contribuer à votre capacité à accéder aux serveurs par leur nom.
Dans unprevious guide, nous avons discuté de la terminologie et des concepts de base du système de noms de domaine. Nous supposerons une certaine familiarité avec les concepts abordés dans cet article. Dans ce guide, nous allons parler de différents types de configurations de serveur DNS et de leurs avantages, cas d'utilisation et propriétés.
Le chemin d'une requête DNS
Lorsqu'un programme client souhaite accéder à un serveur par son nom de domaine, il doit savoir comment traduire le nom de domaine en une adresse routable réelle qu'il peut utiliser pour communiquer. Il doit connaître ces informations pour obtenir ou envoyer des informations au serveur.
Certaines applications, y compris la plupart des navigateurs Web, conservent un cache interne des requêtes récentes. C’est le premier endroit où l’application vérifiera, si elle en a la capacité, afin de trouver l’adresse IP du domaine en question. S'il ne trouve pas ici la réponse à sa question, il demande alors auxsystem resolver de savoir quelle est l'adresse du nom de domaine.
Unresolver en général est tout composant qui agit en tant que participant côté client dans une requête DNS. Le résolveur système est la bibliothèque de résolution utilisée par votre système d'exploitation pour rechercher la réponse aux requêtes DNS. En général, les résolveurs système sont généralement ce que nous considéronsstub resolvers car ils ne sont pas capables de beaucoup de complexité au-delà de la recherche de quelques fichiers statiques sur le système (comme le fichier/etc/hosts) et de la transmission des requêtes à un autre résolveur.
En règle générale, une requête va de l'application cliente au résolveur système, où elle est ensuite transmise à un serveur DNS pour lequel elle possède l'adresse. Ce serveur DNS est appelé unrecursive DNS server. Un serveur récursif est un serveur DNS configuré pour interroger d'autres serveurs DNS jusqu'à ce qu'il trouve la réponse à la question. Il renverra la réponse ou un message d'erreur au client (le résolveur système dans ce cas, qui le transmettra à son tour à l'application cliente).
Les serveurs récursifs conservent généralement un cache également. Il va d'abord vérifier ce cache pour voir s'il a déjà la réponse à la requête. Si ce n'est pas le cas, il verra s'il a l'adresse vers l'un des serveurs qui contrôlent les composants de domaine de niveau supérieur. Donc, si la requête est pourwww.example.com et qu'il ne trouve pas cette adresse d'hôte dans son cache, il verra s'il a l'adresse des serveurs de noms pourexample.com et si nécessaire,com. Il enverra ensuite une requête au serveur de noms du composant de domaine le plus spécifique qu'il pourra trouver afin de rechercher plus d'informations.
S'il ne trouve l'adresse de l'un de ces composants du domaine, il doit commencer par le haut de la hiérarchie en interrogeant lesroot name servers. Les serveurs racine connaissent les adresses de tous les serveurs de noms TLD (domaine de premier niveau) qui contrôlent les zones pour.com,.net,.org, etc. Il demandera aux serveurs racine s'il connaît l'adresse de towww.example.com. Le serveur racine renverra le serveur récursif aux serveurs de noms pour le TLD.com.
Le serveur récursif suit ensuite la trace des renvois vers chaque serveur de noms successif à qui la responsabilité des composants du domaine a été déléguée, jusqu'à ce qu'il puisse cibler le serveur de noms spécifique qui possède la réponse complète. Il place cette réponse dans son cache pour les requêtes ultérieures, puis la renvoie au client.
Comme vous pouvez le constater à partir de cet exemple, il existe différents types de serveurs, qui jouent chacun un rôle différent. Passons en revue les spécificités des différents types de serveurs DNS.
Différences fonctionnelles
Certaines des différences entre les serveurs DNS sont purement fonctionnelles. La plupart des serveurs impliqués dans la mise en œuvre de DNS sont spécialisés pour certaines fonctions. Le type de serveur DNS que vous choisirez dépendra en grande partie de vos besoins et du type de problème que vous souhaitez résoudre.
Serveurs DNS faisant autorité
Un serveur DNS faisant uniquement autorité est un serveur qui ne s'occupe que de répondre aux requêtes des zones dont il est responsable. Dans la mesure où cela ne facilite pas la résolution des requêtes pour les zones extérieures, il est généralement très rapide et peut gérer efficacement de nombreuses requêtes.
Les serveurs faisant uniquement autorité ont les propriétés suivantes:
-
Very fast at responding to queries for zones it controls. Un serveur faisant autorité uniquement aura toutes les informations sur le domaine dont il est responsable ou les informations de référence pour les zones du domaine qui ont été déléguées à d'autres serveurs de noms.
-
Will not respond to recursive queries. La définition même d'un serveur faisant autorité uniquement est celui qui ne gère pas les requêtes récursives. Cela en fait un serveur uniquement et jamais un client dans le système DNS. Toute demande qui parvient à un serveur faisant autorité uniquement provient généralement d'un résolveur ayant reçu une référence à ce dernier, ce qui signifie que le serveur faisant uniquement autorité aura la réponse complète ou sera en mesure de transmettre une nouvelle référence au serveur de noms. qu’il a délégué la responsabilité à.
-
Does not cache query results. Puisqu'un serveur faisant autorité uniquement ne demande jamais aux autres serveurs des informations pour résoudre une demande, il n'a jamais la possibilité de mettre en cache les résultats. Toutes les informations dont il dispose se trouvent déjà dans son système.
Mise en cache du serveur DNS
Un serveur DNS en cache est un serveur qui gère les demandes récursives des clients. Presque tous les serveurs DNS contactés par le résolveur de stub du système d’exploitation seront des serveurs DNS en cache.
Les serveurs de cache ont l’avantage de répondre aux demandes récursives des clients. Alors que les serveurs faisant uniquement autorité peuvent être l’idéal pour servir des informations de zone spécifiques, la mise en cache de serveurs DNS est plus généralement utile du point de vue du client. Ils rendent le système DNS du monde accessible à des interfaces client plutôt stupides.
Pour éviter d'avoir à subir l'impact de l'émission de plusieurs requêtes itératives sur d'autres serveurs DNS chaque fois qu'il reçoit une requête récursive, le serveur met en cache ses résultats. Cela lui permet d’avoir accès à une large base d’informations DNS (le DNS accessible au public dans le monde entier) tout en traitant très rapidement les demandes récentes.
Un serveur DNS en cache a les propriétés suivantes:
-
Access to the entire range of public DNS data. Toutes les données de zone servies par des serveurs DNS accessibles au public connectés à l'arborescence de délégation globale peuvent être atteintes par un serveur DNS de mise en cache. Il connaît les serveurs DNS racine et peut suivre intelligemment les renvois lors de la réception des données.
-
Ability to spoon-feed data to dumb clients. Presque tous les systèmes d'exploitation modernes déchargent la résolution DNS vers des serveurs récursifs dédiés via l'utilisation de résolveurs de stub. Ces bibliothèques de résolution émettent simplement une demande récursive et s'attendent à recevoir une réponse complète. Un serveur DNS de mise en cache a les capacités exactes de servir ces clients. En acceptant une requête récursive, ces serveurs promettent de renvoyer une réponse ou un message d'erreur DNS.
-
Maintains a cache of recently requested data. En mettant en cache les résultats au fur et à mesure qu'ils les collectent auprès d'autres serveurs DNS pour ses requêtes client, un serveur DNS de mise en cache crée un cache pour les données DNS récentes. En fonction du nombre de clients utilisant le serveur, de la taille du cache et de la durée des données TTL sur les enregistrements DNS eux-mêmes, cela peut considérablement accélérer la résolution DNS.
Serveur DNS de transfert
Une autre solution pour développer un cache pour les ordinateurs clients consiste à utiliser un serveur DNS de transfert. Cette approche ajoute un lien supplémentaire dans la chaîne de résolution DNS en implémentant un serveur de transfert qui transmet simplement toutes les demandes à un autre serveur DNS doté de fonctionnalités récursives (telles qu'un serveur DNS en cache).
L'avantage de ce système est qu'il peut vous donner l'avantage d'un cache accessible localement sans avoir à effectuer le travail récursif (ce qui peut entraîner un trafic réseau supplémentaire et mobiliser des ressources substantielles sur des serveurs à trafic important). Cela peut également offrir une flexibilité intéressante pour fractionner votre trafic privé et public en le transférant vers différents serveurs.
Un serveur DNS de transfert a les propriétés suivantes:
-
The ability to handle recursive requests without performing recursion itself. La propriété la plus fondamentale d'un serveur DNS de transfert est qu'il transmet les requêtes à un autre agent pour résolution. Le serveur de transfert peut avoir un minimum de ressources tout en offrant une grande valeur en exploitant son cache.
-
Provide a local cache at a closer network location. En particulier si vous ne vous sentez pas en mesure de créer, maintenir et sécuriser une solution DNS récursive à part entière, un serveur de transfert peut utiliser des serveurs DNS récursifs publics. Il peut exploiter ces serveurs tout en déplaçant l'emplacement de mise en cache principal très près des ordinateurs clients. Cela peut réduire les temps de réponse.
-
Increases flexibility in defining local domain space. En transmettant des demandes à différents serveurs de manière conditionnelle, un serveur de transfert peut garantir que les demandes internes sont servies par des serveurs privés tandis que les demandes externes utilisent un DNS public.
Solutions combinées
Bien que les solutions ci-dessus soient conçues avec des objectifs très spécifiques, il est souvent souhaitable de configurer votre serveur DNS pour combiner les avantages de chacun.
Un serveur DNS peut être configuré pour agir en tant que serveur de mise en cache récursif pour un nombre sélectionné de clients locaux, tout en répondant aux demandes itératives faisant autorité émanant d'autres clients. Il s'agit d'une configuration courante car elle vous permet de répondre aux demandes globales de votre domaine, tout en permettant également à vos clients locaux d'utiliser le serveur pour la résolution récursive.
Certains logiciels DNS sont spécialement conçus pour remplir un rôle spécifique, mais les applications telles que Bind sont incroyablement flexibles et peuvent être utilisées comme solutions hybrides. Tenter de fournir trop de services sur un seul serveur peut parfois entraîner une dégradation des performances, mais dans de nombreux cas, en particulier dans le cas de petites infrastructures, il est tout à fait judicieux de conserver une solution unique tout-en-un.
Différences relationnelles
Bien que les différences les plus apparentes entre les configurations de serveur DNS soient probablement fonctionnelles, les différences relationnelles sont également extrêmement importantes.
Serveurs Primaires et Secondaires
Compte tenu de l'importance du DNS pour rendre accessibles des services et des réseaux entiers, la plupart des serveurs DNS faisant autorité pour une zone auront une redondance intégrée. Il existe différents termes pour les relations entre ces serveurs, mais en général, un serveur peut être unprimary ou unsecondary dans sa configuration.
Les serveurs principaux et secondaires font autorité pour les zones qu’ils gèrent. Le primaire n’a pas plus de pouvoir sur les zones que le secondaire. Le seul facteur de différenciation entre un serveur principal et un serveur secondaire est l'emplacement de lecture des fichiers de zone.
Un serveur principal lit ses fichiers de zone à partir de fichiers sur le disque du système. Ce sont généralement les endroits où l'administrateur de zone ajoute, édite ou transfère les fichiers de zone d'origine.
Le serveur secondaire reçoit les zones pour lesquelles il fait autorité via un transfert de zone à partir de l'un des serveurs principaux de la zone. Une fois qu'il a ces zones, il les place dans une cache. S'il doit redémarrer, il vérifie d'abord son cache pour voir si les zones à l'intérieur sont à jour. Sinon, il demande les informations mises à jour au serveur principal.
Les serveurs ne sont pas relégués pour n'être qu'un primaire ou un secondaire pour toutes les zones qu'ils gèrent. Les statuts principal ou secondaire étant affectés zone par zone, un serveur peut être un serveur principal pour certaines zones et un serveur secondaire pour d'autres.
Les zones DNS ont généralement au moins deux serveurs de noms. Toute zone responsable d'une zone routable Internetmust possède au moins deux serveurs de noms. Souvent, beaucoup plus de serveurs de noms sont maintenus afin de répartir la charge et d'accroître la redondance.
Serveurs publics vs privés
Les organisations utilisent souvent le DNS à la fois en externe et en interne. Cependant, les informations qui devraient être disponibles dans ces deux domaines sont souvent radicalement différentes.
Une organisation peut conserver un serveur DNS faisant uniquement autorité faisant appel à des ressources externes pour gérer les requêtes DNS publiques des domaines et des zones qu’elle gère. Pour ses utilisateurs internes, l'organisation peut utiliser un serveur DNS distinct contenant les informations faisant autorité fournies par le DNS public, ainsi que des informations supplémentaires sur les hôtes et les services internes. Il peut également fournir des fonctionnalités supplémentaires, telles que la récursivité et la mise en cache pour ses clients internes.
Bien que nous ayons mentionné la possibilité d’avoir un serveur unique pour gérer toutes ces tâches dans le serveur «combinaison» ci-dessus, le fractionnement de la charge de travail présente des avantages certains. En fait, il est souvent souhaitable de maintenir des serveurs complètement séparés (internes et externes) qui ne se connaissent pas. Du point de vue de la sécurité, il est particulièrement important que le serveur public ne possède pas d’enregistrement de la contrepartie privée. Cela signifie ne pas répertorier vos serveurs de noms privés avec des enregistrements NS dans les fichiers de zone publique.
Il y a quelques considérations supplémentaires à garder à l'esprit. S'il est peut-être plus facile de faire partager par vos serveurs public et privé les données de zone qu'ils ont en commun dans une relation primaire-secondaire traditionnelle, cela peut entraîner une fuite des informations sur votre infrastructure privée.
Au-delà de garder vos serveurs privés hors des fichiers de zone eux-mêmes (essentiellement une entité pouvant faire l’objet d’une recherche publique), il est généralement conseillé de supprimer également toute référence au serveur privé dans les fichiers de configuration du serveur public. Cela signifie la suppression des détails de la configuration principale du transfert, de la notification et du transfert, de sorte qu'une compromission du serveur public ne signifie pas que vos serveurs de noms internes sont exposés de manière soudaine.
Cela implique de conserver des fichiers de zone distincts pour chacun, ce qui peut représenter un travail supplémentaire. Cependant, cela peut être nécessaire pour la séparation absolue et la sécurité.
Conclusion
Vous êtes probablement au courant, à ce stade-ci, que le choix de votre configuration DNS offre une grande flexibilité.
Vos choix dépendront en grande partie des besoins de votre organisation et de votre priorité principale: fournir une résolution DNS plus rapide pour une sélection de clients (mise en cache ou transfert) ou desservir vos domaines et zones sur Internet au sens large (serveurs faisant autorité). Les approches combinées sont communes et, à la fin, les deux côtés du processus de résolution doivent être pris en compte.
Dans nos prochains guides, nous montrerons comment utiliser certaines de ces configurations. Nous commencerons par enseignerhow to set up a caching or forwarding server. Plus tard, nous verrons comment servir vos domaines parsetting up a pair of authoritative-only DNS servers.