Table des matières

• 3.2. Le DNS
  • Historique
  • Nommage DNS
  • Resources Records DNS
  • Architecture DNS
    • Serveurs de noms
    • Domaines, zones et délégation
      • Domaine et zone
      • Fichier de zone
    • Requête DNS complète
    • Délégation avec et sans Glue Record
  • Format des échanges DNS
  • Paramètres pour la couche transport
  • Optimisation du DNS
    • Résolveur
    • Cache DNS
  • Le DNS pour les services internes
• DNS inverse
  • Noms DNS inverses et RR PTR
  • Zone DNS inverse

3.2. Le DNS

Références :

• CNP3, chap. Naming and adressing
• CNP3, chap. The domain name system

Le service DNS est un service incontournable dans tout réseau TCP/IP. Son rôle est de permettre aux utilisateurs humains d’identifier des machines par des noms DNS plutôt que par des adresses IP, difficiles à retenir en IPv4 et impossibles à retenir en IPv6. En plus de fournir cette traduction d’adresse, le service DNS permet également la localisation des services dans un réseau. Ce service permet de répondre à des questions telles que :

• Quelle est l’adresse IPv4 de la machine www.ephec-ti.be?
• Quelle est l’adresse IPv6 de la machine www.google.com?
• Quelle est la machine responsable du service mail dans le domaine ephec-ti.be?
• …

Le DNS possède même la fonctionnalité “DNS inverse”, qui permet, pour une adresse IP donnée, d’obtenir le nom de la machine correspondante.

Historique

A l’origine, lorsqu’il n’y avait qu’un nombre très restreint de machines interconnectées dans l’Internet, chacune de ses machines possédait un fichier référençant l’ensemble des noms de machines sur le réseau, ainsi que leurs IPs. Ce fichier s’appelle le fichier “hosts”, et existe toujours aujourd’hui.

Cependant, lorsque le nombre de machines a commencé à augmenter, la mise à jour des fichiers “hosts” est devenue très complexe, à la fois à cause du nombre d’informations qu’ils contenaient et à cause de la fréquence à laquelle ces informations changeaient. De plus, il devenait de plus en plus difficile de garantir l’unicité des noms de machines dans un système à nommage “plat”.

Le DNS a alors été proposé, et apporte plusieurs grands changements au système de nommage primitif :

• un système de nommage hiérarchique, accolant un nom de domaine au nom de la machine. Ainsi, la machine “tartempion” utilisée à l’Ephec devient “tartempion.ephec.be”.
• une architecture décentralisée, permettant de répartir les informations concernant les noms dans de multiples serveurs
• un protocole permettant à un client de demander une information concernant un nom à un serveur DNS.

Nommage DNS

Un nom DNS est composé d’un nom d’hôte et d’un ou plusieurs noms de domaines imbriqués. Les domaines sont des divisions de l’ensemble des machines de l’Internet, chaque domaine étant géré par une entité administrative distincte. Etant donné le nombre de domaines possibles dans l’Internet, ils peuvent également être regroupés en domaines de haut niveau, et ainsi de suite. Les domaines tout en haut de cette hiérarchie sont les TLD : Top Level Domains. Ils peuvent être de différentes sortes :

• Géographiques (.be, .fr, .eu, etc.)
• Génériques (.com, .gov, .edu, etc.)
• Commerciaux (.airbus, .apple, .kinder, etc.)
• …

Les Top Level Domains sont gérés par l’IANA (Internet Assigned Numbers Authority).

Lorsqu’un domaine est inclus dans un domaine de plus haut niveau, on dit qu’il est un sous-domaine de ce dernier. Cette découpe hiérarchique est similaire à ce qu’on trouve en géographie : la Terre est découpée en continent, chaque continent étant découpé en pays, et chaque pays en régions.

