Re: Auto signing ARM
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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Auto signing ARM
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 d...@dotat.at http://dotat.at/
On 20 Sep 2010, at 20:28, Timothe Litt l...@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Auto signing ARM
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
