slave transfer problems

Barry Margolin barmar at
Thu Apr 30 00:03:43 UTC 2009

In article <gtamqt$1k3$1 at>,
 Scott Haneda <talklists at> wrote:

> I have been having some long standing issues with my secondary  
> provider that I would like to learn how to solve, and who needs to  
> look to solve the errors.  When I make an update, it seems hit or miss  
> as to how long before I see it hit the secondary.
> Apparently they have a server at  xx.xx.0.26 that pulls the slave  
> data, even though I list the secondary NS as  xx.xx.0.18.   xx.xx.0.18  
> seems to be a slave of  xx.xx.0.26.
> My master has:
> options {
>          directory "/var/named";
>          allow-transfer {  xx.xx.0.26; };
>          transfer-source  xx.xx.37.14;
>          also-notify {  xx.xx.0.26; };
> };
> * I redacted some lines, but those are the ones I believe to be  
> important.
> They sent me some lines from their logs, which I will make comments on  
> in-between. I am pretty sure there is nothing for me to do on my end,  
> and this is for them to solve, but wanted to confirm...
> NS0 is  xx.xx.0.26, which is where I send my notifications to.
> > Computer:	NS0
> > Description:
> > zone refresh: unexpected rcode (REFUSED) from
> > master xx.xx.37.14#53 (source
> I do not understand this one, why would source be  This looks means they haven't configured a transfer source, it's letting 
the OS pick the address and port on the fly.
> like my machine, .14 is refusing their refresh request.  Do I need to  
> allow-recursion for their NS0?

No, you shouldn't need allow-recursion.  You might need allow-query, if 
you're not allowing to all.

> At any rate, I no longer have zones for this domain on the primary,  
> the domain owner has asked to terminate hosting.  I asked the  
> secondary to remove this from their slave.  I assume this, and the  
> below errors, especially the NOTAUTH are telling me exactly that, that  
> there is simply no data for this zone, and they need to remove the  
> slave files?


> > Computer:	NS0
> > Description:
> > Transfer started.
> >
> > Computer:	NS0
> > Description:
> > transfer of '' from xx.xx.37.14#53: connected  
> > using
> >  xx.xx.0.26#4012
> >
> > Computer:	NS0
> > Description:
> > transfer of '' from xx.xx.37.14#53: failed while
> > receiving responses: NOTAUTH
> -- end of logs for
> > Computer:	NS0
> > Description:
> > zone refused notify from non-master:
> >  xx.xx.37.6#56516
> This is a valid domain, current records, should be working fine.  Is  
> the refusal because they are asking  xx.xx.37.6?  Yes, this IP is on  
> the same machine, but that IP is used for http, and not DNS. So in  
> this case, my transfer source is  xx.xx.37.14, and they hit  xx.xx. 

Unless your machine is a slave, it doesn't need the transfer-source 

> 37.6, which named is not listening on, and get the above error?

Try setting notify-source to xx.xx.37.14.

> Those are the only two they gave me, but the general problem is, I can  
> update a zone, change the serial, issue rndc reload, and see my logs  
> show a notify sent their way.  It can then take anywhere from a few  
> minutes, to hours, to sometimes days to get the change to hit the  
> secondary.

Even if there's a problem with the notify, it shouldn't take much longer 
than the refresh time in the SOA record.  I recommend setting this to 
something in the neighborhood of an hour, so that there isn't too much 
of a lag if the notify is lost.

Barry Margolin, barmar at
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

More information about the bind-users mailing list