Bind9 and djbdns zone transfers

[Kevin Darcy]

entropathy at gmail.com wrote:

>I have a simple problem that I've been searching all day for an answer
>too and have turned up nothing so far. I have a dns server that is
>running bind 9.2.1 and a friend who use's djbdns suite. He is the
>master I am the slave. I am trying to slave 2 zones from him. He has
>the authoritative server running on localhost(udp 53) and the caching
>server running on the exposed IP of the machine, lets say 192.168.100.1
>(udp/tcp 53) and finally the xfer daemon runs on port 5000. Here is my
>problem when I set up my slave zone it looks like this
>
>zone "myslavezone1.com" {
>        type slave;
>        file "db.slavezone1.com";
>        masters { 192.168.100.1 port 5000; };
>};
>
>The problem here is that when I restart bind the first thing it does is
>the SOA query for the zone to see if it needs to axfr. Of course it
>fires this query off on udp port 5000 since that's what I have
>configured and of course it fails. So then I removed the port 5000
>declaration to make sure bind could at least get the correct SOA record
>and determine if it needs to do a transfer or not. However these
>queries fail as well, but if I use the host command on the same machine
>to grab and SOA it works I took a packet dump and the difference
>appears to be that in my comand line the 'Recursion Desired' Flag is
>enabled but in the bind generated one it is not so after all of this
>here are the questions I have
>
>1) Is there a way to tell bind to flip the recursion flag on for the
>SOA queries
>2) Is there anyway to configure it to use a differnt destination ports
>for queries and transfers
>
>----below here  is OT I think but if anyone can shed light on it i'd
>appreciate it
>
>I'm assuming the bind SOA recursion failure is because only the caching
>server is exposed and accessible on the master server and the real
>authoritative one is not exposed meaning the caching one would have to
>recurse to get the real SOA, I'm not familiar enough with djbdns to
>know if this is a common setup or if the authoritative server should be
>running on an accessible ip.
>
Looks circumstantially like they're running only a non-authoritative 
instance on UDP/5000. That's no good, since named will reject a 
non-authoritative SOA-serial response. I'm not aware of any way within 
BIND to specify a different port for SOA-serial queries than for the 
subsequent zone transfers. If there is no such capability, then the 
other folks will need to run an authoritative instance of the zone(s) on 
UDP/5000. I assume there's a way within djbdns to do this, without 
interfering with "axfrdns" or whatever his AXFR server daemon is called, 
running on TCP/5000. And they should seriously consider dumping djbdns 
with all of its AXFR foibles and quirkiness. Just because DJB doesn't 
personally like AXFR as a replication mechanism, is no justification, 
IMO, for subjecting his users to this nonsense when trying to 
interoperate with more popular DNS implementations.

                                                                         
                                       - Kevin