RE: OT: Bind 9.9.0B1 Inline-Signing Question
I'd like to ask for clarification on the operational issue stated below. Suppose there are no current changes to an inline-signed master zone, i.e. myzone.db.signed timestamp is later than myzone.db timestamp. In this circumstance, is it safe to stop and restart the bind service or reboot the system? What about the situation where changes made by nsupdate have been recorded in the journal files but have not yet been written to the zone files? In other words, myzone.db.jnl timestamp is later than myzone.db timestamp, and myzone.db.signed.jnl timestamp is later than myzone.db.signed timestamp, and myzone.db.signed.jnl timestamp is later than myzone.db.jnl timestamp. Thanks. Jeff. Jeffry A. Spain Network Administrator Cincinnati Country Day School -Original Message- From: bind-users-bounces+spainj=countryday@lists.isc.org [mailto:bind-users-bounces+spainj=countryday@lists.isc.org] On Behalf Of Evan Hunt Sent: Friday, November 11, 2011 12:48 PM To: Adam Tkac Cc: bind-users@lists.isc.org Subject: Re: OT: Bind 9.9.0B1 Inline-Signing Question I should mention that there is a known operational issue in the current version of inline-signing that you should be cautious about. If you're using inline-signing with a master zone, and you make changes to the zone file, you should *not* kill and restart your server to load the new file. Instead, use rndc reload or kill -HUP pid to force named to reload the zone while it's running. That way, named will be able to compare the former version against the new one, and generate the proper set of diffs to apply to the signed zone. If you kill and restart your server to load changes to your zone, then the signed version of the zone will fall out of sync with the raw version, and some of your data will not be accessible to queries. There's no way to recover from this condition except to delete the signed zone and start over, which generates big transfers to slaves and is generally undesirable. We'll have a fix for this in a future release. It's not a problem when using inline-signing on slave zones; slaves load their data via zone transfer, not from files, so this issue doesn't affect them at all. -- 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: OT: Bind 9.9.0B1 Inline-Signing Question
On Fri, Nov 18, 2011 at 11:57:51PM +, Spain, Dr. Jeffry A. wrote: I'd like to ask for clarification on the operational issue stated below. Suppose there are no current changes to an inline-signed master zone, i.e. myzone.db.signed timestamp is later than myzone.db timestamp. In this circumstance, is it safe to stop and restart the bind service or reboot the system? What about the situation where changes made by nsupdate have been recorded in the journal files but have not yet been written to the zone files? In other words, myzone.db.jnl timestamp is later than myzone.db timestamp, and myzone.db.signed.jnl timestamp is later than myzone.db.signed timestamp, and myzone.db.signed.jnl timestamp is later than myzone.db.jnl timestamp. Both of these should be fine. The only thing you need to worry about is if changes to a zone are loaded for the first time in a newly-started server: i.e., you've updated the zone and then shut down the server, or shut down the server and then updated the zone. We expect to have this addressed by the time 9.9.0 is final. -- 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: OT: Bind 9.9.0B1 Inline-Signing Question
So the error being logged isn't really an error, it just looks like one; we should probably see about silencing it. The error is indeed confusing, maybe it should say not yet signed ? 11-Nov-2011 12:32:35.838 zone inline.aa/IN/internal (unsigned): loaded serial 2 11-Nov-2011 12:32:35.838 zone inline.aa/IN/internal (signed): not loaded due to errors. When you modify your static zone file and run 'rndc reload', named will detect the changes that you've made via the same mechanism as ixfr-from-differences, generate signatures for the new records, and add those to the signed version of the zone automatically. Almost. rndc reload behaviour has appaently changed. What actually happens on my copy of BIND 9.9.0b1 is: $ rndc reload rndc: 'reload' failed: up to date $ echo $? 1 named (running with -g) shows: 11-Nov-2011 12:36:08.377 zone inline.aa/IN/internal (signed): (master) removed 11-Nov-2011 12:36:08.378 reloading configuration succeeded 11-Nov-2011 12:36:08.378 reloading zones failed: up to date (The message (master) removed may cause the odd heart attack... :-) $ rndc reload inline.aa zone reload successful $ echo $? 0 Named then prints: 11-Nov-2011 12:38:16.911 received control channel command 'reload inline.aa' 11-Nov-2011 12:38:16.912 zone inline.aa/IN/internal (unsigned): loaded serial 3 11-Nov-2011 12:38:16.912 zone inline.aa/IN/internal (signed): loaded serial 5 (DNSSEC signed) 11-Nov-2011 12:38:16.912 zone inline.aa/IN/internal (signed): reconfiguring zone keys 11-Nov-2011 12:38:16.913 zone inline.aa/IN/internal (signed): next key event: 11-Nov-2011 13:38:16.913 A second (futile) reload: $ rndc reload inline.aa zone reload up-to-date $ echo $? 0 Regards, -JP ___ 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: OT: Bind 9.9.0B1 Inline-Signing Question
I have just one question, what should inline-zone admin do? I assume that named automatically regenerates removes expired RRSIGs so is it sufficient to put new KSK and ZSK to the key-directory when needed and revoke older ones? Thanks for your answer in advance. Yes, it will keep RRSIGs refreshed (same as it does now with dynamic zones). Rolling keys is the same process as now; you generate a successor key (dnssec-keygen -S) and run rndc loadkeys zone to signal the server that there's a new key. I should mention that there is a known operational issue in the current version of inline-signing that you should be cautious about. If you're using inline-signing with a master zone, and you make changes to the zone file, you should *not* kill and restart your server to load the new file. Instead, use rndc reload or kill -HUP pid to force named to reload the zone while it's running. That way, named will be able to compare the former version against the new one, and generate the proper set of diffs to apply to the signed zone. If you kill and restart your server to load changes to your zone, then the signed version of the zone will fall out of sync with the raw version, and some of your data will not be accessible to queries. There's no way to recover from this condition except to delete the signed zone and start over, which generates big transfers to slaves and is generally undesirable. We'll have a fix for this in a future release. It's not a problem when using inline-signing on slave zones; slaves load their data via zone transfer, not from files, so this issue doesn't affect them at all. -- 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
OT: Bind 9.9.0B1 Inline-Signing Question
I know that this isn't the forum for betas, which is why I put off-topic on the subject line. We are trying to implement DNSSEC for our static zones. While the dynamic signing has been automated, static inline-signing isn't available until Bind 9.9 We have been testing with the alphas and now with the beta. What we are seeing is that whenever named starts, it initially creates the signed static zone file, but never really finishes. The logging shows: 10-Nov-2011 14:38:14.766 general: error: zone xx.org/IN (signed): not loaded due to errors. 10-Nov-2011 14:38:14.766 general: info: zone localhost/IN: loaded serial 42 10-Nov-2011 14:38:14.767 general: notice: all zones loaded 10-Nov-2011 14:38:14.768 general: notice: running 10-Nov-2011 14:38:14.768 general: info: zone xx.org/IN (signed): loaded serial 200905 10-Nov-2011 14:38:14.768 notify: info: zone xx.org/IN /IN (signed): sending notifies (serial 200905) So, it doesn't load the zone due to errors, but then later claims to load the same zone file. Has anyone been able to get the inline-signing function to work? I've triple-checked my named.conf, ran named-checkzone, went to a vanilla zone file, and even tested the zone file as dynamic (which worked). Any ideas or suggestions of where to check next are greatly appreciated. Thanks, -Kevin Kevin McConville University at Albany ___ 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: OT: Bind 9.9.0B1 Inline-Signing Question
Do you see that each time named starts or just on the first load of the zone? What happens if you send a query to the server with dig +dnssec? On Nov 10, 2011, at 14:23, McConville, Kevin kmcconvi...@albany.edu wrote: I know that this isn’t the forum for betas, which is why I put off-topic on the subject line. We are trying to implement DNSSEC for our static zones. While the dynamic signing has been automated, static inline-signing isn’t available until Bind 9.9 We have been testing with the alphas and now with the beta. What we are seeing is that whenever named starts, it initially creates the signed static zone file, but never really finishes. The logging shows: 10-Nov-2011 14:38:14.766 general: error: zone xx.org/IN (signed): not loaded due to errors. 10-Nov-2011 14:38:14.766 general: info: zone localhost/IN: loaded serial 42 10-Nov-2011 14:38:14.767 general: notice: all zones loaded 10-Nov-2011 14:38:14.768 general: notice: running 10-Nov-2011 14:38:14.768 general: info: zone xx.org/IN (signed): loaded serial 200905 10-Nov-2011 14:38:14.768 notify: info: zone xx.org/IN /IN (signed): sending notifies (serial 200905) So, it doesn’t load the zone due to errors, but then later claims to load the same zone file. Has anyone been able to get the inline-signing function to work? I’ve triple-checked my named.conf, ran named-checkzone, went to a vanilla zone file, and even tested the zone file as dynamic (which worked). Any ideas or suggestions of where to check next are greatly appreciated. Thanks, -Kevin Kevin McConville University at Albany ___ 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 ___ 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: OT: Bind 9.9.0B1 Inline-Signing Question
I know that this isn't the forum for betas Sure it is. :) We have been testing with the alphas and now with the beta. What we are seeing is that whenever named starts, it initially creates the signed static zone file, but never really finishes. What do you mean by never really finishes? What are the options that are set for the static zone? You should have these: auto-dnssec maintain; inline-signing yes; key-directory dir; ...with dir set to the location of the DNSSEC signing keys for your zone, including at least one KSK and one ZSK, both of which are set to be published and active. 10-Nov-2011 14:38:14.766 general: error: zone xx.org/IN (signed): not loaded due to errors. [...] 10-Nov-2011 14:38:14.768 general: info: zone xx.org/IN (signed): loaded serial 200905 There are two versions of the x.org zone. One is the unsigned (or raw) version, which holds the data loaded from your master file. The other is the signed version, which contains a copy of the raw version *plus* all the DNSSEC data; this is the one that answers queries. If you configure zone xx.org to use the masterfile xx.db, then the unsigned version of the zone is loaded from that file. The signed version of the zone will be loaded from xx.org.signed.. The error referred to in the first log message above is probably that xx.org.signed doesn't exist. Since there's no masterfile to load the signed version of the zone from, named will go about creating one for you. So the error being logged isn't really an error, it just looks like one; we should probably see about silencing it. At this point, named walks through the unsigned version of the zone, adds RRSIG and NSEC records, and generates a delta which is then applied to the signed version of the zone. After that, the signed version of the zone is fully populated and ready to answer queries. You should then be able to run dig +dnssec @localhost xx.org dnskey and see your signing keys and their signatures. (If you don't, I'd check to make sure your keys are in the right place, accessible to named, and published and active.) The next time you start your server up, the not loaded due to errors message should have gone away. (If it hasn't, then something may have prevented the signed zone's masterfile from being created properly, and I would check directory permissions.) When you modify your static zone file and run 'rndc reload', named will detect the changes that you've made via the same mechanism as ixfr-from-differences, generate signatures for the new records, and add those to the signed version of the zone automatically. -- 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
