I have a few comments about draft-wkumari-dnsop-trust-management-00.
(I hope I'm not repeating something already commented on)
- I think the body (not appendix) of the draft should discuss what the
TA maintainer is supposed to do. In its current document
organization the main sections of the draft only define a new RR
type (TDS) and the expected behavior of recursive servers (with a
very brief sentence about the maintainer in the first paragraph of
Section 2.1). These don't address (one of) the main motivation
described in Section 1:
During the recent effort to roll the IANA DNSSEC "root key", it has
become clear that, in order to predict (and minimize) outages caused
by rolling the key, one needs to know who does not have the new key.
More specifically, I think a generalized version of the following
part of Appendix B should be included in the main part of the draft:
[...] The trust anchor maintainer
will observe resolvers change from quering for 17 to querying for
_17-42. [...]
- Likewise, I suggest a main section states more clearly that a TDS
RRset consists of RRs for all currently published (key-signing)
DNSKEYs. It's currently only described through an example in
Appendix B:
_17 IN TDS 17 5 1 111222
IN TDS 42 8 2 333444
- I also think it should explain more explicitly how the approach
using TDS could address this point:
In addition, RFC5011 style key rolls require "double signing", which
significantly increases the size of the responses.
- On Section 3:
[...] It will receive back either an error
(e.g NoError / NoData), or a TDS RRSet.
In the case of error, isn't it more likely to be NXDOMAIN?
Likewise,
2. There is no TDS record (you get NoError / NoData). You have
I suspect this will also more likely to be NXDOMAIN.
- Slightly related to the previous point, the owner name of a TDS
RRset cannot be on a zone cut (right?). In the case of the root
zone, is it guaranteed by an ICANN restriction or something? What
about other TLDs such as .com? (We wouldn't need TDS for .com if
the root employs it, though). For other general cases it's probably
up to the maintainer's decision (either reserve this set of names or
give up using TDS), but it may be useful to note this point
explicitly.
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
