On Mon, 3 Dec 2007, Peter Koch wrote:
> There is a request to adopt <draft-larson-dnsop-trust-anchor-02.txt>
> "DNSSEC Trust Anchor Configuration and Maintenance" as a DNSOP WG item.
> The topic is covered by our charter.
This document RECOMMENDS that a trust anchor be specified as a DS RR.
[...]
Using a DS RR is also recommended because it is smaller than the
DNSKEY RR and is easier to enter manually, either by typing or
cutting and pasting.
I do agree with this, since multiple copy and paste with spaces in the DNSKEY
record, is a real pain. I'm doing these things now between BIND, ldns,
dnssec-tools and firefox plugins, and I frequently break things.
3. Verify that the DNSKEY RR corresponding to the configured DS RR
(i.e., the DNSKEY whose hash appears in the DS record) appears in
the DNSKEY RRSet and that the DNSKEY RR has the Zone Key Flag
(DNSKEY RDATA bit 7) set.
I had to re-read RFC4034 to make that this did not mistakenly mean "zone
signing key". Perhaps it can be slightly rephrased to avoid confusion
between "zone key flag" and "zone signing key"?
One problem I can see is that DS records live at the parent of the
zone, while in this use, one needs the DS record specifying the current
zone. This might be confusing.
This might also be confusing if one wants to load DLV keys. Do we then
need to use a DLV record or a DS record?
As for whether this should be a consideration at all for the working
group, I am unsure. It seems a non-ietf, software vendor issue, but on
the other hand, using one format between the 4 pieces of software I now
use that requires this information, would be a bonus.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
