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
