Linux – dns zone transfer to solaris slave

binddns-zonedomain-name-systemlinuxsolaris

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?

Best Answer

unfortunately, the solaris-host refused to act as a secondary nameserver

That betrays a deep misunderstanding of how DNS works, unfortunately.

How does the rest of the world know, who to query for your domain data ?
-> By the nameservers configured/defined in your zone file.

You need to add the Solaris IP as a nameserver (NS) record, and update the zone.

This will also cause notifies to be sent automatically, as they are sent to all other listed nameservers.

The slave will then pull the zone in response to the notify.

Just FYI, "recursion yes"- No. Just...no. That has no place on an authoritative nameserver; set up a dedicated resolver cache instead.

Related Topic