http://www.ietf.org/internet-drafts/draft-larson-dnsop-trust-anchor-00.txt

What is a trust anchor? Is it a domain name or is it a specific key at a domain name? The question comes up when you mention that it should be a DR RR. Or should that be an RR set?

The wording in section 2 is very confusing. Is a trust anchor as DS RR or a DNSKEY RR? Or, as Ed points out, is it the RR set? The document appears to say "both", but then proceeds as if it had said "DS RR".

The comment about truncation appears to be a martian, in that truncation is neither defined nor referenced here and the reader is left somewhat confused as to what is meant here.


This line is out of context: "DS RRs using SHA-1 (DS digest type 1) are NOT RECOMMENDED." When talking about the format, don't dive into contents as such "don't use" recommendations will change (grow) over time.

agreed


I don't know if priming, as described in section 3, is best done at start up, but rather "on demand." As sparse as the DNSSEC portion of DNS will be, I bet a DNSSEC-intense resolver will have a trust anchor list a kilometer long.


On demand (or upon use) would be more logical in this context. Also I note that somehow the document has changed gear and now we are talking about DS RRs as trust anchors. What happened to DNSKEY RRs?



The TBD at the end of section 3: I don't know that any document ought to prescribe any actions (such as log errors) when inconsistencies are found. That is a matter left to the implementations. The document should explain the inconsistencies, but not dictate a reaction. Local policy is still the trump card.

I also would've thought that where inconsistencies are found between the DS and DNSKEY values are found then they should not longer be considered as viable trust anchors.

The discussion on trusted update mechanism should be pulled. Mentioning trademark names and products is probably not worth the trouble. Also, what is being said is that "there are a number of non-interoperable ways to do this that are in use, they can be used." As we are all about interoperability, what's the point? This is akin to there being only a definition for AXFR when we know there are many implementation specific zone transfer mechanisms out there - we don't have a document that lists them.


I had a similar reaction to all but DNSSEC in-band Update.

As far as the in-band mechanism:

"This protocol is capable of keeping trust anchors up to date indefinitely if the trust anchor zone's operator follows the proper procedures" and the minor protocol change is made. The text isn't clear on whether the minor change is "in effect" or something that has to yet happen.

Surely all this could be better phrased as an applicability note for the DNSSEC In-Band Update specification?

Or is the point of this document the algorithm described in section 2?

regards,

  Geoff



_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Reply via email to