Bind 9.9.0b2 inline signing...

[Evan Hunt]

> 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 -- each at isc.org
Internet Systems Consortium, Inc.