Domain name resolution (Français)

En général, un nom de domaine représente une adresse IP et lui est associé dans le Système de nom de domaine (DNS). Cet article explique comment configurer la résolution des noms de domaine et résoudre les noms de domaine.

État de la traduction: Cet article est la version francophone de Domain name resolution. Date de la dernière traduction: 2022-10-04. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

Name Service Switch

Le Name Service Switch (NSS) fait partie de la bibliothèque GNU C (glibc) et fournit l'API getaddrinfo(3) utilisée pour résoudre les noms de domaine. NSS permet aux bases de données système d'être fournies par des services distincts, dont l'ordre de recherche peut être configuré par l'administrateur dans nsswitch.conf(5). La base de données responsable de la résolution des noms de domaine est la base de données hosts, pour laquelle la glibc offre les services suivants :

files : lit le fichier /etc/hosts, consultez hosts(5).
dns : le résolveur de glibc qui lit /etc/resolv.conf, consultez .

systemd fournit trois services NSS pour la résolution de noms d'hôtes :

- un résolveur de stub DNS en cache, décrit dans systemd-resolved.
. - fournit une résolution de nom d'hôte local sans avoir à modifier /etc/hosts, décrit dans Network configuration#Local network hostname resolution.
. - fournit une résolution de nom d'hôte pour les noms des conteneurs locaux systemd-machined(8).

Résoudre un nom de domaine à l'aide de NSS

Les bases de données NSS peuvent être interrogées avec getent(1). Un nom de domaine peut être résolu par NSS en utilisant :

$ getent hosts nom_de_domaine

Résolveur de glibc

Le résolveur de glibc lit /etc/resolv.conf pour chaque résolution afin de déterminer les serveurs de noms et les options à utiliser.

liste les serveurs de noms ainsi que certaines options de configuration.

Les serveurs de noms listés en premier sont essayés en premier, jusqu'à trois serveurs de noms peuvent être listés. Les lignes commençant par un () sont ignorées.

Écrasement de /etc/resolv.conf

Les gestionnaires de réseau ont tendance à écraser /etc/resolv.conf, pour plus de détails, consultez la section correspondante :

Pour empêcher les programmes d'écraser /etc/resolv.conf, il est également possible de le protéger en écriture en définissant l'attribut immuable au fichier :

# chattr +i /etc/resolv.conf

Limiter le temps de recherche

Si vous êtes confronté à une très longue recherche de nom d'hôte (que ce soit dans pacman ou en naviguant), il est souvent utile de définir un petit délai après lequel un serveur de noms alternatif est utilisé. Pour ce faire, mettez ce qui suit dans /etc/resolv.conf.

options timeout:1

Recherche de nom d'hôte lente avec IPv6

Si vous constatez un retard de 5 secondes lors de la résolution de noms d'hôtes, cela peut être dû à un serveur DNS/pare-feu qui se comporte mal et ne donne qu'une seule réponse à une requête parallèle A et AAAA. Vous pouvez corriger cela en définissant l'option suivante dans /etc/resolv.conf :

options single-request

Noms de domaine locaux

Pour pouvoir utiliser le nom d'hôte des noms de machines locales sans le nom de domaine pleinement qualifié, ajoutez une ligne à /etc/resolv.conf avec le domaine local comme :

domaine exemple.org

De cette façon, vous pouvez vous référer à des hôtes locaux tels que comme étant simplement lorsque vous utilisez la commande ssh, mais la commande drill nécessite toujours les noms de domaine pleinement qualifiés afin d'effectuer des recherches.

Utilitaires de recherche

Pour interroger des serveurs DNS spécifiques et des enregistrements DNS/DNSSEC, vous pouvez utiliser des utilitaires de recherche DNS dédiés. Ces outils mettent en œuvre le DNS eux-mêmes et n'utilisent pas NSS.

fournit , qui est un outil conçu pour récupérer des informations à partir du DNS.

