Jump to content

# Domain name resolution (Français)

7 languages

- Deutsch
- English
- Magyar
- 日本語
- Português
- Русский
- 中文（简体）

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

- Network configuration (Français)
- DNS over HTTPS servers

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 :

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

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

- nss-resolve(8) - un résolveur de stub DNS en cache, décrit dans systemd-resolved.
- nss-myhostname(8). - fournit une résolution de nom d'hôte local sans avoir à modifier `/etc/hosts`, décrit dans Network configuration#Local network hostname resolution.
- nss-mymachines(8). - 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

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 :

- dhcpcd#/etc/resolv.conf
- Netctl#/etc/resolv.conf
- NetworkManager#/etc/resolv.conf
- ConnMan#/etc/resolv.conf

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

- 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 `::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

- 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

Categories:

- Domain Name System (Français)
- Network configuration (Français)

Hidden categories:

- Pages with broken package links
- Pages or sections flagged with Template:Expansion