Domain name resolution (Français)

É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-git
AUR
[
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-up
AUR
nextdns
— Un client CLI DNS-over-HTTPS pour NextDNS
https://github.com/nextdns/nextdns
||
nextdns
AUR
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
Serveur
1
Serveur
CoreDNS
coredns
AUR
ou
coredns-bin
AUR
?
?
?
?
?
?
?
Oui
?
Deadwood
(
MaraDNS
recursor)
maradns
AUR
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
Partiel
2
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-git
AUR
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
Oui
3
Oui
Oui
Oui
Serveur
Oui
Serveur
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
.
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
gdnsd
Non
Oui
Knot DNS
knot
Oui
Oui
MaraDNS
maradns
AUR
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