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 <[email protected]> http://dotat.at/ On 20 Sep 2010, at 20:28, "Timothe Litt" <[email protected]> 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 > [email protected] > https://lists.isc.org/mailman/listinfo/bind-users _______________________________________________ bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
