Service – Service de nom de domaine (DNS) – Bien choisir son serveur d impression

Le service de nom de domaine (DNS) est un service Internet qui mappe les adresses IP et les noms de domaine complets (FQDN) les uns aux autres. De cette façon, DNS atténue le besoin de mémoriser les adresses IP. Les ordinateurs qui exécutent DNS sont appelés serveurs de noms. Ubuntu est livré avec BIND (Berkley Internet Naming Daemon), le programme le plus couramment utilisé pour maintenir un serveur de noms sous Linux.

À l'invite du terminal, entrez la commande suivante pour installer DNS :

sudo apt installer bind9

Un package très utile pour tester et résoudre les problèmes DNS est le dnsutils emballer. Très souvent ces outils seront déjà installés, mais pour vérifier et/ou installer dnsutils entrez ce qui suit :

sudo apt installer dnsutils

Il existe de nombreuses façons de configurer BIND9. Certaines des configurations les plus courantes sont un serveur de noms de mise en cache, un serveur principal et un serveur secondaire.

• Lorsqu'il est configuré en tant que serveur de noms de mise en cache, BIND9 trouvera la réponse aux requêtes de nom et se souviendra de la réponse lorsque le domaine sera à nouveau interrogé.

• En tant que serveur principal, BIND9 lit les données d'une zone à partir d'un fichier sur son hôte et fait autorité pour cette zone.

• En tant que serveur secondaire, BIND9 obtient les données de zone d'un autre serveur de noms faisant autorité pour la zone.

Aperçu

Les fichiers de configuration DNS sont stockés dans le /etc/lier annuaire. Le fichier de configuration principal est /etc/bind/named.conf, qui dans la mise en page fournie par le package n'inclut que ces fichiers.

• /etc/bind/named.conf.options: options DNS globales
• /etc/bind/named.conf.local: pour vos zones
• /etc/bind/named.conf.default-zones: zones par défaut telles que localhost, son reverse, et les indications de racine

Les serveurs de noms racine étaient décrits dans le fichier /etc/bind/db.root. Ceci est maintenant fourni à la place par le /usr/share/dns/root.hints fichier livré avec le dns-root-data package, et est référencé dans le named.conf.default-zones fichier de configuration ci-dessus.

Il est possible de configurer le même serveur pour être un serveur de noms de cache, primaire et secondaire : tout dépend des zones qu'il dessert. Un serveur peut être le Start of Authority (SOA) pour une zone, tout en fournissant un service secondaire pour une autre zone. Tout en fournissant des services de mise en cache pour les hôtes sur le réseau local local.

Serveur de noms en cache

La configuration par défaut agit comme un serveur de mise en cache. Décommentez et modifiez simplement /etc/bind/named.conf.options pour définir les adresses IP des serveurs DNS de votre FAI :

transitaires 
    1.2.3.4 ;
    5.6.7.8 ;
 ;

Noter

Remplacer 1.2.3.4 et 5.6.7.8 avec les adresses IP des serveurs de noms réels.

Pour activer la nouvelle configuration, redémarrez le serveur DNS. À partir d'une invite de terminal :

sudo systemctl redémarrer bind9.service

Voir dig pour plus d'informations sur le test d'un serveur DNS de mise en cache.

Serveur principal

Dans cette section, BIND9 sera configuré comme serveur principal pour le domaine exemple.com. Remplacez simplement exemple.com avec votre FQDN (Fully Qualified Domain Name).

Fichier de zone de transfert

Pour ajouter une zone DNS à BIND9, en transformant BIND9 en serveur principal, modifiez d'abord /etc/bind/named.conf.local:

zone "exemple.com" 
    type maître;
    fichier "/etc/bind/db.example.com" ;
 ;

Noter

Si bind recevra des mises à jour automatiques du fichier comme avec DDNS, utilisez /var/lib/bind/db.exemple.com plutôt que /etc/bind/db.exemple.com à la fois ici et dans la commande de copie ci-dessous.

Utilisez maintenant un fichier de zone existant comme modèle pour créer le /etc/bind/db.exemple.com déposer:

sudo cp /etc/bind/db.local /etc/bind/db.example.com

Modifier le nouveau fichier de zone /etc/bind/db.exemple.com et changer hôte local. au FQDN de votre serveur, en laissant les . à la fin. Changer 127.0.0.1 à l'adresse IP du serveur de noms et root.localhost à une adresse e-mail valide, mais avec un . au lieu de l'habituel @ symbole, laissant à nouveau le . à la fin. Modifiez le commentaire pour indiquer le domaine auquel ce fichier est destiné.

Créé un Un enregistrement pour le domaine de base, exemple.com. Créez également un Un enregistrement pour ns.exemple.com, le serveur de noms dans cet exemple :