Par exemple, dans la figure ci-dessus, le domaine ephec.be est un sous-domaine du TLD be. Il peut y avoir plusieurs domaines imbriqués. On pourrait ainsi imaginer le sous-domaine ti.lln.ephec.be. Si on souhaite placer un serveur web (dont le nom d’hôte est par convention www), ce dernier aurait pour nom complet www.ti.lln.ephec.be. Ce système permet de garantir plus aisément l’unicité des noms DNS : s’il existe deux machines avec le même nom d’hôte, il n’y a pas de conflit tant qu’elles restent dans des domaines différents, puisque leurs noms DNS complet seront différents. C’est d’ailleurs le cas avec les serveurs web, qui s’appellent par convention “www”.

Un nom DNS complet s’appelle un FQDN (Fully Qualified Domain Name). Par convention, un FQDN soit toujours se terminer par un point. En l’absence de point, les serveurs peuvent considérer qu’il s’agit d’un nom d’hôte, à interpréter relativement au domaine dans lequel il se trouve. Si on reprend la machine appelée “tartempion” dans la figure ci-dessus, son FQDN est “tartempion.ti.lln.ephec.be.”. On peut considérer ce point comme étant la “racine” de la hiérarchie du DNS : en lisant les noms de droite à gauche, on parcourt la hiérarchie depuis le haut (racine puis TLD) vers le bas (noms d’hôte)Si le point est oublié, les serveurs DNS pourraient le compléter avec le nom de domaine, ce qui donnerait comme FQDN “tartempion.ephec.be.ephec.be”. C’est une erreur fréquente à laquelle il faut rester attentif.

La figure ci-dessous représente le même “réseau DNS” fictif que celui de la figure précédente, mais cette fois sous forme d’arbre dont les domaines sont les noeuds et les hôtes sont les feuilles. On voit que la racine de l’arbre est bien la racine du DNS, le fameux “.”. Un FQDN se lit depuis la feuille jusqu’à la racine, donc du bas vers le haut.

Resources Records DNS

Le but premier du DNS est d’associer des noms DNS à des adresses IP. L’information que constitue cette association est représentée dans un format particulier, appelé Resource Record (RR).
En plus des associations nom/IP, les Resource Records DNS permettent d’enregistrer d’autres types d’information utiles pour un domaine DNS.

Chaque Resource Record contient les champs suivant :

• Le nom de la ressource à laquelle le RR fait référence
• Le type du RR
• La classe indique l’espace de noms concernés. Il en existe plusieurs, mais en pratique, seule la classe Internet (valeur IN) est utilisée.
• Un TTL éventuel indiquant la durée de validité du RR
• Et enfin, les données (par ex. IP)

Les types possibles de RRs sont notamment :

• Type A : Le RR concerne une adresse IPv4 pour l’hôte dont le nom est spécifié
• Type AAAA : Idem pour une adresse IPv6
• NS : Le RR concerne le nom du serveur DNS du domaine dont le nom est spécifié
• MX : Idem pour le serveur mail du domaine spécifié
• PTR : RR donnant, pour une IP donnée, le nom DNS (inverse du type A/AAAA)
• etc.

Les Ressource Records d’un domaine seront regroupés dans le fichier de zone du domaine, et seront échangés entre machine via le protocole DNS.

Voici quelques exemples de RRs DNS :

• Un RR de type A renseignant l’adresse IP de la machine www du domaine local (utilisation d’un nom DNS relatif) : www     IN      A       203.0.113.1
• Un RR de type A renseignant l’adresse IP de la machine www du domaine example.com (utilisation du FQDN) : www.example.com     IN      A       203.0.113.1
• Un RR de type MX renseignant le nom de la machine responsable du service mail du domaine example.com. Le 10 fait référence à la priorité, au cas où plusieurs serveurs mail sont disponibles (la plus petite valeur est préférée) : example.com    IN      MX    10   203.0.113.2

Architecture DNS

Serveurs de noms

