Aller au contenu principal

6. Name Server Implementation (Implémentation du serveur de noms)

Ce chapitre traite des considérations d'implémentation pour les serveurs de noms DNS.

6.1. Architecture​

La structure optimale pour le serveur de noms dépendra du système d'exploitation hôte et du fait que le serveur de noms soit intégré aux opérations de résolution, soit en prenant en charge le service récursif, soit en partageant sa base de données avec un résolveur.

Cette section traite des considérations d'implémentation pour un serveur de noms qui partage une base de données avec un résolveur, mais la plupart de ces préoccupations sont présentes dans tout serveur de noms.

6.1.1. Control (Contrôle)​

Un serveur de noms doit (MUST) employer plusieurs activités simultanées, qu'elles soient implémentées en tant que tâches séparées dans le système d'exploitation de l'hôte ou multiplexées à l'intérieur d'un seul programme de serveur de noms.

Exigences:

  • UDP non-bloquant: Il est tout simplement inacceptable qu'un serveur de noms bloque le service des requêtes UDP pendant qu'il attend des données TCP pour des activités de rafraîchissement ou de requête

  • Traitement parallèle: Un serveur de noms ne devrait pas (SHOULD NOT) tenter de fournir un service récursif sans traiter de telles requêtes en parallèle, bien qu'il puisse choisir de:

    • Sérialiser les requêtes d'un seul client
    • Considérer les requêtes identiques du même client comme des doublons

  • Opérations de zone non-bloquantes: Un serveur de noms ne devrait pas (SHOULD NOT) retarder considérablement les requêtes pendant qu'il:

    • Recharge une zone à partir de fichiers maîtres
    • Incorpore une zone nouvellement rafraîchie dans sa base de données

6.1.2. Database (Base de données)​

Bien que les implémentations de serveurs de noms soient libres d'utiliser n'importe quelles structures de données internes qu'elles choisissent, la structure suggérée se compose de trois parties principales:

Structure de base de données suggérée​

1. Structure de données de catalogue (Catalog Data Structure):

  • Répertorie les zones disponibles pour ce serveur
  • Contient un "pointeur" vers la structure de données de zone
  • Objectif principal: trouver la zone ancêtre la plus proche, le cas échéant, pour les requêtes standard arrivantes

2. Structures de données de zone (Zone Data Structures):

  • Structures de données séparées pour chacune des zones détenues par le serveur de noms
  • Contient des données autoritatives pour la zone

3. Structure de données de cache (Cache Data Structure):

  • Une structure de données pour les données en cache
  • Peut avoir des caches séparés pour différentes classes

Considérations d'implémentation​

Structure arborescente: Toutes ces structures de données peuvent être implémentées dans un format de structure arborescente identique, avec différentes données chaînées aux nœuds dans différentes parties:

  • Dans le catalogue: les données sont des pointeurs vers les zones
  • Dans les structures de données de zone et de cache: les données seront des RR

Exigences de traitement des requêtes: Lors de la conception du cadre arborescent, le concepteur doit reconnaître que:

  • Le traitement des requêtes devra traverser l'arbre en utilisant des comparaisons d'étiquettes insensibles à la casse
  • Dans les données réelles, quelques nœuds ont un facteur de branchement très élevé (100-1000 ou plus)
  • La grande majorité a un facteur de branchement très faible (0-1)

Solution de stockage insensible à la casse​

Une façon de résoudre le problème de la casse est de stocker les étiquettes pour chaque nœud en deux parties:

  1. Une représentation en casse standardisée de l'étiquette où tous les caractères ASCII sont en une seule casse
  2. Un masque de bits qui indique quels caractères sont réellement d'une casse différente

Optimisation du facteur de branchement​

La diversité du facteur de branchement peut être gérée par:

  • Utilisation d'une simple liste chaînée pour un nœud jusqu'à ce que le facteur de branchement dépasse un certain seuil
  • Transition vers une structure de hachage après le dépassement du seuil

Important: Les structures de hachage utilisées pour stocker les sections d'arbre doivent garantir que les fonctions et procédures de hachage préservent les conventions de casse du DNS.

Avantages des structures séparées​