Par exemple, pour interroger un serveur de noms spécifique avec drill pour les enregistrements TXT d'un domaine :

$ drill @ nameserver TXT domain

Si un serveur DNS n'est pas spécifié, drill utilisera les serveurs de noms définis dans /etc/resolv.conf.

Astuce: Certains serveurs DNS sont livrés avec leurs propres utilitaires de recherche DNS. Par exemple

knot fournit khost(1) et kdig(1).
Unbound a unbound-host(1).
BIND a dig(1), host(1), nslookup(1) et un tas d'outils dnssec-.

Performances du résolveur

Le résolveur de la Glibc ne met pas en cache les requêtes. Pour mettre en œuvre la mise en cache locale, utilisez systemd-resolved ou configurez un serveur DNS de mise en cache locale et utilisez-le comme serveur de noms en définissant 127.0.0.1 et comme serveurs de noms dans /etc/resolv.conf ou dans si vous utilisez openresolv.

Confidentialité et sécurité

Le protocole DNS n'est pas chiffré et ne prend pas en compte la confidentialité, l'intégrité ou l'authentification. Par conséquent, si vous utilisez un réseau non fiable ou un fournisseur d'accès malveillant, vos requêtes DNS peuvent être écoutées et les réponses manipulées. En outre, les serveurs DNS peuvent mener des opérations d'empoisonnement du cache DNS.

Vous devez faire confiance à votre serveur DNS pour traiter vos requêtes de manière confidentielle. Les serveurs DNS sont fournis par les FAI et les tiers. Vous pouvez également faire tourner votre propre serveur, ce qui demande toutefois plus d'efforts. Si vous utilisez un client DHCP dans des réseaux non fiables, veillez à définir des serveurs de noms statiques pour éviter d'utiliser et d'être soumis à des serveurs DNS arbitraires. Pour sécuriser votre communication avec un serveur DNS distant, vous pouvez utiliser un protocole chiffré, comme DNS over TLS. (RFC 7858), DNS sur HTTPS. (RFC 8484), ou DNSCrypt, à condition que le serveur en amont et votre résolveur prennent en charge le protocole. Une alternative peut être un logiciel dédié au chiffrement et au déchiffrement de la communication, tel que stunnel. Pour vérifier que les réponses proviennent bien de serveurs de noms faisant autorité, vous pouvez valider DNSSEC, à condition que le ou les serveurs en amont et votre résolveur le prennent en charge.

DNS au niveau des applications

Sachez que certains logiciels clients, tels que les principaux navigateurs Web , commencent à mettre en œuvre le DNS sur HTTPS. Si le chiffrement des requêtes peut souvent être consulté comme un bonus, cela signifie également que le logiciel détourne les requêtes de la configuration du résolveur du système .

Firefox fournit options de configuration pour activer ou désactiver le DNS sur HTTPS et sélectionner un serveur DNS.

Chromium examinera le résolveur système de l'utilisateur et activera le DNS sur HTTPS si les adresses du résolveur système sont connues pour fournir également le DNS sur HTTPS. Consultez cet article de blog pour plus d'informations et pour savoir comment désactiver le DNS sur HTTPS.

Mozilla a proposé de désactiver universellement le DNS au niveau des applications si le résolveur du système ne peut pas résoudre le domaine . Actuellement, ceci n'est implémenté que dans Firefox.

Oblivious DNS

Oblivious DNS est un système qui répond à un certain nombre de problèmes de confidentialité des DNS. Consultez l'article de Cloudflare pour plus d'informations.

Services DNS tiers

Il existe plusieurs services DNS tiers (en), dont certains disposent également de logiciels dédiés :

Vous pouvez utiliser dnsperftest pour tester les performances des résolveurs DNS les plus populaires depuis votre emplacement. dnsperf.com fournit des points de référence mondiaux entre les fournisseurs.

Serveurs DNS

