Subject: [DNSOP] comments about draft-wkumari-dnsop-trust-management-00

From: 神明達哉 <[email-masked]>
Date: Tue, 14 Jul 2015 11:38:19 -0700

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