[Opendnssec-develop] interface between enforcer and signer
Rick van Rein
rick at openfortress.nl
Tue Feb 24 11:13:27 UTC 2009
> John, Jelte and myself now has a proposal ready for the interface
> between the enforcer and signer.
I've had a look. Thanks for creating these docs, they look good.
Can you indicate _between_ which components these formats are sent,
instead of just _to_ which one it is sent?
Perhaps rename <resign/> to <re-sign/> as people tend to do in
plain English to avoid confusion?
It is not clear yet what PT2H means, and how it differs from 2H.
Similarly for P3D, P7D, P14D, PT12H, PT300S. Do I read from the
<signatures/> element that SOA parameters are decided upon by
In the <keystore/> you refer to <flags/> and <protocol/> and
<algorithm/> values by numbers. These clearly depend on some
external register of definitions. Please make clear where these
are defined, so software builders know where to look. It is always
good to define what happens in case an unknown bit is encountered.
There's double information in this setup:
1. <ksk/> versus <zsk/>
2. <flags/> bit 0
What rules dictate consistency, what happens if there is a failure,
and is it the best course of action to have such double specs?
As for the timing constants, what relationships do they have, and
is it possible to trick the system into, say, a dropped domain if
it gets confused with contradicting information?
If I recall well (but I am not 100% sure) the <opt-out/> allowed
for partial opt-outs in the zone list. I am not convinced this
would be practically usable to have part of a zone opted in and
part of it opted out. If it could be useful, this interface
description should _consider_ taking it into account. (This is
a weak point, just trying to provoke thought.) For subdomains
an opt-out may be really useful, say for dyn.harderwijk.edu
which would hold the DHCP-assigned IPs within this University.
I would not be surprised if we'll need <timestamp/> for more than
one thing; perhaps adding a parameter could help. Just a thought.
It would certainly give a somewhat stronger suggestion as to its
> also a draft of the KASP XML format in:
Similar remarks to the ones above:
- time prefixed P and PT
- <ksk/> and <zsk/>
- <alogrihtm/> should be linked to its spot of definition
- <opt-out/> maybe over partial domains?
<overlap/> -> what does that mean?
<length/> -> perhaps rename it to <bits/> or <bitlength/>
<rfc5011/> -> I think it is generally good to distinguish between
generating and accepting this standard, as it is somewhat
controversial material and may be replaced with an alternative
some day. But the only utility of RFC 5011 in this spec would
be generating, right?
I hope these remarks / questions are helpful.
More information about the Opendnssec-develop