Geoff Huston wrote:
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?
I think it should be RRset, but for the vast majority of cases, there
will only be one RR per RRset (thinking realistically).
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
Agree also - I can't think of the harm in using SHA-1. It isn't really
needed for security of the key material, and the hash size is smaller
and easier to manually enter (if necessary).
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 start up of system, or of the validator?
As for the text on rollover mechanisms: I don't think there will be a
choice for the majority of end systems.
Once the validator is written, it will most likely depend on the
implementors of the validator, and be very difficult for an end user to
change. Manual operation may be the only other alternative to whatever
in-band or out of band the validator implementation is built around.
And most will not care - once one way is chosen, it will probably be
used unless something forces a change.
Scott
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
