1 votes

Veuillez traduire ceci en conservant les mêmes balises HTML si elles existent : transfert de zone DNS vers un esclave Solaris

Je lance bind9 en tant que serveur DNS primaire pour une zone privée sur debian gnu/linux, et tout fonctionne correctement. le serveur de noms fonctionne à l'IP X.X.X.X1,

$ dig foo.zoneA @dns.zoneA

; <<>> DiG 9.7.3 <<>> foo.zoneA @X.X.X.X1
;; options globales: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21295
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2

;; SECTION QUESTION:
;foo.zoneA.         IN  A

;; SECTION ANSWER:
foo.zoneA.      604800  IN  A   192.168.171.Y

;; SECTION AUTHORITY:
zoneA.          604800  IN  NS  ns2.mycompany.net.
zoneA.          604800  IN  NS  dns.zoneA.
zoneA.          604800  IN  NS  dns.mycompany.net.

;; SECTION ADDITIONAL:
dns.mycompany.net.      306 IN  A   X.X.X.X2
dns.zoneA.      604800  IN  A   X.X.X.X1

;; Temps pour la requête: 0 msec
;; SERVEUR: X.X.X.X1#53(X.X.X.X1)
;; QUAND: Jeu Juil 26 17:04:14 2012
;; TAILLE DU MESSAGE reçu: 142

Récemment, nous avons dû miroirer l'une de nos zones vers un serveur DNS secondaire exécutant bind9 sur solaris.

Sur le serveur primaire, nous avons autorisé les transferts de zone vers le serveur secondaire avec quelque chose du genre :

acl zoneAdns { X.X.X.X2; };

view "localview" {
   match-clients { zoneAdns; ...; }; 
   allow-transfer { zoneAdns; };
   zone "zoneA" {
     type master;
     allow-query { zoneAdns; ...; };
     file "/etc/bind/db/db.zoneA";
   };
};

J'ai utilisé ... pour indiquer d'autres acls, et X.X.X.X2 est l'IP du serveur DNS secondaire.

Après cette configuration, il était possible sur la machine solaris d'obtenir manuellement une zone de transfert avec dig axfr zoneA @X.X.X.X1 (X.X.X.X1 étant l'IP du serveur DNS primaire).

La machine solaris était configurée (selon le gars qui l'a fait, car je n'ai pas accès à la machine) avec quelque chose du genre:

zone "zoneA" {
    type slave;
    masters { X.X.X.X1; };
    file "/var/cache/bind/db.zoneA";
};

Malheureusement, la machine solaris refusait de fonctionner en tant que serveur de noms secondaire:

$ dig foo.zoneA @X.X.X.X2

; <<>> DiG 9.7.3 <<>> foo.zoneA @X.X.X.X2
;; options globales: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33528
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; SECTION QUESTION:
;foo.zoneA.         IN  A

;; SECTION AUTHORITY:
.           3533    IN  SOA a.root-servers.net. nstld.verisign-grs.com. 2012072600 1800 900 604800 86400

;; Temps pour la requête: 0 msec
;; SERVEUR: X.X.X.X2#53(X.X.X.X2)
;; QUAND: Jeu Juil 26 16:59:21 2012
;; TAILLE DU MESSAGE reçu: 106

Heureusement, il y avait un troisième serveur de noms disponible (cette fois exécutant bind9 sur linux à nouveau, avec l'IP X.X.X.X3). En configurant ce serveur de noms exactement de la même manière que le bind9 solaris (selon le technicien là-bas), nous avons eu un succès instantané (après avoir autorisé les transferts de zone sur le serveur primaire pour la nouvelle adresse IP):

$ dig foo.zoneA @X.X.X.X3

; <<>> DiG 9.7.3 <<>> foo.zoneA @X.X.X.X3
;; options globales: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9788
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; SECTION QUESTION:
;foo.zoneA.         IN  A

;; SECTION ANSWER:
foo.zoneA.      604800  IN  A   192.168.171.Y

;; SECTION AUTHORITY:
zoneA.          604800  IN  NS  dns.zoneA.
zoneA.          604800  IN  NS  ns2.mycompany.net.
zoneA.          604800  IN  NS  dns.mycompany.net.

;; SECTION ADDITIONAL:
dns.mycompany.net.      600 IN  A   X.X.X.X2
dns.zoneA.      604800  IN  A   X.X.X.X1
ns2.mycompany.net.      600 IN  A   X.X.X.X3

;; Temps pour la requête: 1 msec
;; SERVEUR: X.X.X.X3#53(X.X.X.X3)
;; QUAND: Jeu Juil 26 17:15:53 2012
;; TAILLE DU MESSAGE reçu: 158

Maintenant, ces 2 "autres" serveurs de noms (X.X.X.X2 exécutant solaris et X.X.X.X3 exécutant linux) agissent comme une paire primaire (solaris) / secondaire (linux), donc bind9 parvient à réaliser des transferts de zone au moins de solaris à linux.

Y a-t-il des limitations connues lors de la tentative de transferts de zone de linux à solaris en utilisant bind9 des deux côtés?

0voto

adaptr Points 16431

malheureusement, l'hôte Solaris a refusé d'agir en tant que serveur de noms secondaire

Cela trahit une profonde incompréhension de la manière dont fonctionne DNS, malheureusement.

Comment le reste du monde sait-il vers qui interroger pour les données de votre domaine ?
-> Par les serveurs de noms configurés/définis dans votre fichier de zone.

Vous devez ajouter l'IP de Solaris en tant que serveur de noms (NS) record, et mettre à jour la zone.

Cela provoquera également l'envoi automatique de notifications, car elles sont envoyées à tous les autres serveurs de noms répertoriés.

L'esclave va ensuite tirer la zone en réponse à la notification.

Juste pour info, "récursion yes" - Non. Juste... non. Cela n'a pas sa place sur un serveur de noms autoritaire ; configurez plutôt un cache résolveur dédié.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X