Le nommage DNS hiérarchique nous permet de garantir l’unicité des noms de machines malgré le nombre important d’hôtes, mais ne nous permet pas en tant que tel de réduire la taille des fichiers “hosts”. Une autre approche est nécessaire : plutôt que de regrouper toutes les informations DNS en un seul fichier qui doit être dupliqué sur toutes les machines, elles vont plutôt être distribuées entre un ensemble de serveurs DNS possédant chacun un sous-ensemble des noms DNS. Ces serveurs sont souvent appelés “serveurs de noms” (name serveur en anglais), ou encore “serveurs autoritaires” ou “SOA”. Le fichier “hosts” présent sur chaque hôte ne servira plus qu’à garder les quelques informations DNS qui lui sont propres (ex : localhost).

Les postes client, s’ils ne trouvent pas l’information DNS dont ils ont besoin dans leur fichier “hosts”, vont effectuer des requêtes DNS vers les serveurs DNS. La question qui se pose est alors de trouver le serveur DNS qui détient l’information recherchée. Pour permettre la “navigation” dans le DNS, les serveurs vont être organisés de manière similaire au nommage DNS : chaque domaine ou sous-domaine aura son propre serveur DNS, qui contiendra les informations nécessaires pour répondre aux questions DNS relatives aux noms de ce domaine. Ainsi, le serveur DNS du sous-domaine “ephec.be.” contiendra l’adresse IP de la machine “tartempion.ephec.be.”, et pourra répondre à la requête correspondante.

Avec ce système, il “suffirait” à chaque machine de connaître l’adresse IP du serveur DNS de chaque domaine dans l’Internet. Il en existe beaucoup trop pour que cela soit envisageable… il faut donc trouver un moyen pour que les clients puissent découvrir les serveurs DNS de chaque domaine.

La solution à ce problème repose à nouveau sur la structure hiérarchique du DNS. Pour découvrir l’adresse IP du serveur DNS de “ephec.be.”, il suffira de la demander au serveur DNS de “be.”. Et pour trouver le serveur DNS de “be.”, il faudra s’adresser aux serveurs DNS à la racine du système : il s’agit des “serveurs racines”, ou “root servers”. Ces derniers sont au nombre de quelques dizaines, donc il devient réaliste de supposer qu’un client DNS peut garder ces quelques adresses en mémoire pour pouvoir effectuer des requêtes dans l’ensemble du DNS.

Domaines, zones et délégation

En pratique, un serveur DNS pour un domaine ne sera pas systématiquement en mesure de conserver les informations DNS de l’ensemble des machines de son domaine. Imaginez par exemple le nombre d’entrées pour le domaine “.com.”! A nouveau, la hiérarchie du DNS apporte la solution au problème. Si un nom se trouve “directement” dans un domaine, alors le serveur DNS pourra donner l’information la concernant. Par contre, si ce nom se trouve dans un sous-domaine, alors le serveur DNS exploitera le mécanisme de délégation : il renverra le client vers le serveur DNS du sous-domaine.

Domaine et zone

L’ensemble des machines directement contenues dans un domaine, à l’exclusion des machines contenues dans les sous-domaines de ce domaine s’appelle la zone correspondant à ce domaine.

Par exemple, imaginons à nouveau le domaine “ephec.be.”. Dans ce domaine, considérons deux machines :

• www.ephec.be.
• www.lln.ephec.be

La première de ces machines appartient au domaine “ephec.be.” ET à la zone “ephec.be.”. La seconde appartient également au domaine “ephec.be.”, mais puisqu’elle fait partie d’un sous-domaine de ce dernier, elle n’appartient PAS à la zone “ephec.be”.

Fichier de zone

Un serveur DNS pour un domaine contiendra alors comme informations :

• Les correspondances nom-IP pour les machines de sa zone (et d’autres informations)
• Les noms et adresses IPs des serveurs DNS de ses sous-domaines, auxquels il “délègue” la gestion des noms d’hôtes de ces sous-domaines.

Voici un exemple de fichier de zone pour une zone publique example.com :

; Fichier de zone externe pour le domaine example.com
$ORIGIN example.com
$TTL 1h

