dns zone transfer to solaris slave

Question

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?

"unfortunately, the solaris-host refused to act as a secondary nameserver." What do you mean by this? What are the symptoms? How did you know it refused queries or transfers? What happened when you tried to resolve a name against the Solaris-based DNS server? — mghocke, Jul 26 '12 at 14:41
i have hopefully clarified what is not working by adding the dig output for a host in my zoneA; lookup the rest of the "world" (yes, the secondary nameserver acts as caching proxy as well!) via the solaris box works fine. — umläute, Jul 26 '12 at 15:10
It really looks like the Solaris host is not configured correctly. At this point we really need to see the named.conf from all three servers and the zone file from the master server. Unless you have something within the network that make hosts X.X.X.X2 and X.X.X.X3 be different somehow (ACLs, for example) it must be a configuration problem. — mghocke, Jul 26 '12 at 19:27

score 0 · Answer 1 · answered Jul 26 '12 at 12:43

0

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.

answered Jul 26 '12 at 12:43

adaptr

16,479
21
33

thanks for your comment. the zone we are talking about here is really a non-public zone (".foonet") for internal use. the same nameserver that provides these non-public zones *is* the "gateway nameserver" for the clients, hence it allows recusion – umläute Jul 26 '12 at 12:52
furthermore, afaiu it is not true that only NS-records get updated. RFC1996 speeks of "Stealth" servers which are not listed in the NS-records (it's true that i spoke of "secondary" rather than "stealth" servers, though) and still among the list of servers to be notified. also i don't see why notification is a requirement in order for a secondary nameserver to work. true, notification allows for DNS-changes to propagate fast, but but i dont expect a server that is set as the slave for a domain to sit and wait until the zone-file gets updated. – umläute Jul 26 '12 at 13:03
As I said before, you don't really understand how this all works - and I'm not going to teach you the basics in a 500-character comment. – adaptr Jul 26 '12 at 13:08
since you do know how this all works, how about teaching me the basics by editing your answer? this would allow you to elaborate using more than 500 meagre characters – umläute Jul 26 '12 at 15:12
and just to make sure, i did as you suggested and added the secondary name-server to the NS record, and voila: it fails. – umläute Jul 26 '12 at 15:13
Yes; belligerent badgering is always the best way to receive free help. – adaptr Jul 26 '12 at 16:05

dns zone transfer to solaris slave

1 Answers1