;
; Fichier de données BIND pour example.com
;
$TTL 604800
@ DANS SOA example.com. racine.exemple.com. (
                              2 ; En série
                         604800 ; Rafraîchir
                          86400 ; Réessayez
                        2419200 ; Expirer
                         604800 ) ; TTL du cache négatif

@ IN NS ns.exemple.com.
@ DANS UN 192.168.1.10
@ EN AAAA ::1
ns IN A 192.168.1.10

Vous devez incrémenter le Numéro de série chaque fois que vous apportez des modifications au fichier de zone. Si vous effectuez plusieurs modifications avant de redémarrer BIND9, incrémentez simplement le Serial une fois.

Maintenant, vous pouvez ajouter des enregistrements DNS au bas du fichier de zone. Voir Types d'enregistrement courants pour plus de détails.

Noter

De nombreux administrateurs aiment utiliser la dernière date modifiée comme numéro de série d'une zone, comme 202012100 lequel est aaaammjj (où ss est le numéro de série)

Une fois que vous avez apporté des modifications au fichier de zone, BIND9 doit être redémarré pour que les modifications prennent effet :

sudo systemctl redémarrer bind9.service

Fichier de zone inversée

Maintenant que la zone est configurée et résout les noms en adresses IP, un Zone inversée doit être ajouté pour permettre au DNS de résoudre une adresse en un nom.

Éditer /etc/bind/named.conf.local et ajoutez ce qui suit :

zone "1.168.192.in-addr.arpa" 
    type maître;
    fichier "/etc/bind/db.192" ;
 ;

Noter

Remplacer 1.168.192 avec les trois premiers octets du réseau que vous utilisez. Aussi, nommez le fichier de zone /etc/bind/db.192 de manière appropriée. Il doit correspondre au premier octet de votre réseau.

Créez maintenant le /etc/bind/db.192 déposer:

sudo cp /etc/bind/db.127 /etc/bind/db.192

Modification suivante /etc/bind/db.192 changer les mêmes options que /etc/bind/db.exemple.com:

;
; Fichier de données inversé BIND pour le réseau local 192.168.1.XXX
;
$TTL 604800
@ DANS SOA ns.example.com. racine.exemple.com. (
                              2 ; En série
                         604800 ; Rafraîchir
                          86400 ; Réessayez
                        2419200 ; Expirer
                         604800 ) ; TTL du cache négatif
;
@ IN NS ns.
10 IN PTR ns.example.com.

Les Numéro de série dans la zone Inverse doit également être incrémenté à chaque changement. Pour chaque Un enregistrement vous configurez dans /etc/bind/db.exemple.com, c'est-à-dire pour une adresse différente, vous devez créer un Enregistrement PTR dans /etc/bind/db.192.

Après avoir créé le fichier de zone inversée, redémarrez BIND9 :

sudo systemctl redémarrer bind9.service

Serveur secondaire

Une fois par Serveur principal a été configuré un Serveur secondaire est fortement recommandé afin de maintenir la disponibilité du domaine en cas d'indisponibilité du domaine principal.

Tout d'abord, sur le serveur principal, le transfert de zone doit être autorisé. Ajouter le autoriser-transfert option à l'exemple de définitions de zone avant et arrière dans /etc/bind/named.conf.local:

zone "exemple.com" 
    type maître;
    fichier "/etc/bind/db.example.com" ;
    autoriser le transfert  192.168.1.11;  ;
 ;
    
zone "1.168.192.in-addr.arpa" 
    type maître;
    fichier "/etc/bind/db.192" ;
    autoriser le transfert  192.168.1.11;  ;
 ;

Noter

Remplacer 192.168.1.11 avec l'adresse IP de votre serveur de noms secondaire.

Redémarrez BIND9 sur le serveur principal :

sudo systemctl redémarrer bind9.service

Ensuite, sur le serveur secondaire, installez le package bind9 de la même manière que sur le serveur principal. Puis modifiez le /etc/bind/named.conf.local et ajoutez les déclarations suivantes pour les zones Forward et Reverse :

zone "exemple.com" 
    tapez esclave;
    fichier "db.exemple.com" ;
    maîtres  192.168.1.10;  ;
 ;
          
zone "1.168.192.in-addr.arpa" 
    tapez esclave;
    fichier "db.192" ;
    maîtres  192.168.1.10;  ;
 ;

Noter

Remplacer 192.168.1.10 avec l'adresse IP de votre serveur de noms principal.

Redémarrez BIND9 sur le serveur secondaire :

sudo systemctl redémarrer bind9.service

