mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 14:07:59 +00:00
Code Issues Releases Wiki Activity

update

Browse Source
This commit is contained in:
Bob Halley
1999-09-08 18:25:34 +00:00
parent c5b755203b
commit 15e26d11c8
7 changed files with 1861 additions and 927 deletions
Download Patch File Download Diff File Expand all files Collapse all files

190
doc/draft/draft-ietf-dnsind-apl-rr-01.txt → doc/draft/draft-ietf-dnsind-apl-rr-02.txt
View File

@@ -1,12 +1,9 @@
INTERNET-DRAFT Peter Koch
Expires: August 1999 Universitaet Bielefeld
Updates: RFC 1035 February 1999
A DNS RR Type for Lists of IP Address Prefixes (APL RR)
draft-ietf-dnsind-apl-rr-01.txt
Expires: December 1999 Universitaet Bielefeld
Updates: RFC 1035 June 1999
A DNS RR Type for Lists of Address Prefixes (APL RR)
draft-ietf-dnsind-apl-rr-02.txt
Status of this Memo
@@ -36,7 +33,7 @@ Abstract
The Domain Name System is primarily used to translate domain names
into IPv4 addresses using A RRs. Several approaches exist to describe
networks or address ranges. This document proposes a new DNS RR type
networks or address ranges. This document specifies a new DNS RR type
"APL" for address prefix lists.
1. Conventions used in this document
@@ -46,15 +43,11 @@ Abstract
document are to be interpreted as described in [RFC2119].
Domain names herein are for explanatory purposes only and should not
be expected to lead to useful information in real life [TESTTLD].
be expected to lead to useful information in real life [RFC2606].
Koch Expires December 1999 [Page 1]
Koch Expires August 1999 [Page 1]
INTERNET-DRAFT DNS APL RR February 1999
INTERNET-DRAFT DNS APL RR June 1999
2. Background
@@ -67,7 +60,7 @@ INTERNET-DRAFT DNS APL RR February 1999
older BIND versions, a weak form of controlling access to zone data
was implemented using TXT RRs describing address ranges.
This document proposes a new RR type for address prefix lists.
This document specifies a new RR type for address prefix lists.
3. APL RR Type
@@ -83,63 +76,55 @@ INTERNET-DRAFT DNS APL RR February 1999
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ADDRESSFAMILY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| N | PREFIX | MBZ | AFDLENGTH |
| PREFIX | N | AFDLENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AFDPART /
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
ADDRESSFAMILY 16 bit unsigned value as assigned by IANA
(see IANA Considerations)
PREFIX 8 bit unsigned binary coded prefix length.
Upper and lower bounds and interpretation of
this value are address family specific.
N negation flag, indicates the presence of the
"!" character in the textual format. It has
the value "1" if the "!" was given, "0" else.
PREFIX binary coded prefix length. Upper and lower
bounds and interpretation of this value are
address family specific.
MBZ reserved, must be zero
AFDLENGTH length in octets of the following address
family dependent part. This is to deal with
yet undefined address families and variable
length addresses.
Koch Expires August 1999 [Page 2]
INTERNET-DRAFT DNS APL RR February 1999
family dependent part (7 bit unsigned).
AFDPART address family dependent part. See below.
This document defines the AFDPARTs for address families 1 (IPv4) and
Koch Expires December 1999 [Page 2]
INTERNET-DRAFT DNS APL RR June 1999
2 (IPv6). Future revisions may deal with additional address
families.
4.1. AFDPART for IPv4
The encoding of an IPv4 address (address family 1) follows the
encoding specified for the A RR by [RFC1035], section 3.4.1.
encoding specified for the A RR by [RFC1035], section 3.4.1. Trailing
zero octets MUST be ignored, regardless of the prefix length.
PREFIX specifies the number of bits of the IPv4 address starting at
the most significant bit. Legal encodings range from 0 (1 bit) to 31
(32 bit, complete address).
the most significant bit. Legal values range from 0 to 32.
An IPv4 AFDPART has a fixed length of 4 octets.
An IPv4 AFDPART has a variable length of 0 to 4 octets.
4.1. AFDPART for IPv6
4.2. AFDPART for IPv6
The encoding of an IPv6 address (address family 2) follows the
encoding specified for the AAAA RR by [RFC1886], section 2.2.
specification for the AAAA RR in [RFC1886], section 2.2. The 128 bit
address is encoded in network byte order. Trailing zero octets MUST
be ignored, regardless of the prefix length.
PREFIX specifies the number of bits of the IPv6 address starting at
the most significant bit. Legal encodings range from 0 (1 bit) to 127
(128 bit, complete address).
the most significant bit. Legal values range from 0 to 128.
An IPv6 AFDPART has a fixed length of 16 octets.
An IPv6 AFDPART has a variable length of 0 to 16 octets.
5. Zone File Syntax
@@ -157,28 +142,25 @@ INTERNET-DRAFT DNS APL RR February 1999
An IPv4 address in the <address> part of an <apstring> is in dotted
quad notation, just as in an A RR. The <prefix> has values from the
interval 1..32 (decimal), corresponding to encodings 0..31.
5.1. Textual Representation of IPv6 Addresses
Koch Expires August 1999 [Page 3]
INTERNET-DRAFT DNS APL RR February 1999
interval 0..32 (decimal).
5.2. Textual Representation of IPv6 Addresses
The representation of an IPv6 address in the <address> part of an
<apstring> follows [RFC2373], section 2.2. Legal values for <prefix>
are from the interval 1..128 (decimal), corresponding to encodings
0..127.
Koch Expires December 1999 [Page 3]
INTERNET-DRAFT DNS APL RR June 1999
are from the interval 0..128 (decimal).
6. APL RR usage
An APL RR with empty RDATA is valid and implements an empty list.
Multiple occurences of the same <apstring> in a single APL RR are
allowed and MUST NOT be merged by a DNS server or resolver.
<apstrings> must be kept in order and MUST NOT be rearranged or
<apstrings> MUST be kept in order and MUST NOT be rearranged or
aggregated.
A single APL RR may contain <apstrings> belonging to different
@@ -196,34 +178,39 @@ INTERNET-DRAFT DNS APL RR February 1999
7. Examples
Example usages otlined in the prevois section are shown here. The
line continuation symbol in the second APL RR appears for editorial
purposes only, it is not valid in zone files.
foo.example APL 192.168.32.0/21 !192.168.38.0/28
42.168.192.IN-ADDR.ARPA APL 192.168.42.0/26 192.168.42.64/26 \
192.168.42.128/25
_axfr_.sbo.example APL 127.0.0.1/32 172.16.64.0/22
_axfr.sbo.example APL 127.0.0.1/32 172.16.64.0/22
multicast.example APL 224.0.0.0/4 FF00:0:0:0:0:0:0:0/8
Note that since trailing zeroes are ignored in the first APL RR the
AFDLENGTH of both <apstrings> is three.
8. Security Considerations
Any information obtained from the DNS should be regarded as unsafe
unless techniques specified in [RFC2065] or [TSIGRR] were used. The
unless techniques specified in [RFC2535] or [TSIGRR] were used. The
definition of a new RR type does not introduce security problems into
the DNS, but usage of information made available by APL RRs may
compromise security. This includes disclosure of network topology
Koch Expires December 1999 [Page 4]
INTERNET-DRAFT DNS APL RR June 1999
information and in particular the use of APL RRs to construct access
control lists.
9. IANA Considerations
Koch Expires August 1999 [Page 4]
INTERNET-DRAFT DNS APL RR February 1999
This document does not define any new namespaces. It uses the 16 bit
identifiers for address families maintained by IANA in
ftp://ftp.iana.org/in-notes/iana/assignments/address-family-numbers.
@@ -235,10 +222,9 @@ INTERNET-DRAFT DNS APL RR February 1999
11. References
[A6DNSRR] Crawford,M., Thomson,S., "DNS Extensions to Support IP
Version 6", <draft-ietf-ipngwg-dns-lookups-XX.txt>, work
in progress
[A6DNSRR] Crawford,M., Huitema,C., Thomson,S., "DNS Extensions to
Support IPv6 Address Aggregation and Renumbering",
<draft-ietf-ipngwg-dns-lookups-XX.txt>, work in progress
[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 13, November 1987
@@ -252,9 +238,6 @@ INTERNET-DRAFT DNS APL RR February 1999
[RFC1886] Thomson,S., Huitema.,C., "DNS Extensions to support IP
version 6", RFC 1886, December 1995
[RFC2065] Eastlake,D., Kaufman,C. "Domain Name System Security
Extensions", RFC 2065, January 1997
[RFC2119] Bradner,S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997
@@ -264,22 +247,20 @@ INTERNET-DRAFT DNS APL RR February 1999
[RFC2373] Hinden,R., Deering,S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998
[TESTTLD] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
<draft-ietf-dnsind-test-tlds-XX.txt>, work in progress
[RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC
2535, March 1999
[RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
RFC 2606, BCP 32, June 1999
Koch Expires December 1999 [Page 5]
INTERNET-DRAFT DNS APL RR June 1999
[TSIGRR] Vixie,P., Gudmundsson,O., Eastlake,D., Wellington,B.,
"Secret Key Transaction Signatures for DNS (TSIG)",
<draft-ietf-dnsind-tsig-XX.txt>, work in progress
Koch Expires August 1999 [Page 5]
INTERNET-DRAFT DNS APL RR February 1999
12. Author's Address
Peter Koch
@@ -291,45 +272,4 @@ INTERNET-DRAFT DNS APL RR February 1999
+49 521 106 2902
<pk@TechFak.Uni-Bielefeld.DE>
Koch Expires August 1999 [Page 6]
Koch Expires December 1999 [Page 6]

153
doc/draft/draft-ietf-dnsind-edns1-02.txt → doc/draft/draft-ietf-dnsind-edns1-03.txt
View File

@@ -1,34 +1,29 @@
DNSIND Working Group Paul Vixie
INTERNET-DRAFT ISC
<draft-dnsind-edns1-02.txt> January, 1999
<draft-ietf-dnsind-edns1-03.txt> June, 1999
Extensions to DNS (EDNS1)
Status of this Memo
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.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.''
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
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
@@ -47,14 +42,9 @@
several new extended label types and message options, and the ability to
ask multiple questions in a single request.
Expires December 1999 [Page 1]
Expires July 1999 [Page 1]
INTERNET-DRAFT EDNS1 January 1999
INTERNET-DRAFT EDNS1 June 1999
2 - Affected Protocol Elements
@@ -95,19 +85,9 @@
3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long
local compression pointer'' as described in [KOCH98].
Expires December 1999 [Page 2]
Expires July 1999 [Page 2]
INTERNET-DRAFT EDNS1 January 1999
INTERNET-DRAFT EDNS1 June 1999
4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags
are structured as follows:
@@ -119,7 +99,6 @@
2: |MD |FM |RRD|LM | Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. (As
defined by [EDNS0].)
@@ -143,25 +122,27 @@
segments of a segmented message. It is an error for TC
to be set on any message of a segmented message. Any
given RR must fit completely within a message, and all
messages will both begin and end on RR boundaries.
messages will both begin and end on RR boundaries. Each
section in a multipart message must appear in normal
message order, and each section must be complete before
later sections are added. All segments of a message
must be transmitted contiguously, without interleaving
of other messages.
FM ``First match'' flag. Notable only when multiple
questions are present. If set in a request, questions
will be processed in wire order and the first question
whose answer would have NOERROR AND ANCOUNT>0 is treated
Expires December 1999 [Page 3]
INTERNET-DRAFT EDNS1 June 1999
as if it were the only question in the query message.
Otherwise, questions can be processed in any order and
all possible answer records will be included in the
response. Response FM should be ignored by requestors.
Expires July 1999 [Page 3]
INTERNET-DRAFT EDNS1 January 1999
RRD ``Recursion really desired'' flag. Notable only when a
request is processed by an intermediate name server
(``forwarder'') who is not authoritative for the zone
@@ -200,21 +181,16 @@
Z Set to zero by senders and ignored by receivers, unless
modified in a subsequent specification.
Expires December 1999 [Page 4]
INTERNET-DRAFT EDNS1 June 1999
5 - Multiple Questions for QUERY
5.1. If QDCOUNT>1, multiple questions are present. All questions must
be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It
is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY.
Expires July 1999 [Page 4]
INTERNET-DRAFT EDNS1 January 1999
5.2. RCODE and AA apply to all RRs in the answer section having the
QNAME that is shared by all questions in the question section. AA
applies to all matching answers, and will not be set unless the exact
@@ -236,8 +212,8 @@
6 - Acknowledgements
Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Michael
Patton were each instrumental in creating this specification.
Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Michael Patton,
and Michael Graff were each instrumental in creating this specification.
7 - References
@@ -254,20 +230,13 @@
[KOCH98] P. Koch, ``A New Scheme for the Compression of Domain
Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt.
Expires December 1999 [Page 5]
INTERNET-DRAFT EDNS1 June 1999
IETF DNSIND, March 1998.
Expires July 1999 [Page 5]
INTERNET-DRAFT EDNS1 January 1999
8 - Author's Address
Paul Vixie
@@ -275,46 +244,6 @@
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
<paul@vix.com>
<vixie@isc.org>
Expires July 1999 [Page 6]
Expires December 1999 [Page 6]

755
doc/draft/draft-ietf-dnsind-iana-dns-00.txt Normal file
View File

@@ -0,0 +1,755 @@
INTERNET-DRAFT Donald E. Eastlake 3rd (IBM)
Eric Brunner (Nokia)
Bill Manning (ISI)
Expires: February 2000 August 1999
draft-ietf-dnsind-iana-dns-00.txt
Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ---- --------------
Status of This Document
This draft, file name draft-ietf-dnsind-iana-dns-00.txt, is intended
to become a Best Current Practice RFC. Distribution of this document
is unlimited. Comments should be sent to the DNS Working Group
mailing list <namedroppers@internic.com> or to the authors.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories as listed at <http://www.ietf.org/shadow.html>.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 1]
INTERNET-DRAFT DNS IANA Considerations August 1999
Abstract
Internet Assigned Number Authority (IANA) considerations are given
for the allocation of Domain Name System (DNS) classes, RR types,
operation codes, error codes, etc.
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Table of Contents..........................................2
1. Introduction............................................3
2. DNS Query/Response Header Structure.....................3
2.1 One Spare Bit?.........................................4
2.2 Opcode Assignment......................................4
2.3 RCODE Assignment.......................................4
3. DNS Resource Record Structure...........................5
3.1 RR TYPE IANA Considerations............................7
3.1.1 Special Note on the OPT RR...........................7
3.1.2 Special Note on the SINK RR..........................8
3.2 RR CLASS IANA Considerations...........................8
3.3 IANA DNS Name Considerations...........................9
3.3.1 Becoming Root........................................9
3.3.1 Reserved TLDs in the IN CLASS........................9
3.3.2 'Country Code' TLDs in the IN CLASS.................10
3.3.3 Other TLDs in the IN CLASS..........................10
4. Security Considerations................................11
References................................................12
Authors Addresses.........................................13
Expiration and File Name..................................13
D. Eastlake 3rd, E. Brunner, B. Manning [Page 2]
INTERNET-DRAFT DNS IANA Considerations August 1999
1. Introduction
The Domain Name System (DNS) provides a replicated distributed secure
hierarchical database which stores "resource records" (RRs) by CLASS
under hierarchical domain names. This data is structured into
CLASSes and zones which can be independently maintained. See [RFC
1034, 1035, 2136, 2181, 2535, etc.] familiarity with which is
assumed.
This document covers general IANA considerations applying across DNS
query and response headers and all RRs. There may be additional IANA
considerations that apply to only a particular RR type or
query/response opcode. See the specific RFC defining that RR type or
query/response opcode for such considerations if they have been
defined.
The terms of art used herein with respect to IANA Considerations are
as defined in [RFC 2434].
2. DNS Query/Response Header Structure
The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC 2136/2535]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so
they can be matched.
The QR bit indicates whether the header is for a query or a response.
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value
D. Eastlake 3rd, E. Brunner, B. Manning [Page 3]
INTERNET-DRAFT DNS IANA Considerations August 1999
of the response header without clearing bits. Thus any attempt to
use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous and such meanings
may only be assigned by an IETF standards action.
The QDCOUNT, ANCOUNT, NSCOUNT, and ARCOUNT fields give the number of
queries in the Query section, answer RRs in the Answer section, RRs
in the Authority section, and informational RRs in the Additional
Information section, respectively, for all opcodes except Update.
These fields have the same structure and data type for update but are
instead the counts for the Zone, Prerequisite, Update, and Additional
Information sections.
2.1 One Spare Bit?
While it would appear that the "Z" bit is spare, there have been DNS
implementations for which that bit being on in a query meant that
only a response from the primary server for a zone is acceptable. It
is believed that modern DNS implementations ignore this bit.
Assigning a meaning to this bit requires an IETF standards action.
2.2 Opcode Assignment
IANA DNS OpCode assignments are shown at <ftp://ftp.isi.edu/in-
notes/iana/assignments/dns-parameters>.
Currently the following OpCodes are assigned.
OpCode Name Reference
0 Query [RFC 1035]
1 IQuery (Inverse Query) [RFC 1035]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
New OpCode assignments require an IETF consensus.
2.3 RCODE Assignment
Current IANA DNS RCODE assignments are shown at
<ftp://ftp.isi.edu/in-notes/iana/assignments/dns-parameters>...
D. Eastlake 3rd, E. Brunner, B. Manning [Page 4]
INTERNET-DRAFT DNS IANA Considerations August 1999
The range of RCODEs is extended beyond four bits to twelve bits for
implementations of DNS supporting the OPT RR (see Section 3.1.1).
RCODEs can appear both at the top level of a DNS response in the
header or inside TSIG RRs [RFC XXX3]. The TSIG RR has a 16 bit RCODE
error field.
RCODE Name Reference
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11-15 available for assignment
16 BADSIG Signature Failure [RFC XXX3]
17 BADKEY Key not recognized [RFC XXX3]
18 BADTIME Signature out of time window [RFC XXX3]
19-0xFFFF available for assignment
Since it is important that RCODEs be understood for interoperability,
new RCODE assignment requires an IETF consensus.
3. DNS Resource Record Structure
All RRs have the same top level format shown in the figure below
taken from RFC 1035:
D. Eastlake 3rd, E. Brunner, B. Manning [Page 5]
INTERNET-DRAFT DNS IANA Considerations August 1999
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this
resource record pertains. Names are specific to a CLASS as described
in section 3.2. Names consist of an ordered sequence of one or more
labels each of which has a label type [RFC 1035]. The last label in
each name is "root" which is wire encoded as a single zero octet.
New label types are assigned as provided in [RFC XXX1].
TYPE is two octets containing one of the RR TYPE codes. See section
3.1.
CLASS is two octets containing one of the RR CLASS codes. See
section 3.2.
TTL is a 32 bit unsigned integer that specifies the time interval
that the resource record may be cached before the source of the
information should again be consulted. Zero is interpreted to mean
that the RR can only be used for the transaction in progress.
RDLENGTH is an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
RDATA is a variable length string of octets that describes the
resource. The format of this information varies according to the
TYPE and in some cases the CLASS of the resource record.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 6]
INTERNET-DRAFT DNS IANA Considerations August 1999
3.1 RR TYPE IANA Considerations
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
and Meta-TYPEs. QTYPES can only be used in queries. Meta-TYPEs
designate transient data associate with an particular DNS message and
in some cases can also be used in queries. Thus far, data types have
been assigned from 1 upwards plus the block from 100 through 103
while Q and Meta Types have been assigned from 255 downwards. IANA
RR TYPE assignments are documented at <ftp://ftp.isi.edu/in-
notes/iana/assignments/dns-parameters>.
There are currently three Meta-types: TSIG [RFC XXX3], TKEY, and OPT
[RFC XXX1].
There are currently five Qtypes: * (all), MAILA, MAILB, AXFR, and
IXFR.
RR TYPE zero is used as a special indicator for the SIG RR [RFC 2535]
and in other circumstances and must never be allocated for ordinary
use.
Remaining types in the range 0x0001 to 0x7FFF are assigned by
authority of IETF consensus. The current pattern of assigning
regular data types from 1 upwards and Q and Meta types from 255
downward should continue until that range is exhausted.
Types from 0x8000 through 0xFEFF are assigned based on RFC
publication.
Types from 0xFF00 through 0xFFFF are for private experimental use.
Because their use is not coordinated, it may conflict between
different experiments.
3.1.1 Special Note on the OPT RR
The OPT (OPTion) RR, number (TBD), is specified in [RFC XXX1]. Its
primary purpose is to extend the effective field size of various DNS
fields including RCODE, label type, OpCode, flag bits, and RDATA
size. In particular, for resolvers and servers that recognize it, it
extends the RCODE field from 4 to 12 bits.
IANA considerations for label types are given in [RFC XXX1].
D. Eastlake 3rd, E. Brunner, B. Manning [Page 7]
INTERNET-DRAFT DNS IANA Considerations August 1999
3.1.2 Special Note on the SINK RR
The (Kitchen) SINK RR, number 40, is specified in RFC [XXX2]. It is
designed to accommodate demands for proprietary RRs and provides
flexible encoding and semantic labeling of the RDATA potion. This
should virtually eliminate the need to allocate RR types codes for
private or proprietary purposes.
3.2 RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary
relationship between the namespace or roots servers for one CLASS and
those for another CLASS. A name can have completely different
meanings in different CLASSes. However, as global networking and DNS
have evolved, the IN, or Internet, CLASS has dominated DNS use.
IANA DNS CLASS assignments are shown at <ftp://ftp.isi.edu/in-
notes/iana/assignments/dns-parameters>. There are two subcategories
of DNS CLASSes: normal data containing classes and QCLASSes that are
only meaningful in queries or updates. The current data class
assignments are as follows: 1 - Internet (IN), 3 - Chaos (CH), and 4
- Hesiod (HS). The currently assigned Q classes are as follows: 255
- Any and 254 - None.
Allocation of CLASS 0x0000 requires an IETF standards action.
Allocation of remaining CLASSes in the range of 0x0001-0x00FF are by
IETF consensus with data classes given the lowest available value and
QCLASSes the highest available value in that range until that range
is exhausted.
Allocation of CLASSes in the range 0x0100 through 0x7FFF is by IETF
consensus.
Allocation of CLASSes in the range 0x8000 through 0xFEFF is by RFC
publication.
CLASSes in the range 0xF000 through 0xFFFE are for private
experimental use. Because their use is not coordinated, it may
conflict between different experiments.
CLASS 0xFFFF can only be assigned by an IETF standards action.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 8]
INTERNET-DRAFT DNS IANA Considerations August 1999
3.3 IANA DNS Name Considerations
TheHesiod [Dyer 87] and Chaos CLASSes are essentially for local use.
(Chaos was a network system implemented at MIT.) The IN CLASS is the
only DNS CLASS in global use on the Internet at this time.
3.3.1 Becoming Root
In practice, it is quite easy to put up a set of root servers. DNS
resolvers which use those root servers will see the namespace they
support. DNS has only downward pointers from zone to subzone and no
upward pointers going from zone to superzone. Thus, in creating a
root zone, it works technically to pick whatever top level domains
(TLDs) you want including, if you wish, TLDs that are not generally
recognized.
Setting up your own root zone like this is commonly done within local
enclaves to hide some local names, for security and efficiency. In
some cases, local TLDs are added. But for the global Internet, the
use of variant root zones would lead to non-interoperability at the
application level. Users would find that email addresses didn't work
or addressed different accounts for those using different root zone
contents. Links in web pages wouldn't work or would address
different web resources for those using different root zone contents.
As a result, despite strenuous attempts to promote alternatives, no
significant portion of the global Internet has ever used other than
the IETF recommended root zone contents except, in some cases, for
strictly local names.
3.3.1 Reserved TLDs in the IN CLASS
All single octet length top level domain (TLD) names in the IN class
are reserved as are all TLDs containing any octets that are not ASCII
letters or digits. One reason for reserving single octet TLDs is
that, should the root zone ever get very large, there are technical
solutions which would be eased by having the single byte TLDs
available.
[For like reasons, it is recommended that within TLDs or indeed
within any zone that is or might become very large, all single octet
names be reserved. However, this decision is up to the authority for
each non-root zone.]
Binary label TLDs [RFC XXX4] and other new TLD label data types are
reserved.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 9]
INTERNET-DRAFT DNS IANA Considerations August 1999
The above reservations also provides a means of escape should other
name allocation paint the IN CLASS namespace into a corner.
Assignment of the above reserved names requires an IETF consensus.
Finally, the four TLDs "example", "invalid", "localhost", and "test"
are reserved as described in [RFC 2606].
3.3.2 'Country Code' TLDs in the IN CLASS
All two octet length TLDs in the IN class consisting of letters are
reserved for assignment to territories. Those (1) allocated by [ISO
3166] and (2) allocated by the Universal Postal Union [UPU] and
reserved in [ISO 3166] even though not formally assigned by [ISO
3166] (e.g., a few British Channel Islands), are assigned as so
allocated by the generally recognized acting government of the area
associated with the "country code" or on a first come first served
basis to a designated registry if there is no such government or the
government has not exercised control. In addition, due to historical
factors and consistent with the normal diplomatic usage of special
consideration for founders, the United States of America, as founder
of the Internet, is also assigned the three letter TLDs "gov" and
"mil". A country code for a territory with a generally recognized
acting government should be considered part of the territory of that
government. Decisions by said government as to who should control
the DNS for that TLD are final and unappealable.
Country codes consisting of a letter and a digit or two digits are
not currently used by [ISO 3166] or the [UPU]. However, to permit
possible expansion of the two octet country codes, they are reserved
for future allocation as described in the previous paragraph.
3.3.3 Other TLDs in the IN CLASS
IANA manages the "arpa" and "int" TLDs. The "arpa" TLD is assigned
for use in the IPv4 inverse mapping and IANA delegates /8 subzones to
holders of a /8 chunk of address space, including the regional
address registries. "int" includes the IPv6 inverse address mapping
which is at "ip6.int", international registrations at "reg.int", and
also provides for recognized international organizations. IANA
considerations for IP address assignment are given elsewhere.
Control and assignment of various other existing or prospective IN
CLASS TLDs is currently in a state of flux being transfered to the
ICANN (www.icann.org) DNSO (Domain Name Support Organization,
www.dnso.org). Traditionally "edu" was used for educational
D. Eastlake 3rd, E. Brunner, B. Manning [Page 10]
INTERNET-DRAFT DNS IANA Considerations August 1999
institutions, "net" for network infrastructure organizations, "com"
for commercial organizations, and "org" for other non-profit
organizations.
New registrations in "edu" are currently restricted to four year or
longer institutions of higher learning.
4. Security Considerations
This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 2535] for secure DNS
considerations.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 11]
INTERNET-DRAFT DNS IANA Considerations August 1999
References
[Dyer 87] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
Plan - Name Service, April 1987,
[ISO 3166] - Codes for the representation of names of countries.
[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and
Facilities", STD 13, November 1987.
[RFC 1035] - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
[RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", August 1996.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
[RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS
Specification", July 1997.
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
in RFCs", T. Narten, H. Alvestrand, October 1998.
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
[RFC XXX1] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", xxx
1999 (draft-ietf-dnsind-edns0-*.txt).
[RFC XXX2] - D. Eastlake, "The Kitchen Sink DNS Resource Record", xxx
1999 (draft-ietf-dnsind-kitchen-sink-*.txt).
[RFC XXX3] - P. Vixie, O. Gundmundsson, D. Eastlake, B. Wellington,
"Secret Key Transaction Signatures for DNS (TSIG)" xxx 1999 (draft-
ietf-dnsind-tsig-*.txt).
[RFC XXX4] - M. Crawford, "Binary Labels in the Domain Name System",
xxx 1999 (draft-ietf-dnsind-binary-labels-*.txt).
[UPU] - <http://www.upu/int>
D. Eastlake 3rd, E. Brunner, B. Manning [Page 12]
INTERNET-DRAFT DNS IANA Considerations August 1999
Authors Addresses
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road
Carmel, NY 10512 USA
Telephone: +1-914-784-7913 (w)
+1-914-276-2668 (h)
fax: +1-914-784-3833 (w)
email: dee3@us.ibm.com
Eric Brunner
Mokia Research Center
3 Burlington Woods Drive, Suite 250
Burlington, MA 01803 USA
Telephone: +1 781-359-5159
fax: +1 781-359-5196
email: brunner@maine.rr.com
Bill Manning
USC/ISI
4676 Admiralty Way, #1001
Marina del Rey, CA 90292 USA
Telephone: +1 310 822 1511
email: bmanning@isi.edu
Expiration and File Name
This draft expires February 2000.
Its file name is draft-ietf-dnsind-iana-dns-00.txt.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 13]

121
doc/draft/draft-ietf-dnsind-local-compression-04.txt → doc/draft/draft-ietf-dnsind-local-compression-05.txt
View File

@@ -1,14 +1,9 @@
INTERNET-DRAFT Peter Koch
Expires: August 1999 Universitaet Bielefeld
Updates: 1035, 1183, 2065, 2163, 2168 February 1999
Expires: December 1999 Universitaet Bielefeld
Updates: 1035, 1183, 2163, 2168, 2535 June 1999
A New Scheme for the Compression of Domain Names
draft-ietf-dnsind-local-compression-04.txt
draft-ietf-dnsind-local-compression-05.txt
Status of this Memo
@@ -51,18 +46,15 @@ Abstract
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Koch Expires December 1999 [Page 1]
Koch Expires August 1999 [Page 1]
INTERNET-DRAFT DNS Compression February 1999
INTERNET-DRAFT DNS Compression June 1999
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Domain names herein are for explanatory purposes only and should not
be expected to lead to useful information in real life [TESTTLD].
be expected to lead to useful information in real life [RFC2606].
2. Background
@@ -107,12 +99,9 @@ INTERNET-DRAFT DNS Compression February 1999
names in the RDATA section of "well known" RR types (those initially
defined in [RFC1035]), there is no interoperable way of applying
Koch Expires December 1999 [Page 2]
Koch Expires August 1999 [Page 2]
INTERNET-DRAFT DNS Compression February 1999
INTERNET-DRAFT DNS Compression June 1999
compression to the RDATA section of newer RRs:
@@ -163,12 +152,9 @@ INTERNET-DRAFT DNS Compression February 1999
number (starting at 0 for the topmost label, the TLD). This way we
avoid the need for extra decompression of the owner name during
Koch Expires December 1999 [Page 3]
Koch Expires August 1999 [Page 3]
INTERNET-DRAFT DNS Compression February 1999
INTERNET-DRAFT DNS Compression June 1999
message composition or decomposition.
@@ -194,7 +180,7 @@ Example
section consisting of two domain names:
ab.foo.example IN CNAME bar.example
bar.example IN XMPL ab.foo.example foo.example
bar.example IN XMPL a.foo.example foo.example
In a message this appears as follows (randomly starting at octet 12):
@@ -218,13 +204,9 @@ Example
10 octets skipped (TYPE, CLASS, TTL, RDLENGTH)
Koch Expires December 1999 [Page 4]
Koch Expires August 1999 [Page 4]
INTERNET-DRAFT DNS Compression February 1999
INTERNET-DRAFT DNS Compression June 1999
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
38 | 3 | b |
@@ -264,7 +246,7 @@ INTERNET-DRAFT DNS Compression February 1999
5. Interaction with DNSSEC
The security extensions to DNS [RFC2065] mandate that domain names in
The security extensions to DNS [RFC2535] mandate that domain names in
RDATA be signed only in expanded, lower case format. For RR types
using local compression the specification is changed as follows:
@@ -275,12 +257,9 @@ INTERNET-DRAFT DNS Compression February 1999
This way RR type transparency can be achieved, since domain names in
Koch Expires December 1999 [Page 5]
Koch Expires August 1999 [Page 5]
INTERNET-DRAFT DNS Compression February 1999
INTERNET-DRAFT DNS Compression June 1999
the RDATA section are treated as arbitrary data and can be cached and
verified by resolvers not aware of the particular RR type. Old RR
@@ -292,6 +271,13 @@ INTERNET-DRAFT DNS Compression February 1999
be used to compress the RDATA part more efficiently, this MUST NOT be
done. Otherwise signatures would be invalidated.
Currently slave servers store zones in text format and re-encode the
data into wire format, e.g. after a restart. This encoding must be
unique to ensure signature validity. To achieve this, local
compression MUST be applied optimally, i.e. every domain name must be
compressed as far as possible and each local compression pointer must
point to the earliest available target (including the owner).
6. Interaction with Binary Labels
When constructing local compression pointers into the owner name,
@@ -311,7 +297,7 @@ INTERNET-DRAFT DNS Compression February 1999
introduction of binary labels a domain name can consist of up to 1904
labels (all one-bit labels). This document restricts the possible
compression targets in an owner name to the topmost 255 labels. This
limit was chosen to be consistent with [DNSSEC], section 4.1.
limit was chosen to be consistent with [RFC2535], section 4.1.3.
7. Old RR types and deployment
@@ -322,7 +308,12 @@ INTERNET-DRAFT DNS Compression February 1999
The following RR types with domain names in the RDATA section have
been defined since [RFC1035] (Standards Track, Experimental and
Informational RFCs, ignoring withdrawn types): RP [RFC1183], AFSDB
[RFC1183], RT [RFC1183], SIG [RFC2065], PX [RFC2163], NXT [RFC2065],
[RFC1183], RT [RFC1183], SIG [RFC2535], PX [RFC2163], NXT [RFC2535],
Koch Expires December 1999 [Page 6]
INTERNET-DRAFT DNS Compression June 1999
SRV [RFC2052], NAPTR [RFC2168], KX [RFC2230]. Some specifications do
not mention DNS compression at all, others explicitly suggest it and
only in part identify interoperability issues. Only the KX and SRV
@@ -330,14 +321,6 @@ INTERNET-DRAFT DNS Compression February 1999
The specification of RP, AFSDB, RT, PX, and NAPTR is hereby changed
in that domain names in the RDATA section MUST NOT be compressed and
Koch Expires August 1999 [Page 6]
INTERNET-DRAFT DNS Compression February 1999
MUST NOT be compression targets.
Local compression MUST NOT be used for owner names and it MUST NOT be
@@ -373,10 +356,13 @@ INTERNET-DRAFT DNS Compression February 1999
10. References
[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 13, November 1987
Koch Expires December 1999 [Page 7]
INTERNET-DRAFT DNS Compression June 1999
[RFC1035] Mockapetris,P., "Domain Names - Implementation and
Specification", RFC 1035, STD 13, November 1987
@@ -386,20 +372,9 @@ INTERNET-DRAFT DNS Compression February 1999
[RFC1183] Everhart,C., Mamakos,L., Ullmann,R., Mockapetris,P., "New
DNS RR Definitions", RFC 1183, October 1990
Koch Expires August 1999 [Page 7]
INTERNET-DRAFT DNS Compression February 1999
[RFC2052] Gulbrandsen,A., Vixie,P. "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996
[RFC2065] Eastlake,D., Kaufman,C. "Domain Name System Security
Extensions" RFC 2065, January 1997
[RFC2119] Bradner,S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997
@@ -414,17 +389,18 @@ INTERNET-DRAFT DNS Compression February 1999
[RFC2230] Atkinson,R., "Key Exchange Delegation Record for the DNS",
RFC 2230, November 1997
[RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC
2535, March 1999
[RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
RFC 2606, BCP 32, June 1999
[EDNS0] Vixie,P., "Extension mechanisms for DNS (EDNS0)", draft-
ietf-dnsind-edns0-XX.txt, work in progress
[BINLABELS] Crawford,M., "Binary Labels in the Domain Name System",
draft-ietf-dnsind-binary-labels-XX.txt, work in progress
[TESTTLD] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
<draft-ietf-dnsind-test-tlds-XX.txt>, work in progress
11. Author's Address
Peter Koch
@@ -433,17 +409,12 @@ INTERNET-DRAFT DNS Compression February 1999
Postfach 10 01 31
D-33501 Bielefeld
Germany
Koch Expires December 1999 [Page 8]
INTERNET-DRAFT DNS Compression June 1999
+49 521 106 2902
<pk@TechFak.Uni-Bielefeld.DE>
Koch Expires August 1999 [Page 8]
Koch Expires December 1999 [Page 9]

580
doc/draft/draft-ietf-dnsind-local-names-06.txt → doc/draft/draft-ietf-dnsind-local-names-07.txt
View File

@@ -1,12 +1,12 @@
DNS Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT IBM
Expires December 1999 June 1999
INTERNET-DRAFT Local Domain Names
November 1998
Expires May 1999
draft-ietf-dnsind-local-names-07.txt
Local DNS Names
----- --- -----
Local Domain Name System (DNS) Names
----- ------ ---- ------ ----- -----
Donald E. Eastlake 3rd
@@ -14,12 +14,12 @@ INTERNET-DRAFT Local Domain Names
Status of This Document
This draft, file name draft-ietf-dnsind-local-names-06.txt, is
intended to be become an Informational RFC. Distribution of this
document is unlimited. Comments should be sent to the DNS mailing
list <namedroppers@internic.net> or to the author.
This draft, file name draft-ietf-dnsind-local-names-07.txt.
Distribution of this document is unlimited. Comments should be sent
to the DNS mailing list <namedroppers@internic.net> or to the author.
This document is an Internet-Draft. Internet-Drafts are working
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
@@ -30,6 +30,12 @@ Status of This Document
Drafts as reference material or to cite them other than as a
``working draft'' or ``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.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
@@ -40,26 +46,33 @@ Status of This Document
Abstract
A set of second level domain names are defined under a new top level
domain name such that local private DNS zones can be maintained
similar to the private IP addresses reserved in [RFC 1918]. These
zone locally appear to be part of the global DNS name tree.
Additional second level domain names are assigned under this TLD for
loopback addresses and IPv6 link and site local addresses.
It is increasingly common for their to be "local" domain names which
are not intended to be seen from the global Internet. In some cases
this if for policy reasons, in other cases because they map to IP
addresses or other data which is only locally meaningful [RFC 1918,
2373].
A new top level domain (TLD) name (.local) is reserved and a name
structure suggested below this TLD such that local private DNS zones
can safely be created without fear of conflict if these names should
leak out of a private enclave. It addition, a method of providing
DNS service for these names is suggested such that they are
maintained privately, similar to the reserved private IP addresses,
Donald E. Eastlake 3rd [Page 1]
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT Local DNS Names
yet locally appear to be part of the global DNS name tree and are
reachable by a local resolver with no special knowledge. Additional
second level domain names are assigned under this TLD for IPv6 link
and site local addresses and loopback functions.
Acknowledgments
The valuable contributions of the following persons are gratefully
@@ -71,33 +84,68 @@ Acknowledgments
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT Local DNS Names
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Acknowledgments............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Local Names Via The .local Top Level Domain.............3
2.1 Local DNS Server Specifics.............................6
2.2 Local in-addr.arpa Zones...............................7
2.3 Name Conflicts.........................................7
2.4 Nested Enclaves........................................8
3. Other Names in .local...................................8
4. Security Considerations.................................8
4.1 Strength of Privacy Offered............................8
4.2 Interaction with DNSSEC................................9
4.3 Network Abuse..........................................9
Table of Contents..........................................3
References................................................10
Author's Address..........................................10
Expiration and File Name..................................10
1. Introduction............................................4
2. Local Names Via The .local Top Level Domain.............5
2.1 Local DNS Server Specifics.............................7
2.2 Local in-addr.arpa Zones...............................8
2.3 Name Conflicts.........................................8
2.4 Nested Enclaves........................................9
3. Other Names in .local...................................9
4. Security Considerations.................................9
4.1 Strength of Privacy Offered............................9
4.2 Interaction with DNSSEC...............................10
Appendix A: the .local zone...............................11
Appendix B: the .in-addr.arpa zone.......................13
References................................................11
Author's Address..........................................11
Expiration and File Name..................................11
@@ -112,7 +160,23 @@ Table of Contents
Donald E. Eastlake 3rd [Page 2]
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT Local DNS Names
@@ -121,8 +185,8 @@ INTERNET-DRAFT Local DNS Names
1. Introduction
The global Internet Domain Name System (DNS) is documented in [RFC
1034, 1035, 1591] and numerous additional Requests for Comment. It
defines a tree of names starting with root, ".", immediately below
1034, 1035, 1591, 2606] and numerous additional Requests for Comment.
It defines a tree of names starting with root, ".", immediately below
which are top level domain names such as .com and .us. Below top
level domain names there are normally additional levels of names.
@@ -133,11 +197,13 @@ INTERNET-DRAFT Local DNS Names
appeared. In many cases, organizations have hosts or resources that
they specifically want to reference with DNS names but which they
also want to be walled off from global access and even from global
knowledge of the DNS name.
knowledge of the DNS name for the resource.
In the realm of IP addresses, this has been accomplished by reserving
three blocks of addresses as documented in [RFC 1918]. Familiarity
with the contents of that RFC is assumed.
three blocks of IPv4 addresses as documented in [RFC 1918] and by
allocating parts of the IPv6 address space for link and site local
addresses [RFC 2373]. Familiarity with the contents of these RFCs is
assumed. Addresses in these blocks are not to be globally routed.
In the DNS area, local private names have generally been achieved in
the past by "splitting" DNS at the enclave boundary, giving different
@@ -145,7 +211,7 @@ INTERNET-DRAFT Local DNS Names
of the enclave, using different servers for inside and outside, etc.
as mentioned in [RFC 1918]. Such relatively complex configuration
diddling is at variance with the simple global tree structure of the
initial DNS.
initial DNS concept.
This document specifies an alternative approach to achieving the
effect of local names that is more in tune with the concept of a
@@ -154,28 +220,32 @@ INTERNET-DRAFT Local DNS Names
continue to work.
[RFC 1918] requires that private IP addresses not be indirectly
exposed to the general Internet via DNS records or otherwise. This
exposed to the general Internet via DNS records or otherwise. By
implication, the same would be true of IPv6 local addresses. This
RFC provides the recommended way to accomplish such private IP
address hiding and carves out an exception thereto for the addresses
of the servers for some zones which are children of the .local top
level domain name.
address hiding and carves out a limited exception thereto for the
addresses of the servers for some zones which are children of the
.local top level domain name.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT Local DNS Names
2. Local Names Via The .local Top Level Domain
The fundamental idea, as described in more detail below, is to define
second level domains under .local which are served by DNS name
servers that have private IP addresses. These server's addresses
would only be routed within the domain to which the names are local.
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT Local DNS Names
Thus the servers, and the names and resource records inside them,
would not be directly accessible outside the enclave, if the
guidelines in this document are followed.
@@ -220,20 +290,20 @@ INTERNET-DRAFT Local DNS Names
| example
+---------------------O pubhost6
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT Local DNS Names
Starting at the bottom, pubhost6 is intended to illustrate an
ordinary host connected to the Internet with domain name
pubhost6.example.com. Though not indicated in the above diagram,
every DNS zone is in fact served by at least two hosts (and some but
substantially more). The addresses of the servers for the root (.),
.com, and example.com zones would all be in the public portion of the
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT Local DNS Names
IP address space, i.e., in the space of all unicast IP addresses not
reserved for private use.
@@ -278,6 +348,14 @@ INTERNET-DRAFT Local DNS Names
that privhost3 and pubhost4 are actually the same physical machine.
The could be accomplished equally well by storing a single public
address for that host under both the public and private names or by
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT Local DNS Names
having the host answer to both a public IP address stored under the
public name and a private IP address stored under the private name.
In the later case you could even also store the public address along
@@ -285,13 +363,6 @@ INTERNET-DRAFT Local DNS Names
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT Local DNS Names
2.1 Local DNS Server Specifics
A variety of second level names are provided in the .local zone each
@@ -336,15 +407,8 @@ INTERNET-DRAFT Local DNS Names
enclave to private IP addresses which have a different meaning for
that resolver.
The Appendix A to this document gives the recommended initial content
of the .local zone.
Donald E. Eastlake 3rd [Page 6]
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT Local DNS Names
@@ -353,16 +417,14 @@ INTERNET-DRAFT Local DNS Names
2.2 Local in-addr.arpa Zones
Inverse lookup of local names corresponding to private IP addresses
needs to be provided via the in-addr.arpa zone. Appendix B contains
recommended additions to the in-addr.arpa zone (or subzones thereof)
to accomplish this. Because of the fixed naming within this zone,
different names with different numbers of servers or different
addresses can not be provided. As with the forward .local entries,
the actual NS RRs in the servers serving the private portions of the
inverse in-addr.arpa will dominate. When one of these is queried by
a resolver, it can provide information on additional servers for that
particular subzone in the private IP address portion of the in-
addr.arpa tree.
needs to be provided via the in-addr.arpa and ip6.int zones. Because
of the fixed naming within this zone, different names with different
numbers of servers or different addresses can not be provided. As
with the forward .local entries, the actual NS RRs in the servers
serving the private portions of the inverse in-addr.arpa will
dominate. When one of these is queried by a resolver, it can provide
information on additional servers for that particular subzone in the
private IP address portion of the in-addr.arpa tree.
@@ -381,9 +443,9 @@ INTERNET-DRAFT Local DNS Names
domain name of the enclave SHOULD always be prefixed to .local.
For example, a company might have
host1.company.co.xy
host1.company.example
as a globally accessible host and
host2.company.co.xy.b3.local
host2.company.example.b3.local
as a host for internal use only. The global name could normally be
resolvable anywhere on the Internet while the local name could not be
resolved anywhere except within the company enclave.
@@ -394,22 +456,23 @@ INTERNET-DRAFT Local DNS Names
names, such as host3. For DNS look up purposes, such a name must be
expanded into a fully qualified domain name and a "search list" of
possible suffix qualifications is tried. If, for example, both
host4.school.ac.xy and host4.school.ac.xy.b3.local existed, then a
local reference to "host4" would be ambiguous and could lead to
either machine depending on the order of qualifications tried. This
order could even be different in different pieces of local software
or on different local hosts, resulting in substantial confusion. For
this reason, it is strongly recommended that disjoint name sets be
host4.school.ac.example and host4.school.ac.example.b3.local existed,
then a local reference to "host4" would be ambiguous and could lead
to either machine depending on the order of qualifications tried.
This order could even be different in different pieces of local
software or on different local hosts, resulting in substantial
confusion. For this reason, it is strongly recommended that disjoint
name sets be used for global and local entity unqualified domain
names and that fully qualified domain names be used wherever
Donald E. Eastlake 3rd [Page 7]
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT Local DNS Names
used for global and local entity unqualified domain names and that
fully qualified domain names be used wherever practical.
practical.
@@ -430,8 +493,11 @@ INTERNET-DRAFT Local DNS Names
Three additional second level domain names are assigned in the .local
top level domain for other types of local names.
In particular, link.local and site.local are reserved for use in
qualifying IPv6 link local names and site local names.
In particular,
link.local and
site.local
are reserved for use in qualifying IPv6 link local names and site
local names.
In addition, loopback.local is assigned and given the loopback
address.
@@ -441,34 +507,36 @@ INTERNET-DRAFT Local DNS Names
4. Security Considerations
This section discusses the strength of the privacy offered by using
subzones of .local, interactions with DNS security, and possible
interaction with network abuse.
subzones of .local and interactions with DNS security.
4.1 Strength of Privacy Offered
It should be noted that the privacy of the DNS information protected
by storing it in servers with private IP addresses is not strong. It
is completely dependent on the integrity of enclave perimeter routing
to make these servers inaccessible. And it may occasionally leak out
in any case due to inclusion in email address fields, web pages, and
the like, although such leakage should be no worse than current split
DNS implementations of DNS data hiding.
Local names, as proposed herein, are not intended to be a strong
security mechanism.
Software should not depend on local names being accessible only
within a particular enclave as someone could deliberately create the
The privacy of the DNS information protected by storing it in servers
with private IP addresses is weak. It is completely dependent on the
integrity of enclave perimeter routing to make these servers
inaccessible. And it may occasionally leak out in any case due to
inclusion in email address fields, web pages, and the like, although
such leakage should be no worse than current split DNS
Donald E. Eastlake 3rd [Page 8]
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT Local DNS Names
same names within a different enclave even if the names incorporate
the name of the original enclave in an attempt to avoid such
conflicts.
implementations of DNS data hiding.
Software should not depend on local names being accessible only
within a particular enclave as someone could deliberately create the
same names within a different enclave. This is true even if, as
recommended herein, the names incorporate the domain name of the
original enclave in an attempt to avoid such conflicts.
@@ -476,34 +544,14 @@ INTERNET-DRAFT Local DNS Names
Although an enclave may derive some amount of security by virtue of
its isolation, it will normally be desirable to implement DNS
security [draft-ietf-dnssec-secext2-*.txt] within the enclave. The
enclave owner should generate their own keys and sign their subzone
of .local. However, a signed copy of their public key can not be
included in the .local zone as it is different for every enclave.
Thus, to authenticate the .local subzone contents, it will be
necessary to sign the KEY RR at the apex of the local subzone of
.local with the .local zone key or another key that is trusted by
local resolvers or staticly configure the public key for the .local
subzone in local resolvers.
4.3 Network Abuse
Use of the defined private server second level domain names under
return addresses, or the like, could cause DNS, SMTP, and many other
types of references to IP addresses in the [RFC 1918] blocks. This
can occur from within a firewall due to web browsing or email
processing of web pages or email from virtually anywhere in the
Internet. However, this is not a new situation as anyone who
controls any zone in the DNS, say zone.foo.example, can, although
this violates [RFC 1918], create entries therein with arbitrary IP
addresses (including multicast and undefined formats). Then, by
using these name entries in email, web links, etc., attempt to cause
a variety of spurious protocol connections to those addresses.
Use of .local at least provides some warning that a name may be not
be correctly resolvable.
security [RFC 2535] within the enclave. The enclave owner should
generate their own keys and sign their subzone of .local. However, a
signed copy of their public key can not be included in the .local
zone as it is different for every enclave. Thus, to authenticate the
.local subzone contents, it will be necessary to sign the KEY RR at
the apex of the local subzone of .local with the .local zone key or
another key that is trusted by local resolvers or staticly configure
the public key for the .local subzone in local resolvers.
@@ -518,7 +566,23 @@ INTERNET-DRAFT Local DNS Names
Donald E. Eastlake 3rd [Page 9]
D. Eastlake 3rd [Page 10]
INTERNET-DRAFT Local DNS Names
@@ -544,8 +608,14 @@ References
RFC 1958 - B. Carpenter, "Architectural Principles of the Internet",
06/06/1996.
draft-ietf-dnssec-secext2-*.txt - D. Eastlake "Domain Name System
Security Extensions".
RFC 2373 - R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", July 1998
RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
RFC 2606 - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
@@ -553,202 +623,40 @@ Author's Address
Donald E. Eastlake 3rd
IBM
318 Acton Street
Carlisle, MA 01741 USA
65 Shindegan Hill Road, RR #1
Carmel, NY 10512 USA
Telephone: +1 978-287-4877
+1 914-784-7913
FAX: +1 978-371-7148
Telephone: +1 914-276-2668 (h)
+1 914-784-7913 (w)
FAX: +1 914-784-3833 (w)
EMail: dee3@us.ibm.com
Expiration and File Name
This draft expires May 1999.
This draft expires December 1999.
Its file name is draft-ietf-dnsind-local-names-06.txt.
Its file name is draft-ietf-dnsind-local-names-07.txt.
Donald E. Eastlake 3rd [Page 10]
D. Eastlake 3rd [Page 11]
INTERNET-DRAFT Local DNS Names
Appendix A: the .local zone
===== The .local zone suggested initial contents ====
local. IN SOA ... ... (
1234 ; serial
90000 ; refresh, 25 hours
36000 ; retry, 10 hours
3456000 ; expiry, 40 days
43200 ) ; minimum of 12 hours
NS ... ; actual servers for .local zone
NS ...
...
loopback A 127.0.0.1
AAAA 0::1
MX 100 loopback.local.
a2.local. NS ns1.a2.local.
NS ns2.a2.local.
ns1.a2.local. A 10.1.1.2
ns2.a2.local. A 10.1.2.2
a3.local. NS ns1.a3.local.
NS ns2.a3.local.
NS ns3.a3.local.
ns1.a3.local. A 10.1.1.2
ns2.a3.local. A 10.1.2.2
ns3.a3.local. A 10.2.1.2
a4.local. NS ns1.a4.local.
NS ns2.a4.local.
NS ns3.a4.local.
NS ns4.a4.local.
ns1.a4.local. A 10.1.1.2
ns2.a4.local. A 10.1.2.2
ns3.a4.local. A 10.2.1.2
ns4.a4.local. A 10.128.1.2
b2.local. NS ns1.b2.local.
NS ns2.b2.local.
ns1.b2.local. A 172.16.1.2
ns2.b2.local. A 172.16.2.2
b3.local. NS ns1.b3.local.
NS ns2.b3.local.
NS ns3.b3.local.
ns1.b3.local. A 172.16.1.2
ns2.b3.local. A 172.16.2.2
ns3.b3.local. A 172.16.128.2
Donald E. Eastlake 3rd [Page 11]
INTERNET-DRAFT Local DNS Names
c2.local. NS ns1.c2.local.
NS ns2.c2.local.
ns1.c2.local. A 192.168.1.2
ns2.c2.local. A 192.168.2.2
c3.local. NS ns1.c3.local.
NS ns2.c3.local.
NS ns3.c3.local.
ns1.c3.local. A 192.168.1.2
ns2.c3.local. A 192.168.2.2
ns3.c3.local. A 192.168.128.2
Donald E. Eastlake 3rd [Page 12]
INTERNET-DRAFT Local DNS Names
Appendix B: the .in-addr.arpa zone
===== Auggested additional entries in the in-addr.arpa zone ====
10.in-addr.arpa. NS ns1.a2.local.
NS ns2.a2.local.
ns1.a2.local. A 10.1.1.2
ns2.a2.local. A 10.1.2.2
16.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
ns1.b2.local. A 172.16.1.2 ; one set of glue records
ns2.b2.local. A 172.16.2.2 ; for all the b2 cases
17.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
18.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
19.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
20.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
21.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
22.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
23.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
24.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
25.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
26.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
27.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
28.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
29.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
30.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
31.172.in-addr.arpa. NS ns1.b2.local.
NS ns2.b2.local.
168.192.in-addr.arpa. NS ns1.c2.local.
NS ns2.c2.local.
ns1.c2.local. A 192.168.1.2
ns2.c2.local. A 102.168.2.2
Donald E. Eastlake 3rd [Page 13]
D. Eastlake 3rd [Page 12]

390
doc/draft/draft-ietf-dnsind-tsig-08.txt → doc/draft/draft-ietf-dnsind-tsig-11.txt
View File

@@ -1,18 +1,13 @@
DNSIND Working Group Paul Vixie (Ed.) (ISC)
INTERNET-DRAFT Olafur Gudmundsson (TISLabs)
INTERNET-DRAFT Olafur Gudmundsson (NAILabs)
Donald Eastlake 3rd (IBM)
Brian Wellington (TISLabs)
<draft-ietf-dnsind-tsig-08.txt> February 1999
Brian Wellington (NAILabs)
<draft-ietf-dnsind-tsig-11.txt> July 1999
Amends: RFC 1035
Secret Key Transaction Signatures for DNS (TSIG)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
@@ -34,7 +29,6 @@
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This protocol allows for transaction level authentication using
@@ -46,44 +40,40 @@
it is expected that a network administrator will statically configure
name servers and clients using some out of band mechanism such as
sneaker-net until a secure automated mechanism for key distribution
Expires August 1999 [Page 1]
INTERNET-DRAFT DNS TSIG February 1999
is available.
Expires January 2000 [Page 1]
INTERNET-DRAFT DNS TSIG July 1999
1 - Introduction
1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
hierarchical distributed database system that provides information
fundamental to Internet operations, such as name <=> address translation
and mail handling information. DNS has recently been extended [RFC2065]
and mail handling information. DNS has recently been extended [RFC2535]
to provide for data origin authentication, and public key distribution,
all based on public key cryptography and public key based digital
signatures. To be practical, this form of security generally requires
extensive local caching of keys and tracing of authentication through
multiple keys and signatures to a pre-trusted locally configured key.
1.2. One difficulty with the [RFC2065] scheme is that common DNS
1.2. One difficulty with the [RFC2535] scheme is that common DNS
implementations include simple ``stub'' resolvers which do not have
caches. Such resolvers typically rely on a caching DNS server on
another host. It is impractical for these stub resolvers to perform
general [RFC2065] authentication and they would naturally depend on
general [RFC2535] authentication and they would naturally depend on
their caching DNS server to perform such services for them. To do so
securely requires secure communication of queries and responses.
[RFC2065] provides public key transaction signatures to support this but
[RFC2535] provides public key transaction signatures to support this but
such signatures are very expensive computationally to generate. In
general, these require the same complex public key logic that is
impractical for stubs. This document specifies an efficient secret key
based transaction signature that avoids these difficulties.
1.3. A second area where use of straight [RFC2065] public key based
1.3. A second area where use of straight [RFC2535] public key based
mechanisms may be impractical is authenticating dynamic update [RFC2136]
requests. [RFC2065] provides for request signatures but with [RFC2065]
requests. [RFC2535] provides for request signatures but with [RFC2535]
they, like transaction signatures, require computationally expensive
public key cryptography and complex authentication logic. Secure Domain
Name System Dynamic Update ([RFC2137]) describes how different keys are
@@ -94,18 +84,13 @@
1.4. A further use of this mechanishm is to protect zone transfers. In
this case the data covered would be the whole zone transfer including
any glue records sent. The protocol described by [RFC2065] does not
any glue records sent. The protocol described by [RFC2535] does not
protect glue records and unsigned records unless SIG(0) (transaction
signature) is used.
Expires January 2000 [Page 2]
Expires August 1999 [Page 2]
INTERNET-DRAFT DNS TSIG February 1999
INTERNET-DRAFT DNS TSIG July 1999
1.5. The signature mechanism proposed in this document uses shared
secret keys to establish trust relationship between two entities. Such
@@ -132,8 +117,9 @@
ERROR = 16 (BADSIG)
ERROR = 17 (BADKEY)
ERROR = 18 (BADTIME)
ERROR = 19 (BADID)
1.7. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in [RFC 2119].
2 - TSIG RR Format
@@ -146,19 +132,9 @@
computed to cover a particular DNS transaction and are not DNS RRs in
the usual sense.
Expires January 2000 [Page 3]
Expires August 1999 [Page 3]
INTERNET-DRAFT DNS TSIG February 1999
INTERNET-DRAFT DNS TSIG July 1999
2.2 TSIG Calculation
@@ -166,10 +142,11 @@
value in storing or retransmitting them, thus the TSIG RR should be
discarded once it has been used to authenticate DNS message. The only
Message Digest algorithm specified in this document is ``HMAC-MD5'' (see
[RFC1321], [RFC2104]). Other algorithms can be specified at later date.
Names and definitions of new algorithms should be registered with IANA.
All multi-octet integers in TSIG Record are sent in network byte order
(see [RFC1035 2.3.2]).
[RFC1321], [RFC2104]). The ``HMAC-MD5'' algorithm is mandatory to
implement for interoperability. Other algorithms can be specified at a
later date. Names and definitions of new algorithms should be
registered with IANA. All multi-octet integers in TSIG Record are sent
in network byte order (see [RFC1035 2.3.2]).
2.3. Record Format
@@ -199,24 +176,15 @@
RdLen (variable)
Expires January 2000 [Page 4]
Expires August 1999 [Page 4]
INTERNET-DRAFT DNS TSIG February 1999
INTERNET-DRAFT DNS TSIG July 1999
RDATA
Field Name Data Type Notes
------------------------------------------------------------------
------------------------------------------------------------------
Algorithm Name domain-name Name of the algorithm
expressed as a domain name.
Time Signed u_int48_t seconds since 1-Jan-70 UTC.
@@ -227,13 +195,12 @@
Original ID u_int16_t original message ID
Error u_int16_t expanded RCODE covering
signature processing.
Other Len u_int16_t length, in octets, of Other Data.
Other Len u_int16_t length, in octets, of Other
Data.
Other Data octet stream undefined by this protocol.
2.4. Example
NAME GW-DENVAX-0042.HOME.VIX.COM.
TYPE TSIG
@@ -258,13 +225,9 @@
Other Len 0
Other Data empty
Expires January 2000 [Page 5]
Expires August 1999 [Page 5]
INTERNET-DRAFT DNS TSIG February 1999
INTERNET-DRAFT DNS TSIG July 1999
3 - Protocol Operation
@@ -272,29 +235,34 @@
Once the outgoing message has been constructed, the keyed message digest
operation can be performed. The resulting message digest will then be
stored in a TSIG which is appended to the additional data section.
Appending a transaction signature to an DNS message is not allowed to
result in a truncated response; a TCP connection must be used to prevent
the truncation. To force a TCP connection, the server is permitted to
return an answer with no data only TSIG attached and TC bit set and
RCODE 0 (NOERROR). The client should at this point retry the request
using TCP (per [RFC1035 4.2.2]).
stored in a TSIG which is appended to the additional data section (the
ARCOUNT is incremented to reflect this). Appending a transaction
signature to an DNS message is not allowed to result in a truncated
response; a TCP connection must be used to prevent the truncation. To
force a TCP connection, the server is permitted to return an answer with
no data only TSIG attached and TC bit set and RCODE 0 (NOERROR). The
client should at this point retry the request using TCP (per [RFC1035
4.2.2]).
3.2. TSIG processing on incoming messages
Upon receipt of a message with a TSIG RR, the TSIG RR is copied to a
If an incoming message contains a TSIG record, it MUST be the last
record in the additional section. Multiple TSIG records are not
allowed. If a TSIG record is prsent in any other position, the packet
is dropped and a response with RCODE 1 (should be sent). Upon receipt
of a message with a correctly placed TSIG RR, the TSIG RR is copied to a
safe location, removed from the DNS Message, and decremented out of the
DNS Message Headers ARCOUNT. At this point the keyed message digest
operation is performed. If the algorithm name or key name is unknown to
the recipient, or if the message digests do not match, the whole DNS
Message must be discarded. A response with RCODE 9 (NOTAUTH) should be
sent back to the originator with TSIG ERROR 17 (BADKEY), if no key is
available to sign this message it must be sent unsigned (Signature Size
== 0 and empty signature). A message to the system operations log
should to be generated, to warn the operations staff of a possible
security incident in progress. Care should be taken to ensure that
logging of this type of event does not open the system to a denial of
service attack.
Message must be discarded. If the message is a query, a response with
RCODE 9 (NOTAUTH) should be sent back to the originator with TSIG ERROR
17 (BADKEY) or TSIG error 16 (BADSIG). If no key is available to sign
this message it must be sent unsigned (Signature Size == 0 and empty
signature). A message to the system operations log should to be
generated, to warn the operations staff of a possible security incident
in progress. Care should be taken to ensure that logging of this type
of event does not open the system to a denial of service attack.
3.3. Time values used in TSIG calculations
@@ -306,19 +274,16 @@
their ``on the wire'' format, in the following order: first Time Signed,
then Fudge. For example:
Expires January 2000 [Page 6]
INTERNET-DRAFT DNS TSIG July 1999
Field Name Value Wire Format Meaning
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997
Fudge 300 01 2C 5 minutes
Expires August 1999 [Page 6]
INTERNET-DRAFT DNS TSIG February 1999
3.4. TSIG Variables and Coverage
When generating or verifying a transaction signature, the following data
@@ -329,9 +294,8 @@
A whole and complete DNS message in wire format, before the TSIG RR has
been added to the additional data section and before the DNS Message
Header's ARCOUNT field has been incremented to contain the TSIG RR. If
the message is of a type that can be forwarded (i.e. update) and the
message ID differs from the original message ID, the original message ID
is substituted for the message ID.
the message ID differs from the original message ID, the original
message ID is substituted for the message ID.
3.4.2. TSIG Variables
@@ -358,26 +322,21 @@
case. The use of label types other than 00 is not defined for this
specification.
Expires January 2000 [Page 7]
INTERNET-DRAFT DNS TSIG July 1999
3.4.3. Request Signature
Response signatures will include the request signature in their digest.
The request's signature is digested in wire format, including the
following fields:
Expires August 1999 [Page 7]
INTERNET-DRAFT DNS TSIG February 1999
Field Type Description
---------------------------------------------------------
Signature Length u_int16_t in network byte order
Signature Data octet stream exactly as transmitted
3.5. Padding
Digested components are fed into the hashing function as a continuous
@@ -393,8 +352,7 @@
Digest components for requests are:
DNS Message (request)
TSIG Variables (response)
TSIG Variables (request)
Note that some older name servers will not accept requests with a
nonempty additional data section, but clients should only attempt signed
@@ -411,26 +369,17 @@
DNS Message (response)
TSIG Variables (response)
Expires January 2000 [Page 8]
Expires August 1999 [Page 8]
INTERNET-DRAFT DNS TSIG February 1999
INTERNET-DRAFT DNS TSIG July 1999
4.3. TSIG on TSIG Error returns
When a server detects an error in TSIG checks relating to the key or
signature, the server should send back an unsigned error message. If an
error is detected that does not relate to the key or signature, the
server should send back a signed error message. Digest components are:
signature, the server should send back an unsigned error message
(Signature Size == 0 and empty signature). If an error is detected that
does not relate to the key or signature, the server should send back a
signed error message. Digest components are:
Request signature (if the request signature validated)
DNS Message (response)
@@ -461,29 +410,20 @@
TSIG check fails, the client MUST close the connection. If the client
does not get TSIG frequently enough (as specified above) it SHOULD
assume the connection has been hijacked and it SHOULD close the
connection. Client should treat this the same way as any other
interrupted transfer.
connection. Client should treat this the same way as they would any
other interrupted transfer (although the exact behavior is not
specified).
Expires January 2000 [Page 9]
Expires August 1999 [Page 9]
INTERNET-DRAFT DNS TSIG February 1999
INTERNET-DRAFT DNS TSIG July 1999
4.5. Server TSIG checks
Upon receipt of a message, server will check if there is a TSIG RR. If
one exists, the server is required to return a TSIG RR in the response.
The server MUST perform the following checks in the following order,
check KEY, check ID, check TIME values, check Signature.
check KEY, check TIME values, check Signature.
4.5.1. KEY check and error handling
@@ -492,15 +432,7 @@
TSIG ERROR 17 (BADKEY). This response should be unsigned as specified
in [4.3]. The server should log the error.
4.5.2. ID check and error handling
If the message is has an opcode that may not be forwarded, the ID field
in the DNS header is expected to match the Original ID field in the TSIG
record. If this is not the case, the server MUST generate an error
response with RCODE 9 (NOTAUTH) and TSIG ERROR 19 (BADID). The server
MUST sign this error response with the same key the client used.
4.5.3. TIME check and error handling
4.5.2. TIME check and error handling
If the server time is outside the time interval specified by the request
(which is: Time Signed, plus/minus Fudge), the server MUST generate an
@@ -512,25 +444,13 @@
verification detecting another BADTIME error. The data signed is
specified in [4.3].
4.5.4. Signature check and error handling
4.5.3. Signature check and error handling
If TSIG fails to verify, the server MUST generate an error response as
specified in [4.3] with RCODE of 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG).
This response should be unsigned as specified in [4.3]. The server
should log the error.
Expires August 1999 [Page 10]
INTERNET-DRAFT DNS TSIG February 1999
4.6. Client processing of answer
When a client receives a response from a server it expects a TSIG from,
@@ -543,6 +463,11 @@
response as it was TSIG error as specified in [4.3]. An message
containing an unsigned TSIG record or a TSIG record which fails
verification should not be considered an acceptable response; the client
Expires January 2000 [Page 10]
INTERNET-DRAFT DNS TSIG July 1999
should log an error and continue to wait for a signed response until the
request times out.
@@ -555,14 +480,7 @@
should never sign a response with a different key than signed the
request.
4.6.2. ID error handling
If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
validates, and the TSIG ERROR is 19 (BADID), this means that for some
reason, the server received a forwarded message of a type that should
not be forwarded. This likely indicates a faulty server.
4.6.3. Time error handling
4.6.2. Time error handling
If the response RCODE is 9 (NOTAUTH), and TSIG ERROR is 18 (BADTIME) or
the TSIG times in request and answer do not overlap, then this is a TIME
@@ -571,20 +489,7 @@
resolvers MUST NOT adjust any clocks in the client based on BADTIME
errors, but the server's time in other data field should be logged.
Expires August 1999 [Page 11]
INTERNET-DRAFT DNS TSIG February 1999
4.6.4. Signature error handling
4.6.3. Signature error handling
If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this
is a signature error, and client MAY retry the request with a new
@@ -602,9 +507,13 @@
TSIG. If the TSIG passes all checks, the forwarding server has the
obligation of including a TSIG of his own, to the destination or the
next forwarder. If no transaction security is available to the
destination and response has the AD flag (see [RFC2065]), the forwarder
destination and response has the AD flag (see [RFC2535]), the forwarder
MUST unset the AD flag before adding the TSIG to the answer.
Expires January 2000 [Page 11]
INTERNET-DRAFT DNS TSIG July 1999
5 - Shared Secrets
5.1. Secret keys are very sensitive information and all available steps
@@ -628,19 +537,10 @@
be at least as long as the keyed message digest , i.e., 16 bytes for
HMAC-MD5 or 20 bytes for HMAC-SHA1.
Expires August 1999 [Page 12]
INTERNET-DRAFT DNS TSIG February 1999
6 - Security Considerations
6.1. The approach specified here is computationally much less expensive
than the signatures specified in [RFC2065]. As long as the shared
than the signatures specified in [RFC2535]. As long as the shared
secret key is not compromised, strong authentication is provided for the
last hop from a local name server to the user resolver.
@@ -656,9 +556,13 @@
source data can come from a compromised zone master or can be corrupted
during transit from an authentic zone master to some ``caching
forwarder.'' However, if the server is faithfully performing the full
[RFC2065] security checks, then only security checked data will be
[RFC2535] security checks, then only security checked data will be
available to the client.
Expires January 2000 [Page 12]
INTERNET-DRAFT DNS TSIG July 1999
7 - IANA Considerations
A new algorithm name should be a valid domain name of the type
@@ -668,28 +572,6 @@
IANA must maintain control over the SIG-ALG.REG.INT domain.
Expires August 1999 [Page 13]
INTERNET-DRAFT DNS TSIG February 1999
7 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
@@ -705,13 +587,13 @@
Recommendations for Security,'' RFC 1750, DEC, CyberCash &
MIT, December 1995.
[RFC2065] D. Eastlake , C Kaufman, ``Domain Name System Security
Extensions,'' RFC 2065, CyberCash & Iris, January 1997.
[RFC2104] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5
for Message Authentication,'' RFC 2104 , IBM, UCSD & IBM,
February 1997.
[RFC2119] S. Bradner, ``Key words for use in RFCs to Indicate
Requirement Levels,'' RFC 2119, Harvard, March 1997
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
& Cisco & DEC, April 1997.
@@ -719,77 +601,27 @@
[RFC2137] D. Eastlake 3rd ``Secure Domain Name System Dynamic Update,''
CyberCash, April 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
2535, IBM, March 1999.
Expires January 2000 [Page 13]
Expires August 1999 [Page 14]
INTERNET-DRAFT DNS TSIG February 1999
INTERNET-DRAFT DNS TSIG July 1999
9 - Authors' Addresses
Paul Vixie Olafur Gudmundsson
Internet Software Consortium TIS Labs at Network Associates
Internet Software Consortium NAILabs
950 Charter Street 3060 Washington Road, Route 97
Redwood City, CA 94063 Glenwood, MD 21738
+1 650 779 7001 +1 443 259 2389
<paul@vix.com> <ogud@tislabs.com>
<vixie@isc.org> <ogud@tislabs.com>
Donald E. Eastlake 3rd Brian Wellington
IBM TIS Labs at Network Associates
IBM NAILabs
65 Shindegan Hill Road, RR #1 3060 Washington Road, Route 97
Carmel, NY 10512 USA Glenwood, MD 21738
+1 914 783 7913 +1 443 259 2369
+1 914 784 7913 +1 443 259 2369
<dee3@us.ibm.com> <bwelling@tislabs.com>
Expires August 1999 [Page 15]
Expires January 2000 [Page 14]

599
doc/draft/draft-skwan-gss-tsig-04.txt Normal file
View File

@@ -0,0 +1,599 @@
INTERNET-DRAFT Stuart Kwan
Praerit Garg
James Gilroy
Microsoft Corp.
June 1999
<draft-skwan-gss-tsig-04.txt> Expires January 2000
GSS Algorithm for TSIG (GSS-TSIG)
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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
The TSIG protocol provides transaction level authentication for DNS.
TSIG is extensible through the definition of new algorithms. This
document specifies an algorithm based on the Generic Security Service
Application Program Interface (GSS-API) [RFC2078].
Expires January 2000 [Page 1]
INTERNET-DRAFT GSS-TSIG June 1999
Table of Contents
1: Introduction......................................................2
2: Protocol Overview.................................................3
2.1: GSS Details...................................................4
3: Client Protocol Details...........................................4
3.1: Negotiating Context...........................................4
3.1.1: Call GSS_Init_sec_context.................................5
3.1.2: Send TKEY Query to Server.................................6
3.1.3: Receive TKEY Query-Response from Server...................6
3.2: Context Established...........................................8
4: Server Protocol Details...........................................8
4.1: Negotiating Context...........................................8
4.1.1: Receive TKEY Query from Client............................9
4.1.2: Call GSS_Accept_sec_context...............................9
4.1.3: Send TKEY Query-Response to Client........................9
4.2: Context Established..........................................10
4.2.1: Terminating a Context....................................10
5: Sending and Verifying Signed Messages............................11
5.1: Sending a Signed Message - Call GSS_GetMIC...................11
5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............12
6: Security Considerations..........................................12
7: Acknowledgements.................................................13
8: References.......................................................13
1. Introduction
The Secret Key Transaction Signature for DNS [TSIG] protocol was
developed to provide a lightweight alternative to full DNS security
[RFC2535] and secure dynamic update [RFC2137], where full security is
impractical due to implementation complexity, management overhead, or
computational cost.
The [TSIG] protocol is extensible through the definition of new
algorithms. This document specifies an algorithm based on the Generic
Security Service Application Program Interface (GSS-API) [RFC2078].
GSS-API is a framework that provides an abstraction of security to the
application protocol developer. The security services offered can
include authentication, integrity, and confidentiality.
The GSS-API framework has several benefits:
* Mechanism and protocol independence. The underlying mechanisms that
realize the security services can be negotiated on the fly and varied
over time. For example, a client and server may use Kerberos for one
transaction, whereas that same server may use TLS with a different
client.
Expires January 2000 [Page 2]
INTERNET-DRAFT GSS-TSIG June 1999
* The protocol developer is removed from the responsibility of
creating and managing a security infrastructure. For example, the
developer does not need to create new key distribution or key
management systems. Instead the developer relies on the security
service mechanism to manage this on its behalf.
2. Protocol Overview
Readers that are unfamiliar with the GSS-API concepts are encouraged
to read the characteristics and concepts section of [RFC2078] before
examining this protocol in detail.
In GSS, client and server interact to create a "security context".
The security context is used to create and verify transaction
signatures on messages between the two parties. A unique security
context is required for each unique connection between client and
server.
Creating a security context involves a negotiation between client and
server. Once a context has been established, it has a finite lifetime
for which it can be used to secure messages. Thus there are three
states of a context associated with a connection:
+----------+
| |
V |
+---------------+ |
| Uninitialized | |
| | |
+---------------+ |
| |
V |
+---------------+ |
| Negotiating | |
| Context | |
+---------------+ |
| |
V |
+---------------+ |
| Context | |
| Established | |
+---------------+ |
| |
+----------+
Every connection begins in the uninitialized state.
Expires January 2000 [Page 3]
INTERNET-DRAFT GSS-TSIG June 1999
2.1 GSS Details
Client and server must be locally authenticated and have acquired
default credentials per [RFC2078] before using this protocol.
Not all flags used in GSS-API interfaces are specified in this
document. Where omitted, clients and servers may select the default
or use a value based on local system policy.
Not all error return values from GSS-API interfaces are specified in
this document. When errors are encountered, the caller should act
appropriately.
3. Client Protocol Details
A unique context is required for each server to which the client sends
secure messages. A context is identified by a context handle. A
client maintains a mapping of handles to servers,
(target_server_name, key_name, context_handle)
The value key_name also identifies a context handle, and is used on
the wire to indicate to a server which context should be used to
process the current request.
3.1 Negotiating Context
In GSS, establishing a security context involves the passing of opaque
tokens between the client and the server. The client generates the
initial token and sends it to the server. The server processes the
token and if necessary, returns a subsequent token to the client. The
client processes this token, and so on, until the negotiation is
complete. The number of times the client and server exchange tokens
depends on the underlying security mechanism. A completed negotiation
results in a context handle.
The TKEY resource record [TKEY] is used as the vehicle to transfer
tokens between client and server. The TKEY record is a general
mechanism for establishing secret keys for use with TSIG. For more
information, see [TKEY].
Expires January 2000 [Page 4]
INTERNET-DRAFT GSS-TSIG June 1999
3.1.1 Call GSS_Init_sec_context
The client obtains the first token by calling GSS_Init_sec_context.
The following input parameters are used. The outcome of the call
is indicated with the output values below. Consult [RFC2078] for
syntax definitions.
INPUTS
CONTEXT HANDLE input_context_handle = 0
INTERNAL NAME targ_name = DNS/<target_server_name>
OCTET STRING input_token = NULL
BOOLEAN replay_det_req_flag = TRUE
BOOLEAN mutual_req_flag = TRUE
BOOLEAN deleg_req_flag = TRUE (optional)
OUTPUTS
INTEGER major_status
CONTEXT HANDLE output_context_handle
OCTET STRING output_token
BOOLEAN replay_det_state
BOOLEAN mutual_state
The values of replay_det_state and mutual_state indicate if the
security package can provide replay detection and mutual
authentication, respectively. If one or both of these values
are FALSE, the client must abandon this protocol.
The deleg_req_flag is optional, and can be used if the client wants
the server to be able to call out to other services under the
context of the client.
If major_status indicates an error, the client must abandon the
protocol. Success values of major_status are GSS_S_CONTINUE_NEEDED
and GSS_S_COMPLETE. The exact success code is important during later
processing.
The handle output_context_handle is unique to this negotiation and
is stored in the client's mapping table as the context_handle that
maps to target_server_name.
Expires January 2000 [Page 5]
INTERNET-DRAFT GSS-TSIG June 1999
3.1.2 Send TKEY Query to Server
The output_token from GSS_Init_sec_context is transmitted to the
server in a query request for a TKEY record. The token itself
will be placed in a TKEY record in the additional records section of
the query. The domain-like name of the TKEY record set queried for
and the name of the supplied TKEY record in the additional section
will uniquely identify the security context to both the client and
server, and thus the client should use a value which is globally
unique.
TKEY Record
NAME = client-generated globally unique domain name string
(see [TKEY])
RDATA
Algorithm Name = gss-tsig.microsoft.com
Mode = 3 (GSS-API negotiation - see [TKEY])
Key Size = size of output_token
Key = output_token
Assign the remaining fields in the TKEY RDATA appropriate values
per [TKEY].
If the last call to GSS_Init_sec_context yielded a major_status value
of GSS_S_COMPLETE, then the message should be signed with a TSIG
record before being sent to the server. See section 5, Sending
and Verifying Signed Messages, for the signing procedure.
The query is transmitted to the server.
3.1.3 Receive TKEY Query-Response from Server
The server will return a standard TKEY query-response (see [TKEY]).
The response may indicate that TKEY is not supported, or that the
GSS-API mode and algorithm are not supported. If this is the case,
the client must abandon this algorithm.
If the value of the Error field in the TKEY RDATA (TKEY.Error) is
BADKEY, then the token provided by the client was invalid. The
client must abandon this algorithm.
If TKEY.Error indicates success, then the client may continue. The
next processing step depends on the value of major_status from the
most recent call to GSS_Init_sec_context: either GSS_S_COMPLETE or
GSS_S_CONTINUE.
Expires January 2000 [Page 6]
INTERNET-DRAFT GSS-TSIG June 1999
3.1.3.1 Value of major_status == GSS_S_COMPLETE
If the last call to GSS_Init_sec_context yielded a major_status value
of GSS_S_COMPLETE and a non-NULL output_token was sent to the server,
then the client side component of the negotiation is complete and the
client is awaiting confirmation from the server.
Confirmation will be in the form of a NOERROR query response
containing the last client supplied TKEY record in the answer section
of the query. The response may also be signed with a TSIG record,
and if present this signature must be verified using the procedure
detailed in section 5, Sending and Verifying Signed Messages.
If the message verification completes without an error, or if a TSIG
signature was not included, the context state is advanced to Context
Established. Proceed to section 3.2 for usage of the security
context.
3.1.3.2 Value of major_status == GSS_S_CONTINUE
If the last call to GSS_Init_sec_context yielded a major_status value
of GSS_S_CONTINUE, then the negotiation is not yet complete. The
server will respond to the TKEY query with a NOERROR query response
that contains a TKEY record in the answer section. The TKEY record
contains a token that is passed to GSS_Init_sec_context using the
parameters from the previous call and the following modifications:
INPUTS
CONTEXT HANDLE input_context_handle = context_handle
OCTET STRING input_token = token from Key field of
TKEY record
OUTPUTS
INTEGER major_status
OCTET STRING output_token
If major_status indicates an error, the client must abandon this
algorithm. Success values are GSS_S_CONTINUE and GSS_S_COMPLETE.
If major_status is GSS_S_CONTINUE the negotiation is not yet
finished. The token output_token must again be passed to the server
in a TKEY record. The negotiation sequence is repeated beginning
with section 3.1.2. The client should place a limit on the number
of continuations in a context negotiation to prevent endless
looping.
Expires January 2000 [Page 7]
INTERNET-DRAFT GSS-TSIG June 1999
If major_status is GSS_S_COMPLETE and output_token is non-NULL,
the client-side component of the negotiation is complete but the
token output_token must be passed to the server. The negotiation
sequence is repeated beginning with section 3.1.2.
If major_status is GSS_S_COMPLETE and output_token is NULL, context
negotiation is complete. The response from the server may be signed
with a TSIG record, and if present this signature must be verified
using the procedure detailed in section 5, Sending and
Verifying Signed Messages.
If the message verification completes without an error, or if a TSIG
signature was not included, the context state is advanced to Context
Established. Proceed to section 3.2 for usage of the security
context.
3.2 Context Established
When context negotiation is complete, the handle context_handle is
used for the generation and verification of transaction signatures.
The procedures for sending and receiving signed messages are given in
section 5, Sending and Verifying Signed Messages.
4. Server Protocol Details
As on the client-side, the result of a successful context negotiation
is a context handle used in future processing.
A server may be managing several contexts with several clients.
Clients identify their contexts by providing a key name in their
request. The server maintains a mapping of key names to handles:
(key_name, context_handle)
4.1 Negotiating Context
A server recognizes TKEY queries as security context negotiation
messages.
Expires January 2000 [Page 8]
INTERNET-DRAFT GSS-TSIG June 1999
4.1.1 Receive TKEY Query from Client
Upon receiving a TKEY query, the server must examine the Mode and
Algorithm Name fields to see if they match this algorithm. If they
match, the (key_name, context_handle) mapping table is searched for
the NAME value of the TKEY record. If the name is found in the table,
the corresponding context_handle is used in following GSS operations.
If the name is not found a new negotiation is started.
4.1.2 Call GSS_Accept_sec_context
The server performs its side of a context negotiation by calling
GSS_Accept_sec_context with the token provided by the client in the
TKEY record.
The server calls GSS_Accept_sec_context:
INPUTS
CONTEXT HANDLE input_context_handle = 0 if new negotiation,
context_handle if ongoing
OCTET STRING input_token = Key field from TKEY RR
OUTPUTS
INTEGER major_status
CONTEXT_HANDLE output_context_handle
OCTET STRING output_token
If this is the first call to GSS_Accept_sec_context in a new
negotiation, then output_context_handle is stored in the server's
key-mapping table as the context_handle that maps to the name of the
TKEY record.
4.1.3 Send TKEY Query-Response to Client
If major_status returns a GSS failure code, the negotiation has
failed. The server must respond to the client with a standard
TKEY query-response where the TKEY error field value is set to
BADKEY.
Success values for major_status are GSS_S_COMPLETE or GSS_S_CONTINUE.
Expires January 2000 [Page 9]
INTERNET-DRAFT GSS-TSIG June 1999
If major_status is GSS_S_COMPLETE the server component of the
negotiation is finished. The message from the client may be signed
with a TSIG RR, and if present this signature must be verified
using the procedure detailed in section 5, Sending and
Verifying Signed Messages. The server responds to the TKEY query
using a standard query response. If output_token is non-NULL, then it
must be returned to the client in a TKEY in the Answer section of the
response. If output_token is NULL, then the TKEY record received from
the client must be returned in the Answer section of the response.
The answer should be signed with a TSIG record per the procedure given
in section 5, Sending and Verifying Signed Messages.
The context state is advanced to Established. Section 4.2 discusses
the usage of the security context.
If major_status is GSS_S_CONTINUE, the server component of the
negotiation is not yet finished. The server responds to the TKEY
query with a standard query response, placing a TKEY record containing
output_token in the answer section. The negotiation sequence then
repeats beginning with section 4.1.1. The server must limit the
number of times that a given context is allowed to repeat, to prevent
endless looping.
4.2 Context Established
When context negotiation is complete, the handle context_handle
is used for the generation and verification of transaction signatures.
The handle is valid for a finite amount of time determined by the
underlying security mechanism. A server may unilaterally terminate
a context at any time.
The procedures for sending and receiving signed messages are given in
section 5, Sending and Verifying Signed Messages.
4.2.1 Terminating a Context
A server can terminate any established context at any time. The
server may hint to the client that the context is being deleted
by including a TKEY RR in a response with the mode field set to
"key deletion". See [TKEY] for more details.
An active context is deleted by calling GSS_Delete_sec_context
providing the associated context_handle.
Expires January 2000 [Page 10]
INTERNET-DRAFT GSS-TSIG June 1999
5. Sending and Verifying Signed Messages
5.1 Sending a Signed Message - Call GSS_GetMIC
The procedure for sending a signature-protected message is specified
in [TSIG]. The data to be passed to the signature routine includes
the whole DNS message with specific TSIG variables appended. For the
exact format, see [TSIG]. For this protocol, use the following
TSIG variable values:
TSIG Record
NAME = key_name that identifies this context
RDATA
Algorithm Name = gss-tsig.microsoft.com
Assign the remaining fields in the TKEY RDATA appropriate values
per [TKEY].
For the GSS algorithm, the signature is generated by calling
GSS_GetMIC:
INPUTS
CONTEXT HANDLE context_handle = context_handle for key_name
OCTET STRING message = outgoing message plus TSIG
variables (see [TSIG])
OUTPUTS
INTEGER major_status
OCTET STRING per_msg_token
If major_status is GSS_S_COMPLETE, then signature generation
succeeded. The signature in per_msg_token is inserted into the
Signature field of the TSIG RR and the message is transmitted.
If major_status is GSS_S_CONTEXT_EXPIRED or GSS_S_CREDENTIALS_EXPIRED,
the caller needs to return to the uninitialized state and negotiate
a new security context.
Expires January 2000 [Page 11]
INTERNET-DRAFT GSS-TSIG June 1999
5.2 Verifying a Signed Message - Call GSS_VerifyMIC
The procedure for verifying a signature-protected message is specified
in [TSIG].
The NAME of the TSIG record determines which context_handle
maps to this context. If the NAME does not map to a currently active
context, the server must send a standard TSIG error response to the
client indicating BADKEY in the TSIG error field (see [TSIG]).
For the GSS algorithm, a signature is verified by using GSS_VerifyMIC:
INPUTS
CONTEXT HANDLE context_handle = context_handle for key_name
OCTET STRING message = incoming message plus TSIG
variables (see [TSIG])
OCTET STRING per_msg_token = Signature field from TSIG RR
OUTPUTS
INTEGER major_status
If major_status is GSS_S_COMPLETE, the signature is authentic and the
message was delivered intact. Per [TSIG], the timer values of the
TSIG record must also be valid before considering the message to be
authentic. The caller must not act on the request or response in the
message until these checks are verified.
If major_status is GSS_S_CONTEXT_EXPIRED, the negotiated context is no
longer valid. If this failure occurs when a server is processing a
client request, the server must send a standard TSIG error response
to the client indicating BADKEY in the TSIG error field (see [TSIG]).
If major_status is any other error code or if the timer values of the
TSIG record are invalid, the message must not be considered authentic.
If this error checking fails when a server is processing a client
request, the appropriate error response must be sent to the client
per [TSIG].
6. Security Considerations
This document describes a protocol for DNS security using GSS-API.
The security provided by this protocol is only as effective as the
security provided by the underlying GSS mechanisms.
Expires January 2000 [Page 12]
INTERNET-DRAFT GSS-TSIG June 1999
7. Acknowledgements
The authors of this document would like to thank the following people
for their contribution to this specification: Chuck Chan, Mike Swift,
Ram Viswanathan and Donald E. Eastlake 3rd.
8. References
[RFC2078] J. Linn, "Generic Security Service Application Program
Interface, Version 2," RFC 2078, OpenVision Technologies,
January 1997.
[TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key
Transaction Signatures for DNS (TSIG),"
draft-ietf-dnsind-tsig-*..txt, ISC, TIS, Cybercash.
[TKEY] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY
RR)," draft-ietf-dnssec-tkey-*.txt.
[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions,"
RFC 2535, IBM, March 1999.
[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update,"
RFC 2137, CyberCash, April 1997.
9. Author's Addresses
Stuart Kwan Praerit Garg
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
<skwan@microsoft.com> <praeritg@microsoft.com>
James Gilroy
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
<jamesg@microsoft.com>