Man page - resolver(5)

Packages contains this manual

Available languages:

en fr pl ja ro zh_TW zh_CN de

Manual

resolv.conf

NOM
SYNOPSIS
DESCRIPTION
FICHIERS
VOIR AUSSI
TRADUCTION

NOM

resolv.conf — Fichier de configuration de la rĂ©solution de noms

SYNOPSIS

/etc/resolv.conf

DESCRIPTION

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 :
nameserver
Adresse IP du serveur de noms

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.)

search Liste de recherche pour les noms d’hîte.

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.

sortlist

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

options

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 :

debug

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)).

ndots: n

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.

timeout: n

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.

attempts: n

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.

rotate

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Ă©.

no-aaaa (depuis la glibc 2.36)

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.

no-check-names

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.

inet6

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).

Certains programmes se comportent étrangement quand cette option est activée.
ip6-bytestring
(glibc 2.3.4 Ă  glibc 2.24)

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.

ip6-dotint / no-ip6-dotint (glibc 2.3.4 Ă  glibc 2.24)

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.

edns0 (depuis la glibc 2.6)

Définition de RES_USE_EDNSO dans _res.options . Cela active la prise en charge des extensions DNS décrites dans la RFC 2671.

single-request (depuis la glibc 2.10)

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).

single-request-reopen (depuis la glibc 2.9)

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.

no-tld-query (depuis la glibc 2.14)

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.

use-vc (depuis la glibc 2.14)

DĂ©finition de RES_USE_EDNSO dans _res.options . Cette option oblige l’utilisation de TCP dans la rĂ©solution DNS.

no-reload (depuis la glibc 2.26)

DĂ©finition de RES_USE_EDNSO dans _res.options . Cette option dĂ©sactive le rechargement automatique d’un fichier de configuration modifiĂ©.

trust-ad (depuis la glibc 2.31)

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.

FICHIERS

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

VOIR AUSSI

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

Name Server Operations Guide for BIND

TRADUCTION

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 .