@       IN      SOA     ns1.example.com. hostmaster.example.com. (
                        2023111101      ; Numéro de série
                        1h              ; Délai de rafraîchissement
                        15m             ; Délai de réessai
                        1w              ; Délai d'expiration
                        1h )            ; TTL par défaut

  

; Définition des serveurs de noms 
        IN      NS      ns1.example.com.
        IN      NS      ns2.provider-dns.com.

; Définition des enregistrements A (adresses IPv4) pour les services de la zone
ns      IN      A       203.0.113.1
@       IN      A       203.0.113.2
www     IN      A       203.0.113.2
mail    IN      A       203.0.113.3  

; Définition des enregistrements AAAA (adresses IPv6)
www     IN      AAAA    2001:db8::1

; Définition des enregistrements MX (mail exchanger)
        IN      MX      10      mail.example.com.

; Définition des enregistrements CNAME (alias)
ftp     IN      CNAME   www.example.com.

; Délégation du sous-domaine ss-domaine.example.com
ss-domaine        IN      NS      ns1.ss-domaine.example.com. 
ns1.ss-domaine    IN      A       203.0.114.1

Requête DNS complète

Avec toutes ces informations, il devient possible de comprendre une requête DNS complète. Imaginons ainsi un poste client souhaitant joindre la machine www.google.com.

1. Il commencera par joindre les seuls serveurs DNS qu’il connaît : les serveurs racines. Il en choisit un, et lui demande l’adresse IP de www.google.com.
2. Le serveur racine répond que la machine demandée n’est pas dans sa zone, mais puisqu’il connait le serveur DNS du sous-domaine .com dans son fichier de zone, il transmet le nom (ns.com.) et l’IP de ce serveur au client.
3. Le client contacte le serveur DNS du domaine com. (ns.com).
4. Ce dernier, lui aussi, le redirige vers un sous-domaine, à savoir google.com., en lui donnant le nom du NS de ce sous-domaine (ns.google.com) ainsi que son adresse IP.
5. Finalement, le client peut enfin s’adresser directement au serveur DNS de google.com. (ns.google.com.).
6. Il reçoit cette fois la réponse attendue : l’adresse IP de la machine www.google.com., qui se trouve effectivement dans le fichier de zone de ns.google.com.

Délégation avec et sans Glue Record

Lorsqu’un serveur DNS pour un domaine redirige une requête vers un serveur DNS d’un sous-domaine suivant le mécanisme de délégation, il existe deux cas de figure, illustrés dans la figure ci-dessous :

• Le nom du serveur DNS de la zone concernée n’appartient pas lui-même à cette zone, mais éventuellement à un autre domaine. C’est par exemple le cas du domaine “tartempion.be” dans la figure ci-dessous, qui n’héberge pas lui-même sa zone mais utilise le service DNS du fournisseur OVH. Le NS de la zone tartempion.be est la machine “ns.ovh.net”, qui est dans un tout autre domaine. Lorsqu’un client demande au serveur NS de la zone “be.” comment joindre la zone tartempion.be., ce dernier renvoie “ns.ovh.net”, et le client devra faire un requête DNS distincte pour trouver l’IP de cette machine.
• Le nom du serveur DNS de la zone appartient lui-même à cette zone. Par exemple, dans le cas du domaine ephec.be, nous pourrions avoir un serveur DNS appelé “ns.ephec.be.” (ns pour Name Server). Lorsque le serveur DNS de “be.” nous redirige vers “ns.ephec.be”, nous devrions, pour trouver son adresse IP, envoyer une requête… à ce serveur même, ce qui n’est pas possible sans son adresse IP! Pour résoudre ce problème de dépendance circulaire, la solution consiste à donner l’adresse IP du serveur DNS du sous-domaine délégué au serveur DNS du serveur de plus haut niveau, même si cette machine n’est pas normalement dans sa zone. Cette information concernant l’adresse IP d’un serveur de sous-domaine s’appelle le “Glue Record”. Dans la figure ci-dessous, le “glue record” figure dans le fichier de zone de “be.” : il s’agit du record A pour ns.ephec.be. Il sera donné comme “information additionnelle” en complément du NS de la zone “ephec.be.”