L'utilisation de structures séparées pour les différentes parties de la base de données est motivée par plusieurs facteurs:

1. Stabilité du catalogue:

  • La structure du catalogue peut être une structure presque statique
  • Ne doit changer que lorsque l'administrateur système modifie les zones prises en charge par le serveur
  • Peut également stocker des paramètres utilisés pour contrôler les activités de rafraîchissement

2. Remplacement atomique de zone:

  • Les structures de données individuelles pour les zones permettent de remplacer une zone simplement en changeant un pointeur dans le catalogue
  • Les opérations de rafraîchissement de zone peuvent construire une nouvelle structure et, une fois terminées, l'épisser dans la base de données via un simple remplacement de pointeur
  • Critique: Lorsqu'une zone est rafraîchie, les requêtes ne devraient pas (SHOULD NOT) utiliser simultanément les anciennes et les nouvelles données

3. Priorité des données:

  • Avec les procédures de recherche appropriées, les données autoritatives dans les zones "masqueront" toujours, et auront donc priorité sur, les données en cache

4. Isolation des erreurs:

  • Les erreurs dans les définitions de zone qui causent des zones qui se chevauchent peuvent causer des réponses erronées aux requêtes
  • La détermination des problèmes est simplifiée
  • Le contenu d'une "mauvaise" zone ne peut pas corrompre une autre

5. Gestion du cache:

  • Étant donné que le cache est le plus fréquemment mis à jour, il est le plus vulnérable à la corruption lors des redémarrages du système
  • Il peut également se remplir de données RR expirées
  • Dans les deux cas, il peut facilement être supprimé sans perturber les données de zone

Récupération après plantage​

Un aspect majeur de la conception de la base de données est la sélection d'une structure qui permet au serveur de noms de faire face aux plantages de l'hôte du serveur de noms.

