Auto signing & ARM

Phil Mayers p.mayers at imperial.ac.uk
Sat Oct 2 09:21:06 UTC 2010


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.



More information about the bind-users mailing list