Format des échanges DNS

Le protocole DNS est un protocole relativement basique, basé essentiellement sur des échanges de messages courts entre un client et un serveur, sous forme de requête/réponse. Les messages contiendront généralement des “Resource Records” (RRs), qui sont les unités d’informations DNS.

Lorsqu’un client fait une requête, il enverra sa demande sous forme d’un RR ne contenant pas de données. Le serveur y répondra alors en envoyant une réponse contenant le RR de la requête, ainsi qu’un second RR contenant les informations demandées. Cela peut s’observer sur la trace Wireshark ci-dessous, qui représente une réponse DNS à une requête de type A. On voit bien la section “Query” avec le RR sans information sur l’IP, puis la section “Response”, contenant le même RR mais avec des données reprenant l’adreses IP demandée.

Lorsque le serveur ne connaît pas la réponse et doit rediriger vers le serveur d’un sous-domaine via le mécanisme de délégation, il ne pourrait pas répondre directement à la requête, mais donnera des resources records dit “authoritative” qui donneront le nom de domaine. Dans la capture ci-dessous, une requête DNS pour “www.google.be” a été envoyée à un des serveurs de la zone “be.”. Ce dernier a répondu en envoyant vers les serveurs responsable du domaine “google.be”. Ces serveurs n’appartenant pas eux-mêmes au domaine “google.be”, mais plutôt au domaine “google.com”, la réponse n’inclut pas de Glue Record les concernant.

Refaisons l’expérience précédente, cette fois avec un autre domaine. Une requête DNS pour la machine “dns12.ovh.net” a été envoyée vers le NS du domaine “net”. Ce dernier a répondu en indiquant plusieurs noms de serveurs responsables du domaine “ovh.net” (section “Authoritative Nameservers”). Comme tous ces serveurs font également partie du domaine “ovh.net”, il ne sera pas possible d’obtenir leur IP en les contactant. Le serveur du domaine “net.” nous envoie donc également leurs adresses IP dans une section “records additionnels” (Glue Records).

Paramètres pour la couche transport

Le DNS utilise les deux protocoles Transport TCP et UDP, selon les cas. La plupart du temps, les requêtes et les réponses DNS sont courtes, et il est essentiel que l’échange soit rapide. Le protocole UDP sera utilisé dans ce cas de figure. Lorsque les informations échangées font plus que 512 octets, l’utilisation de TCP est requise.

Dans les deux cas, le port utilisé pour le DNS est le port 53.

Optimisation du DNS

Résolveur

Nous l’avons vu, obtenir une information DNS n’est pas simple, puisqu’il faut parcourir la hiérarchie des serveurs DNS pour arriver à trouver celui qui possède l’information qui nous intéresse. Ces requêtes multiples nécessaires pour obtenir l’information en partant du haut de la hiérarchie pour trouver le serveur responsable s’appellent des requêtes itératives. Cela a été illustré plus haut, dans la figure montrant une machine du réseau ephec.be recherchant l’IP de www.google.com en parcourant la hiérarchie DNS.

Pour simplifier la tâche des postes clients, un serveur dédié va typiquement être mis en place pour effectuer les requêtes itérative à leur place. Ce serveur s’appelle un résolveur DNS. Les clients vont être configurés pour lui confier toutes leurs requêtes DNS, et le résolveur se chargera d’obtenir l’information en appliquant la procédure de recherche complète. La requête d’un client à un résolveur s’appelle requête récursive : lorsqu’il reçoit une requête récursive, le résolveur va lui-même effectuer des requêtes DNS itératives jusqu’à obtenir l’information.

Dans la figure ci-dessus, nous revoyons le scénario déjà illustré plus tôt : un client du réseau ephec.be. souhaite obtenir l’adresse IP de www.google.com. Cependant, cette fois, un serveur intermédiaire va venir alléger la tâche du client et du système DNS : il s’agit du résolveur.

