i'm running bind9 as a primary DNS-server for a private zone on debian gnu/linux, and everything is happy.
the namserver is working at IP X.X.X.X1
,
$ dig foo.zoneA @dns.zoneA
; <<>> DiG 9.7.3 <<>> foo.zoneA @X.X.X.X1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21295
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
;; QUESTION SECTION:
;foo.zoneA. IN A
;; ANSWER SECTION:
foo.zoneA. 604800 IN A 192.168.171.Y
;; AUTHORITY SECTION:
zoneA. 604800 IN NS ns2.mycompany.net.
zoneA. 604800 IN NS dns.zoneA.
zoneA. 604800 IN NS dns.mycompany.net.
;; ADDITIONAL SECTION:
dns.mycompany.net. 306 IN A X.X.X.X2
dns.zoneA. 604800 IN A X.X.X.X1
;; Query time: 0 msec
;; SERVER: X.X.X.X1#53(X.X.X.X1)
;; WHEN: Thu Jul 26 17:04:14 2012
;; MSG SIZE rcvd: 142
recently we had to mirror one of our zones to a secondary DNS-server running bind9 on solaris.
on the primary server, we allowed zone-transfers to the secondary server with something like:
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";
};
};
i used ...
to indicate other acls, and X.X.X.X2
is the IP of the secondary DNS-server.
after that configuration, it was possible on the solaris machine to manually get a zone-transfer with dig axfr zoneA @X.X.X.X1
(with X.X.X.X1 being the IP of the primary DNS server).
the solaris machine was configured (according to the guy who did it, as i don't have access to the machine) with something like:
zone "zoneA" {
type slave;
masters { X.X.X.X1; };
file "/var/cache/bind/db.zoneA";
};
unfortunately, the solaris-host refused to act as a secondary nameserver:
$ dig foo.zoneA @X.X.X.X2
; <<>> DiG 9.7.3 <<>> foo.zoneA @X.X.X.X2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33528
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;foo.zoneA. IN A
;; AUTHORITY SECTION:
. 3533 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2012072600 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: X.X.X.X2#53(X.X.X.X2)
;; WHEN: Thu Jul 26 16:59:21 2012
;; MSG SIZE rcvd: 106
luckily there was a third nameserver available (this time running bind9 on linux again, with the IP X.X.X.X3
).
configuring this nameserver exactly the same as the solaris bind9 (according to the tech guy there), we had instant success (after allowing zone-transfers on the primary server for the new IP address):
$ dig foo.zoneA @X.X.X.X3
; <<>> DiG 9.7.3 <<>> foo.zoneA @X.X.X.X3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9788
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;foo.zoneA. IN A
;; ANSWER SECTION:
foo.zoneA. 604800 IN A 192.168.171.Y
;; AUTHORITY SECTION:
zoneA. 604800 IN NS dns.zoneA.
zoneA. 604800 IN NS ns2.mycompany.net.
zoneA. 604800 IN NS dns.mycompany.net.
;; ADDITIONAL SECTION:
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
;; Query time: 1 msec
;; SERVER: X.X.X.X3#53(X.X.X.X3)
;; WHEN: Thu Jul 26 17:15:53 2012
;; MSG SIZE rcvd: 158
now those 2 "other" nameserves (X.X.X.X2 running solaris and X.X.X.X3 running linux) act as a primary (solaris) / secondary (linux) pair, so bind9 manages to do zone-transfers at least from solaris to linux.
are there any known limitiations when trying to do zone-transfers from linux to solaris using bind9 on both sides?