Informations d'état qu'un serveur de noms devrait (SHOULD) sauvegarder à travers les plantages du système:

  • La structure du catalogue (y compris l'état de rafraîchissement pour chaque zone)
  • Les données de zone elles-mêmes

6.1.3. Time (Temps)​

Les données TTL pour les RR et les données de temporisation pour les activités de rafraîchissement dépendent de temporisateurs 32 bits en unités de secondes.

Représentation du temps​

Modèle conceptuel:

  • À l'intérieur de la base de données, les temporisateurs de rafraîchissement et les TTL pour les données en cache "décomptent" conceptuellement
  • Les données dans la zone restent avec des TTL constants

Stratégie d'implémentation recommandée:

Stocker le temps de deux manières: en tant qu'incrément relatif et en tant que temps absolu.

Une façon de le faire est d'utiliser:

  • Des nombres positifs 32 bits pour un type
  • Des nombres négatifs pour l'autre

Utilisation:

  • Les RR dans les zones utilisent des temps relatifs
  • Les temporisateurs de rafraîchissement et les données de cache utilisent des temps absolus
  • Les nombres absolus sont pris par rapport à une origine connue et convertis en valeurs relatives lorsqu'ils sont placés dans la réponse à une requête
  • Lorsqu'un TTL absolu est négatif après conversion en relatif, alors les données sont expirées et devraient être ignorées

6.2. Standard Query Processing (Traitement des requêtes standard)​

L'algorithme principal pour le traitement des requêtes standard est présenté dans RFC-1034.

Cas spéciaux et règles​

Traitement QCLASS=*:

  • Lors du traitement des requêtes avec QCLASS=*, ou une autre QCLASS qui correspond à plusieurs classes
  • La réponse ne devrait jamais (SHOULD NOT) être autoritaire à moins que le serveur ne puisse garantir que la réponse couvre toutes les classes

Gestion des RR en double:

  • Lors de la composition d'une réponse, les RR qui doivent être insérés dans la section additionnelle, mais dupliquent des RR dans les sections réponse ou autorité, peuvent être omis de la section additionnelle

Politique de troncature:

  • Lorsqu'une réponse est si longue que la troncature est requise
  • La troncature devrait (SHOULD) commencer à la fin de la réponse et travailler vers l'avant dans le datagramme
  • Ainsi, s'il y a des données pour la section autorité, la section réponse est garantie d'être unique

Champ SOA MINIMUM:

  • La valeur MINIMUM dans le SOA devrait (SHOULD) être utilisée pour définir un plancher sur le TTL des données distribuées depuis une zone
  • Cette fonction de plancher devrait (SHOULD) être effectuée lorsque les données sont copiées dans une réponse
  • Cela permettra aux futurs protocoles de mise à jour dynamique de modifier le champ SOA MINIMUM sans sémantique ambiguë

6.3. Zone Refresh and Reload Processing (Traitement du rafraîchissement et du rechargement de zone)​

Gestion des erreurs​

Malgré les meilleurs efforts d'un serveur, il peut être incapable de:

  • Charger les données de zone à partir d'un fichier maître en raison d'erreurs de syntaxe, etc.
  • Rafraîchir une zone dans son paramètre d'expiration

Dans ce cas: Le serveur de noms devrait (SHOULD) répondre aux requêtes comme s'il n'était pas censé posséder la zone.

Cohérence du transfert de zone​

Si un maître envoie une zone via AXFR, et qu'une nouvelle version est créée pendant le transfert:

  • Le maître devrait (SHOULD) continuer à envoyer l'ancienne version si possible
  • Dans tous les cas, il ne devrait jamais (MUST NOT) envoyer une partie d'une version et une partie d'une autre
  • Si l'achèvement n'est pas possible, le maître devrait (SHOULD) réinitialiser la connexion sur laquelle le transfert de zone a lieu

6.4. Inverse Queries (Requêtes inverses) (Optionnel)​

Les requêtes inverses sont une partie optionnelle du DNS.

Exigences de support​

  • Les serveurs de noms ne sont pas requis (NOT REQUIRED) de prendre en charge toute forme de requêtes inverses
  • Si un serveur de noms reçoit une requête inverse qu'il ne prend pas en charge, il renvoie une réponse d'erreur avec l'erreur "Non implémenté" définie dans l'en-tête
  • Bien que le support des requêtes inverses soit optionnel, tous les serveurs de noms doivent (MUST) au moins être capables de renvoyer la réponse d'erreur

6.4.1. The Contents of Inverse Queries and Responses (Contenu des requêtes et réponses inverses)​

Les requêtes inverses inversent les mappages effectués par les opérations de requête standard:

  • Alors qu'une requête standard mappe un nom de domaine vers une ressource
  • Une requête inverse mappe une ressource vers un nom de domaine

Exemple:

  • Une requête standard peut lier un nom de domaine à une adresse d'hôte
  • La requête inverse correspondante lie l'adresse d'hôte à un nom de domaine

Format​

Les requêtes inverses prennent la forme de:

  • Un seul RR dans la section réponse du message
  • Une section question vide
  • Le nom de propriétaire du RR de requête et son TTL ne sont pas significatifs

Réponse​

La réponse porte des questions dans la section question qui identifient tous les noms possédant le RR de requête QUE LE SERVEUR DE NOMS CONNAÎT.

Limitations importantes:

  • Étant donné qu'aucun serveur de noms ne connaît tout l'espace de noms de domaine, la réponse ne peut jamais être supposée complète
  • Ainsi, les requêtes inverses sont principalement utiles pour les activités de gestion de base de données et de débogage
  • Les requêtes inverses ne sont PAS une méthode acceptable de mappage des adresses d'hôte aux noms d'hôte; utilisez plutôt le domaine IN-ADDR.ARPA

Comparaisons insensibles à la casse​

Dans la mesure du possible, les serveurs de noms devraient (SHOULD) fournir des comparaisons insensibles à la casse pour les requêtes inverses:

  • Une requête inverse demandant un RR MX de Venera.isi.edu devrait (SHOULD) obtenir la même réponse qu'une requête pour VENERA.ISI.EDU
  • Une requête inverse pour le RR HINFO IBM-PC UNIX devrait (SHOULD) produire le même résultat qu'une requête inverse pour IBM-pc unix

Note: Cela ne peut pas être garanti car les serveurs de noms peuvent posséder des RR qui contiennent des chaînes de caractères mais le serveur de noms ne sait pas que les données sont des caractères.

Traitement des résultats​

Lorsqu'un serveur de noms traite une requête inverse, il renvoie soit:

  1. Zéro, un ou plusieurs noms de domaine pour la ressource spécifiée en tant que QNAME dans la section question
  2. Un code d'erreur indiquant que le serveur de noms ne prend pas en charge le mappage inverse du type de ressource spécifié

Modification de la réponse​

Lorsque la réponse à une requête inverse contient un ou plusieurs QNAME:

  • Le nom de propriétaire et le TTL du RR dans la section réponse qui définit la requête inverse sont modifiés pour correspondre exactement à un RR trouvé au premier QNAME

Restrictions de mise en cache​

Les RR renvoyés dans les requêtes inverses ne peuvent pas être mis en cache (CANNOT) en utilisant le même mécanisme que celui utilisé pour les réponses aux requêtes standard.

Raison: Un nom peut avoir plusieurs RR du même type, et un seul apparaîtrait. Par exemple, une requête inverse pour une seule adresse d'un hôte multi-hébergé pourrait créer l'impression qu'une seule adresse existait.

6.4.2. Inverse Query and Response Example (Exemple de requête et réponse inverse)​

La structure globale d'une requête inverse pour récupérer le nom de domaine qui correspond à l'adresse Internet 10.1.0.52:

Requête:

+-----------------------------------------+
|  Header   | OPCODE=IQUERY, ID=997       |
+-----------------------------------------+
| Question  | <empty>                     |
+-----------------------------------------+
|  Answer   | <anyname> A IN 10.1.0.52    |
+-----------------------------------------+
| Authority | <empty>                     |
+-----------------------------------------+
|Additional | <empty>                     |
+-----------------------------------------+

Explication:

  • Cette requête demande une question dont la réponse est l'adresse de style Internet 10.1.0.52
  • Étant donné que le nom de propriétaire n'est pas connu, n'importe quel nom de domaine peut être utilisé comme espace réservé (et est ignoré)
  • Un seul octet de zéro, signifiant la racine, est généralement utilisé car il minimise la longueur du message
  • Le TTL du RR n'est pas significatif

Réponse:

+-----------------------------------------+
|  Header   | OPCODE=RESPONSE, ID=997     |
+-----------------------------------------+
| Question  | QTYPE=A, QCLASS=IN,         |
|           | QNAME=VENERA.ISI.EDU        |
+-----------------------------------------+
|  Answer   | VENERA.ISI.EDU A IN         |
|           | 10.1.0.52                   |
+-----------------------------------------+
| Authority | <empty>                     |
+-----------------------------------------+
|Additional | <empty>                     |
+-----------------------------------------+

Note: Le QTYPE dans une réponse à une requête inverse est le même que le champ TYPE dans la section réponse de la requête inverse. Les réponses aux requêtes inverses peuvent contenir plusieurs questions lorsque l'inverse n'est pas unique. Si la section question dans la réponse n'est pas vide, alors le RR dans la section réponse est modifié pour correspondre à une copie exacte d'un RR au premier QNAME.

6.4.3. Inverse Query Processing (Traitement des requêtes inverses)​

Les serveurs de noms qui prennent en charge les requêtes inverses peuvent prendre en charge ces opérations par des recherches exhaustives de leurs bases de données, mais cela devient impraticable à mesure que la taille de la base de données augmente.

Approche alternative: Inverser la base de données selon la clé de recherche.

Recommandation pour les grands serveurs​

Pour les serveurs de noms qui prennent en charge plusieurs zones et une grande quantité de données, l'approche recommandée est:

  • Des inversions séparées pour chaque zone
  • Lorsqu'une zone particulière est modifiée lors d'un rafraîchissement, seules ses inversions doivent être refaites

Note: Le support pour le transfert de ce type d'inversion peut être inclus dans les versions futures du système de domaine, mais n'est pas pris en charge dans cette version.

6.5. Completion Queries and Responses (Requêtes et réponses de complétion)​

Les services de complétion optionnels décrits dans RFC-882 et RFC-883 ont été supprimés.

Des services redessinés peuvent devenir disponibles à l'avenir.

Suivant: 7. Resolver Implementation (Implémentation du résolveur)

Dernière mise à jour le