On secure DNS update and NXT

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Reading draft-ietf-dnsop-keyhand-00.txt, it is my pleasure to see
people working on DNSSEC finally understand DNS issues.

That is, it seems to be the time to revive:

> INTERNET DRAFT                                                   M. Ohta
> draft-ohta-simple-dns-01.txt               Tokyo Institute of Technology
>                                                            November 1994

>                         Simple Secure DNS

Incorporation of some (all is better if you want to remove all the
complex tricks to implement and operate DNSSEC, but I'm so humble)
of it should not be too late.

On the dynamic update issue, it said:

   In
   cases where frequent and/or automatic update of a zone is desired, it
   is necessary to make signature generation mechanism of the zone
   accessible on-line.  Still, it is worthwhile to keep the secret
   information and secure time stamping mechanism of the zone off-line.
   To make it easier, the protocol is designed to let signed information
   have the consistent format about time stamping and signature
   generation.  Then, after the security of the signature generation
   mechanism is restored, signatures using the same secret information
   become reliable again.

In 1994 in DNSSEC WG, the need on frequent update was not
recognized very well.

On the NXT issue, it said:

   ZL (Zone List)

      data used to store sorted list of all the nodes in a zone.  The
      information is necessary for protection against denial of service
      attacks, that is, if a node does not appear in certain ZLs, a
      negative response that a queried node does not exist is
      authenticated.  The simplest way to authenticate negative answer
      that some data does not exist is to have an authenticated list of
      all the existing data.  But, unless the number of existing data is
      expected to be small, as in the case with [RRD], listing up is
      inefficient.  Especially, for a very large zone such as "com.",
      the size of the list is impractically large.  So, existing data
      are sorted in a certain order and segmented appropriately into
      multiple ZL records.  To authenticate the non-existence of a node,
      only a ZL RR containing the node (according to the sorting order)
      needs to be returned.  To not to cause UDP size overflow, ZL RRs
      are intended to be returned as a partial RR in the additional
      section of a negative answer with truncation bit set.  To
      authenticate a partial ZL RR, it is necessary to attach
      authentication signatures to individual ZL RRs.  With wildcarding,
      actual authentication is a little more complicated and is
      discussed in section 5.3: "Resolver Algorithm".

      ZL will have the following syntax.

            <zone> [ZL] <nttl> <first> <last> <n> <domain name #1> ...
                        <domain name #n> <timestamp> <expire>
                        <signature>

      where [ZL] is the RR name of ZL data, <nttl> is the number of
      seconds appropriate for negative caching, <n> is the number of
      domains covered by the record.  The record contains all the domain
      names of the zone (including the top level nodes of child zones
      but excluding the zone name itself) after (or including) <first>
      and before <last> sorted with dictionary order.  Cases of
      characters in <first>, <last> <domain name #1>... must be
      canonicalized to lower cases.  <first> and <last> is merely a
      separator and should not be interpreted that such a node exists
      unless explicitly listed as <domain name #1>.  Comparison is
      performed first label by label.  Top level labels are compared
      first and the leaf labels are compared last, which makes domain
      name compression work quite well.  Within labels, comparison are
      by dictionary oder, that is, first bytes are compared first.  For
      example, "a.b.c.", "a.c.b.", "a.c.", "ab.c.", "ac.b." and "c." are
      ordered as "ac.b.", "a.c.b.", "c.", "a.c.", "ab.c." and "a.b.c.".

      Thus, the name of the zone is ordered before all the other names
      in the domain.  For the comparison purpose, when the name of the
      zone itself appears as <last>, it is considered to be ordered
      after all the other names in the domain.  For example,

            <zone> [ZL] <nttl> <zone> <zone> 0 <timestamp> <expire>
                        <signature>

      represents a zone consisting of only a single node.

      <nttl> and <n> are two byte integers.  <first>, <last>, <domain
      name #1>, ..., <domain name #n> have the syntax of domain names.

      To make an authenticated response of non existent node resides
      within 512 byte UDP packet, it is recommeded that the length of a
      single [ZL] record be shorter than 400 bytes, after limited domain
      name compression (those information available within the record
      itself only, may be shared for compression).

      <timestamp>, <expire> and <signature> are the same as that of
      [NSIG] except that the signature covers the byte stream of the
      sequence of <timestamp> <expire> <nttl> <first> <last> <n> <domain
      name #1> ...  <domain name #n> contained in the [ZL] record
      itself.

In short, ZL is data belongs to the parent zone to authenticate
the non existence of a node.

							Masataka Ohta