Le client n’a plus que deux actions à effectuer : envoyer sa requête (1) et attendre la réponse (8). Entre les deux, le résolveur s’occupe du reste, à savoir parcourir la hiérarchie DNS par de multiples requêtes.

La requête initiale (1) envoyée par le client est une requête dite récursive : le client souhaite que le serveur auquel il s’adresse recherche l’information s’il ne la connait pas.
Les requêtes (2), (4) et (6) envoyées par le résolveur en direction des serveurs DNS publics sont itératives : les serveurs interrogés ne répondent qu’avec des informations qu’ils connaissent ou des redirections vers d’autres serveurs de noms. Ils ne feront pas eux-mêmes de recherche à la place du résolveur.

Ce système de résolveur simplifie la configuration des postes client : plutôt que de devoir leur donner et tenir à jour la liste des serveurs racine, il suffit de leur indiquer l’adresse IP du résolveur du réseau. Cette information est facilement configurable via le DHCP vu plus haut.

Il est important de bien connaître les différences entre un résolveur et un serveur de noms : bien qu’étant tous les deux des serveurs DNS, ils fonctionnent de manière complètement différente!

	Serveur de noms public	Résolveur
Origine des requêtes acceptées	Tout Internet	Uniquement les postes du réseau
Requêtes traitées	Uniquement celles concernant la zone	N’importe lesquelles
Accepte les requêtes récursives?	Non	Oui

Cache DNS

Pour alléger à la fois le trafic et la charge sur les serveurs DNS, il est nécessaire d’utiliser des mécanismes de cache. En effet, beaucoup d’utilisateurs vont effectuer la même requête dans la même journée, ou bien un même utilisateur visitera plusieurs fois un même site Internet. Une fois qu’une information a été obtenue du DNS, il est intéressant de la mettre en cache pour éviter des requêtes ultérieures coûteuses.

Des caches sont possibles à plusieurs niveaux :

• Au niveau des OS des postes utilisateurs, qui permettent d’éviter de faire plusieurs fois la même requête pour un même poste. Avant de lancer une nouvelle requête DNS, l’OS vérifiera si l’information ne figure pas déjà dans sa cache.
• Au niveau de serveurs DNS cache dédiés, placés dans les réseaux de fournisseurs ou les réseaux d’entreprise, qui permettent de mutualiser les requêtes DNS de tous les clients. Les résolveurs sont typiquement configurés en tant que serveurs cache.

En pratique, une information DNS pourra être gardée en cache pour une durée équivalente au TTL indiqué dans son RR. Passé ce délai, le RR est considéré comme périmé, et la requête doit être relancée.

Le DNS pour les services internes

Jusqu’ici, les mécanismes DNS qui ont été présentés s’appliquent aux ressources DNS publiques, à savoir les noms accessibles publiquement par Internet, et les machines joignables par des IP publiques. Néanmoins, dans les réseaux d’entreprise, il existe souvent des services internes qui ne sont pas et ne doivent pas être accessibles publiquement. On parle ainsi souvent d’“intranet”. Ces services, bien qu’inaccessibles publiquement, doivent néanmoins être joignables par les postes internes. Il faut donc également un système DNS pour ces services internes. Pour cela, on va en général créer un domaine interne découplé de la hiérarchie DNS publique, et mettre en place un serveur de noms dédié à cette zone.

Pour que les postes clients puissent joindre cette zone interne en plus d’avoir un accès classique à l’Internet, le résolveur sera configuré pour réagir différemment en fonction des noms recherchés :

• Si la requête concerne un nom du domaine interne, la requête est transmise au serveur de noms internes.
• Si la requête concerne l’Internet, le résolveur effectue ses requêtes itératives comme vu plus tôt.

Dans la figure ci-dessus, plusieurs serveurs DNS sont représentés, pour synthétiser les rôles DNS vu jusqu’ici. Nous avons, dans la partie DNS public :

