resolv.conf(5) File Formats Manual resolv.conf(5)

resolv.conf — Fichier de configuration de la résolution de noms

/etc/resolv.conf

La bibliothèque resolver est un ensemble de routines de la bibliothèque C qui fournit un accès au système DNS Internet. Le fichier de configuration de la résolution de noms contient des informations qui sont lues par les routines de résolution la première fois qu'elles sont invoquées par un processus. Le fichier est prévu pour être lisible par des humains et contient une liste de mots-clés avec des valeurs qui fournissent divers types d’information de résolution. Le fichier de configuration est considéré comme une source fiable d'information DNS. Consulter l’option trust-ad ci-après pour les détails.

Si ce fichier n'existe pas, seul le serveur de noms de la machine locale sera interrogé, et la liste de recherche contient le nom de domaine local déterminé à partir du nom d'hôte.

Les différentes options de configuration sont :

Adresse Internet du serveur de noms que la bibliothèque resolver interrogera, soit une adresse IPv4 (en notation avec des points), soit une adresse IPv6 en notation séparée par des deux-points (ou éventuellement avec des points) conformément à la RFC 2373. Jusqu'à MAXNS (actuellement 3, consultez <resolv.h>) serveurs de noms peuvent être mentionnés, un par mot-clé. S'il y a plusieurs serveurs, la bibliothèque de résolution les interrogera dans l'ordre indiqué. Si aucune entrée nameserver n'est présente, le fonctionnement par défaut consiste à utiliser le serveur de noms se trouvant sur la machine locale (l'algorithme consiste à interroger un serveur de noms, et si la requête dépasse le temps maximal, à essayer le suivant, jusqu'à la fin de la liste, et à recommencer jusqu'à un nombre maximal de tentatives.)
Par défaut, la liste de recherche contient une entrée, le nom du domaine local. Celui-ci est déterminé à partir du nom local de l'hôte renvoyé par gethostname(2). Le nom de domaine local est constitué de tout ce qui se trouve après le premier « . ». Finalement, si le nom d'hôte ne contient pas de « . », le domaine racine est assumé comme nom de domaine local.
Cela peut être modifié en listant le chemin de recherche de domaines désiré qui suit le mot-clé search avec des espaces ou des tabulations séparant les noms. Les requêtes de résolution ayant moins de ndots points (par défaut, 1) seront menées en essayant chaque élément du chemin de recherche l'un après l'autre jusqu'à obtenir une correspondance. Pour les environnements comprenant de nombreux sous-domaines, veuillez consulter options ndots :n ci-dessous pour éviter des attaques de type homme du milieu et du trafic superflu pour les serveurs DNS racine. Veuillez noter que ce processus peut être lent et engendrer un trafic réseau très important si les serveurs pour les domaines listés ne sont pas locaux, et que les requêtes dépasseront le délai alloué si aucun serveur n'est disponible pour l'un de ces domaines.
Si plusieurs directives search existent, seule la liste de recherche de la dernière instance sera utilisée.
Dans la glibc, versions 2.25 et précédentes, la liste de recherche est limitée à six domaines, avec un maximum de 256 caractères. Depuis la glibc 2.25, la liste de recherche est illimitée.
La directive domain est un nom obsolète pour la directive search qui gère une seule entrée de liste de recherche.
Cette option permet aux adresses renvoyées par gethostbyname(3) d'être ordonnées. Une liste de tri est indiquée par des paires adresse IP-masque réseau. Le masque réseau est optionnel et prend par défaut la valeur du masque natif du réseau. Les paires adresse IP-masque réseau optionnel sont séparées par des barres obliques. Jusqu'à 10 paires peuvent être mentionnées. Voici un exemple :

sortlist 130.155.160.0/255.255.240.0 130.155.0.0
Les options permettent de modifier certaines variables internes de la bibliothèque resolver. La syntaxe est
options option ...

où option est une des options suivantes :

Définition de RES_DEBUG dans _res.options (effectif uniquement si la glibc a été construite avec la prise en charge du débogage ; consulter resolver(3)).
Définition d’un seuil pour le nombre de points qui doivent apparaître dans un nom fourni à res_query(3) (consulter resolver(3)) avant qu'une requête absolue initiale soit entreprise. La valeur par défaut pour n est 1, ce qui signifie que dès qu'un point apparaît dans un nom, ce dernier sera d'abord essayé en tant que nom absolu avant d'ajouter tout élément de la liste de recherche search. La valeur de cette option est silencieusement plafonnée à 15.
Définition du temps pendant lequel la bibliothèque de résolution attendra la réponse d'un serveur de noms distant avant de réessayer une requête sur un serveur de noms différent. Cela peut ne pas être le temps total pris par n’importe quel appel d’API de résolution et il n’y a aucune garantie qu’un seul appel corresponde à un seul délai. Exprimée en secondes, la valeur par défaut est RES_TIMEOUT (actuellement 5, voir <resolv.h>). La valeur de cette option est plafonnée silencieusement à 30.
Définition du nombre de fois que la bibliothèque de résolution enverra une requête à ses serveurs de noms avant d'abandonner et renvoyer une erreur à l'application appelante. La valeur par défaut est RES_DFLRETRY (actuellement 2, voir <resolv.h>). La valeur de cette option est silencieusement plafonnée à 5.
Définition de RES_ROTATE dans _res.options, ce qui provoque une sélection en tourniquet des serveurs de noms parmi ceux qui sont listés. Cela a pour effet de répartir la charge de la requête parmi tous les serveurs listés en évitant que tous les clients essayent à chaque fois le premier serveur listé.
Définition de RES_NOAAAA dans _res.options, ce qui supprime les requêtes AAAA faites par le « stub resolver », y compris les requêtes déclenchées par les interfaces basées sur NSS telles que getaddrinfo(3). Seules les recherches de DNS sont affectées : les données IPv6 dans hosts(5) sont encore utilisées, getaddrinfo(3) avec AI_PASSIVE produira encore des adresses IPv6 et les serveurs de noms IPv6 configurés seront toujours utilisés. Pour produire des résultats d'erreur de nom corrects (NXDOMAIN), les requêtes AAAA sont traduites en requêtes A. Cette option est destinée en premier lieu à des diagnostics pour éliminer le fait que les requêtes de DNS AAAA ont un impact inverse. Elle est incompatible avec l'utilisation de EDNS0 et la validation DNSSEC par les applications.
Définition de RES_NOCHECKNAME dans _res.options, ce qui désactive la vérification BIND moderne des noms d'hôtes et de courriers entrants pour les caractères non autorisés comme le caractère de soulignement « _ », les caractères non ASCII ou les caractères de contrôle.
Définition de RES_USE_INET6 dans _res.options. Cela a pour effet d'essayer une requête AAAA avant une requête A dans la fonction gethostbyname(3), et le mappage des réponses IPv4 dans la « forme tunnellisée » d’IPv6 si aucun enregistrement AAAA n'est trouvé alors qu'un ensemble d’enregistrements A existe. Depuis la glibc 2.25, cette option est obsolète. Les applications doivent utiliser getaddrinfo(3) plutôt que gethostbyname(3).
Définition de RES_USE_BSTRING dans _res.options. Cela implique que les recherches IPv6 inverses sont effectuées avec le format d’étiquette binaire décrit dans la RFC 2673. Si cette option n'est pas activée (réglage par défaut), le format nibble est utilisé. Cette option a été retirée depuis la glibc 2.25, puisqu’elle repose sur une extension DNS non rétro-compatible n’ayant jamais été déployée dans l’Internet.
Activation ou désactivation de RES_NOIP6DOTINT dans _res.options. Quand cette option est désactivée (ip6-dotint), les recherches inverses IPv6 sont effectuées dans la zone (obsolète) ip6.int ; quand cette option est activée ((no-ip6-dotint), les recherches inverses IPv6 sont effectuées par défaut dans la zone ip6.arpa. Puisque la prise en charge de ip6-dotint a cessé depuis longtemps dans l’Internet, ces options ont été retirées dans la glibc 2.25.
Définition de RES_USE_EDNSO dans _res.options. Cela active la prise en charge des extensions DNS décrites dans la RFC 2671.
Définition de RES_SNGLKUP dans _res.options. Par défaut, la glibc réalise des recherches IPv4 et IPv6 en parallèle depuis sa version 2.9. Certains serveurs DNS d’équipement dédié ne peuvent pas traiter correctement ces demandes et font expirer les requêtes. Cette option désactive ce comportement et force la glibc à réaliser les requêtes IPv4 et IPv6 de façon séquentielle (au prix de quelques ralentissements du processus de résolution).
Définition de RES_SNGLKUPREOP dans _res.options. La bibliothèque de résolution utilise le même socket pour les requêtes A et AAAA. Certains matériels ne renvoient par erreur qu'une seule réponse. Quand cela arrive, le système client est bloqué en attendant la deuxième réponse. Activer cette option modifie le comportement de telle façon qu’en cas de traitement incorrect de deux requêtes venant du même port, le socket sera fermé et un nouveau sera ouvert avant d'envoyer la deuxième requête.
Définition de RES_NOTLDQUERY dans _res.options. Cette option fait que res_nsearch() n’essaie pas de résoudre un nom non qualifié comme s’il était un domaine de premier niveau (top level domain — TLD). Cette option peut causer des problèmes si le site a « localhost » comme TLD plutôt que d’avoir localhost dans un ou plus éléments dans la liste de recherche. Cette option n’a aucun effet si ni RES_DEFNAMES ni RES_DNSRCH ne sont définis.
Définition de RES_USE_EDNSO dans _res.options. Cette option oblige l’utilisation de TCP dans la résolution DNS.
Définition de RES_USE_EDNSO dans _res.options. Cette option désactive le rechargement automatique d’un fichier de configuration modifié.
Définition de RES_TRUSTAD dans _res.options. Cette option contrôle le comportement du bit AD (authenticated data) du « stub resolver ». Si un résolveur de validation définit un bit AD dans une réponse, il indique que les données dans cette réponse ont été vérifiées selon le protocole DNSSEC. Pour pouvoir se fier au bit AD, le système local doit faire confiance à la fois au résolveur de validation DNSSEC et au chemin réseau vers celui-ci, ce qui est la raison pour laquelle une option d’inclusion explicite est nécessaire. Si l’option trust-ad est active, le « stub resolver » définit le bit AD dans les requêtes DNS sortantes (pour activer la prise en charge du bit AD) et préserve le bit AD dans les réponses. Sans cette option, le bit AD n’est pas défini dans les requêtes et est toujours supprimé des réponses avant qu’elles ne soient renvoyées à l’application. Cela signifie que les applications peuvent faire confiance au bit AD dans les réponses si l’option trust-ad a été définie correctement.
Dans la glibc 2.30 et ses versions précédentes, le bit AD n’est pas défini automatiquement dans les requêtes et est répercuté inchangé aux applications dans les réponses.

Le mot-clé search du fichier resolv.conf du système peut être surchargé indépendamment pour chaque processus en remplissant la variable d'environnement LOCALDOMAIN avec une liste de domaines de recherche séparés par des espaces.

Le mot-clé options du fichier resolv.conf du système peut être surchargé indépendamment pour chaque processus en remplissant la variable d'environnement RES_OPTIONS en une liste d'options de la bibliothèque resolver (séparées par des espaces), comme indiqué à la rubrique options plus haut.

Le mot-clé et la valeur doivent apparaître sur une seule ligne, le mot-clé (par exemple nameserver) doit apparaître en début de ligne et il doit être séparé de la valeur par une espace.

Les lignes qui contiennent un point-virgule (« ; ») ou un croisillon (« # ») en première colonne sont traitées comme des commentaires.

/etc/resolv.conf, <resolv.h>

gethostbyname(3), resolver(3), host.conf(5), hosts(5), nsswitch.conf(5), hostname(7), named(8)

Name Server Operations Guide for BIND

La traduction française de cette page de manuel a été créée par Christophe Blaess https://www.blaess.fr/christophe/, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org>, David Prévot <david@tilapin.org> et Jean-Paul Guillonneau <guillonneau.jeanpaul@free.fr>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org.

2 mai 2024 4th Berkeley Distribution