Domain name resolution (Français)

From ArchWiki
É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.

Related articles

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.

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 :

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

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
Note: Bien que la plupart des programmes résolvent les noms de domaine en utilisant NSS, certains peuvent lire directement /etc/resolv.conf et/ou /etc/hosts. Consultez Network configuration#Local network hostname resolution.

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.

resolv.conf(5) 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.

Note: Le résolveur glibc ne met pas les requêtes en cache. Pour améliorer le temps de consultation des requêtes, vous pouvez configurer un résolveur avec cache. Le résolveur glibc ne peut pas non plus valider les DNSSEC. Un résolveur validateur capable de valider les DNSSEC est nécessaire pour cela. Consultez #Serveurs DNS pour plus d'informations.

É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
Astuce: Si vous voulez que plusieurs processus écrivent dans /etc/resolv.conf, vous pouvez utiliser resolvconf.

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.[1] 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 mainmachine1.example.org comme étant simplement mainmachine1 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.

ldns fournit drill(1), 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

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 ::1 comme serveurs de noms dans /etc/resolv.conf ou dans /etc/resolvconf.conf si vous utilisez openresolv.

Astuce:
  • Les utilitaires de recherche de type drill ou dig indiquent le temps d'interrogation.
  • Un routeur définit généralement son propre résolveur de cache comme serveur DNS du réseau, fournissant ainsi un cache DNS pour l'ensemble du réseau.
  • Si le passage au serveur DNS suivant prend trop de temps, vous pouvez essayer de réduire le délai d'expiration.

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 [2] [3], 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 [4].

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 use-application-dns.net. Actuellement, ceci n'est implémenté que dans Firefox.

Oblivious DNS

Oblivious DNS (RFC:9230) 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

Note: Avant d'utiliser un service DNS tiers, vérifiez sa politique de confidentialité pour savoir comment les données des utilisateurs sont traitées. Les données des utilisateurs ont de la valeur et peuvent être vendues à d'autres parties.

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

  • cloudflared — Un client DNS pour Cloudflare DNS over HTTPS
https://developers.cloudflare.com/1.1.1.1/dns-over-https/cloudflared-proxy || cloudflared
  • dingo — Un client DNS pour Google DNS sur HTTPS
https://github.com/pforemski/dingo || dingo-gitAUR[broken link: package not found]
  • opennic-up — Automate le renouvellement des serveurs DNS avec les serveurs OpenNIC les plus réactifs
https://github.com/kewlfft/opennic-up || opennic-upAUR
  • nextdns — Un client CLI DNS-over-HTTPS pour NextDNS
https://github.com/nextdns/nextdns || nextdnsAUR

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.

This article or section needs expansion.

Reason: Remplir les cases inconnues (Discuss in Talk:Domain name resolution)
Nom Paquet Capacités resolvconf Protocoles pris en charge
Authoritatif Recursif Cache Valide
DNSSEC 		DNS DNSCrypt DNS
over TLS		 DNS
over HTTPS
BIND bind Oui Oui Oui Oui Oui Oui Non Serveur1 Serveur
CoreDNS corednsAUR ou coredns-binAUR ? ? ? ? ? ? ? Oui ?
Deadwood (MaraDNS recursor) maradnsAUR Non Oui Oui Non Non Oui Non Non Non
dnscrypt-proxy dnscrypt-proxy Non Non Oui Non Non Serveur Résolveur Non Oui
dnsmasq dnsmasq Partiel2 Non Oui Oui Oui Oui Non Non Non
Knot Resolver knot-resolver Non Oui Oui Oui Non Oui Non Oui Serveur
pdnsd pdnsd Oui Oui Permanent Non Oui Oui Non Non Non
PowerDNS Recursor powerdns-recursor Non Oui Oui Oui Oui Oui Non Non Non
Rescached rescached-gitAUR Non Non Oui Non Oui Oui Non Oui Oui
SmartDNS smartdns Non Non Oui Non ? Oui Non Résolveur Résolveur
Stubby stubby Non Non Non Oui Non Serveur Non Résolveur Non
systemd-resolved systemd Non Non Oui Oui Oui Résolveur et serveur limité Non Résolveur Non
Unbound unbound Partiel Oui Oui3 Oui Oui Oui Serveur Oui Serveur
  1. 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 +tls et +https), mais sans vérification des certificats.
  2. 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.
  3. Le backend Redis peut être utilisé pour fournir un cache persistant pour Unbound.

Serveurs faisant autorité uniquement

Nom Paquet DNSSEC Équilibrage
Géographique
gdnsd gdnsd Non Oui
Knot DNS knot Oui Oui
MaraDNS maradnsAUR Non ?
NSD nsd Non Non
PowerDNS 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.

Note: Bien que vous puissiez utiliser d'autres conditions pour le transfert (par exemple, l'adresse IP source), le "transfert conditionnel" semble être le nom utilisé pour la condition "domaine interrogé".

Voir aussi