On 10/01/2010 09:59 PM, Tony Finch wrote:
I haven't seen any answers to Timothe's questions below, though I
have been keeping an eye out for them. The documentation in this area
is a bit thin...
A few comments based on what I've observed.
Consider this configuration snippet:
View "internal" in { key-directory "/..." ... } zone
"xx.example.net" in { auto-dnssec maintain; type master; file ...
allow-transfer ... update policy { grant ... } }
I run (This is a test, /dev/urandom isn't used in real life)
dnssec-keygen -q -a NSEC3RSASHA1 -b 1024 -P now -A +3mo -r
/dev/urandom -K /... xx.example.net.
I get a Kxx.example.net+... file with all the right permissions.
Now, according to the ARM:
"4.9.5 DNSKEY rollovers via UPDATE It is possible to perform key
rollovers via dynamic update. You need to add the K* files ...
But: if I DON'T add the keys by dynamic update, but instead issue
an rndc sign xx.example.net in internal
The new key shows up in the zone. As expected, nothing is signed.
So, it seems that it is NOT necessary to insert the DNSKEY RRs via
dynamic update. Either dynamic update or rndc wakes up named and
causes a scan of the keys directory.
Note the "it is possible to".
In bind 9.6, you could only perform a key rollover by inserting the
DNSKEY via dynamic update. The process was a bit awkward for ZSK rollover:
1. Generate the new key
2. Insert the public DNSKEY via DDNS; do NOT add the private key to
the key-directory
3. Wait the required time for the old DNSKEY to be flushed from caches
4. In quick succession:
* add the new private key to key-directory
* remove the old private key from key-directory
5. Wait until bind has incrementally resigned the zone, plus cache
expiry time
6. Use DDNS to remove the old key
Note, no "rndc reload" is required; bind checks for the private key for
each DNSKEY it has on each signing batch.
Bind 9.7 essentially adds two things:
1. Key lifetime data to the private key files
2. An "rndc sign" command, for doing the initial signing
1) Before I decide whether to rely on it, is this a bug or a
feature? Dynamic update is a bit less work - but avoids having the
control channel open beyond the local host. So there are
trade-offs.
Personally, I think the key lifetime stuff in bind 9.7 is far superior
to using DDNS of DNSKEY.
In the same area of the ARM, the 5011 section seems to be a good
way to let the slave servers learn about key changes. The section
talks about dnssec-signzone -S as the way to trigger distribution.
2) I would expect that a key to a "dnssec-auto maintain" zone via
the dynamic update/rndc sign route would also satisfy the 5011
requirements. Is that correct?
I don't follow I'm afraid.
Slave servers don't need/have the keys; they can't sign the zone, and
don't verify it either because they're authoritative.
3) If dnssec-revoke or dnssec-settime are invoked, I assume that
rndc sign would trigger publication. If one would rather do
everything with dynamic update, what's the simplest transaction
that will trigger Re-scanning the changed key? Do I have to read
the key file& insert the key?
Well, the dynamic update to add/remove a DNSKEY will happen instantly.
Bind will not sign with it until it a) does a scheduled incremental
resign and b) sees the private key in the key-directory.
Note that bind will NOT stop you removing the final DNSKEY from the
zone, or stop you removing the ZSK leaving only the KSK.
In bind 9.7 at least, bind seems to be smart enough to defer removal of
the DNSKEY until any corresponding signatures have been removed, IIRC.
What this means is:
* if you accidentially remove the ZSK, there will be a CPU spike as
the KSK is used to resign the zone, and then the ZSK will be removed.
You stand a reasonable chance of this causing you problems of course -
cached RRSIG records without the corresponding DNSKEY cached will fail
to validate until their TTL expires
* if you accidentally remove the KSK, obviously it will all blow up.
That leaves the DS records for internally delegated zones. As
best I can tell, I still need to find the parent zone and insert
them via dynamic update. But: in the case where the parent zone is
served by the same view in the same server, named has everything it
needs to autogenerate DS record(s) when a DNSKEY is published and
install it in the parent. Well, maybe which hash type(s) are
desired, but that would be easy to put in a .conf file...
4) Shouldn't named handle this?
Perhaps, perhaps not. It does not thought.
_______________________________________________
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
