Auto signing & ARM

[Tony Finch]

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...

Tony.
--
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/

On 20 Sep 2010, at 20:28, "Timothe Litt" <litt at acm.org> wrote:

> I'm trying to get named and my management tool cooperating
> with named on DNSSEC key management.
> 
> I'm seeing behavior with auto-signing that doesn't strictly 
> match the ARM and would like to know what's correct.  I'm
> also not clear on what named expects for some cases.
> 
> 4 questions after a little context:
> 
> 9.7.1-P2
> 
> 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 for the new keys
> so that named can find them. You can then ***add the new DNSKEY RRs via
> dynamic update***. named
> will then cause the zone to be signed with the new keys. When the signing is
> complete the private type
> records will be updated so that the last octet is non zero."
> 
> 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.
> 
> 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.
> 
> 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?  
> 
> 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?  
> 
> 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?
> 
> ---------------------------------------------------------
> This communication may not represent my employer's views,
> if any, on the matters discussed. 
> 
> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users