I have reviewed the trust-anchor document, and have some comments. I am not sure if this issue has been up for discussion.
The following statement is in section 2: "Specifying a trust anchor using a DS format instead of a DNSKEY format offers an advantage because it forces the resolver to make a DNS query to obtain the trust anchor's complete DNSKEY RRSet during a priming operation (described below). If only a DNSKEY record were specified, resolver implementers could conceivably avoid priming the trust anchor. But priming is desirable because it causes the resolver to retrieve an up-to-date version of a zone's DNSKEY RRSet from one of the zone's authoritative servers. It should be noted that in practice, priming is frequently required, when the data in the trust anchor zone is signed with a different key than the one configured as the trust anchor." I fail to see how priming is the solution to up-to-date keys, either you trust the key or not. It's the signatures over the DNSKEY RRSet that forces the resolver to prime the DNSKEY for the zone, if there is missing keys. So the priming using the DS is a non-issue here. and also this: "Using a DS format is also recommended because it is smaller than the DNSKEY format and is easier to compare manually, either by typing or cutting and pasting." This seems to be the major reason for wishing to use the DS as a trust-anchor for a resolver. But I don't believe that this is not a good enough reason for avoiding the use of DNSKEY as a trust-anchor. In the case of using the Root or TLD trust-anchors, in most cases you also have to verify the key by other means, for example cryptographic signatures. These are also not easy to read, so you still need tools, copy&paste or file transfers to verify the key. The "easier to compare" argument fails me here. Using DS as the forced trust-anchor mechanism adds a lot more complexity to this document, for example the whole of section 3, and to be fair, I cannot really see the advantage. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
