Subject: [dnsext] draft-wijngaards-dnsext-trust-history-02

From: Alfred Hönes <[email-masked]>
Date: Tue, 24 Mar 2009 20:30:09 +0100 (MEZ)

Hello again,
I have studied the new version of your
"DNSSEC Trust Anchor History Service" proposal,
    draft-wijngaards-dnsext-trust-history-02,
and would like to submit a few comments.

First of all, the simplification achieved is astonishing and
convincing at once!  In fact, without any protocol additions,
the new proposal could be ready for use immediately.

However, I have a multi-faced proposal for making the structure
of history zones a bit more regular and intuitive.  The use of
two PTR RRs at the zone apex with the awkward collation boundary
condition seems to be unfortunate and sub-optimally structured.

I suggest to use two reserved labels for the 'head' and 'tail'
pointers of the history list, for instance, in the example
in Section 4:

   $ORIGIN tuhi.example.com.
|  @ PTR h0
|  @ PTR h2
---
   $ORIGIN tuhi.example.com.
|  _adam_  PTR h0             ; pointer to most ancient data set
|  _curr_  PTR h2             ; pointer to most recent data set

The labels used here are only examples; any other reasonably
mnemonical labels not colliding with commonly used DNS labels
will do, but they should be specified.

In your proposal, the numbering scheme ("h%d") for the list entries
needs to be monotonically increasing solely for the purpose of
distinguishing the two "anchors" in a common RRset and has no
additional semantics; otherwise, it is only guiding a human reader
of the zone data.  With the distinct anchors, the former reason no
more pertains; using short labels of limited and equal length might
then be of benefit as well.

Indeed, with the reserved "anchor" labels, it would become possible
to use "serial number arithmetics" of a finite length, for instance
(if it is intended to allow up to 999 entries) by using 3-digit
values (including leading zeros) for "%d"; one single 'gap' is left
unused in stable conditions, but can be used to reduce the need for
a specific order of the dynamic update operations.
The assignment procedure to obtain a "new number" would be
instantiated in this case to: "increment the number found in the
_curr_ PTR target, modulo 1000".
The actual number of digits used could be a deployment decision
(per trust history zone).

The wraparound would not make any problems due to the fact that
the two "anchors" are distinguished by their name and no more
by content (within a single RRset).

Here are a few editorials I have observed.

(1)  Section 1, 1st para:  s/of/or/

   DNSSEC [RFC4034] validators that have been offline of have missed ...
---                                                    v
   DNSSEC [RFC4034] validators that have been offline or have missed ...

(2)  Section 3, 2nd para

The darft says:

   Copy the newly polled DNSKEY RRset and RRSIGs, change the owner name
|  to "h%d.example" or similar.  With %d a new number, and .example the
|  history location.  Publish the new RRset.  Publish PTR records that
   link list elements.  Update PTR records for the list start and end.

The 2nd sentence apparently is incomplete.  How about this update:

   Copy the newly polled DNSKEY RRset and RRSIGs, change the owner name
|  to "h%d.example" or similar, with "%d" replaced by a new number, and
|  ".example" replaced by the history location.  Publish the new RRset.
   Publish PTR records that link list elements.  Update PTR records for
   the list start and end.

(3)  Section 3, 3rd para

Please insert the missing articles, and adjust the punctuation:

   The list is a double linked list, because this empowers low memory
   hosts to perform consistency checks.  Thus if there is x.example PTR
|  y.example then there MUST be y.example PTR x.example.  Except at
|  start and end of list.
---
   The list is a double linked list, because this empowers low memory
   hosts to perform consistency checks.  Thus if there is x.example PTR
|  y.example then there MUST be y.example PTR x.example, except at the
|  start and end of the list.
                   ^^^^^                               ^^^        ^^^^

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 25 Mar 2009 10:58:14 +0100

Hi Alfred,

> the new proposal could be ready for use immediately.

Thank you, I tried to make it very short and easy.  In fact, since the
zone operator cooperation is not required (no special delays or REVOKE),
it can be used on any signed zone right away.

> pointers of the history list, for instance, in the example

Great idea. _tuhihead and _tuhitail are good I think.

> then be of benefit as well.
...
> by content (within a single RRset).

Perhaps, I had better note that the storage names can be chosen by the
provider at will.  So that "h%d" becomes a suggestion.  And providers
can use dates or a rolling modulo 3-digit number if they want to.
Because this keeps the draft short, long ones make the sleepy dnsext
group snore more :-)

Best regards,
   Wouter