Dans /var/log/syslog vous devriez voir quelque chose de similaire à ce qui suit (certaines lignes ont été divisées pour s'adapter au format de ce document) :

client 192.168.1.10#39448 : notification reçue pour la zone '1.168.192.in-addr.arpa'
zone 1.168.192.in-addr.arpa/IN : Transfert commencé.
transfert de '100.18.172.in-addr.arpa/IN' de 192.168.1.10#53 :
 connecté en utilisant 192.168.1.11#37531
zone 1.168.192.in-addr.arpa/IN : transfert série 5
transfert de '100.18.172.in-addr.arpa/IN' de 192.168.1.10#53 :
 Transfert terminé : 1 messages,
6 enregistrements, 212 octets, 0,002 s (106 000 octets/s)
zone 1.168.192.in-addr.arpa/IN : envoi des notifications (série 5)

client 192.168.1.10#20329 : notification reçue pour la zone 'example.com'
zone example.com/IN : Le transfert a commencé.
transfert de 'example.com/IN' depuis 192.168.1.10#53 : connecté via 192.168.1.11#38577
zone example.com/IN : transfert série 5
transfert de 'example.com/IN' de 192.168.1.10#53 : Transfert terminé : 1 messages,
8 enregistrements, 225 octets, 0,002 s (112 500 octets/s)

Noter

Remarque : Une zone n'est transférée que si le Numéro de série sur le primaire est plus grand que celui sur le secondaire. Si vous souhaitez que votre DNS principal informe les autres serveurs DNS secondaires des changements de zone, vous pouvez ajouter aussi-notifier adresse-ip;  ; à /etc/bind/named.conf.local comme le montre l'exemple ci-dessous :

zone "exemple.com" 
    type maître;
    fichier "/etc/bind/db.example.com" ;
    autoriser le transfert  192.168.1.11;  ;
    notifier également  192.168.1.11;  ;
 ;

zone "1.168.192.in-addr.arpa" 
    type maître;
    fichier "/etc/bind/db.192" ;
    autoriser le transfert  192.168.1.11;  ;
    notifier également  192.168.1.11;  ;
 ;
    

Noter

Le répertoire par défaut pour les fichiers de zone ne faisant pas autorité est /var/cache/bind/. Ce répertoire est également configuré dans AppArmor pour permettre au démon nommé d'y écrire. Pour plus d'informations sur AppArmor, consultez Sécurité – AppArmor.

Cette section couvre le diagnostic des problèmes avec les configurations DNS et BIND9.

Essai

resolv.conf

La première étape du test de BIND9 consiste à ajouter l'adresse IP du serveur de noms à un résolveur d'hôtes. Le serveur de noms principal doit être configuré ainsi qu'un autre hôte pour vérifier les choses. Reportez-vous à la configuration du client DNS pour plus de détails sur l'ajout d'adresses de serveur de noms à vos clients réseau. En fin de compte votre nom du serveur faire la queue /etc/resolv.conf devrait pointer vers 127.0.0.53 et tu devrais avoir un chercher paramètre pour votre domaine. Quelque chose comme ça:

serveur de noms 127.0.0.53
rechercher exemple.com

Pour vérifier quel serveur DNS votre résolveur local utilise, exécutez :

systemd-resolve --status

Noter

Vous devez également ajouter l'adresse IP du serveur de noms secondaire à votre configuration client au cas où le serveur principal deviendrait indisponible.

creuser

Si vous avez installé le package dnsutils, vous pouvez tester votre configuration à l'aide de l'utilitaire de recherche DNS dig :

• Après avoir installé BIND9, utilisez dig contre l'interface de bouclage pour vous assurer qu'il écoute sur le port 53. À partir d'une invite de terminal :

  creuser -x 127.0.0.1
  

  Vous devriez voir des lignes similaires à ce qui suit dans la sortie de la commande :

  ;; Temps de requête : 1 ms
  ;; SERVEUR : 192.168.1.10#53 (192.168.1.10)
  

• Si vous avez configuré BIND9 en tant que Mise en cache le serveur de noms « creuse » un domaine extérieur pour vérifier l'heure de la requête :

  creuser ubuntu.com
  

  Notez le temps de requête vers la fin de la sortie de la commande :

  ;; Temps de requête : 49 ms
  

  Après une deuxième fouille, il devrait y avoir une amélioration :

  ;; Temps de requête : 1 ms
  

ping

Maintenant, pour montrer comment les applications utilisent DNS pour résoudre un nom d'hôte, utilisez l'utilitaire ping pour envoyer une requête d'écho ICMP :

ping exemple.com

Ceci teste si le serveur de noms peut résoudre le nom ns.exemple.com à une adresse IP. La sortie de la commande doit ressembler à :

PING ns.example.com (192.168.1.10) 56(84) octets de données.
64 octets à partir de 192.168.1.10 : icmp_seq=1 ttl=64 time=0.800 ms
64 octets à partir de 192.168.1.10 : icmp_seq=2 ttl=64 time=0.813 ms

zone de contrôle nommée

Un excellent moyen de tester vos fichiers de zone est d'utiliser le zone de contrôle nommée utilitaire installé avec le lier9 emballer. Cet utilitaire vous permet de vous assurer que la configuration est correcte avant de redémarrer BIND9 et de mettre les modifications en ligne.

• Pour tester notre exemple de fichier de zone de transfert, saisissez ce qui suit à partir d'une invite de commande :

  zone de contrôle nommée example.com /etc/bind/db.example.com
  

  Si tout est configuré correctement, vous devriez voir une sortie similaire à :

  zone example.com/IN : chargé série 6
  d'accord
  

• De même, pour tester le fichier de zone inversée, saisissez ce qui suit :

  zone de contrôle nommée 1.168.192.in-addr.arpa /etc/bind/db.192
  

  La sortie doit être similaire à :

  zone 1.168.192.in-addr.arpa/IN : chargé série 3
  d'accord
  

Noter

Les Numéro de série de votre fichier de zone sera probablement différent.

Journalisation rapide des requêtes temporaires

Avec le rndc outil, vous pouvez rapidement activer et désactiver la connexion aux requêtes, sans redémarrer le service ni modifier le fichier de configuration.

Pour activer la journalisation des requêtes au, Cours:

requête sudo rndc se connecter

De même, pour le désactiver, exécutez :

requête sudo rndc se déconnecter

Les journaux seront envoyés à syslog et apparaîtront dans /var/log/syslog par défaut:

20 janvier 19:40:50 nouveau-n1 nommé[816]: commande de canal de contrôle reçue 'querylog on'
20 janvier 19:40:50 nouveau-n1 nommé[816]: la journalisation des requêtes est maintenant activée
20 janvier 19:40:57 nouveau-n1 nommé[816]: client @0x7f48ec101480 192.168.1.10#36139 (ubuntu.com) : requête : ubuntu.com IN A +E(0)K (192.168.1.10)

Noter

La quantité de journaux générés en activant journal des requêtes peut être énorme !

Enregistrement

BIND9 propose une grande variété d'options de configuration de journalisation, mais les deux principales sont canaliser et Catégorie, qui configurent où vont les journaux et quelles informations sont enregistrées, respectivement.

Si aucune option de journalisation n'est configurée, la configuration par défaut est :

journalisation 
     catégorie par défaut  default_syslog; default_debug ;  ;
     catégorie sans correspondance  null;  ;
 ;

Configurons plutôt BIND9 pour envoyer déboguer messages liés aux requêtes DNS dans un fichier séparé.

Nous devons configurer un canaliser pour spécifier à quel fichier envoyer les messages, et un Catégorie. Dans cet exemple, le Catégorie enregistrera toutes les requêtes. Éditer /etc/bind/named.conf.local et ajoutez ce qui suit :

journalisation 
    requête de canal.log 
        fichier "/var/log/named/query.log" ;
        débogage de gravité 3 ;
     ;
    requêtes de catégorie  query.log;  ;
 ;

Noter

Les déboguer L'option peut être définie de 1 à 3. Si aucun niveau n'est spécifié, le niveau 1 est la valeur par défaut.

• Depuis le démon nommé fonctionne comme le lier l'utilisateur le /var/log/named le répertoire doit être créé et la propriété modifiée :

  sudo mkdir /var/log/named
  sudo chown bind:bind /var/log/named
  

• Redémarrez maintenant BIND9 pour que les modifications prennent effet :

  sudo systemctl redémarrer bind9.service
  

Vous devriez voir le fichier /var/log/named/query.log remplir avec les informations de la requête. Il s'agit d'un exemple simple des options de journalisation BIND9. Pour la couverture des options avancées, voir Plus d'informations.

Types d'enregistrement courants

Cette section couvre certains des types d'enregistrement DNS les plus courants.

• UNE record : cet enregistrement mappe une adresse IP à un nom d'hôte.

  www IN A 192.168.1.12
  

• CNAME record : utilisé pour créer un alias vers un enregistrement A existant. Vous ne pouvez pas créer un CNAME enregistrement pointant vers un autre CNAME enregistrer.

  web IN CNAME www
  

• MX record : Utilisé pour définir où le courrier électronique doit être envoyé. Doit pointer vers un UNE enregistrement, pas un CNAME.

  @ IN MX 1 mail.exemple.com.
  courrier IN A 192.168.1.13
  

• N.-É. record : Utilisé pour définir quels serveurs servent des copies d'une zone. Il doit indiquer un UNE enregistrement, pas un CNAME. C'est là que les serveurs primaire et secondaire sont définis.

  @ IN NS ns.exemple.com.
  @ IN NS ns2.example.com.
  ns IN A 192.168.1.10
  ns2 IN A 192.168.1.11
  

Plus d'information