159 lines
4.7 KiB
Plaintext
159 lines
4.7 KiB
Plaintext
|
||
|
||
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
|
||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||
|
||
The list of Internet-Draft Shadow Directories can be accessed at
|
||
http://www.ietf.org/shadow.html.
|
||
|
||
|
||
Abstract
|
||
|
||
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",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
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
|
||
routines.
|
||
|
||
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
|
||
|
||
|
||
References
|
||
|
||
|
||
[RFC2065]
|
||
Eastlake, D. 3rd. and Kaufman, C,. "Domain Name System Security
|
||
Extensions," RFC 2065, January 1997
|
||
|
||
|
||
[RFC2119]
|
||
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
|
||
AUSTRALIA
|
||
+61 2 9871 4742
|
||
<Mark_Andrews@isc.org>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Expires August 1999 [Page 3]
|
||
|