introduction
Configurer un serveur DNS pour être responsable des noms de domaine peut être une tâche complexe, même pour des administrateurs chevronnés. La gestion de la zone DNS est une tâche vitale, mais peut être déconcertante, surtout lorsque vous essayez de démarrer.
Des logiciels comme le serveur DNS deBind sont incroyablement flexibles et peuvent être configurés pour faire fonctionner autant de composants dans la hiérarchie DNS globale. Cependant, cette flexibilité signifie également que Bind n'est pas optimisé pour une tâche en particulier. Cela a quelques effets secondaires.
La plupart du temps, il y a d'énormes quantités de fonctionnalités dont votre configuration n'a pas besoin. Cette complexité supplémentaire rend la gestion plus difficile. Cela signifie également que le logiciel lui-même sera moins réactif pour une tâche donnée.
Pour résoudre ce problème, des serveurs DNS alternatifs ont été créés, spécialisés dans un domaine de résolution DNS unique. Un logiciel connu sous le nom deNSD est un serveur DNS faisant autorité uniquement, idéal pour gérer les zones DNS avec autorité. Sans avoir à se soucier de la récursivité ni de la mise en cache, ce serveur offre des performances élevées et un encombrement réduit.
Dans ce guide, nous montrerons comment installer et configurer NSD pour administrer de manière sécurisée nos zones DNS sur des serveurs Ubuntu 14.04.
Prérequis et objectifs
Avant de commencer avec ce guide, vous devez vous familiariser avec certainsbasic DNS concepts and terminology. Si vous avez besoin d'aide pour comprendre à quoi sert un serveur DNS faisant autorité uniquement, consultez notre guide surthe differences between DNS server types.
En tant que serveur DNS faisant autorité, NSD ne fournit aucune fonctionnalité de mise en cache, de transfert ou récursive. Il ne répond qu'aux demandes itératives pour les zones qu'il contrôle. Il peut également renvoyer les résolveurs vers d'autres serveurs de noms pour les zones qu'il a déléguées.
Pour les besoins de ce guide, nous allons configurer deux serveurs avec le logiciel NSD afin qu'ils agissent en tant que serveurs principaux et secondaires pour nos zones. Nous fournirons également des données de configuration qui permettront aux clients d’atteindre un serveur Web sur un troisième hôte.
Nous utiliserons le domaine facticeexample.com pour ce guide. Vous devriez substituer votre propre domaine à suivre. Les machines que nous allons configurer auront les propriétés suivantes:
| Objectif | DNS FQDN | Adresse IP |
|---|---|---|
Serveur de noms principal |
ns1.example.com. |
192.0.2.1 |
Serveur de noms secondaire |
ns2.example.com. |
192.0.2.2 |
Serveur Web |
192.0.2.3 |
Une fois que vous avez terminé avec ce guide, vous devez configurer les deux premiers serveurs avec NSD pour qu’ils agissent en tant que serveur faisant autorité pour vos zones. Vous pourrez utiliser les noms d’hôte que nous configurons pour atteindre vos serveurs depuis Internet, ainsi que rechercher les noms d’hôte en interrogeant les adresses IP. Tout client de résolution capable d’atteindre nos serveurs sera capable d’obtenir les données du domaine de nos serveurs.
Définition du nom d'hôte sur les serveurs de noms
La première étape à franchir est une étape préparatoire. Avant de nous préoccuper de la configuration DNS, nous devons nous assurer que nos serveurs de noms peuvent résoudre correctement leur propre nom d'hôte de la manière dont nous en avons besoin.
Sur votre premier serveur DNS, modifiez le fichier/etc/hosts pour configurer le FQDN de cet ordinateur:
sudo nano /etc/hostsDans notre cas, nous devons mapper l'adresse IP de192.0.2.1 sur le nom complet de notre serveur de noms,ns1.example.com. Pour ce faire, nous pouvons remplacer la ligne spécifiant notre nom d’hôte par notre adresse IP publique, le nom de domaine complet (FQDN), ainsi que l’alias raccourci de notre hôte:
127.0.0.1 localhost
192.0.2.1 ns1.example.com ns1Enregistrez et fermez le fichier lorsque vous avez terminé.
Ensuite, nous devons revérifier le fichier/etc/hostname:
sudo nano /etc/hostnameCela doit contenir la valeur de notre nom d'hôteunqualified. Modifiez-le si nécessaire:
ns1Enregistrez et fermez le fichier lorsque vous avez terminé.
Si vous avez modifié le fichier/etc/hostname ci-dessus, dites au système de relire le fichier:
sudo hostname -F /etc/hostnameNous en avons terminé avec notre premier serveur DNS pour le moment. Répétez les étapes sur le deuxième serveur.
Modifiez le fichier/etc/hosts pour spécifier l'hôte du deuxième serveur DNS:
sudo nano /etc/hosts127.0.0.1 localhost
192.0.2.2 ns2.example.com ns2Vérifiez également le fichier/etc/hostname. Cela devrait seulement avoir le nom court non qualifié:
sudo nano /etc/hostnamens2Encore une fois, faites relire le fichier par le système si vous deviez modifier quoi que ce soit:
sudo hostname -F /etc/hostnameVos serveurs peuvent maintenant résoudre leurs propres noms sans utiliser DNS. Vous êtes maintenant prêt à configurer NSD sur vos serveurs.
Installer NSD sur les deux serveurs de noms
La prochaine étape consiste à installer le logiciel sur vos serveurs de noms.
Avant de commencer, nous devons en fait franchir une étape préparatoire supplémentaire. Le package NSD du référentiel installe le logiciel, configure certains composants et tente de démarrer le service. Le service s'attend à s'exécuter en tant qu'utilisateur appelénsd, mais le package ne crée pas réellement ce compte utilisateur.
Pour éviter une erreur lors de l'installation, nous allons créer cet utilisateurbefore nous installerons le logiciel. Sur chacune de vos machines, créez l'utilisateur systèmensd en tapant:
sudo useradd -r nsdCela créera le compte approprié nécessaire pour terminer l'installation avec succès.
Il ne reste plus qu’à installer le logiciel NSD. Heureusement, NSD est inclus dans les référentiels Ubuntu 14.04, nous pouvons donc simplement utiliserapt pour le retirer. Nous mettrons à jour notre index de package local, puis téléchargerons le package approprié:
sudo apt-get update
sudo apt-get install nsdCela installera le logiciel et effectuera une configuration initiale. Il lancera également le service, même si nous ne l’avons pas encore configuré pour servir.
Configurez le serveur NSD principal
Nous commencerons par configurer notre serveurns1, qui sera configuré comme serveur DNS principal pour nos zones.
La première chose à faire est de s’assurer que toutes les clés SSL et tous les certificats utilisés par NSD pour communiquer en toute sécurité entre la partie démon de l’application et le contrôleur sont générés.
Pour ce faire, tapez:
sudo nsd-control-setupIl y a probablement déjà des clés et des certificats présents dans le répertoire/etc/nsd, mais cette commande générera tout ce qui manque.
Configurez le fichier nsd.conf
Le fichier de configuration principal pour NSD est un fichier appelénsd.conf situé dans le répertoire/etc/nsd.
Il existe déjà un fichier contenant seulement quelques commentaires dans ce répertoire, mais nous utiliserons un exemple de fichier plus commenté comme modèle. Copiez ceci maintenant pour écraser le fichier actuel:
sudo cp /usr/share/doc/nsd/examples/nsd.conf /etc/nsd/nsd.confMaintenant, ouvrez le nouveau fichier dans votre éditeur de texte avec les privilèges sudo:
sudo nano /etc/nsd/nsd.confÀ l'intérieur, vous verrez un certain nombre de lignes de configuration commentées organisées en sections. Les sections principales sontserver,remote-control,key,pattern etzone. Nous allons utiliser la plupart de ceux-ci pour notre configuration.
Pour commencer, nous devons configurer les propriétés de base de notre serveur DNS dans la sectionserver. Nous allons gérer le trafic IPv4 de base sur le port DNS 53 par défaut. Nous utiliserons l'utilisateurnsd que nous avons configuré précédemment. La plupart d'entre elles seront les valeurs par défaut, mais nous décommenterons les lignes associées pour rendre leurs valeurs explicites.
Nous souhaitons également définir explicitement le répertoire contenant nos données de zone, ainsi que nos emplacements de fichier journal et pid. Il existe de nombreux autres choix de configuration que vous pouvez définir pour cette section, mais nous allons rester relativement simples. N'hésitez pas à apporter des modifications supplémentaires.
Notre section serveur ressemblera à ceci:
server:
do-ip4: yes
port: 53
username: nsd
zonesdir: "/etc/nsd"
logfile: "/var/log/nsd.log"
pidfile: "/run/nsd/nsd.pid"Ensuite, jetons un œil à la sectionremote-control. Cette section est un peu trompeuse, car elle n’est pas uniquement utilisée pour le contrôle à distance de notre démon. Nous allons configurer cela pour contrôler le démon localement.
Premièrement, nous devons activer la ressource et définir son interface et son numéro de port. Tout cela peut être fait en décommentant les lignes appropriées et en changeant la directivecontrol-enable en «yes».
Ensuite, nous pouvons décommenter les lignes spécifiant les fichiers de clé et de certificat. Ceux-ci correspondent aux noms de fichiers générés lorsque nous avons exécuté la commandensd-control-setup et ne devraient pas avoir besoin d'être modifiés une fois qu'ils n'ont pas été commentés.
Nos valeurs pour cette section devraient ressembler à ceci:
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 8952
server-key-file: "/etc/nsd/nsd_server.key"
server-cert-file: "/etc/nsd/nsd_server.pem"
control-key-file: "/etc/nsd/nsd_control.key"
control-cert-file: "/etc/nsd/nsd_control.pem"Ensuite, nous allons configurer la sectionkey. Cette section contient les clés secrètes que NSD utilisera pour exécuter en toute sécurité des transferts de zone entre nos serveurs primaire et secondaire.
Nous devons définir le nom et l'algorithme qui sera utilisé. Nous utiliserons le nomdemokey pour notre exemple. Nous utiliserons également l'algorithme par défaut (hmac-sha256) qu'ils ont sélectionné.
Pour le secret lui-même, nous allons prendre conseil dans le commentaire sur la façon de générer un en toute sécurité. Quittez l'éditeur de texte. Dans votre terminal, exécutez la commande suivante:
dd if=/dev/random of=/dev/stdout count=1 bs=32 | base64Vous recevrez une clé générée aléatoirement dans le résultat de la commande:
0+1 records in
0+1 records out
19 bytes (19 B) copied, 0.000571766 s, 33.2 kB/s
+kO0Vu6gC+9bxzMy3TIZVLH+fg==Copiez la sortie en rouge ci-dessus et ouvrez à nouveau votre fichier de configuration. Utilisez la sortie copiée comme valeur du paramètresecret. Cette section devrait ressembler à ceci:
key:
name: "demokey"
algorithm: hmac-sha256
secret: "+kO0Vu6gC+9bxzMy3TIZVLH+fg=="Ensuite, nous allons configurer un modèle simple car nous avons des informations répétitives impliquant notre serveur secondaire. Nous notifierons et transférerons nos zones vers la même zone secondaire à chaque fois. Il est donc judicieux de créer un motif.
Nous appellerons notre modèletosecondary pour décrire à quoi le modèle sera utilisé. Nous allons définir le nom et le fichier de chaque zone individuellement, nous n’avons donc pas à nous soucier de cela dans le modèle.
Nous voulons définir le paramètrenotify dans notre modèle pour référencer l'adresse IP de notre serveur secondaire. Nous souhaitons également utiliser la clé que nous avons spécifiée pour transférer en toute sécurité les zones avec TSIG. Nous allons configurer le paramètreprovide-xfr exactement de la même manière.
À la fin, notre sectionpattern devrait ressembler à ceci:
pattern:
name: "tosecondary"
notify: 192.0.2.2 demokey
provide-xfr: 192.0.2.2 demokeyEnfin, nous arrivons à notre sectionzone. Ici, nous configurons la façon dont NSD gérera nos zones spécifiques et leurs fichiers associés.
Tout d'abord, nous allons configurer notre zone avancée. Nous devons configurer la zone pour notre zoneexample.com. C'est aussi simple que de spécifier le domaine lui-même sous le paramètrename, de spécifier le nom que nous utiliserons pour le fichier de zone et d'inclure le modèle que nous avons créé ci-dessus afin de le transférer vers notre serveur secondaire.
La zone avant terminée pour notre démo devrait ressembler à ceci:
zone:
name: "example.com"
zonefile: "example.com.zone"
include-pattern: "tosecondary"Ensuite, nous pouvons nous occuper de la zone inverse. Une zone inversée est essentiellement un fichier de zone qui permet au logiciel DNS de mapper une adresse IP sur un nom d'hôte pour les clients. En général, avec un hébergement comme DigitalOcean, le fournisseur d'hébergement s'en charge.
Par exemple, avec DigitalOcean, vous n'êtes pas responsable d'une plage d'adresses IP pour configurer des correspondances inverses. Au lieu de cela, DigitalOcean crée automatiquement les correspondances inverses nécessaires si vous définissez le nom d'hôte du serveur dans le panneau de configuration sur le nom de domaine complet (FQDN) sur lequel vous souhaitez le mapper.
Vous pouvez en savoir plus sur les mappages inversés en lisant la section «Un peu sur les zones inversées» desBind authoritative-only guide. Nous allons vous montrer comment configurer les zones inversées pour NSD à des fins d’information et pour une plus grande flexibilité, même si cela ne sera pertinent que dans les cas où vous avez reçu le contrôle délégué sur les mappages inverses pour un bloc d’IP.
Pour une zone inversée, nous prenons les trois premiers octets de l'adresse IP, les inversons et les ajoutons en tant que délégations de sous-domaine sur le domaine spécialin-addr.arpa. Voici comment le système DNS recherche les adresses IP en utilisant les mêmes méthodes de recherche que les domaines classiques. Pour notre cas, nous allons créer une zone inversée qui définit le mappage de2.0.192.in-addr.arpa. Cela ressemblera beaucoup à la spécification de la zone de transfert:
zone:
name: "2.0.192.in-addr.arpa"
zonefile: "192.0.2.zone"
include-pattern: "tosecondary"Enregistrez et fermez le fichier lorsque vous avez terminé.
Créer le fichier de zone de transfert
Maintenant, nous devons créer le fichier de zone avant. Dans notre configuration, nous avons nommé le fichier de zone «exemple.com.zone». Nous devrons créer un fichier avec ce nom dans notre répertoire/etc/nsd.
Ouvrez ce fichier dans votre éditeur de texte avec les privilèges sudo:
sudo nano /etc/nsd/example.com.zoneLa première chose à faire est de définir quelques paramètres. Nous allons définir le paramètre$ORIGIN qui pointe vers le domaine que nous configurons au format FQDN (avec le point de fin). Nous voulons également définir la durée de vie par défaut. Nous allons utiliser 1800 secondes ou 30 minutes:
$ORIGIN example.com.
$TTL 1800Ensuite, nous avons besoin de notre SOA, ou début de la notice d’autorité. Cela ressemblera à ceci:
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)Ceci définit certaines valeurs à l'échelle de la zone. La valeurns1.example.com. est utilisée pour spécifier l'emplacement du domaine de l'un des serveurs faisant autorité pour cette zone. Leadmin.example.com. est utilisé pour spécifier une adresse e-mail où les administrateurs de zone peuvent être joints.
L'adresse e-mail, dans ce cas, est[email protected]. Dans un fichier de zone DNS, le symbole “@” doit être transformé en un point. Le point final est également important, comme ils le sont toujours lors de la spécification d'un nom de domaine complet.
Les valeurs entre parenthèses définissent certaines des valeurs de notre zone. Le seul que nous mentionnerons ici est le numéro de série. Cette valeurmust est incrémentée chaque fois que vous modifiez le fichier de zone. Ici, nous démontrons en utilisant la date de cette écriture (02 juillet 2014) plus un numéro de révision.
Ensuite, nous devons utiliser les enregistrements NS pour définir les serveurs de noms faisant autorité pour cette zone. N'oubliez pas d'utiliser le nom de domaine complet de votre domaine, y compris le dernier point:
IN NS ns1.example.com.
IN NS ns2.example.com.Ensuite, nous devons configurer les enregistrements A qui indiqueront aux clients comment accéder aux serveurs de noms que nous avons spécifiés. C’est ce qui mappe nos noms d’hôtes sur leurs adresses IP réelles:
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2Enfin, nous souhaitons ajouter des enregistrements A supplémentaires pour nos autres hôtes. Dans notre cas, nous allons configurer notre domaine de base (example.com) et le nom d'hôte dewww à mapper sur notre serveur Web:
@ IN A 192.0.2.3
www IN A 192.0.2.3Lorsque vous avez terminé, votre fichier terminé doit ressembler à ceci:
$ORIGIN example.com.
$TTL 1800
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)
; Name servers
IN NS ns1.example.com.
IN NS ns2.example.com.
; A records for name servers
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
; Additional A records
@ IN A 192.0.2.3
www IN A 192.0.2.3Enregistrez et fermez le fichier lorsque vous avez terminé.
Créer le fichier de zone inversée
Ensuite, nous allons créer un fichier similaire pour notre zone inversée. Rappelez-vous que cela n’est nécessaire que si la responsabilité de la mise en correspondance inverse d’un bloc d’adresses vous a été déléguée.
Créez le fichier de zone inversée que vous avez référencé dans votre fichiernsd.conf et ouvrez-le avec les privilèges sudo dans votre éditeur de texte:
sudo nano /etc/nsd/192.0.2.zoneEncore une fois, nous commencerons par définir les paramètres$ORIGIN et$TTL. Cette fois, n'oubliez pas de définir l'origine sur le sous-domainein-addr.arpa de votre zone. Dans notre cas, cela ressemblera à ceci:
$ORIGIN 2.0.192.in-addr.arpa.
$TTL 1800Ensuite, nous devons définir les enregistrements SOA, comme auparavant. Nous pouvons très bien utiliser exactement les mêmes valeurs pour ce fichier car le même serveur de messagerie et le même serveur de noms faisant autorité sont responsables des deux zones. De plus, les valeurs numériques devraient également fonctionner dans ce cas. N'oubliez pas de modifier le numéro de série à chaque fois que vous effectuez une modification:
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)Lorsque vous avez terminé, le fichier devrait ressembler à ceci:
Encore une fois, nous devons définir les serveurs de noms qui font autorité pour la zone. Ce seront les mêmes serveurs encore:
IN NS ns1.example.com.
IN NS ns2.example.com.Enfin, nous devons fournir les mappages de domaine inversés réels en acheminant le dernier octet de chaque adresse IP vers le nom de domaine complet de l'hôte associé à l'aide d'enregistrements PTR:
1 IN PTR ns1.example.com.
2 IN PTR ns2.example.com.
3 IN PTR www.example.com.Lorsque vous avez terminé, le fichier devrait ressembler à ceci:
$ORIGIN 2.0.192.in-addr.arpa.
$TTL 1800
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)
; Name servers
IN NS ns1.example.com.
IN NS ns2.example.com.
; PTR records
1 IN PTR ns1.example.com.
2 IN PTR ns2.example.com.
3 IN PTR www.example.com.Enregistrez et fermez le fichier lorsque vous avez terminé.
Test des fichiers et redémarrage du service
Maintenant que notre serveur principal est configuré, nous pouvons continuer, tester notre fichier de configuration et implémenter nos modifications.
Vous pouvez vérifier la syntaxe du fichier de configuration principal en utilisant l'outilnsd-checkconf inclus. Pointez simplement l'outil sur votre fichier de configuration principal:
sudo nsd-checkconf /etc/nsd/nsd.confSi cela retourne immédiatement sans sortie, cela signifie que la syntaxe de votre fichier de configuration principal est valide. Si vous obtenez une erreur, vérifiez la syntaxe de votre fichier de configuration pour corriger les erreurs.
Une fois que vous êtes capable d'exécuter le contrôle proprement, vous pouvez redémarrer le service en tapant:
sudo service nsd restartCela arrêtera et démarrera le démon NSD.
Consultez les journaux pour voir tous les messages:
sudo tail -f /var/log/nsd.logVous devriez voir un certain nombre d'erreurs ressemblant à ceci:
. . .
[1404333729] nsd[2142]: error: xfrd: zone 2.0.192.in-addr.arpa: received notify response error NAME ERROR from 192.0.2.2
[1404333729] nsd[2142]: error: xfrd: zone 2.0.192.in-addr.arpa: max notify send count reached, 192.0.2.2 unreachableCeci est ici parce que NSD tente de transférer la zone sur le serveur secondaire, qui n’a pas encore été configuré.
Configurer le serveur NSD secondaire
Maintenant que le serveur principal est configuré, nous pouvons également préparer le serveur secondaire.
Encore une fois, nous voulons nous assurer que nos certificats et clés SSL sont tous générés et disponibles. Pour ce faire, lancez la commande suivante:
sudo nsd-control-setupCela garantira que tous les fichiers d'informations d'identification nécessaires pour contrôler le démon sont disponibles.
Configurez le fichier nsd.conf
Le fichiernsd.conf du serveur secondaire sera essentiellement le même que le serveur principal. Il y a seulement quelques petites choses que nous devrons modifier. Commencez par copier le fichier/etc/nsd/nsd.conf du serveur principal dans le fichier/etc/nsd/nsd.conf du serveur secondaire.
Le fichier de ce serveur secondaire devrait maintenant ressembler à ceci:
server:
do-ip4: yes
port: 53
username: nsd
zonesdir: "/etc/nsd"
logfile: "/var/log/nsd.log"
pidfile: "/run/nsd/nsd.pid"
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 8952
server-key-file: "/etc/nsd/nsd_server.key"
server-cert-file: "/etc/nsd/nsd_server.pem"
control-key-file: "/etc/nsd/nsd_control.key"
control-cert-file: "/etc/nsd/nsd_control.pem"
key:
name: "demokey"
algorithm: hmac-sha256
secret: "+kO0Vu6gC+9bxzMy3TIZVLH+fg=="
pattern:
name: "tosecondary"
notify: 192.0.2.2 demokey
provide-xfr: 192.0.2.2 demokey
zone:
name: "example.com"
zonefile: "example.com.zone"
include-pattern: "tosecondary"
zone:
name: "2.0.192.in-addr.arpa"
zonefile: "192.0.2.zone"
include-pattern: "tosecondary"C'est presque exactement ce dont nous avons besoin.
Les sectionsserver,remote-control etkey sont déjà complètement configurées. Le «secret» dans la sectionkeymust correspond à la valeur du serveur principal, donc la copie du contenu complet du fichier facilite la satisfaction de cette exigence.
La première chose que nous devrons modifier est la sectionpattern. La section que nous avons copiée est spécifique au serveur principal. Nous souhaitons donc la modifier pour traiter les problèmes du point de vue du serveur secondaire.
Commencez par changer le nom en quelque chose de plus descriptif. Nous utiliserons la même convention et appellerons celafromprimary. Nous devons également modifier les directives que cela définit. Au lieu du paramètrenotify, les serveurs secondaires ont besoin d'un paramètreallow-notify, qui spécifie les serveurs autorisés à le notifier. Nous utiliserons toujours la même clé. Il suffit donc de modifier le nom et l'adresse IP appropriée.
De la même manière, nous devons changer le paramètreprovide-xfr enrequest-xfr. Le format de ceci change légèrement. Nous devons spécifier que nous voulons un transfert AXFR (le seul type dont les primaires NSD sont capables) et nous devons spécifier l'adresse IPand le numéro de port du primaire.
La sectionpattern ressemblera à quelque chose comme ceci lorsque vous aurez terminé:
pattern:
name: "fromprimary"
allow-notify: 192.0.2.1 demokey
request-xfr: AXFR 192.0.2.1@53 demokeyPour les sectionszone, la seule chose que nous devons modifier est lesinclude-pattern pour correspondre au nouveau modèle que nous venons de créer:
zone:
name: "example.com"
zonefile: "example.com.zone"
include-pattern: "fromprimary"
zone:
name: "2.0.192.in-addr.arpa"
zonefile: "192.0.2.zone"
include-pattern: "fromprimary"Lorsque vous avez terminé, enregistrez et fermez le fichier.
Test des fichiers et redémarrage du service
Étant donné que notre serveur secondaire recevra toutes ses données de zone par le biais de transferts du serveur principal, nous n'avons pas réellement besoin de configurer les fichiers de zone sur cet hôte.
Encore une fois, nous devrions vérifier la syntaxe de notre fichier de configuration principal en tapant:
sudo nsd-checkconf /etc/nsd/nsd.confSi vous recevez des erreurs, vous devez réexaminer votre fichiernsd.conf pour résoudre les problèmes de syntaxe. Si la commande retourne sans aucune sortie, cela signifie que votre syntaxe est valide dans le fichier.
Lorsque votre fichier de configuration réussit le test, vous pouvez redémarrer le service en tapant:
sudo service nsd restartVérifiez les journaux pour vous assurer que tout va bien:
sudo tail -f /var/log/nsd.logDéléguer l'autorité à vos serveurs de noms
Désormais, vos serveurs NSD faisant uniquement autorité, doivent être configurés et prêts à fournir des informations DNS sur votre domaine. Nous devons toujours configurer votre domaine pour qu'il sache utiliser vos serveurs de noms.
Pour ce faire, vous devez ajuster certains paramètres sous le registraire où vous avez acheté votre nom de domaine. Une partie de la terminologie et l'interface varient certainement d'un registraire à l'autre, mais vous devriez être capable de trouver les paramètres si vous regardez attentivement.
Je vais vous montrer comment faire cela avecNamecheap, un registraire de noms de domaine assez standard.
Nous devons ajuster vos serveurs de noms de manière à nous permettre de définirglue records sur le parent du domaine. Ceci est nécessaire chaque fois que les serveurs de noms sontwithin le domaine lui-même.
Lorsque vous déléguez un sous-domaine (commeexample.com du domainecom), vous devez spécifier les serveurs de noms faisant autorité pour le domaine. Si les serveurs de noms se trouvent dans le domaine, vousalsodevez inclure un enregistrement glue, qui est simplement un enregistrement A pour chacun des serveurs de noms faisant autorité pour la zone déléguée.
Nous en avons besoin, car les recherches DNS seraient bloquées dans une boucle si les enregistrements collés n'étaient pas inclus. Les clients demanderaient à notre registraire qui fait autorité pour le domaineexample.com et notre registraire renverrait (après avoir configuré cela)ns1.example.com etns2.example.com. Si nous n'incluons pas les enregistrements A pour les résoudre en adresses IP, le client ne pourra jamais se déplacer au-delà de ce point. Il n'aurait aucun moyen de trouver les adresses IP des serveurs de noms dont il a besoin, car celles-ci sont généralement définies dans les serveurs de noms eux-mêmes.
L’emplacement dans l’interface du bureau d’enregistrement où vous pouvez configurer vos serveurs de nomsand leurs adresses IP associées varie en fonction de votre fournisseur. Avec Namecheap, une section intitulée «Enregistrement de serveur de noms» vous permet de définir les adresses IP des serveurs de noms pour créer des enregistrements de liaison:
Ici, vous pouvez configurer les serveurs de noms et les mapper sur une adresse IP spécifique:
Lorsque vous avez terminé, vous devez définir les serveurs de noms actifs utilisés pour votre domaine. Namecheap a une option appelée «Configuration du serveur de noms de domaine» qui accomplit ceci:
Dans l'interface que vous obtenez lorsque vous sélectionnez cette option, vous pouvez entrer les noms d'hôte de vos serveurs de noms que vous venez d'enregistrer:
Les modifications que vous apportez avec votre registraire peuvent prendre un certain temps à se propager. Les données mettront également un temps supplémentaire à se propager aux serveurs DNS du reste du monde. En règle générale, ce processus devrait être terminé dans les prochaines 24 à 48 heures.
Conclusion
À l'aide de ce guide, vous devez maintenant disposer de serveurs DNS principal et secondaire faisant autorité, pouvant servir à fournir des informations DNS sur vos domaines. Contrairement à Bind, NSD est optimisé pour un comportement faisant autorité de hautes performances. Vous pouvez ainsi obtenir des performances supérieures, adaptées à vos besoins.