View selection via TSIG

Josh Paetzel josh at
Wed Aug 19 15:12:21 UTC 2009

On Aug 18, 2009, at 12:32 AM, Josh Paetzel wrote:

> On Aug 17, 2009, at 11:08 PM, Mark Andrews wrote:
>> In message <96123FB1-1F2E-493C-BBB8-24A86A1DD99A at>, Josh  
>> Paetzel write
>> s:
>>> On Aug 16, 2009, at 12:26 AM, Mark Andrews wrote:
>>>> In message <5EA10B89-4650-4F82-A41D-CB511CE2A9A9 at>, Josh
>>>> Paetzel write
>>>> s:
>>>>> I've googled a bit and been unable to find the solution that I  
>>>>> need.
>>>>> I have a master nameserver that has 4 views configured.  I have a
>>>>> slave for this that is currently using 4 IPs to slave the views.
>>>>> This
>>>>> works fairly well, except that the slave server is unable to  
>>>>> handle
>>>>> NOTIFY from the master.  So when I do an update to a zone I have  
>>>>> to
>>>>> stop the slave, delete it's cache files, and restart it.  The  
>>>>> slave
>>>>> is
>>>>> able to properly load zones, since it uses the correct IPs to
>>>>> transfer
>>>>> the zones, and it gets the right views, all is well.
>>>>> I've read that BIND 9.3 can use TSIG for view selection, but all  
>>>>> I've
>>>>> ben able to find is using TSIG for one view, and no TSIG for the
>>>>> other
>>>>> view.  What I would like to do is configure four separate TSIG  
>>>>> keys
>>>>> and do view selection based on which key is used.
>>>>> Is this possible?  And where can I find documentation on it?
>>>> 	Yes.  Read the FAQ.
>>> I read the FAQ, and there was a question entitled "How to share a
>>> dynamic zone between multiple views?" that seemed to get me most of
>>> the way there.  I am now running my slave nameserver on one IP, and
>>> zones transfers seem to work fine.  NOTIFY also seems to work for
>>> every view but the external view.  This is somewhat perplexing to  
>>> me.
>>> Tomorrow I plan on turning on logging for NOTIFY to see if I can at
>>> least determine what is going on.
>>> If you have any tips or common gotchas feel free to let me know.
>>> Thanks,
>>> Josh Paetzel
>> 	You need to make the notify go to the correct view by using
>> 	appropriate server clauses at the view level.  It's a matter
>> 	of making what the master sends match what the client expects.
>> 	Mark
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742                 INTERNET: marka at
> Well, I found the issue.  If the key is listed last in match-clients  
> it works.
> // doesn't work
> match-clients { key external; all; };
> // works
> match-clients { all; key external; };
> Somehow I think either I've hit a bug, or I'm too tired to fully  
> understand how those statements are different, or even more likely,  
> that there's something else going on that just makes this work by  
> coincidence
> It's very reproducible though.  It also only seems to affect my  
> external view, all the other views, that match specific  subnets,  
> can have the key specified anywhere in the list.
> So to reiterate:
> Zone transfers worked properly for all views
> The slave updated properly upon receiving NOTIFY for every zone but  
> the external view.
> Any update that resulted in a NOTIFY being set for the external view  
> was not picked up by the slave.
> The differences between the external view and all the other views  
> was the external view was last, it had any in it's match-clients and  
> recursion turned off.
> Thanks,
> Josh Paetzel

Well, still having some intermittent trouble with this.  It seems that  
about half the the slave missed NOTIFY for the external view.  My  
previous email was basically the result of it not missing NOTIFY  
enough times for me to think it was fixed.

I've tried turning on NOTIFY logging, but I must be doing something  
wrong there, because nothing is ever logged.

logging {
         channel my_log {
                 file "/var/log/bind/named.log" versions 3 size 5m;
                 severity warning;
                 print-time yes;
                 print-severity yes;
                 print-category yes;
         category "notify" {

I've changed the category to default to make sure that it can log that  
and it can.

I'm starting to suspect there's a bug in BIND I'm tripping here, or I  
simply don't understand something fundemental.  Zone transfers work  
perfectly, and every view except for the external view responds  
correctly to NOTIFY.  It seems to be NOTIFY for the external view  
which is intermittently broken.  The only thing different between the  
external view and the other three is it has match-clients any instead  
of a subnet, it has recursion turned off, and it's the last view  
listed. I can send along my configuration if that helps.  Somehow I  
think getting logging to work would help resolve this too.


Josh Paetzel

More information about the bind-users mailing list