> Evan: I'd like to ask for clarification. My understanding is that > "inline-signing yes:" is necessary to cause bind to keep separate signed > and unsigned zone files, and that the source of the unsigned zone file > can be a disk file in the case of a master, or a zone transfer in the > case of a slave.
Correct. > I further understand that "update-policy local;" is > necessary to allow the use of nsupdate on the local machine to operate on > the applicable master zone. Therefore if you want to use nsupdate locally > and have separate signed and unsigned master zone files, you need both of > the above statements in the zone configuration. Would you please comment > on any misunderstanding on my part about this. Correct, but... let me start by explaining the situation in releases prior to 9.9, without the inline-signing feature. When you turn on DDNS (whether it's via update-policy local, some other update-policy, or the allow-update ACL), the contents of the zone can be modified by named. Changes to the zone are written to a journal file, and then periodically synced to the master file. This process obliterates the master file you originally provided, removing any comments you may have had, and reordering the records; should you wish to edit the zone file directly, it's necessary to 'freeze' and 'thaw' the zone. For some operators, this is undesirable: they're accustomed to maintaining zone files by hand, or having them generated by provisioning tools, and they run 'rndc reload' or kill and restart their servers when there are changes to be picked up. They only want to use DDNS if they have an specific need for it, such as a DHCP pool; the rest of the time they prefer to keep it simple. Turning on DDNS, however, will enable a zone to keep itself signed. If named has access to the private signing keys for the zone, it will detect and replace expiring RRSIGs. If you use 'auto-dnssec maintain', it can also keep your DNSKEYs up to date, rolling on schedule and such. This only works if you have DDNS turned on; otherwise, named isn't allowed to modify the zone contents. So, in 9.7 and 9.8, the easiest way to maintain a DNSSEC-signed zone is to turn on DDNS. In my own domains, I simply don't bother editing zone files anymore; I use nsupdate for everything. But, for the reasons above, some operators dislike that approach. Now in 9.9, we have the ability to separate the signed and unsigned data internally within named. If you want to do things the old- fashioned way--edit and reload when necessary, with named never overwriting your zone file--but you still want to use DNSSEC, then you turn on inline-signing. The assorted RRSIG and DNSKEY changes are synced to the "signed" zonefile, not to the original master file, and there's no more need to worry about freezing and thawing. Now, you can *also* turn on DDNS and use nsupdate on an inline-signing zone... but, if you're going to be using DDNS anyway, then I'm unclear what operational need is being served by separating the data. With or without inline-singing, your master file will be overwritten, and you'll have to concern yourself with freezing and thawing... and *with* inline-signing, there are more moving parts. So, I'd probably just use DDNS, turn off inline-signing, and let the zone take care of itself. (Mind you, I'm grateful that you've been beta-testing this scenario, I just don't think I'd be likely to run in that way in production myself.) > By the way, I think there is a typo on page 99 of Bv9ARM.pdf: For > "inline-signing inline-signing", read "inline-signing". Thank you, fixed now. -- 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