• les serveurs racines, connaissant les noms (et éventuellement les glue records) des NS des TLDs (Top Level Domains)
• Les serveurs NS des TLDs
• ainsi que les NS publics des sous-domaines des TLDs (non représentés ici)

Dans la partie de gauche, un réseau d’entreprise est représenté, avec trois zones : la zone pour les postes employés, la zone pour les serveurs internes, et la zone pour les serveurs accessibles depuis l’extérieur (DMZ). Pour des raisons de sécurité, ces trois réseaux doivent être isolés l’un de l’autre ainsi que de l’Internet par un firewall.

Ce réseau d’entreprise contient trois serveurs DNS :

• Dans la DMZ, un NS public, permettant à n’importe qui depuis l’internet de joindre les services publics de l’entreprise (mail, site web, …)
• Dans la zone interne, un NS privé, contenant les informations permettant aux employés d’utiliser les services internes de l’entreprise (intranet, téléphonie interne, …)
• Dans la zone interne, le résolveur, pour traduire les noms DNS en IP à la place des postes employés. Ce résolveur devra répondre différemment selon les requêtes envoyées par les employés :
  • Si la requête concerne un service de la zone interne, le résolveur redirigera la requête vers le NS interne.
  • Si la requête concerne un service de la zone publique, le résolveur pourrait rediriger la requête vers le NS public.
  • Si la requête concerne un nom externe à l’entreprise, le résolveur effectue une requête itérative dans le DNS public.

Le tableau ci-dessous reprend les caractéristiques des trois types de serveurs DNS rencontrés :

	Serveur de noms public	Serveur de noms interne	Résolveur
Origine des requêtes acceptées	Tout Internet	Uniquement les postes du réseau interne	Uniquement les postes du réseau interne
Requêtes traitées	Uniquement celles concernant la zone publique (IP publiques)	Uniquement celles concernant la zone interne (IP privées)	- Zone interne : Redirige vers le NS interne. - Internet (zone « . ») : Requêtes itératives pour trouver la réponse
Accepte les requêtes récursives?	Non	Non	Oui

Un serveur de noms interne, tout comme un serveur de noms public, répondra aux requêtes sur base de son fichier de zone. Ce dernier est d’un format similaire à celui d’une zone publique, si ce n’est que les adresses IP mentionnées sont des adresses privées. Comme ces adresses ne sont pas routables et qu’on ne souhaite pas dévoiler publiquement l’adressage interne de la zone, cela explique que le serveur de noms interne ne réponde qu’aux requêtes internes.

Voici un exemple de fichier pour une zone interne :

; Fichier de zone interne pour le domaine internal.example.com
$ORIGIN internal.example.com.
$TTL 1h

@       IN      SOA     ns1.internal.example.com. hostmaster.example.com. (
                        2023111101      ; Numéro de série
                        1h              ; Délai de rafraîchissement
                        15m             ; Délai de réessai
                        1w              ; Délai d'expiration
                        1h )            ; TTL par défaut

  

; Définition des serveurs de noms 
        IN      NS      ns1.internal.example.com.

; Définition des enregistrements A (adresses IPv4) pour les services de la zone
ns1     IN      A       192.168.0.1
@       IN      A       192.168.0.2
www     IN      A       192.168.0.3

DNS inverse

Dans une zone, il est également utile de pouvoir disposer du DNS inverse, ou Reverse DNS, pour des raisons de facilité d’administration (fichiers de logs plus clairs), mais également de sécurité. Certaines applications exigent également du DNS inverse pour fonctionner. Dans le cas d’une zone DNS publique avec un service mail, le reverse DNS est un des moyens utilisés pour garantir l’authenticité du serveur mail.

Le DNS inverse consiste à pouvoir récupérer, au départ d’une adresse IP, le nom de machine associé, contrairement au DNS direct (record A/AAAA) qui, au départ d’un nom, renvoie une IP.

