draft-ietf-dnsext-not-existing-rr-01.txt

bind-3.2.

   Also, to prove there are no wildcard records for baz.example.org.,
   NO records for possible wildcard expansions are returned.  A client
   should similarily calculate hash values of possible wildcards and
   compare them to the authority section.

   Of course, if the zone was generated with the more advanced NO
   creating entity, only the NO record from the previous section would
   have to be returned.

3.13.5 Resolver Query for Non-existing Type At Existing Domain

   Consider a client looking up TXT records for the existing domain
   "www.example.org.", again, using the same zone file as previous.  A
   server would reply with an authority section like the following:

   839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org.
   		IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f
   839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org. IN SIG NO

   The resolver verifies the signature and make sure
   SHA-1("bar.example.org.") hashes correctly.













Josefsson                 Expires May 25, 2001                 [Page 12]

Internet-Draft               The NO Record                 November 2000


4. Comparing NO and NXT

   To ease comparison between NXT and NO records, this section
   summarize (mis-)features of the NXT and the NO record formats. The
   intent here is to address all operational differences between NO and
   NXT records.

4.1 Denial Of Existence Of Non-Existing Names

   Both NXT and NO provide strong data non-existance for non-existing
   names.

   NXT records authenticate data non-existance up to the probability of
   finding a collision in the signature algorithm (1 in 2^64 for
   RSA/MD5).  NO records authenticate data non-existance up to the
   probability of finding a collision in the signature algorithm (1 in
   2^64 for RSA/MD5) and the NO record hash value (varies due to
   truncation).  If the RSA/MD5 scheme is used, hash values in NO
   records may be truncated to 64 bits.

4.2 Denial Of Types Of Existing Names

   Both NXT and NO provide strong data non-existance of types for
   existing names.  The previous discussion also apply here.

4.3 Information disclosure (chain problem)

   NXT records make it possible to collect all names (and records) in a
   zone.  NO records prohibit this.

4.4 Delegation problem

   NXT records require a special case where two different RRsets exist
   at the same owner name, class and type.  NO records does not have
   this problem.

4.5 Zone size (Bytes)

   The size difference is due to changing complete domain names with
   hash values (SHA1 20 bytes).  Without truncation, NO records are
   probably larger than most NXT records.  With truncation, NO records
   uses a few byte per hash value instead of the (possibly compressed)
   complete owner name.

4.6 Zone size (Number Of Records)

   When NO compression is not used, NXT and NO uses the same number of
   records.



Josefsson                 Expires May 25, 2001                 [Page 13]

Internet-Draft               The NO Record                 November 2000


   However, NO compression can greatly reduce the number of records. 
   As an example, considering a zone with records of 100.000 different
   names.  NXT uses 200.000 records (NXT+SIG). Using NO compression
   with 10 hash values on each reduce this number to 20.000 records
   (NO+SIG).

4.7 Zone size (Number Of Owner names)

   NO uses twice the amount of owner names as NXT.

   However, NO compression can be used to reduce this to a fraction of
   the normal amount.  From the previous example with 10 hash values
   per NO record, it will uses 10.000 additional owner names in a zone
   with 100.000 names

4.8 SIG Labels field and Wildcard records

   It is marginally faster to verify signatures for NXT records when
   wildcard records are involved -- the SIG "Label fields" hints can be
   used to determine the canonical name. With NO records this hint
   cannot be used, because it relies on knowing the full name whereas
   only the hash is available. One need to try a few SHA1 hashes to
   find the correct canonical name.  The number of hashes required to
   try depend on the number of labels in the name, and scale linearly.

   N.B.  This penalty only apply to wildcard records.

4.9 Dynamic Updates

   Resigning dynamically updated records is required both with NXT and
   NO records.

   However, when NO truncation and compression is used, the additional
   penalty of re-hashing might also be required.

















Josefsson                 Expires May 25, 2001                 [Page 14]

Internet-Draft               The NO Record                 November 2000


5. Security Considerations

   Chaining through all NO records is still technically possible,
   altough it cannot be used to collect names and/or records in the
   zone (other than NO records themself).

   The security of NO record hash values is dependent on the security
   of the SHA-1 hash functions used.  Truncation may affect this, but
   the birthday-paradox argument does not apply. One must find a hash
   collision given an existing hash value -- not simply find any hash
   collision.  It is thus reasonably to truncate NO records to half the
   hash length used in the signature scheme (this would mean 64 bits in
   the RSA/MD5 case).

   It should be pointed out that given this scheme, it is easy to
   estimate the number of records within a zone, considering hash
   values are supposed to be equally distributed.  This can be foiled
   by adding any number of bogus records in the zone.

   The authentication of NO records is provided by DNS SIG records, as
   specified in RFC 2535. The security considerations of RFC 2535 is
   not affected by this document, and should also be considered.

6. IANA Considerations

   The NO RR type number should be selected by the IANA from the normal
   RR type space.

   The meaning of a zero hash length value can only be assigned by a
   standards action.

Acknowledgement

   The idea of encrypting names, that later evolved into just hashing
   them, was originally proposed by Jonas Holmerin in private
   discussions about DNS Security.  Magnus Nystr鱩 proposed truncating
   the hash values.

   Thanks to John Linn and Magnus Nystr鱩 for comments on a early
   version of this draft.

   Olafur Gudmundsson pointed out delegation point issues, suggested
   the use of a "_no" subdomain, and suggested replacing the type bit
   map field with a sorted list.  From the namedroppers mailing list,
   I'd like to thank Alan Barrett, Andrew Draper, Andreas Gustafsson,
   Peter Koch and Brian Wellington for comments and suggestions.  Ed
   Lewis noted that truncation to shortest unique prefix would not work.




Josefsson                 Expires May 25, 2001                 [Page 15]

Internet-Draft               The NO Record                 November 2000


References

   [1]  Eastlake, D., "Domain Name System Security Extensions", RFC
        2535, March 1999.

   [2]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
        Domain Name System (DNS)", RFC 2538, March 1999.

   [3]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC
        2606, June 1999.

   [4]  NIST, , "Secure Hash Standard", FIPS PUB 180-1, April 1995.

   [5]  Massey, D., Lehman, T. and E. Lewis, "DNSSEC Implementation in
        the CAIRN Testbed.", I.D. draft-ietf-dnsop-dnsseccairn-00.txt,
        October 1999.

   [6]  Josefsson, S.A. (editor), "Base 64, 32 and 16 Encodings", I.D.
        draft-josefsson-base-encoding-00.txt, August 2000.

   [7]  Wellington, B, "Domain Name System Security (DNSSEC) Signing
        Authority", I.D. draft-ietf-dnsext-signing-auth-01.txt, May
        2000.


Author's Address

   Simon Josefsson
   RSA Security
   Arenav刧en 29
   Stockholm  121 29
   Sweden

   Phone: [phone]
   EMail: [e-mail]
















Josefsson                 Expires May 25, 2001                 [Page 16]

Internet-Draft               The NO Record                 November 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.



















Josefsson                 Expires May 25, 2001                 [Page 17]