bind restart needed to reflect changes to dynamic zone in multiple views
I am using BIND 9.7.2-P2.
I have two views, one internal and one for external queries. In
both of those views I have some zones which are common so I put them
into their own file zones.common and include that file in both of the
views.
The problem I am having is that when I make a dynamic update to a common
zone, only the internal view sees that change. External queries still
return the data prior to the update. If I restart the server, then
external queries get the updated data.
To provide an (excerpted, for brevity) example...
zones.common
zone rbl.interlinx.bc.ca {
type master;
file /etc/bind/master/rbl.interlinx.bc.ca.zone;
allow-update { ... };
allow-transfer { ... };
allow-query { any; };
};
zones.common
named.conf
view trusted {
match-clients { trusted_networks; }; // our internal networks
...
include /etc/bind/zones.common;
...
zone interlinx.bc.ca {
type master;
file /etc/bind/master/interlinx.bc.ca.zone;
allow-update { ... };
allow-query { ... };
allow-transfer { ... };
};
...
};
view greatunwashed {
match-clients { any; }; // all others hosts
...
include /etc/bind/zones.common;
allow-query { great_unwashed_allowed_query; };
zone interlinx.bc.ca {
type slave;
file /etc/bind/slave/interlinx.bc.ca.zone;
masters { ... };
allow-query { any; };
};
};
named.conf
To demonstrate, given the above configuration:
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca. not found: 3(NXDOMAIN)
dns_server $ nsupdate
server localhost
zone rbl.interlinx.bc.ca.
update add 1.2.3.4.rbl.interlinx.bc.ca 60 A 127.0.0.2
send
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
dns_server # /usr/sbin/rndc reload
server reload successful
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
dns_server # service bind9 restart
* Stopping domain name service... bind9
...done.
* Starting domain name service... bind9
...done.
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
As you can see, it took a complete server restart for the greatunwashed
view to get the zone update.
Is this expected behavior or a (known?) bug?
Cheers,
b.
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 06/24/11 08:22, Brian J. Murrell wrote:
I am using BIND 9.7.2-P2.
I have two views, one internal and one for external queries. In
both of those views I have some zones which are common so I put them
into their own file zones.common and include that file in both of the
views.
The problem I am having is that when I make a dynamic update to a common
zone, only the internal view sees that change. External queries still
return the data prior to the update. If I restart the server, then
external queries get the updated data.
To provide an (excerpted, for brevity) example...
zones.common
zone rbl.interlinx.bc.ca {
type master;
file /etc/bind/master/rbl.interlinx.bc.ca.zone;
allow-update { ... };
allow-transfer { ... };
allow-query { any; };
};
zones.common
named.conf
view trusted {
match-clients { trusted_networks; }; // our internal networks
...
include /etc/bind/zones.common;
...
zone interlinx.bc.ca {
type master;
file /etc/bind/master/interlinx.bc.ca.zone;
allow-update { ... };
allow-query { ... };
allow-transfer { ... };
};
...
};
view greatunwashed {
match-clients { any; }; // all others hosts
...
include /etc/bind/zones.common;
allow-query { great_unwashed_allowed_query; };
zone interlinx.bc.ca {
type slave;
file /etc/bind/slave/interlinx.bc.ca.zone;
masters { ... };
allow-query { any; };
};
};
named.conf
To demonstrate, given the above configuration:
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca. not found: 3(NXDOMAIN)
dns_server $ nsupdate
server localhost
zone rbl.interlinx.bc.ca.
update add 1.2.3.4.rbl.interlinx.bc.ca 60 A 127.0.0.2
send
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
dns_server # /usr/sbin/rndc reload
server reload successful
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
dns_server # service bind9 restart
* Stopping domain name service... bind9
...done.
* Starting domain name service... bind9
...done.
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
As you can see, it took a complete server restart for the greatunwashed
view to get the zone update.
Is this expected behavior or a (known?) bug?
Cheers,
b.
It's expected behavior in a way. You are probably making this change in
the internal view and the internal named process knows about the change
and reloads the zone.
The external view's process is unaware of the change and does not reload.
1) You could send a periodic rndc reload to the external view process.
2) Since this appears to be an rbl zone, use rbldnsd instead of named to
serve this zone. Rbldnsd has code in it to auto-detect a change in the
zone file and will auto-reload. Rbldnsd is a tighter piece of code
designed not to be a general purpose piece of software, but a
specialized service. It takes fewer system resources for this purpose.
FYI, I have an internal rbl that I use here. I store the zone data in a
postgres sql database and do the updates to it there. The two hosts
that serve the data run rbldnsd. I have written perl scripts to
periodicly pull a copy of the database and parse that into text files
compatible with rbldnsd and move them into place. rbldnsd automagically
reloads the updated zone files.
Lyle Giese
LCR Computer Services, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 24/06/11 14:22, Brian J. Murrell wrote: I am using BIND 9.7.2-P2. I have two views, one internal and one for external queries. In both of those views I have some zones which are common so I put them into their own file zones.common and include that file in both of the views. The problem I am having is that when I make a dynamic update to a common zone, only the internal view sees that change. External queries still return the data prior to the update. If I restart the server, then external queries get the updated data. That's not supported. You will need to transfer the zone from the the internal view to the external view, and store them in different files. This kind of things gets discussed on the list often - you can find more info in the archives. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 11-06-24 09:57 AM, Lyle Giese wrote: It's expected behavior in a way. Given your explanation, indeed. :-) You are probably making this change in the internal view and the internal named process knows about the change and reloads the zone. The external view's process is unaware of the change and does not reload. A. I guess I had not considered how BIND handles views and that it's done with a separate process per view. But I only have one named process, so I suppose it's threading for each view. 1) You could send a periodic rndc reload to the external view process. Except that I only have the one process. Any thoughts on how to do this in such a case? 2) Since this appears to be an rbl zone, use rbldnsd instead of named to serve this zone. Yeah, I suppose I could. It would solve this specific use case, but I don't know that this RBL zone is the extent of this problem. I'd have to examine further where there are zones shared by multiple views. I'm guessing though that rbldnsd doesn't support remote update, yes? That would be limiting for my purposes here. Cheers, b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 06/24/11 09:21, Brian J. Murrell wrote: On 11-06-24 09:57 AM, Lyle Giese wrote: It's expected behavior in a way. Given your explanation, indeed. :-) You are probably making this change in the internal view and the internal named process knows about the change and reloads the zone. The external view's process is unaware of the change and does not reload. A. I guess I had not considered how BIND handles views and that it's done with a separate process per view. But I only have one named process, so I suppose it's threading for each view. 1) You could send a periodic rndc reload to the external view process. Except that I only have the one process. Any thoughts on how to do this in such a case? 2) Since this appears to be an rbl zone, use rbldnsd instead of named to serve this zone. Yeah, I suppose I could. It would solve this specific use case, but I don't know that this RBL zone is the extent of this problem. I'd have to examine further where there are zones shared by multiple views. I'm guessing though that rbldnsd doesn't support remote update, yes? That would be limiting for my purposes here. Cheers, b. rbldnsd does not support dynamic updates like bind. But there is no reason you can not create a script in any language to update the zone file. When rbldnsd detects that the zone file has been changed, it auto reloads it. In my situation, when I place a new zone file in place, rbldnsd auto loads the new one. Lyle ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
A. I guess I had not considered how BIND handles views and that it's done with a separate process per view. But I only have one named process, so I suppose it's threading for each view. No, the views will all share the same process and thread(s), but they are separate chunks of memory, and simulate being separate servers. Except that I only have the one process. Any thoughts on how to do this in such a case? You can specify the view in the reload command: $ rndc reload example.com in external You can also configure the zone in one view as a master and the one in the other view as a slave; then reloading the master will automatically send a notify to the slave. This involves tsig keys and is kind of fiddly, but works quite well (I run several zones that way on my home server). -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 11-06-24 12:39 PM, Evan Hunt wrote: You can specify the view in the reload command: $ rndc reload example.com in external But reload doesn't work for dynamic zones: # rndc reload rbl.interlinx.bc.ca in greatunwashed rndc: 'reload' failed: dynamic zone and since I want the same zone definition file to be included in both views, I can't (without separating and mostly duplicating) easily do that. I don't think I can even point a non-dynamic zone definition at a dynamic zone file because of the journal and all that, right? You can also configure the zone in one view as a master and the one in the other view as a slave; then reloading the master will automatically send a notify to the slave. Yeah, so I've been hearing about. I suppose in this case I am creating separate definitions for the zones also. :-( This all seems like a pretty serious deficiency in BIND9. That it exists I suppose attests to the difficulty in fixing it though. :-( Cheers, b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
But reload doesn't work for dynamic zones:
Do the internal and external versions *both* need to be dynamic?
I'd expect it to work okay if you had only one of them dynamic, and
sent periodic reload commands to the other one.
The master/slave approach really works better, though. Something like
this:
view internal {
match-clients { !key example-key; localnets; };
zone example.com {
type slave;
masters { localhost key example-key; }
};
};
view external {
match-clients { any; };
zone example.com {
type master;
file filename;
update-policy { grant example-key zonesub ANY; };
also-notify { 127.0.0.1; };
};
};
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 11-06-24 01:47 PM, Evan Hunt wrote:
Do the internal and external versions *both* need to be dynamic?
No, only the internal in fact.
I'd expect it to work okay if you had only one of them dynamic, and
sent periodic reload commands to the other one.
Yeah. I got the master/slave approach working with your suggestion
below as a model. I reversed the master/slave relationship however to
reflect that changes come from internal only.
I guess it's hoping for too much though to have the master sent notifies
to the slave given that master and slave are both on the same host, yes?
Hence your suggestion of periodic reload commands?
The data really does need to be quite in sync though. I'm not sure a
period of less than a second or two is going to be acceptable. :-(
The master/slave approach really works better, though. Something like
this:
view internal {
match-clients { !key example-key; localnets; };
zone example.com {
type slave;
masters { localhost key example-key; }
};
};
view external {
match-clients { any; };
zone example.com {
type master;
file filename;
update-policy { grant example-key zonesub ANY; };
also-notify { 127.0.0.1; };
};
};
Cheers, and thanx much for all of that.
b.
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 6/24/2011 2:51 PM, Brian J. Murrell wrote: The data really does need to be quite in sync though. I'm not sure a period of less than a second or two is going to be acceptable.:-( Do you have control of the update process. You could potentially send and update to both views (in other words, send two updates). I think you'd need separate zone files on the server, too. -- Dave ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 11-06-24 03:19 PM, David Sparro wrote: Do you have control of the update process. Sure. You could potentially send and update to both views (in other words, send two updates). How do I, with nsupdate, specify which view's zone I want to update? I think you'd need separate zone files on the server, too. Sure, that's not hard. The hard (or rather, unknown) part is how to tell nsupdate which view to interact with? b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 06/24/2011 10:47 PM, Brian J. Murrell wrote:
On 11-06-24 03:19 PM, David Sparro wrote:
Do you have control of the update process.
Sure.
You could potentially send
and update to both views (in other words, send two updates).
How do I, with nsupdate, specify which view's zone I want to update?
Use two separate TSIG keys to secure the updates (-y argument to
nsupdate). Set match-clients { key xxx; } in the view.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