Les serveurs DNS peuvent être autoritatif et récursif. S'ils ne sont ni l'un ni l'autre, ils sont appelés résolveurs stub (ébauches) et transmettent simplement toutes les requêtes à un autre serveur de noms récursif. Les résolveurs «stub» sont généralement utilisés pour introduire la mise en cache du DNS sur l'hôte ou le réseau local. Notez que la même chose peut également être réalisée avec un serveur de noms à part entière. Cette section compare les serveurs DNS disponibles, pour une comparaison plus détaillée, reportez-vous à Wikipedia:Comparison of DNS server software.

Nom	Paquet	Capacités				resolvconf	Protocoles pris en charge
Nom	Paquet	Authoritatif	Recursif	Cache	Valide DNSSEC	resolvconf	DNS	DNSCrypt	DNS over TLS	DNS over HTTPS
BIND		Oui	Oui	Oui	Oui		Oui
CoreDNS	ou	?	?	?	?	?	?	?	Oui	?
Deadwood (MaraDNS recursor)			Oui	Oui			Oui
dnscrypt-proxy	dnscrypt-proxy			Oui						Oui
dnsmasq	dnsmasq	²		Oui	Oui		Oui
Knot Resolver			Oui	Oui	Oui		Oui		Oui
pdnsd		Oui	Oui				Oui
PowerDNS Recursor			Oui	Oui	Oui		Oui
Rescached	rescached-git^AUR			Oui			Oui		Oui	Oui
SmartDNS				Oui		?	Oui
Stubby					Oui
systemd-resolved	systemd			Oui	Oui
Unbound	unbound		Oui	Oui³	Oui		Oui		Oui

BIND peut servir à la fois les DNS sur TLS et les DNS sur HTTPS (voir tls{} et listen-on), mais ne peut pas encore transmettre les requêtes à un DNS sur TLS/DNS sur HTTPS nativement. L'outil dig peut effectuer des requêtes sur des DNS sur TLS et des DNS sur HTTPS (en utilisant les options et ), mais sans vérification des certificats.
D'après Wikipedia : dnsmasq dispose d'une prise en charge limitée de l'autorité, destinée à un usage interne au réseau plutôt qu'à un usage public sur Internet.
Le backend Redis peut être utilisé pour fournir un cache persistant pour Unbound.

Serveurs faisant autorité uniquement

Nom	DNSSEC	Équilibrage Géographique
gdnsd		Oui
Knot DNS	Oui
MaraDNS		?
NSD
PowerDNS	Oui	Oui

Redirection conditionnelle

Il est possible d'utiliser des résolveurs DNS spécifiques lors de l'interrogation de noms de domaine spécifiques. Ceci est particulièrement utile lors de la connexion à un VPN, afin que les requêtes vers le réseau VPN soient résolues par le DNS du VPN, tandis que les requêtes vers l'Internet seront toujours résolues par votre résolveur DNS standard. Elle peut également être utilisée sur les réseaux locaux.

Pour l'implémenter, vous devez utiliser un résolveur local car la glibc ne le prend pas en charge.

Dans un environnement dynamique (ordinateurs portables et, dans une certaine mesure, ordinateurs de bureau), vous devez configurer votre résolveur en fonction du ou des réseaux auxquels vous êtes connecté. La meilleure façon de le faire est d'utiliser openresolv car il prend en charge multiple subscribers. Certains gestionnaires de réseau le prennent en charge, soit par le biais d'openresolv, soit en configurant directement le résolveur. NetworkManager prend en charge la redirection conditionnelle sans openresolv.

Voir aussi

Guide de l'administrateur réseau Linux
Manuel Debian
RFC:7706 - Diminution du temps d'accès aux serveurs racine en en faisant tourner un sur le loopback
Domain name system overview - Diagramme sur le DNS
Alternative DNS services

gollark: Ah, so that one's sick, yes.

gollark: Is the one which isn't there a sick one?

gollark: Which one is it?

gollark: They're filtered out every five minutes.

gollark: It's not very mobile friendly, is it...

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.