Noms DNS inverses et RR PTR

Le DNS inverse fonctionne via des Resource Record de type PTR (pointeur).
Comme les resources records doivent normalement être des FQDNs (tels que www.internal.example.com), il faut trouver un moyen de transformer une adresse IP en nom DNS hiérarchique. Les adresses IPs ont déjà une structure hiérarchique, avec ses bits de poids fort spécifiant le sous-réseau et les bits de poids faible spécifiant l’hôte. Le DNS inverse va donc se baser sur cette logique, mais en inversant le sens des octets pour que la partie “host” soit à gauche, comme dans un nom DNS classique.

En plus de cela, pour faire la distinction entre les noms “IP” et les noms “normaux”, un domaine particulier a été défini pour contenir tous les noms DNS inverses. Il s’agit du domaine in-addr.arpa.

Prenons l’exemple de l’adresse IP 192.168.0.1. En inversant ses octets et en insérant ce résultat dans le domaine in-addr.arpa, on obtient son un nom DNS inverse 1.0.168.192.in-addr.arpa. Pour l’associer à son nom de machine ```www.internal.example.com, on va définir le Resource Record PTR comme suit :

1.0.168.192.in-addr.arpa          IN     PTR    router.internal.example.com.

Pour effectuer une requête DNS inverse avec dig pour ce record particulier, on utilisera la commande suivante (dans le réseau concerné) :

dig -x 192.168.0.1

L’option -x permet d’indiquer que l’on souhaite faire du DNS inverse. On aurait également pu utiliser la commande suivante, où l’on n’indique pas que l’on fait du DNS inverse, mais où on spécifie explicitement que l’on souhaite un record PTR portant sur le nom DNS inverse de l’IP visée :

dig -t PTR 1.0.168.192.in-addr.arpa

Zone DNS inverse

Le DNS direct (forward) s’organise en zones basées sur la hiérarchie des domaines. Dans le DNS inverse, la hiérarchie est liée aux sous-réseaux. On va donc définir une zone par sous-réseau, et, pour cette zone, lister les IPs pour lesquelles on souhaite du DNS inverse.
Voici un exemple de fichier de zone pour le subnet 192.168.0.0/24:

$TTL 86400
$ORIGIN 0.168.192.in-addr.arpa.  ; Nom de la zone

@   IN  SOA     ns1.internal.example.com. admin.internal.example.com. (
                    2023110601 ; Numéro de série (année-mois-jour-rev)
                    3600        ; Intervalle de rafraîchissement
                    1800        ; Délai de réessai
                    1209600     ; Expiration
                    86400 )     ; Durée minimum du cache

    IN  NS      ns1.internal.example.com.

1   IN  PTR     router.internal.example.com.
2   IN  PTR     www.internal.example.com.
3   IN  PTR     files.internal.example.com.
4   IN  PTR     workstation.internal.example.com.

Notez bien la variable $ORIGIN: elle définit le nom de la zone concernée. Tous les noms DNS relatifs (non-FQDNs) seront interprétés relativement à cette variable.

Dans la définition des hôtes, le nom DNS inverse est relatif, et ne contient que le dernier octet. Le premier hôte a le nom relatif 1, qui doit donc être interprété comme correspondant au FQDN 1.0.168.192.in-addr.arpa.

Notez que le nom DNS mappé à l’IP doit être un FQDN : en effet, il appartient à la zone internal.example.com., qui n’est pas dans la zone 0.168.192.in-addr.arpa. Si on avait juste indiqué router, cela aurait été interprété comme le nom router.0.168.192.in-addr.arpa, ce qui n’aurait eu aucun sens.

En pratique, dans un réseau d’entreprise interne, on définira typiquement deux zones :

• La zone directe
• La zone inverse

Le serveur NS interne doit donc être configuré pour servir ces deux zones. Quant au résolveur, il doit pouvoir également connaître ses deux zones, pour pouvoir relayer les requêtes les concernant au serveur NS interne.