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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
