[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

   INTERNET-DRAFT                                        Mark Andrews (ISC)
   <draft-ietf-dnsind-verify-00.txt>                          February 1999
          Verifying Resource Records Without Knowing Their Contents
   Status of This Memo
      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.
      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its areas,
      and its working groups.  Note that other groups may also distribute
      working documents as Internet-Drafts.
      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as "work in progress."
      The list of current Internet-Drafts can be accessed at
      The list of Internet-Draft Shadow Directories can be accessed at
      DNSSEC [RFC2065] provides a mechanism to cryptographically verify a
      DNS resource record provided we can get it into canonical form.
      The problem is how do we do this without knowing the contents of all
      resource record types?
      This document provides one possible solution to this problem.
   1 - Terminology
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].
   Expires August 1999                                             [Page 1]

   INTERNET-DRAFT       draft-ietf-dnsind-verify-00.txt       February 1998
   2 - Method
   In order to be able to canonicalise a resource record a resolver needs
   to know where in the data domain names exist so that the resolver can
   decompress the domain names and convert the uppercase ASCII in ordinary
   labels to lowercase prior to the data being feed into the encryption
   This document propose that all new resource record types defined MUST
   have a header at the start of the data section locating where the domain
   names are in the data section.  A new resource record for the purpose of
   this document is any type NOT referenced in section 3 Old Types.  Meta
   queries such as MAILA (254), MAILB (253), AXFR (252) and IXFR (251) are
   not covered by this document as they do not return data of this type.
   This table would be a series of unsigned 16 bit words in network order.
   The first word contains the length of the table as 16 bit words not
   counting the first word.  Subsequent words contain the offset from the
   start of the data to the start of relevent domain name in the data
   assuming all domain names are uncompressed.  Offsets in the table are in
   the same order as domain names in the data.
   3 Old Types
   The following types are deemed old and are NOT covered by this document.
   A (1), NS (2), MD (3), MF (4), CNAME (5), SOA (6), MB (7), MG (8), MR
   (9), NULL (10), WKS (11), PTR (12), HINFO (13), MINFO (14), MX (15), TXT
   (16), RP (17), AFSDB (18), X25 (19), ISDN (20), RT (21), NSAP (22),
   NSAP-PTR (23), SIG (24), KEY (25), PX (26), GPOS (27), AAAA (28), LOC
   (29), NXT (30), EID (31), NIMLOC (32), SRV (33), ATMA (34), NAPTR (35),
   KX (36), CERT (37), A6 (38), DNAME (39), UINFO (100), UID (101), GID
   (102), UNSPEC (103), OPT (XXX), TKEY (249) and TSIG (250).
   4 Security Considerations
   It is believed that this document does not introduce any significant
   additional security threats other that those that already exist when
   using data from the DNS but rather enhances security by allowing new
   resource record types to be checked by security aware resolvers.
   5 IANA Considerations
   This document places no requirements apon IANA.
   Expires August 1999                                             [Page 2]

   INTERNET-DRAFT       draft-ietf-dnsind-verify-00.txt       February 1998
      Eastlake, D. 3rd. and Kaufman, C,. "Domain Name System Security
      Extensions," RFC 2065, January 1997
      Bradner, S., "Key words for use in RFCs to Indicate Requirement LevĀ­
      els," BCP 14, RFC 2119, March 1997
   Author's Address
      Mark Andrews
         Internet Software Consortium
         1 Seymour St.
         Dundas Valley
         NSW 2117
         +61 2 9871 4742
   Expires August 1999                                             [Page 3]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/