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?