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.
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 :
- 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
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
.
- 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 | ||||||
---|---|---|---|---|---|---|---|---|---|---|
Authoritatif | Recursif | Cache | Valide DNSSEC | 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 | 2 | Oui | Oui | Oui | |||||
Knot Resolver | Oui | Oui | Oui | Oui | Oui | |||||
pdnsd | Oui | Oui | Oui | |||||||
PowerDNS Recursor | Oui | Oui | Oui | Oui | ||||||
Rescached | rescached-gitAUR | Oui | Oui | Oui | Oui | |||||
SmartDNS | Oui | ? | Oui | |||||||
Stubby | Oui | |||||||||
systemd-resolved | systemd | Oui | Oui | |||||||
Unbound | unbound | Oui | Oui3 | 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 | Paquet | 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