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
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 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 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
> 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 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
> 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 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
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 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 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
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