upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-05-28 04:34:54 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

add RFCs and drafts

Browse source
This commit is contained in:
Bob Halley 1999-03-23 17:37:55 +00:00
parent 0d46301a6e
commit c7ddab7655
57 changed files with 54619 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

335
doc/draft/draft-ietf-dnsind-apl-rr-01.txt Normal file
View file

@ -0,0 +1,335 @@
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
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.
Comments should be sent to the author or the DNSIND WG mailing list
<namedroppers@internic.net>.
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
"APL" for address prefix lists.
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Domain names herein are for explanatory purposes only and should not
be expected to lead to useful information in real life [TESTTLD].
Koch Expires August 1999 [Page 1]
INTERNET-DRAFT DNS APL RR February 1999
2. Background
The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
assign addresses and other internet infrastructure elements to
hierarchically built domain names. Various types of resource records
have been defined, especially those for IPv4 and IPv6 [RFC1886],
[A6DNSRR] addresses. In [RFC1101] a method is described to publish
information about the address space allocated to an organisation. In
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.
3. APL RR Type
An APL record has the DNS type of "APL" [draft: not yet applied for]
and a numeric value of [draft:to be assigned]. The APL RR is defined
in the IN class only. APL RRs cause no additional section processing.
4. APL RDATA format
The RDATA section consists of zero or more strings (<apstring>) of
the form
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ADDRESSFAMILY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| N | PREFIX | MBZ | AFDLENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AFDPART /
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
ADDRESSFAMILY 16 bit unsigned value as assigned by IANA
(see IANA Considerations)
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
AFDPART address family dependent part. See below.
This document defines the AFDPARTs for address families 1 (IPv4) and
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.
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).
An IPv4 AFDPART has a fixed length of 4 octets.
4.1. 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.
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).
An IPv6 AFDPART has a fixed length of 16 octets.
5. Zone File Syntax
The textual representation of an APL RR in a DNS zone file is as
follows:
<owner> IN <TTL> APL {[!]address/prefix}*
The data consists of zero or more strings of an address, immediately
followed by the "/" character, immediately followed by a decimal
numeric value for the prefix length. Any such string may be preceeded
by a "!" character. The strings are separated by whitespace.
5.1. Textual Representation of IPv4 Addresses
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
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.
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
aggregated.
A single APL RR may contain <apstrings> belonging to different
address families. The maximum number of <apstrings> is upperbounded
by the available RDATA space.
RRSets consisting of more than one APL RR are legal but the
interpretation is left to the particular application. It may choose
to join the lists or treat them as alternatives.
Possible applications include the publication of address ranges
similar to [RFC1101], description of zones built following [RFC2317]
and in-band access control to limit general access or zone transfer
(AXFR) availability for zone data held in DNS servers.
7. Examples
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
multicast.example APL 224.0.0.0/4 FF00:0:0:0:0:0:0:0/8
8. Security Considerations
Any information obtained from the DNS should be regarded as unsafe
unless techniques specified in [RFC2065] 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
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.
10. Acknowledgements
The author would like to thank Mark Andrews for his review and
constructive comments.
11. References
[A6DNSRR] Crawford,M., Thomson,S., "DNS Extensions to Support IP
Version 6", <draft-ietf-ipngwg-dns-lookups-XX.txt>, work
in progress
[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 13, November 1987
[RFC1035] Mockapetris,P., "Domain Names - Implementation and
Specification", RFC 1035, STD 13, November 1987
[RFC1101] Mockapetris,P., "DNS Encoding of Network Names and Other
Types", RFC 1101, April 1989
[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
[RFC2181] Elz,R., Bush,R., "Clarifications to the DNS
Specification", RFC 2181, July 1997
[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
[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
Universitaet Bielefeld
Technische Fakultaet
Postfach 10 01 31
D-33501 Bielefeld
Germany
+49 521 106 2902
<pk@TechFak.Uni-Bielefeld.DE>
Koch Expires August 1999 [Page 6]

334
doc/draft/draft-ietf-dnsind-binary-labels-04.txt Normal file
View file

@ -0,0 +1,334 @@
DNSIND Working Group Matt Crawford
Internet Draft Fermilab
March 21, 1999
Binary Labels in the Domain Name System
<draft-ietf-dnsind-binary-labels-04.txt>
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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
1. Introduction and Terminology
This document defines a ``Bit-String Label'' which may appear within
domain names. This new label type compactly represents a sequence
of ``One-Bit Labels'' and enables resource records to be stored at
any bit-boundary in a binary-named section of the domain name tree.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KWORD].
2. Motivation
Binary labels are intended to efficiently solve the problem of
storing data and delegating authority on arbitrary boundaries when
the structure of underlying name space is most naturally represented
in binary.
Expires September 26, 1999 Crawford [Page 1]
Internet Draft Binary DNS Labels March 21, 1999
3. Label Format
Up to 256 One-Bit Labels can be grouped into a single Bit-String
Label. Within a Bit-String Label the most significant or "highest
level" bit appears first. This is unlike the ordering of DNS labels
themselves, which has the least significant or "lowest level" label
first. Nonetheless, this ordering seems to be the most natural and
efficient for representing binary labels.
Among consecutive Bit-String Labels, the bits in the first-appearing
label are less significant or "at a lower level" than the bits in
subsequent Bit-String Labels, just as ASCII labels are ordered.
3.1. Encoding
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
|0 1| ELT | Count | Label ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
(Each tic mark represents one bit.)
ELT 000001 binary, the six-bit extended label type [EDNS0]
assigned to the Bit-String Label.
Count The number of significant bits in the Label field. A
Count value of zero indicates that 256 bits are
significant. (Thus the null label representing the DNS
root cannot be represented as a Bit String Label.)
Label The bit string representing a sequence of One-Bit Labels,
with the most significant bit first. That is, the One-Bit
Label in position 17 in the diagram above represents a
subdomain of the domain represented by the One-Bit Label
in position 16, and so on.
The Label field is padded on the right with zero to seven
pad bits to make the entire field occupy an integral
number of octets. These pad bits MUST be zero on
transmission and ignored on reception.
A sequence of bits may be split into two or more Bit-String Labels,
but the division points have no significance and need not be
preserved. An excessively clever server implementation might split
Expires September 26, 1999 Crawford [Page 2]
Internet Draft Binary DNS Labels March 21, 1999
Bit-String Labels so as to maximize the effectiveness of message
compression [DNSIS]. A simpler server might divide Bit-String
Labels at zone boundaries, if any zone boundaries happen to fall
between One-Bit Labels.
3.2. Textual Representation
A Bit-String Label is represented in text -- in a zone file, for
example -- as a <bit-spec> surrounded by the delimiters "\[" and
"]". The <bit-spec> is either a dotted quad or a base indicator and
a sequence of digits appropriate to that base, optionally followed
by a slash and a length. The base indicators are "b", "o" and "x",
denoting base 2, 8 and 16 respectively. The length counts the
significant bits and MUST be between 1 and 32, inclusive, after a
dotted quad, or between 1 and 256, inclusive, after one of the other
forms. If the length is omitted, the implicit length is 32 for a
dotted quad or 1, 3 or 4 times the number of binary, octal or
hexadecimal digits supplied, respectively, for the other forms.
In augmented Backus-Naur form [ABNF],
bit-string-label = "\[" bit-spec "]"
bit-spec = bit-data [ "/" length ]
/ dotted-quad [ "/" slength ]
bit-data = "x" 1*64HEXDIG
/ "o" 1*86OCTDIG
/ "b" 1*256BIT
dotted-quad = decbyte "." decbyte "." decbyte "." decbyte
decbyte = 1*3DIGIT
length = NZDIGIT *2DIGIT
slength = NZDIGIT [ DIGIT ]
OCTDIG = %x30-37
NZDIGIT = %x31-39
If a <length> is present, the number of digits in the <bit-data>
MUST be just sufficient to contain the number of bits specified by
the <length>. If there are insignificant bits in a final
hexadecimal or octal digit, they MUST be zero. A <dotted-quad>
always has all four parts even if the associated <slength> is less
Expires September 26, 1999 Crawford [Page 3]
Internet Draft Binary DNS Labels March 21, 1999
than 24, but, like the other forms, insignificant bits MUST be zero.
Each number represented by a <decbyte> must be between 0 and 255,
inclusive.
The number represented by <length> must be between 1 and 256
inclusive.
The number represented by <slength> must be between 1 and 32
inclusive.
When the textual form of a Bit-String Label is generated by machine,
the length SHOULD be explicit, not implicit.
3.2.1. Examples
The following four textual forms represent the same Bit-String
Label.
\[b11010000011101]
\[o64072/14]
\[xd074/14]
\[208.116.0.0/14]
The following represents two consecutive Bit-String Labels which
denote the same relative point in the DNS tree as any of the above
single Bit-String Labels.
\[b11101].\[o640]
3.3. Canonical Representation and Sort Order
Both the wire form and the text form of binary labels have a degree
of flexibility in their grouping into multiple consecutive Bit-
String Labels. For generating and checking DNS signature records
[DNSSEC] binary labels must be in a predictable form. This
canonical form is defined as the form which has the fewest possible
Bit-String Labels and in which all except possibly the first (least
significant) label in any sequence of consecutive Bit-String Labels
is of maximum length.
For example, the canonical form of any sequence of up to 256 One-Bit
Labels has a single Bit-String Label, and the canonical form of a
sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of
which the second and third contain 256 label bits.
Expires September 26, 1999 Crawford [Page 4]
Internet Draft Binary DNS Labels March 21, 1999
The canonical sort order of domain names [DNSSEC] is extended to
encompass binary labels as follows. Sorting is still label-by-
label, from most to least significant, where a label may now be a
One-Bit Label or a standard (code 00) label. Any One-Bit Label
sorts before any standard label, and a 0 bit sorts before a 1 bit.
The absence of a label sorts before any label, as specified in
[DNSSEC].
For example, the following domain names are correctly sorted.
foo.example
\[b1].foo.example
\[b100].foo.example
\[b101].foo.example
bravo.\[b10].foo.example
alpha.foo.example
4. Processing Rules
A One-Bit Label never matches any other kind of label. In
particular, the DNS labels represented by the single ASCII
characters "0" and "1" do not match One-Bit Labels represented by
the bit values 0 and 1.
5. Discussion
A Count of zero in the wire-form represents a 256-bit sequence, not
to optimize that particular case, but to make it completely
impossible to have a zero-bit label.
6. IANA Considerations
This document defines one Extended Label Type, termed the Bit-String
Label, and requests registration of the code point 000001 binary in
the space defined by [EDNS0].
7. Security Considerations
All security considerations which apply to traditional ASCII DNS
labels apply equally to binary labels. The only new consideration
is the particular canonical representation which must be used for
creating or verifying signatures [DNSSEC] on data containing binary
labels.
Expires September 26, 1999 Crawford [Page 5]
Internet Draft Binary DNS Labels March 21, 1999
8. References
[ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234.
[DNSIS] P.V. Mockapetris, "Domain names - implementation and
specification", RFC 1035.
[DNSSEC]D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security
Extensions", RFC 2065.
[EDNS0] P. Vixie, "Extension mechanisms for DNS (EDNS0)", Currently
draft-dnsind-edns0-01.txt.
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
9. Author's Address
Matt Crawford
Fermilab MS 368
PO Box 500
Batavia, IL 60510
USA
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Expires September 26, 1999 Crawford [Page 6]

336
doc/draft/draft-ietf-dnsind-dddd-00.txt Normal file
View file

@ -0,0 +1,336 @@
DNSSEC Working Group Brian Wellington (TISLabs)
INTERNET-DRAFT Olafur Gudmundsson (TISLabs)
February 1999
<draft-ietf-dnsind-dddd-00.txt>
Updates: RFC 2136
Deferred Dynamic Domain Name System (DNS) Delete Operations
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
This document proposes a mechanism for notifying a dynamic DNS server
that a delete operation should be performed at a certain point in the
future. This works within the framework of the current DNS dynamic
update protocol, and provides needed functionality for clients with
leased dynamic addresses.
Expires August 1999 [Page 1]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
1 - Introduction
Dynamic update operations for the Domain Name System [RFC1034, RFC1035]
are defined in [RFC2136], but there is no automated method of specifying
that records should have a fixed lifetime, or lease.
1.1 - Overview of DNS Dynamic Update
DNS dynamic update defines a new DNS opcode and a new interpretation of
the DNS message if that opcode is used. An update can specify
insertions or deletions of data, along with prerequisites necessary for
the updates to occur. All tests and changes for a DNS update request
are restricted to a single zone, and are performed at the primary server
for the zone. The primary server for a dynamic zone must increment the
zone SOA serial number when an update occurs or before the next
retrieval of the SOA.
1.2 - Overview of DHCP leases
DHCP [RFC2131] provides a means for a host to obtain a network address
from a DHCP server. The server may ``lease'' this address to the host,
meaning that it is valid only for the period of time specified in the
lease. The host may may extend its lease with subsequent requests, or
may issue a message to release the address back to the server when it is
no longer needed.
2 - Background
When a host receives dynamic addresses with associated dynamic DNS
records, the records can be updated by either the host or the DHCP
server. If possible, update by the server is recommended, since the
server maintains lease information for each address. In some cases,
though, the server cannot update some or all of the DNS records. This
happens when the DNS and DHCP server are under different administration,
for example.
A host can easily update its own DNS records when receiving information
from the DHCP server. It can also delete its records when shutting
down. If the host unexpectedly goes down, though, it cannot delete the
records. When the DHCP lease on the address expires and is not renewed,
the DHCP server may reassign the address. The DNS records now point to
an assigned address, but not the correct address. Until the host
updates its records again, DNS will contain bad information.
Since the DHCP and DNS servers are often not co-located with the
clients, the possibility of a host unexpectedly going down and not
communicating with the servers is non-trivial.
Expires August 1999 [Page 2]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
If the host could set a lease on the DNS records similar to that on its
address, the DNS records would lose validity at the same time as the
address. This would prevent bad information from remaining in DNS. DNS
has no such provision for leases, though, since this would require
storing a lease time along with each record (or each record in a dynamic
zone).
An alternative method is suggested. A ``delete'' update is sent along
with the ``add'' update, but the delete is marked in such a way that it
will not be executed immediately. Instead, it will be stored for the
specified amount of time before being applied. If the host wishes to
extend or shorten the lifetime of the DNS record(s), it can replace the
``deferred delete'' record, which will reset the lease time of the
record(s). The ``deferred delete'' record would, of course, also be
removed if a normal delete update was received.
This functionality is useful for DHCP leases and maintainance of IPv6
routing prefixes. DNSSEC compliant server can also use deferred dynamic
delete information to compute signatures of records affected by the
delete operation prior to the delete operation, using spare cycles.
3 - Protocol changes
When doing a delete update operation as defined in [RFC2136] (deleting
an RR, an RRset, or all RRset from a name), the TTL field MUST be
specified as 0. An [RFC2136] compliant server will reject an update
record with a non-zero TTL. This document overloads the TTL field. If
TTL is non-zero, the value represents the number of seconds (a 32 bit
unsigned integer) before which the delete will be applied to the zone.
Thus, the delete operation will be deferred for that number of seconds,
where the number of seconds indicates the lease time. A 32 bit integer
provides for a lease time of over 136 years, which should be long enough
for most uses.
3.1 - Storage and execution
Deferred delete records are stored, persistently, by the name server.
The name server SHOULD attempt to evaluate the deletes in a timely
manner.
3.2 - Processing of deferred deletes
When a deferred delete is received, the server must check to see if it
matches an existing deferred delete records, where matching indicates
the same name, type, class, and rdata. If a match is found, the new
deferred delete MUST replace the old one. If the deferred delete does
not refer to any record in the server, it should fail as a normal delete
would.
Expires August 1999 [Page 3]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
3.3 - Processing of normal deletes
When a normal delete is received and accepted, the server MUST purge any
deferred delete that no longer refers to any records.
3.4 - Processing of cancellations
The value 0xFFFFFFFF (the largest unsigned 32 bit integer) in the TTL
field has a special meaning. If a delete containing this lease time is
received, the server will unconditionally remove any matching deferred
deletes.
3.5 - Processing of adds
When data is added through a dynamic update which matches a deferred
delete, there is no additional processing done.
3.6 - Detecting server support of Deferred Delete
Client can determine if server supports deferred delete by the return
code of a deferred delete request by sending a ADD + Delete request to
the server, where the delete has low TTL. RFC2136 compliant server MUST
return either rcode FORMERR or NOTIMPL. Server compliant with this
document will return NOERROR.
4 - TTL Modification
4.1 - Initial TTL Limits
The TTL of all added or updated RRs in the Update Section SHOULD be
maximized silently to one half of the lease time. This will cause
downstream caching name servers to purge RRsets containing this RR at
least once before expiry.
4.2 - TTL Half Life
Each time an RR's expiry reaches half of its previous value, that RR's
TTL will be reduced to half of its previous value, until the TTL reaches
a value less than or equal to sixty (60), i.e., one minute of real time,
at which time the TTL will not be automatically reduced further by the
primary master. It should be noted that RRs held in a server's memory
need not be swept for half life processing, as long as the TTL changes
appear when the RR next becomes externally visible, and as long as the
``zone has changed'' processing (see below) is done at the time of the
half life expiration.
Expires August 1999 [Page 4]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
Whenever the TTL is automatically reduced by this process, the zone will
be considered ``changed'' for the purpose of automatic SOA SERIAL
increment (as in [RFC2136]) and real time zone slave notification
[RFC1996].
5 - Usage
Normally, a deferred delete update will initially be sent along with an
add, although this is not required. Further updates to the deferred
delete will be sent independently. If the deferred delete is associated
with a leased address, the lease time of the update SHOULD be
approximately equal to the lease time of the address.
6 - Security considerations
This addition to the dynamic DNS protocol does not affect the security
of the protocol. If security is desired, TSIG [TSIG] and/or DNSSEC
[secext2] authentication should be used, as specified in [simple-update]
or [RFC2137, update2]. The authors strongly recommend using security
along with this protocol.
If a DNSSEC signed-zone is modified with deferred deletes, the server
must resign any affected records when the delete is executed. No
special processing is required when the delete is received.
7 - IANA Considerations
None.
8 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987.
[RFC1996] P. Vixie ``A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY),'' RFC 1996, ISC, August 1996.
[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.
[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
2137, CyberCash, April 1997.
Expires August 1999 [Page 5]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
[secext2] D. Eastlake ``Domain Name System Security Extensions,''
draft-ietf-dnssec-secext2-07.txt, IBM, December 1998.
[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington
``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
ietf-dnsind-tsig-08.txt, ISC & TIS & IBM, February 1999.
[simple-update]
B. Wellington ``Simple Secure Domain Name System (DNS)
Dynamic Update,'' draft-ietf-dnsind-simple-update-00.txt,
TISLabs, November 1998.
[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic
Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite
Systems Company, August 1998.
8 - Author's Address
Brian Wellington Olafur Gudmundsson
TISLabs at Network Associates TISLabs at Network Associates
3060 Washington Road, Route 97 3060 Washington Road, Route 97
Glenwood, MD 21738 Glenwood, MD 21738
+1 443 259 2369 +1 443 259 2389
+1 301 854 6889 (main number) +1 301 854 6889
<bwelling@tislabs.com> <ogud@tislabs.com>
Expires August 1999 [Page 6]

502
doc/draft/draft-ietf-dnsind-dname-03.txt Normal file
View file

@ -0,0 +1,502 @@
DNSIND Working Group Matt Crawford
Internet Draft Fermilab
March 21, 1999
Non-Terminal DNS Name Redirection
<draft-ietf-dnsind-dname-03.txt>
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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
1. Introduction
This document defines a new DNS Resource Record called ``DNAME'',
which provides the capability to map an entire subtree of the DNS
name space to another domain. It differs from the CNAME record
which maps a single node of the name space.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KWORD].
2. Motivation
This Resource Record and its processing rules were conceived as a
solution to the problem of maintaining address-to-name mappings in a
context of network renumbering. Without the DNAME mechanism, an
authoritative DNS server for the address-to-name mappings of some
network must be reconfigured when that network is renumbered. With
DNAME, the zone can be constructed so that it needs no modification
when renumbered. DNAME can also be useful in other situations, such
as when an organizational unit is renamed.
Expires September 26, 1999 Crawford [Page 1]
Internet Draft Non-Terminal Nicknames March 21, 1999
3. The DNAME Resource Record
The DNAME RR has mnemonic DNAME and type code 39 (decimal).
DNAME has the following format:
<owner> <ttl> <class> DNAME <target>
The format is not class-sensitive. All fields are required. The
RDATA field <target> is a <domain-name> [DNSIS].
The DNAME RR causes type NS additional section processing.
The effect of the DNAME record is the substitution of the record's
<target> for its <owner> as a suffix of a domain name. A "no-
descendants" limitation governs the use of DNAMEs in a zone file:
If a DNAME RR is present at a node N, there may be other data at
N (except a CNAME or another DNAME), but there MUST be no data
at any descendant of N. This restriction applies only to
records of the same class as the DNAME record.
This rule assures predictable results when a DNAME record is cached
by a server which is not authoritative for the record's zone. It
MUST be enforced when authoritative zone data is loaded. Together
with the rules for DNS zone authority [DNSCLR] it implies that DNAME
and NS records can only coexist at the top of a zone which has only
one node.
The compression scheme of [DNSIS] MUST NOT be applied to the RDATA
portion of a DNAME record unless the sending server has some way of
knowing that the receiver understands the DNAME record format.
Signalling such understanding is expected to be the subject of
future DNS Extensions.
Naming loops can be created with DNAME records or a combination of
DNAME and CNAME records, just as they can with CNAME records alone.
Resolvers, including resolvers embedded in DNS servers, MUST limit
the resources they devote to any query. Implementors should note,
however, that fairly lengthy chains of DNAME records may be valid.
4. Query Processing
To exploit the DNAME mechanism the name resolution algorithms
[DNSCF] must be modified slightly for both servers and resolvers.
Both modified algorithms incorporate the operation of making a
Expires September 26, 1999 Crawford [Page 2]
Internet Draft Non-Terminal Nicknames March 21, 1999
substitution on a name (either QNAME or SNAME) under control of a
DNAME record. This operation will be referred to as "the DNAME
substitution".
4.1. Processing by Servers
For a server performing non-recursive service steps 3.c and 4 of
section 4.3.2 [DNSCF] are changed to check for a DNAME record before
checking for a wildcard ("*") label, and to return certain DNAME
records from zone data and the cache.
DNS clients sending Extended DNS [EDNS0] queries with Version 0 or
non-extended queries are presumed not to understand the semantics of
the DNAME record, so a server which implements this specification,
when answering a non-extended query, SHOULD synthesize a CNAME
record for each DNAME record encountered during query processing to
help the client reach the correct DNS data. The behavior of clients
and servers under Extended DNS versions greater than 0 will be
specified when those versions are defined.
The synthesized CNAME RR, if provided, MUST have
The same CLASS as the QCLASS of the query,
TTL equal to zero,
An <owner> equal to the QNAME in effect at the moment the DNAME
RR was encountered, and
An RDATA field containing the new QNAME formed by the action of
the DNAME substitution.
If the server has the appropriate key on-line [DNSSEC, SECDYN], it
MAY generate and return a SIG RR for the synthesized CNAME RR.
The revised server algorithm is:
1. Set or clear the value of recursion available in the response
depending on whether the name server is willing to provide
recursive service. If recursive service is available and
requested via the RD bit in the query, go to step 5, otherwise
step 2.
2. Search the available zones for the zone which is the nearest
ancestor to QNAME. If such a zone is found, go to step 3,
otherwise step 4.
Expires September 26, 1999 Crawford [Page 3]
Internet Draft Non-Terminal Nicknames March 21, 1999
3. Start matching down, label by label, in the zone. The matching
process can terminate several ways:
a. If the whole of QNAME is matched, we have found the node.
If the data at the node is a CNAME, and QTYPE doesn't match
CNAME, copy the CNAME RR into the answer section of the
response, change QNAME to the canonical name in the CNAME
RR, and go back to step 1.
Otherwise, copy all RRs which match QTYPE into the answer
section and go to step 6.
b. If a match would take us out of the authoritative data, we
have a referral. This happens when we encounter a node with
NS RRs marking cuts along the bottom of a zone.
Copy the NS RRs for the subzone into the authority section
of the reply. Put whatever addresses are available into the
additional section, using glue RRs if the addresses are not
available from authoritative data or the cache. Go to step
4.
c. If at some label, a match is impossible (i.e., the
corresponding label does not exist), look to see whether the
last label matched has a DNAME record.
If a DNAME record exists at that point, copy that record
into the answer section. If substitution of its <target>
for its <owner> in QNAME would overflow the legal size for a
<domain-name>, set RCODE to YXDOMAIN [DNSUPD] and exit;
otherwise perform the substitution and continue. If the
query was not extended [EDNS0] with a Version indicating
understanding of the DNAME record, the server SHOULD
synthesize a CNAME record as described above and include it
in the answer section. Go back to step 1.
If there was no DNAME record, look to see if the "*" label
exists.
If the "*" label does not exist, check whether the name we
are looking for is the original QNAME in the query or a name
we have followed due to a CNAME. If the name is original,
set an authoritative name error in the response and exit.
Otherwise just exit.
If the "*" label does exist, match RRs at that node against
QTYPE. If any match, copy them into the answer section, but
Expires September 26, 1999 Crawford [Page 4]
Internet Draft Non-Terminal Nicknames March 21, 1999
set the owner of the RR to be QNAME, and not the node with
the "*" label. Go to step 6.
4. Start matching down in the cache. If QNAME is found in the
cache, copy all RRs attached to it that match QTYPE into the
answer section. If QNAME is not found in the cache but a DNAME
record is present at an ancestor of QNAME, copy that DNAME
record into the answer section. If there was no delegation from
authoritative data, look for the best one from the cache, and
put it in the authority section. Go to step 6.
5. Use the local resolver or a copy of its algorithm (see resolver
section of this memo) to answer the query. Store the results,
including any intermediate CNAMEs and DNAMEs, in the answer
section of the response.
6. Using local data only, attempt to add other RRs which may be
useful to the additional section of the query. Exit.
Note that there will be at most one ancestor with a DNAME as
described in step 4 unless some zone's data is in violation of the
no-descendants limitation in section 3. An implementation might
take advantage of this limitation by stopping the search of step 3c
or step 4 when a DNAME record is encountered.
4.2. Processing by Resolvers
A resolver or a server providing recursive service must be modified
to treat a DNAME as somewhat analogous to a CNAME. The resolver
algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
as 4.e and insert a new 4.d. The complete algorithm becomes:
1. See if the answer is in local information, and if so return it
to the client.
2. Find the best servers to ask.
3. Send them queries until one returns a response.
4. Analyze the response, either:
a. if the response answers the question or contains a name
error, cache the data as well as returning it back to the
client.
b. if the response contains a better delegation to other
servers, cache the delegation information, and go to step 2.
Expires September 26, 1999 Crawford [Page 5]
Internet Draft Non-Terminal Nicknames March 21, 1999
c. if the response shows a CNAME and that is not the answer
itself, cache the CNAME, change the SNAME to the canonical
name in the CNAME RR and go to step 1.
d. if the response shows a DNAME and that is not the answer
itself, cache the DNAME. If substitution of the DNAME's
<target> for its <owner> in the SNAME would overflow the
legal size for a <domain-name>, return an implementation-
dependent error to the application; otherwise perform the
substitution and go to step 1.
e. if the response shows a server failure or other bizarre
contents, delete the server from the SLIST and go back to
step 3.
A resolver or recursive server which understands DNAME records but
sends non-extended queries MUST augment step 4.c by deleting from
the reply any CNAME records which have an <owner> which is a
subdomain of the <owner> of any DNAME record in the response.
5. Examples of Use
5.1. Organizational Renaming
If an organization with domain name FROBOZZ.EXAMPLE became part of
an organization with domain name ACME.EXAMPLE, it might ease
transition by placing information such as this in its old zone.
frobozz.example. DNAME frobozz-division.acme.example.
MX 10 mailhub.acme.example.
The response to an extended recursive query for www.frobozz.example
would contain, in the answer section, the DNAME record shown above
and the relevant RRs for www.frobozz-division.acme.example.
5.2. Classless Delegation of Shorter Prefixes
The classless scheme for in-addr.arpa delegation [INADDR] can be
extended to prefixes shorter than 24 bits by use of the DNAME
record. For example, the prefix 192.0.8.0/22 can be delegated by
the following records.
Expires September 26, 1999 Crawford [Page 6]
Internet Draft Non-Terminal Nicknames March 21, 1999
$ORIGIN 0.192.in-addr.arpa.
8/22 NS ns.slash-22-holder.example.
8 DNAME 8.8/22
9 DNAME 9.8/22
10 DNAME 10.8/22
11 DNAME 11.8/22
A typical entry in the resulting reverse zone for some host with
address 192.0.9.33 might be
$ORIGIN 8/22.0.192.in-addr.arpa.
33.9 PTR somehost.slash-22-holder.example.
The same advisory remarks concerning the choice of the "/" character
apply here as in [INADDR].
5.3. Network Renumbering Support
If IPv4 network renumbering were common, maintenance of address
space delegation could be simplified by using DNAME records instead
of NS records to delegate.
$ORIGIN new-style.in-addr.arpa.
189.190 DNAME in-addr.example.net.
$ORIGIN in-addr.example.net.
188 DNAME in-addr.customer.example.
$ORIGIN in-addr.customer.example.
1 PTR www.customer.example.
2 PTR mailhub.customer.example.
; etc ...
This would allow the address space 190.189.0.0/16 assigned to the
ISP "example.net" to be changed without the necessity of altering
the zone files describing the use of that space by the ISP and its
customers.
Renumbering IPv4 networks is currently so arduous a task that
updating the DNS is only a small part of the labor, so this scheme
may have a low value. But it is hoped that in IPv6 the renumbering
task will be quite different and the DNAME mechanism may play a
useful part.
Expires September 26, 1999 Crawford [Page 7]
Internet Draft Non-Terminal Nicknames March 21, 1999
6. IANA Considerations
This document defines a new DNS Resource Record type with the
mnemonic DNAME and type code 39 (decimal). The naming/numbering
space is defined in [DNSIS]. This name and number have already been
registered with the IANA.
7. Security Considerations
The DNAME record is similar to the CNAME record with regard to the
consequences of insertion of a spoofed record into a DNS server or
resolver, differing in that the DNAME's effect covers a whole
subtree of the name space. The facilities of [DNSSEC] are available
to authenticate this record type.
8. References
[DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities",
RFC 1034.
[DNSCLR] R. Elz, R. Bush, "Clarifications to the DNS Specification",
RFC 2181.
[DNSIS] P.V. Mockapetris, "Domain names - implementation and
specification", RFC 1035.
[DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security
Extensions", RFC 2065.
[DNSUPD] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System", RFC 2136.
[EDNS0] P. Vixie, "Extensions mechanisms for DNS (EDNS0)", Currently
draft-dnsind-edns0-01.txt.
[INADDR] H. Eidnes, G. de Groot, P. Vixie, "Classless IN-ADDR.ARPA
delegation", RFC 2317.
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
Update", RFC 2137.
Expires September 26, 1999 Crawford [Page 8]
Internet Draft Non-Terminal Nicknames March 21, 1999
9. Author's Address
Matt Crawford
Fermilab MS 368
PO Box 500
Batavia, IL 60510
USA
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Expires September 26, 1999 Crawford [Page 9]

319
doc/draft/draft-ietf-dnsind-edns0-01.txt Normal file
View file

@ -0,0 +1,319 @@
DNSIND Working Group Paul Vixie
INTERNET-DRAFT ISC
<draft-dnsind-edns0-01.txt> January, 1999
Extension mechanisms for DNS (EDNS0)
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.
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.''
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).
Abstract
The Domain Name System's wire protocol includes a number of fixed
fields whose range has been or soon will be exhausted and does not
allow clients to advertise their capabilities to servers. This
document describes backward compatible mechanisms for allowing the
protocol to grow.
1 - Rationale and Scope
1.1. DNS (see [RFC1035]) specifies a Message Format and within such
messages there are standard formats for encoding options, errors, and
name compression. The maximum allowable size of a DNS Message is fixed.
Many of DNS's protocol limits are too small for uses which are or which
are desired to become common. There is no way for implementations to
advertise their capabilities.
Expires July 1999 [Page 1]
INTERNET-DRAFT EDNS0 January 1999
1.2. Existing clients will not know how to interpret the protocol
extensions detailed here. In practice, these clients will be upgraded
when they have need of a new feature, and only new features will make
use of the extensions. We must however take account of client behaviour
in the face of extra fields, and design a fallback scheme for
interoperability with these clients.
2 - Affected Protocol Elements
2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
1-bit flags. The original reserved Z bits have been allocated to
various purposes, and most of the RCODE values are now in use. More
flags and more possible RCODEs are needed.
2.2. The first two bits of a wire format domain label are used to denote
the type of the label. [RFC1035 4.1.4] allocates two of the four
possible types and reserves the other two. Proposals for use of the
remaining types far outnumber those available. More label types are
needed.
2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
While the minimum maximum reassembly buffer size still allows a limit of
512 octets of UDP payload, most of the hosts now connected to the
Internet are able to reassemble larger datagrams. Some mechanism must
be created to allow requestors to advertise larger buffer sizes to
responders.
3 - Extended Label Types
3.1. The ``0 1'' label type will now indicate an extended label type,
whose value is encoded in the lower six bits of the first octet of a
label. All subsequently developed label types should be encoded using
an extended label type.
3.2. The ``1 1 1 1 1 1'' extended label type will be reserved for future
expansion of the extended label type code space.
4 - OPT pseudo-RR
4.1. The OPT pseudo-RR can be added to the additional data section of
either a request or a response. An OPT is called a pseudo-RR because it
pertains to a particular transport level message and not to any actual
DNS data. OPT RRs shall never be cached, forwarded, or stored in or
loaded from master files.
Expires July 1999 [Page 2]
INTERNET-DRAFT EDNS0 January 1999
4.2. An OPT RR has a fixed part and a variable set of options expressed
as {attribute, value} pairs. The fixed part holds some DNS meta data
and also a small collection of new protocol elements which we expect to
be so popular that it would be a waste of wire space to encode them as
{attribute, value} pairs.
4.3. The fixed part of an OPT RR is structured as follows:
Field Name Field Type Description
------------------------------------------------------
NAME domain name empty (root domain)
TYPE u_int16_t OPT
CLASS u_int16_t sender's UDP payload size
TTL u_int32_t extended RCODE and flags
RDLEN u_int16_t describes RDATA
RDATA octet stream {attribute,value} pairs
4.4. The variable part of an OPT RR is encoded in its RDATA and is
structured as zero or more of the following:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | |
/ OPTION-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
OPTION-CODE (Assigned by IANA.)
OPTION-LENGTH Size (in octets) of OPTION-DATA.
OPTION-DATA Varies per OPTION-CODE.
4.5. The sender's UDP buffer size (which OPT stores in the RR CLASS
field) is the number of octets of the largest UDP payload that can be
reassembled and delivered in the sender's network stack. Note that path
MTU, with or without fragmentation, may be smaller than this.
Expires July 1999 [Page 3]
INTERNET-DRAFT EDNS0 January 1999
4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
reassembly buffer. Choosing 1280 on an Ethernet connected requestor
would be reasonable. The consequence of choosing too large a value may
be an ICMP message from an intermediate gateway, or even a silent drop
of the response message. Requestors are advised to retry in such cases.
4.5.2. Both requestors and responders are advised to take account of the
path's already discovered MTU (if known) when considering message sizes.
4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
are structured as follows:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that
EXTENDED-RCODE value "0" indicates that an unextended
RCODE is in use (values "0" through "15").
VERSION Indicates the implementation level of whoever sets it.
Full conformance with this specification is indicated by
version ``0.'' Note that both requestors and responders
should set this to the highest level they implement,
that responders should send back RCODE=BADVERS and that
requestors should be prepared to probe using lower
version numbers if they receive an RCODE=BADVERS.
Z Set to zero by senders and ignored by receivers, unless
modified in a subsequent specification.
5 - Transport Considerations
5.1. The presence of an OPT pseudo-RR in a request should be taken as an
indication that the requestor fully implements the given version of
EDNS, and can correctly understand any response that conforms to that
feature's specification.
5.2. Lack of use of these features in a request must be taken as an
indication that the requestor does not implement any part of this
specification and that the responder may make no use of any protocol
Expires July 1999 [Page 4]
INTERNET-DRAFT EDNS0 January 1999
extension described here in its response.
5.3. Responders who do not understand these protocol extensions are
expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL.
Therefore use of extensions should be ``probed'' such that a responder
who isn't known to support them be allowed a retry with no extensions if
it responds with such an RCODE. If a responder's capability level is
cached by a requestor, a new probe should be sent periodically to test
for changes to responder capability.
6 - Security Considerations
Requestor-side specification of the maximum buffer size may open a new
DNS denial of service attack if responders can be made to send messages
which are too large for intermediate gateways to forward, thus leading
to potential ICMP storms between gateways and responders.
7 - IANA Considerations
IANA is hereby requested to assign an RR type code for OPT.
It is the recommendation of this document and its working group that
IANA create a registry for EDNS Extended Label Types, for EDNS Option
Codes, and for EDNS Version Numbers.
This document assigns label type 0b01xxxxxx as "EDNS Extended Label
Type." We request that IANA record this assignment.
This document assigns extended label type 0bxx111111 as "Reserved for
future extended label types." We request that IANA record this
assignment.
This document assigns option code 65535 to "Reserved for future
expansion."
This document expands the RCODE space from 4 bits to 12 bits. This will
allow IANA to assign more than the 16 distinct RCODE values allowed in
[RFC1035].
This document assigns EDNS Extended RCODE "16" to "BADVERS".
IESG approval should be required to create new entries in the EDNS
Extended Label Type or EDNS Version Number registries, while any
published RFC (including Informational, Experimental, or BCP) should be
grounds for allocation of an EDNS Option Code.
Expires July 1999 [Page 5]
INTERNET-DRAFT EDNS0 January 1999
8 - Acknowledgements
Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
Narten were each instrumental in creating and refining this
specification.
9 - References
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, USC/Information Sciences
Institute, November 1987.
10 - Author's Address
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
<paul@vix.com>
Expires July 1999 [Page 6]

320
doc/draft/draft-ietf-dnsind-edns1-02.txt Normal file
View file

@ -0,0 +1,320 @@
DNSIND Working Group Paul Vixie
INTERNET-DRAFT ISC
<draft-dnsind-edns1-02.txt> January, 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.
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.''
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).
Abstract
This document specifies a number of extensions within the Extended
DNS framework defined by [EDNS0], including several new extended
label types and the ability to ask multiple questions in a single
request.
1 - Rationale and Scope
1.1. EDNS (see [EDNS0]) specifies an extension mechanism to DNS (see
[RFC1035]) which provides for larger message sizes, additional label
types, and new message flags.
1.2. This document makes use of the EDNS extension mechanisms to add
several new extended label types and message options, and the ability to
ask multiple questions in a single request.
Expires July 1999 [Page 1]
INTERNET-DRAFT EDNS1 January 1999
2 - Affected Protocol Elements
2.1. Compression pointers are 14 bits in size and are relative to the
start of the DNS Message, which can be 64KB in length. 14 bits restrict
pointers to the first 16KB of the message, which makes labels introduced
in the last 48KB of the message unreachable by compression pointers. A
longer pointer format is needed.
2.2. DNS Messages are limited to 65535 octets in size when sent over
TCP. This acts as an effective maximum on RRset size, since multiple
TCP messages are only possible in the case of zone transfers. Some
mechanism must be created to allow normal DNS responses (other than zone
transfers) to span multiple DNS Messages when TCP is used.
2.3. Multiple queries in a question section have not been supported in
DNS due the applicability of some DNS Message Header flags (such as AA)
and of the RCODE field only to a single QNAME, QTYPE, and QCLASS.
Multiple questions per request are desirable, and some way of asking
them must be made available.
3 - Extended Label Types
3.1. In [EDNS0], the ``0 1'' label type was specified to denote an
extended label type, whose value is encoded in the lower six bits of the
first octet of a label, and an extended label type of ``1 1 1 1 1 1''
was further reserved for use in future multibyte extended label types.
3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended
compression pointer, such that the following two octets comprise a
16-bit compression pointer in network byte order. Like the normal
compression pointer, this pointer is relative to the start of the DNS
Message.
3.3. The ``0 0 0 0 0 1'' extended label type will indicate a counted bit
string label as described in [CRAW98].
3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long
local compression pointer'' as described in [KOCH98].
Expires July 1999 [Page 2]
INTERNET-DRAFT EDNS1 January 1999
4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags
are structured as follows:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: |MD |FM |RRD|LM | Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. (As
defined by [EDNS0].)
VERSION Indicates the implementation level of whoever sets it.
Full conformance with the draft standard version of this
specification is version ``1.'' Note that both
requestors and responders should set this to the highest
level they implement, that responders should send back
RCODE=BADVERS and that requestors should be prepared to
probe using lower version numbers if they receive an
RCODE=BADVERS.
MD ``More data'' flag. Valid only in TCP streams where
message ordering and reliability are guaranteed. This
flag indicates that the current message is not the
complete request or response, and should be aggregated
with the following message(s) before being considered
complete. Such messages are called ``segmented.'' It
is an error for the RCODE (including the EXTENDED-
RCODE), AA flag, or DNS Message ID to differ among
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.
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
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
containing QNAME, and where QTYPE=ANY or QDCOUNT>1. If
set in a request, the intermediate name server can only
answer using unexpired cached answers (either positive
or negative) which were atomically acquired using (a)
the same QTYPE or set of QTYPEs present in the current
question and whose TTLs were each minimized to the
smallest among them when first cached, and (b) the same
FM and LM settings present in the current question.
LM ``Longest match'' flag. If this flag is present in a
query message, then for any question whose QNAME is not
fully matched by zone or cache data, the longest
trailing label-bounded suffix of the QNAME for which
zone or cache data is present will be eligible for use
as an answer. Note that an intervening wildcard name
shall supercede this behaviour and the rules described
in [RFC1034 4.3.2, 4.3.3] shall apply, except that the
owner name of the answer will be the wildcard name
rather than the QNAME. Any of: QTYPE=ANY, or
QCLASS=ANY, or QCOUNT>1, shall be considered an error if
the LM flag is set.
If LM is set in a request, then LM has meaning in the
response as follows: If the content of the response
would have been different without the LM flag being set
on the request, then the response LM will be set; If the
content of the response was not determined or affected
by the request LM, then the response LM will be cleared.
If the request LM was not set, then the response LM is
not meaningful and should be set to zero by responders
and ignored by requestors.
Z Set to zero by senders and ignored by receivers, unless
modified in a subsequent specification.
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
original request was processed by an authoritative server and the
response forwarded in its entirety.
5.3. If a multiple question request is processed by an intermediate
server and the authority server does not support multiple questions, the
intermediate server must generate an answer iteratively by making
multiple requests of the authority server. In this case, AA must never
be set in the final answer due to lack of atomicity of the contributing
authoritative responses.
5.4. If iteratively processing a multiple question request using an
authority server which can only process single question requests, if any
contributing request generates a SERVFAIL response, then the final
response's RCODE should be SERVFAIL.
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.
7 - References
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, USC/Information Sciences
Institute, November 1987.
[EDNS0] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' Draft
draft-ietf-dnsind-edns0-XX, IETF DNSIND, September 1998
[CRAW98] M. Crawford, ``Binary Labels in the Domain Name System,''
Draft draft-ietf-dnsind-binary-labels-XX, IETF DNSIND, March
1998.
[KOCH98] P. Koch, ``A New Scheme for the Compression of Domain
Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt.
IETF DNSIND, March 1998.
Expires July 1999 [Page 5]
INTERNET-DRAFT EDNS1 January 1999
8 - Author's Address
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
<paul@vix.com>
Expires July 1999 [Page 6]

449
doc/draft/draft-ietf-dnsind-local-compression-04.txt Normal file
View file

@ -0,0 +1,449 @@
INTERNET-DRAFT Peter Koch
Expires: August 1999 Universitaet Bielefeld
Updates: 1035, 1183, 2065, 2163, 2168 February 1999
A New Scheme for the Compression of Domain Names
draft-ietf-dnsind-local-compression-04.txt
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.
Comments should be sent to the author or the DNSIND WG mailing list
<namedroppers@internic.net>.
Abstract
The compression of domain names in DNS messages was introduced in
[RFC1035]. Although some remarks were made about applicability to
future defined resource record types, no method has been deployed yet
to support interoperable DNS compression for RR types specified since
then.
This document summarizes current problems and proposes a new
compression scheme to be applied to future RR types which supports
interoperability. Also, suggestions are made how to deal with RR
types defined so far.
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Koch Expires August 1999 [Page 1]
INTERNET-DRAFT DNS Compression February 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].
2. Background
Domain name compression was introduced in [RFC1035], section 4.1.4,
as an optional protocol feature and later mandated by [RFC1123],
section 6.1.2.4. The intent was to reduce the message length,
especially that of UDP datagrams, by avoiding repetition of domain
names or even parts thereof.
A domain name is internally represented by the concatenation of label
strings, where the first octet denotes the string length, not
including itself. The null string, consisting of a single octet of
zeroes, is the representation of the root domain name and also
terminates every domain name.
As labels may be at most 63 characters long, the two most significant
bits in the length octet will always be zero. Compression works by
overloading the length octet with a second meaning. If the two MSB
have the value '1', the remainder of the length octet and the next
octet form a compression pointer, which denotes the position of the
next label of the current domain name in the message:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
It is important that these pointers always point backwards.
Compression may occur in several places. First, the owner name of an
RR may be compressed. The compression target may be another owner
name or a domain name in the RDATA section of a previous RR. Second,
any domain name within the RDATA section may be compressed and the
target may be part of the same RR, being the owner name or another
domain name in the RDATA section, or it may live in a previous RR,
either as its owner or as a domain name in its RDATA section. In
fact, due to the chaining feature, combinations of the above may
occur.
3. Problems
While implementations shall use and must understand compressed domain
names in the RDATA section of "well known" RR types (those initially
defined in [RFC1035]), there is no interoperable way of applying
Koch Expires August 1999 [Page 2]
INTERNET-DRAFT DNS Compression February 1999
compression to the RDATA section of newer RRs:
Quote from [RFC1123], section 6.1.3.5:
Compression relies on knowledge of the format of data inside a
particular RR. Hence compression must only be used for the
contents of well-known, class-independent RRs, and must never be
used for class-specific RRs or RR types that are not well-known.
The owner name of an RR is always eligible for compression.
DNS records in messages may travel through caching resolvers not
aware of the particular RR's type and format. These caches cannot
rearrange compression pointers in the RDATA section simply because
they do not recognize them. Handing out these RRs in a different
context later will lead to confusion if the target resolver tries to
uncompress the domain names using wrong information. This is not
restricted to intermediate caching but affects any modification to
the order of RRs in the DNS message.
4. Local Compression
We often observe a certain locality in the domain names used as owner
and occuring in the RDATA section, e.g. in MX or NS RRs but also in
newer RR types [RFC1183]:
host.foo.bar.example RP adm.foo.bar.example adm.persons.bar.example
So, to still profit from compression without putting interoperability
at risk, a new scheme is defined which limits the effect of
compression to a single RR.
In contrast to the usual method of using offsets relative to the
start of a DNS packet we start counting at the RR owner or calculate
pointers relative to the start of the RDATA to avoid context
sensitivity. We use an additional compression indicator for a two
octet local pointer:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 0| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The "10" bits will indicate the use of local compression and
distinguish it from conventional compression, plain labels and EDNS
label codes [EDNS0]. Two types of pointers need to be specified:
those pointing into the owner name and those pointing into RDATA.
A) Pointers into the owner name are interpreted as the ordinal label
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 August 1999 [Page 3]
INTERNET-DRAFT DNS Compression February 1999
message composition or decomposition.
The highest possible value of a compression pointer pointing into
the owner name is 254. The value 255 is reserved for future use.
B) Pointers into the RDATA section start at the fixed value 256 for
the first octet and have a maximum value of 16383 limiting
possible targets to the first 16128 octets. The actual offset
relative to the start of RDATA is determined by subtracting 256
from the value of the pointer.
Local pointers MUST point to a previous occurence of the same name in
the same RR. Even domain names in another RR of the same type cannot
serve as compression targets since the order of RRs in an RRSet is
not necessarily stable. The length of the compressed name(s) MUST be
used in the length calculation for the RDLENGTH field.
Example
Consider a DNS message containing two resource records, one CNAME RR
and one XMPL RR, undefined and meaningless so far, with an RDATA
section consisting of two domain names:
ab.foo.example IN CNAME bar.example
bar.example IN XMPL ab.foo.example foo.example
In a message this appears as follows (randomly starting at octet 12):
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | 2 | a |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
14 | b | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
16 | f | o |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
18 | o | 7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | e | x |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | a | m |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | p | l |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | e | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 octets skipped (TYPE, CLASS, TTL, RDLENGTH)
Koch Expires August 1999 [Page 4]
INTERNET-DRAFT DNS Compression February 1999
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
38 | 3 | b |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 | a | r |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 | 1 1| 19 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The XMPL RR with local compression applied:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1 | 38 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 octets skipped (TYPE, CLASS, TTL, RDLENGTH)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
56 | 1 | a |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
58 | 3 | f |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
60 | o | o |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
62 | 1 0| 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1 0| 258 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The first local pointer at position 62 points to the topmost label
"example" of the XMPL RR's owner.
The second local pointer at position 64 represents the "foo.example"
and points backwards into the RDATA section, third octet, at absolute
position 58. Note that with conventional compression this example
message would have occupied less space.
5. Interaction with DNSSEC
The security extensions to DNS [RFC2065] 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:
Resource Records subject to local compression MUST be stored,
signed, transmitted and verified in locally compressed form. Name
expansion or canonicalization MUST NOT be performed on the RDATA
section for signing or verification.
This way RR type transparency can be achieved, since domain names in
Koch Expires August 1999 [Page 5]
INTERNET-DRAFT DNS Compression February 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
types subject to conventional or no compression are not affected by
this change.
Wildcard owners may serve as compression targets only in their fixed
part. Even if a particular query asks for a domain name which could
be used to compress the RDATA part more efficiently, this MUST NOT be
done. Otherwise signatures would be invalidated.
6. Interaction with Binary Labels
When constructing local compression pointers into the owner name,
every one-bit label is counted as a label. This way the compression
and decompression is independent of the actual bit-string
representation.
For local compression pointers into the RDATA section, only bit-
string labels may serve as targets, not single one-bit labels. Bit-
string labels may be adjusted to increase compression efficiency
[BINLABELS, section 3.1]
The internal representation of a domain name has a maximum length of
255 [RFC 1035]. Any label consists of at least two octets, leading
to at most 127 labels per domain name plus the terminating zero
octet, which does not qualify as a compression target. With the
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.
7. Old RR types and deployment
Although differences in RDATA sections by class have not yet been
reported and the concept of classes did not really spread, we are
just considering the IN class here.
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],
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
RR types are safe as their specifications prohibit compression.
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
applied to domain names in RDATA sections of any RR type defined so
far.
The specification of future RR types should explicitly select the use
of local compression or forbid RDATA domain name compression at all.
8. Security Considerations
The usual caveats for using unauthenticated DNS apply. This scheme is
believed not to introduce any new security problems. However,
implementors should be aware of problems caused by blindly following
compression pointers of any kind. [RFC1035] and this document limit
compression targets to previous occurences and this MUST be followed
in constructing and decoding messages. Otherwise applications might
be vulnerable to denial of service attacks launched by sending DNS
messages with infinite compression pointer loops. In addition,
pointers should be verified to really point to the start of a label
(for conventional and local RDATA pointers) and not beyond the end of
the domain name (for local owner name pointers).
The maximum length of 255 applies to domain names in uncompressed
wire format, so care must be taken during decompression not to exceed
this limit to avoid buffer overruns.
9. Acknowledgements
The author would like to thank Andreas Gustafsson, Paul Vixie, Bob
Halley, Mark Andrews and Thomas Narten for their review and
constructive comments.
10. References
[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 13, November 1987
[RFC1035] Mockapetris,P., "Domain Names - Implementation and
Specification", RFC 1035, STD 13, November 1987
[RFC1123] Braden,R., "Requirements for Internet Hosts -- Application
and Support", RFC 1123, STD 3, October 1989
[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
[RFC2163] Allocchio,C., "Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping (MCGAM)", RFC 2163,
January 1998
[RFC2168] Daniel,R., Mealling,M., "Resolution of Uniform Resource
Identifiers using the Domain Name System", RFC 2168, June
1997
[RFC2230] Atkinson,R., "Key Exchange Delegation Record for the DNS",
RFC 2230, November 1997
[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
Universitaet Bielefeld
Technische Fakultaet
Postfach 10 01 31
D-33501 Bielefeld
Germany
+49 521 106 2902
<pk@TechFak.Uni-Bielefeld.DE>
Koch Expires August 1999 [Page 8]

754
doc/draft/draft-ietf-dnsind-local-names-06.txt Normal file
View file

@ -0,0 +1,754 @@
INTERNET-DRAFT Local Domain Names
November 1998
Expires May 1999
Local DNS Names
----- --- -----
Donald E. Eastlake 3rd
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 document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. 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 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).
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.
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT Local DNS Names
Acknowledgments
The valuable contributions of the following persons are gratefully
acknowledged:
Dan Harrington
Michael A. Patton
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
References................................................10
Author's Address..........................................10
Expiration and File Name..................................10
Appendix A: the .local zone...............................11
Appendix B: the .in-addr.arpa zone.......................13
Donald E. Eastlake 3rd [Page 2]
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
which are top level domain names such as .com and .us. Below top
level domain names there are normally additional levels of names.
Generally the information in the DNS is public and intended to be
globally accessible. Certainly, in the past, the model of the
Internet was one of end-to-end openness [RFC 1958]. However, with
increasing security threats and concerns, firewalls and enclaves have
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.
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.
In the DNS area, local private names have generally been achieved in
the past by "splitting" DNS at the enclave boundary, giving different
answers to resolvers depending or whether they are inside or outside
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.
This document specifies an alternative approach to achieving the
effect of local names that is more in tune with the concept of a
single global DNS tree or at least the appearance of a single tree.
Use of this approach is not required and older techniques will
continue to work.
[RFC 1918] requires that private IP addresses not be indirectly
exposed to the general Internet via DNS records or otherwise. 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.
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.
The following figure shows a highly simplified overview of an example
configuration:
+----------------------------+
| domain/enclave A |
| |
| #====================# |
| H private IP addrs A H |
| H H |
+-----------------------O privhost1 H |
| | H H |
+-----+-----------------O privhost2 H |
| | | H H |
| | | #====================# |
| | a | |
| +--------------------O pubhost3 |
.local | | | | |
+----+ | | +----------------------------+
| | | |
| | | | +----------------------------+
| | | | | domain/enclave B |
(root) | | | | | |
. ----+ | | | | #====================# |
| | | | | H private IP addrs B H |
| | | | | H H |
| +--|--------------------O privhost2 H |
| | | | H H |
+-------+ +-----------------O privhost3 H |
.com | | H : H |
| | #====:===============# |
| | : |
| b +-------------O pubhost4 |
+------+ | |
| +-------------O pubhost5 |
| | |
| +----------------------------+
|
| example
+---------------------O pubhost6
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.
Moving to the top of the figure, enclave A represents some
organization that wishes to have some hosts with publicly visible
names and some with hidden names that are visible only locally.
pubhost3.a.com is an example of a publicly visible host which would
probably have a public IP address although access to pubhost3 from
outside the enclave might be filtered or even blocked by a firewall
or the like. privhost1 and privhost2 are examples of hidden names.
If a zone with privhost1 and privhost2 in it is served by DNS servers
with private IP addresses ("private IP addresses A") such that the
servers are accessible within enclave A but not from outside enclave
A, then the information is that zone will only be locally visible.
As show in the above figure, privhost1 and privhost2 have addresses
that are also private IP addresses, making those hosts inaccessible
outside enclave A, but it is the private addresses of the DNS
servers, not of the hosts pointed to from within the private DNS
zone, that provides the protection for the DNS names and other
private DNS information. (From the above simplified diagram, it
might appear that fully qualified domain names of these hosts would
be privhost1.local and privhost2.local but the names are actually
more complex as explained in Section 2.1.)
Finally, in the middle, another enclave is shown with two hosts with
visible names and public IP addresses, pubhost4.b.com and
pubhost5.b.com. In addition, there are two private host names
privhost2 and privhost3. The duplication of privhost2 between
enclaves A and B would not be a problem as only DNS resolvers in
enclave A can access the DNS servers with the zone having the enclave
A version of privhost2 and only DNS resolvers in enclave B can access
the DNS servers with the zone having the enclave B version of
privhost2.
Publicly visible host names are required by [RFC 1918] to have public
(i.e., globally unique) IP addresses. Private DNS names would
normally have private IP addresses, and all do in the figure above,
but this is not required. A public IP address could be stored under
a private name. And, of course, it is possible for the same physical
host to have multiple IP addresses, including a mix of public and
private. The dotted line in the figure above is intended to indicate
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
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
with the private address under the private name.
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
of which is a delegation point to a zone with some number of name
servers in one of the private IP address space blocks. The multiple
second level names permit choice between the different private IP
blocks and different numbers of servers. Thus the actual fully
qualified name for the private host examples in the figure above
would be more like privhost1.a2.local, privhost2.a2.local, etc. (but
see Section 2.3 below).
Glue records are provided to give private IP addresses for initial
name servers; however, it should be noted that the NS and A records
in the local zones will dominate the information stored in the .local
zone. This means that once a resolver has contacted a local server,
the list of NS RRs in the local zone on that server will control and
could contain more or different servers than were given at the chosen
.local delegation point. Nevertheless, the glue A records in the
global .local zone do place some constraints of the private IP
address of the local DNS servers implementing zones which are
children of .local.
It is also possible for an enclave to locally configure its own
version of the .local zone. Depending on its enclave boundary
implementation, it might be able to constrain all of its internal
references to .local to use its own variant version. This version
could have whatever private addresses were desired for the name
servers involved. Such a configuration MAY be used, but it is
recommended that the globally accessible .local specified herein be
used for uniformity. That way, even a unconstrained resolver
starting from the normal root servers (i.e., an "out of the box"
resolver) will correctly resolve or fail to resolve names under
.local depending on the resolvers location in the network as
specified herein.
It is only necessary for the local DNS servers to have private IP
addresses to achieve the effect of local names. However, care MUST
be taken that none of the local DNS servers or any server that might
cache their output is accessible by any network interface that has a
non-private IP address. Otherwise considerable confusion could
result if local names are resolved by a resolver outside a local
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]
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.
2.3 Name Conflicts
The intention is that local names would only be used in the enclave
where the entities they refer to exist, and these names would not be
exported. However, experience indicates that. despite best efforts
to avoid it, some such names will leak out via email cc's, URL's in
HTML, etc. (Such leakage occurs regardless of how the local names
are formed or whether they are accessible via the default root zone.)
These leaked private names can cause confusion if they can conflict
with global names or names local to other enclaves. Use of the
.local top level domain assures no conflict with global names. To
assure no conflict with different local fully qualified names, the
domain name of the enclave SHOULD always be prefixed to .local.
For example, a company might have
host1.company.co.xy
as a globally accessible host and
host2.company.co.xy.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.
Note that different names were chosen for the initial label in the
two names above, i.e., host1 and host2. The reason for this is that,
in some environments, local hosts are referred to by an unqualified
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
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT Local DNS Names
used for global and local entity unqualified domain names and that
fully qualified domain names be used wherever practical.
2.4 Nested Enclaves
It is possible to have enclaves within enclaves. In general the best
way to accomplish this is to use a different portion of the private
IP address space at each nesting level of enclave. (Private IP
address space can be reused in enclaves that are siblings or the
like.) Then similar entries to those proposed here for .local can be
made in the private zone referring to name servers with addresses in
the nested enclave's private IP address space.
3. Other Names in .local
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 addition, loopback.local is assigned and given the loopback
address.
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.
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.
Software should not depend on local names being accessible only
within a particular enclave as someone could deliberately create the
Donald E. Eastlake 3rd [Page 8]
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.
4.2 Interaction with DNSSEC
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.
Donald E. Eastlake 3rd [Page 9]
INTERNET-DRAFT Local DNS Names
References
RFC 1033 - M. Lottor, "Domain Administrators Operations Guide",
November 1987.
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 1591 - J. Postel, "Domain Name System Structure and Delegation",
03/03/1994.
RFC 1918 - Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E.
Lear, "Address Allocation for Private Internets", 02/29/1996.
RFC 1958 - B. Carpenter, "Architectural Principles of the Internet",
06/06/1996.
draft-ietf-dnssec-secext2-*.txt - D. Eastlake "Domain Name System
Security Extensions".
Author's Address
Donald E. Eastlake 3rd
IBM
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978-287-4877
+1 914-784-7913
FAX: +1 978-371-7148
EMail: dee3@us.ibm.com
Expiration and File Name
This draft expires May 1999.
Its file name is draft-ietf-dnsind-local-names-06.txt.
Donald E. Eastlake 3rd [Page 10]
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]

560
doc/draft/draft-ietf-dnsind-rfc2052bis-02.txt Normal file
View file

@ -0,0 +1,560 @@
Applications Area Arnt Gulbrandsen
INTERNET-DRAFT Troll Technologies
<draft-ietf-dnsind-rfc2052bis-02.txt> Paul Vixie
Obsoletes: RFC 2052 Internet Software Consortium
January 1999
A DNS RR for specifying the location of services (DNS SRV)
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.
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."
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).
Abstract
This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain (like a more general
form of MX).
Overview and rationale
Currently, one must either know the exact address of a server to
contact it, or broadcast a question. This has led to, for example,
ftp.whatever.com aliases [RFC 2219], the SMTP-specific MX RR, and
using MAC-level broadcasts to locate servers.
The SRV RR allows administrators to use several servers for a single
domain, to move services from host to host with little fuss, and to
designate some hosts as primary servers for a service and others as
backups.
Clients ask for a specific service/protocol for a specific domain
(the word domain is used here in the strict RFC 1034 sense), and get
back the names of any available servers.
Gulbrandsen and Vixie Proposed [Page 1]
RFC 2052bis DNS SRV RR January 1999
Note that where this document refers to "address records", it means A
RR's, AAAA RR's, or their most modern equivalent.
Introductory example
If a SRV-cognizant web-browser wants to retrieve
http://www.example.com/
it does a lookup of
_http._tcp.www.example.com
and retrieves the document from one of the servers in the reply. The
example zone file near the end of this memo contains answering RRs
for this query.
Definitions
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
used in this document are to be interpreted as specified in BCP 14.
Other terms used in this document are defined in the DNS
specification, RFC 1034.
The format of the SRV RR
Here is the format of the SRV RR, whose DNS type code is 33:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
(There is an example near the end of this document.)
Service
The symbolic name of the desired service, as defined in Assigned
Numbers [STD 2] or locally. An underscore (_) is prepended to
the service identifier to avoid collisions with DNS labels that
occur in nature.
Some widely used services, notably POP, don't have a single
universal name. If Assigned Numbers names the service
indicated, that name is the only name which is legal for SRV
lookups. Only locally defined services may be named locally.
The Service is case insensitive.
Proto
The symbolic name of the desired protocol, with an underscore
(_) prepended to prevent collisions with DNS labels that occur
Gulbrandsen and Vixie Proposed [Page 2]
RFC 2052bis DNS SRV RR January 1999
in nature. _TCP and _UDP are at present the most useful values
for this field, though any name defined by Assigned Numbers or
locally may be used (as for Service). The Proto is case
insensitive.
Name
The domain this RR refers to. The SRV RR is unique in that the
name one searches for is not this name; the example near the end
shows this clearly.
TTL
Standard DNS meaning [RFC 1035].
Class
Standard DNS meaning [RFC 1035]. SRV records occur in the IN
Class.
Priority
As for MX, the priority of this target host. A client MUST
attempt to contact the target host with the lowest-numbered
priority it can reach; target hosts with the same priority
SHOULD be tried in an order defined by the weight field. The
range is 0-65535. This is a 16 bit binary integer in network
byte order.
Weight
A load balancing mechanism. When selecting a target host among
the those that have the same priority, the chance of trying this
one first SHOULD be proportional to its weight, as specified
below. Larger weights lead to a higher probability of being
selected. The range of this number is 0-65535. This is a 16
bit binary integer in network byte order. Domain administrators
are urged to use Weight 0 when there isn't any load balancing to
do, to make the RR easier to read for humans (less noisy). In
the presence records containing weights greater than 0, records
with weight 0 have a very small chance of being selected.
To choose the target, the client SHOULD implement the effect of
this algorithm. This permits administrators to plan weights to
achieve the load distribution desired. Each time a target is
needed, the client should order the remaining (not previously
used) SRV RRs at the current priority in any random fashion,
except placing all those with weight 0 at the beginning of the
list. Compute the sum of the weights of those RRs, and with
each RR associate the running sum in the selected order. Then
choose a random number (not necessarily of integral value)
between 0 and the sum computed (inclusive), and select the RR
whose running sum value is the first in the selected order which
Gulbrandsen and Vixie Proposed [Page 3]
RFC 2052bis DNS SRV RR January 1999
is greater than or equal to the random number selected.
Port
The port on this target host of this service. The range is
0-65535. This is a 16 bit binary integer in network byte order.
This is often as specified in Assigned Numbers but need not be.
Target
As for MX, the domain name of the target host. There MUST be
one or more address records for this name, the name MUST NOT be
an alias (in the sense of RFC 1034 or RFC 2181). Implementors
are urged, but not required, to return the address record(s) in
the Additional Data section. Unless and until permitted by
future standards action, name compression is not to be used for
this field.
A Target of "." means that the service is decidedly not
available at this domain.
Applicability Statement
In general, it is expected that SRV records will be used by clients
for applications where the relevant protocol specification indicates
that clients should use the SRV record. The examples in this
document use familiar protocols as an aid in understanding. It is
not intended that those protocols will necessarily use SRV records.
Domain administrator advice
Expecting everyone to update their client applications when the first
internet site adds a SRV RR for some server is futile (even if
desirable). Therefore SRV would have to coexist with address record
lookups for existing protocols, and DNS administrators should try to
provide address records to support old clients:
- Where the services for a single domain are spread over several
hosts, it seems advisable to have a list of address records at
the same DNS node as the SRV RR, listing reasonable (if perhaps
suboptimal) fallback hosts for Telnet, NNTP and other protocols
likely to be used with this name. Note that some programs only
try the first address they get back from e.g. gethostbyname(),
and we don't know how widespread this behavior is.
- Where one service is provided by several hosts, one can either
provide address records for all the hosts (in which case the
round-robin mechanism, where available, will share the load
equally) or just for one (presumably the fastest).
Gulbrandsen and Vixie Proposed [Page 4]
RFC 2052bis DNS SRV RR January 1999
- If a host is intended to provide a service only when the main
server(s) is/are down, it probably shouldn't be listed in
address records.
- Hosts that are referenced by backup address records must use the
port number specified in Assigned Numbers for the service.
- Designers of future protocols for which "secondary servers" is
not useful (or meaningful) may choose to not use SRV's support
for secondary servers. Clients for such protocols may use or
ignore SRV RRs with Priority higher than the RR with the lowest
Priority for a domain.
Currently there's a practical limit of 512 bytes for DNS replies.
Until all resolvers can handle larger responses, domain
administrators are strongly advised to keep their SRV replies below
512 bytes.
All round numbers, wrote Dr. Johnson, are false, and these numbers
are very round: A reply packet has a 30-byte overhead plus the name
of the service ("_telnet._tcp.example.com" for instance); each SRV RR
adds 20 bytes plus the name of the target host; each NS RR in the NS
section is 15 bytes plus the name of the name server host; and
finally each A RR in the additional data section is 20 bytes or so,
and there are A's for each SRV and NS RR mentioned in the answer.
This size estimate is extremely crude, but shouldn't underestimate
the actual answer size by much. If an answer may be close to the
limit, using a DNS query tool (e.g. "dig") to look at the actual
answer is a good idea.
The "Weight" field
Weight, the load balancing field, is not quite satisfactory, but the
actual load on typical servers changes much too quickly to be kept
around in DNS caches. It seems to the authors that offering
administrators a way to say "this machine is three times as fast as
that one" is the best that can practically be done.
The only way the authors can see of getting a "better" load figure is
asking a separate server when the client selects a server and
contacts it. For short-lived services like SMTP an extra step in the
connection establishment seems too expensive, and for long-lived
services like telnet, the load figure may well be thrown off a minute
after the connection is established when someone else starts or
finishes a heavy job.
Gulbrandsen and Vixie Proposed [Page 5]
RFC 2052bis DNS SRV RR January 1999
The Port number
Currently, the translation from service name to port number happens
at the client, often using a file such as /etc/services.
Moving this information to the DNS makes it less necessary to update
these files on every single computer of the net every time a new
service is added, and makes it possible to move standard services out
of the "root-only" port range on unix.
Usage rules
A SRV-cognizant client SHOULD use this procedure to locate a list of
servers and connect to the preferred one:
Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
QTYPE=SRV.
If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
RR which specifies the requested Service and Protocol in the
reply:
If there is precisely one SRV RR, and its Target is "."
(the root domain), abort.
Else, for all such RR's, build a list of (Priority, Weight,
Target) tuples
Sort the list by priority (lowest number first)
Create a new empty list
For each distinct priority level
While there are still elements left at this priority
level
Select an element randomly, with probability
Weight, as specified above, and move it to the
tail of the new list
For each element in the new list
query the DNS for address records for the Target or
use any such records found in the Additional Data
section of the earlier SRV response.
for each address record found, try to connect to the
(protocol, address, service).
Gulbrandsen and Vixie Proposed [Page 6]
RFC 2052bis DNS SRV RR January 1999
else if the service desired is SMTP (and SMTP has been defined
elsewhere to expect SRV lookups)
skip to RFC 974 (MX).
else
Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
for each address record found, try to connect to the
(protocol, address, service)
Notes:
- Port numbers SHOULD NOT be used in place of the symbolic service
or protocol names (for the same reason why variant names cannot
be allowed: Applications would have to do two or more lookups).
- If a truncated response comes back from an SRV query, the rules
described in [RFC2181] shall apply.
- A client MAY use means other than Weight to choose among target
hosts with equal Priority.
- A client MUST parse all of the RR's in the reply.
- If the Additional Data section doesn't contain address records
for all the SRV RR's and the client may want to connect to the
target host(s) involved, the client MUST look up the address
record(s). (This happens quite often when the address record
has shorter TTL than the SRV or NS RR's.)
- Future protocols could be designed to use SRV RR lookups as the
means by which clients locate their servers.
Fictional example
This is (part of) the zone file for example.com, a still-unused
domain:
$ORIGIN example.com.
@ SOA server.example.com. root.example.com. (
1995032001 3600 3600 604800 86400 )
NS server.example.com.
NS ns1.ip-provider.net.
NS ns2.ip-provider.net.
Gulbrandsen and Vixie Proposed [Page 7]
RFC 2052bis DNS SRV RR January 1999
_ftp._tcp SRV 0 0 21 server.example.com.
_finger._tcp SRV 0 0 79 server.example.com.
; telnet - use old-slow-box or new-fast-box if either is
; available, make three quarters of the logins go to
; new-fast-box.
_telnet._tcp SRV 0 1 23 old-slow-box.example.com.
SRV 0 3 23 new-fast-box.example.com.
; if neither old-slow-box or new-fast-box is up, switch to
; using the sysdmin's box and the server
SRV 1 0 23 sysadmins-box.example.com.
SRV 1 0 23 server.example.com.
; HTTP - server is the main server, new-fast-box is the backup
; (On new-fast-box, the HTTP daemon runs on port 8000)
_http._tcp SRV 0 0 80 server.example.com.
SRV 10 0 8000 new-fast-box.example.com.
; since we want to support both http://example.com/ and
; http://www.example.com/ we need the next two RRs as well
_http._tcp.www SRV 0 0 80 server.example.com.
SRV 10 0 8000 new-fast-box.example.com.
; SMTP - mail goes to the server, and to the IP provider if
; the net is down
_smtp._tcp SRV 0 0 25 server.example.com.
SRV 1 0 25 mailhost.ip-provider.net.
@ MX 0 server.example.com.
MX 1 mailhost.ip-provider.net.
; NNTP - use the IP provider's NNTP server
_nntp._tcp SRV 0 0 119 nntphost.ip-provider.net.
; IDB is an locally defined protocol
_idb._tcp SRV 0 0 2025 new-fast-box.example.com.
; addresses
server A 172.30.79.10
old-slow-box A 172.30.79.11
sysadmins-box A 172.30.79.12
new-fast-box A 172.30.79.13
; backup address records - new-fast-box and old-slow-box are
; included, naturally, and server is too, but might go
; if the load got too bad
@ A 172.30.79.10
A 172.30.79.11
A 172.30.79.13
; backup address record for www.example.com
www A 172.30.79.10
; NO other services are supported
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .
In this example, a telnet connection to "example.com." needs an SRV
lookup of "_telnet._tcp.example.com." and possibly A lookups of "new-
Gulbrandsen and Vixie Proposed [Page 8]
RFC 2052bis DNS SRV RR January 1999
fast-box.example.com." and/or the other hosts named. The size of the
SRV reply is approximately 365 bytes:
30 bytes general overhead
20 bytes for the query string, "_telnet._tcp.example.com."
130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
fast-box", "old-slow-box", "server" and "sysadmins-box" -
"example.com" in the query section is quoted here and doesn't
need to be counted again.
75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
"ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is
quoted and only needs to be counted once.
120 bytes for the 6 address records (assuming IPv4 only) mentioned
by the SRV and NS RR's.
IANA Considerations
The IANA has assigned RR type value 33 to the SRV RR. No other IANA
services are required by this document.
Changes from RFC 2052
This document obsoletes RFC 2052. The major change from that
previous, experimental, version of this specification is that now the
protocol and service labels are prepended with an underscore, to
lower the probability of an accidental clash with a similar name used
for unrelated purposes. Aside from that, changes are only intended
to increase the clarity and completeness of the document.
Security Considerations
The authors believes this RR to not cause any new security problems.
Some problems become more visible, though.
- The ability to specify ports on a fine-grained basis obviously
changes how a router can filter packets. It becomes impossible
to block internal clients from accessing specific external
services, slightly harder to block internal users from running
unauthorized services, and more important for the router
operations and DNS operations personnel to cooperate.
- There is no way a site can keep its hosts from being referenced
as servers (as, indeed, some sites become unwilling secondary
MXes today). This could lead to denial of service.
- With SRV, DNS spoofers can supply false port numbers, as well as
Gulbrandsen and Vixie Proposed [Page 9]
RFC 2052bis DNS SRV RR January 1999
host names and addresses. Because this vunerability exists
already, with names and addresses, this is not a new
vunerability, merely a slightly extended one, with little
practical effect.
References
STD 2: Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700,
October 1994 (as currently updated by the IANA).
RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
RFC 1035: Mockapetris, P., "Domain names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
RFC 974: Partridge, C., "Mail routing and the domain system", RFC
974, January 1986.
BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2181: Elz, R., Bush, R., "Clarifications to the DNS
Specification", RFC 2181, July 1997
RFC 2219: Hamilton, M., Wright, R., "Use of DNS Aliases for Network
Services", BCP 17, RFC 2219, October 1997
Acknowledgements
The algorithm used to select from the weighted SRV RRs of equal
priority is adapted from one supplied by Dan Bernstein.
Authors' Addresses
Arnt Gulbrandsen Paul Vixie
Troll Tech Internet Software Consortium
Postboks 6133 Etterstad 950 Charter Street
N-0602 Oslo, Norway Redwood City, CA 94063
+47 22646966 +1 650 779 7001
<agulbra@troll.no> <paul@vix.com>
Gulbrandsen and Vixie Proposed [Page 10]

290
doc/draft/draft-ietf-dnsind-test-tlds-13.txt Normal file
View file

@ -0,0 +1,290 @@
INTERNET-DRAFT Reserved TLDs
February 1999
Expires August 1999
Reserved Top Level DNS Names
-------- --- ----- --- -----
Donald E. Eastlake 3rd
Aliza R. Panitz
Status of This Document
This draft is file name draft-ietf-dnsind-test-tlds-13.txt.
Distribution of this document is unlimited. Comments should be sent
to the DNS mailing list <namedroppers@internic.net> 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 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).
D. Eastlake, A. Panitz [Page 1]
INTERNET-DRAFT Reserved TLDs
Abstract
To reduce the likelihood of conflict and confusion, a few top level
domain names are reserved for use in private testing, as examples in
documentation, and the like. In addition, a few second level domain
names reserved for use as examples are documented.
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Table of Contents..........................................2
1. Introduction............................................3
2. TLDs for Testing, & Documentation Examples..............3
3. Reserved Example Second Level Domain Names..............4
4. IANA Considerations.....................................4
5. Security Considerations.................................4
References.................................................5
Authors Addresses..........................................5
Expiration and File Name...................................5
D. Eastlake, A. Panitz [Page 2]
INTERNET-DRAFT Reserved TLDs
1. Introduction
The global Internet Domain Name System is documented in [RFC 1034,
1035, 1591] 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.
2. TLDs for Testing, & Documentation Examples
There is a need for top level domain (TLD) names that can be used for
creating names which, without fear of conflicts with current or
future actual TLD names in the global DNS, can be used for private
testing of existing DNS related code, examples in documentation, DNS
related experimentation, invalid DNS names, or other similar uses.
For example, without guidance, a site might set up some local
additional unused top level domains for testing of its local DNS code
and configuration. Later, these TLDs might come into actual use on
the global Internet. As a result, local attempts to reference the
real data in these zones could be thwarted by the local test
versions. Or test or example code might be written that accesses a
TLD that is in use with the thought that the test code would only be
run in a restricted testbed net or the example never actually run.
Later, the test code could escape from the testbed or the example be
actually coded and run on the Internet. Depending on the nature of
the test or example, it might be best for it to be referencing a TLD
permanently reserved for such purposes.
To safely satisfy these needs, four domain names are reserved as
listed and described below.
.test
.example
.invalid
.localhost
".test" is recommended for use in testing of current or new DNS
related code.
".example" is recommended for use in documentation or as
examples.
".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a glance
are invalid.
The ".localhost" TLD has traditionally been statically defined
D. Eastlake, A. Panitz [Page 3]
INTERNET-DRAFT Reserved TLDs
in host DNS implementations as having an A record pointing to the
loop back IP address and is reserved for such use. Any other use
would conflict with widely deployed code which assumes this use.
3. Reserved Example Second Level Domain Names
The Internet Assigned Numbers Authority (IANA) also currently has the
following second level domain names reserved which can be used as
examples.
example.com
example.net
example.org
4. IANA Considerations
IANA has agreed to the four top level domain name reservations
specified in this document and will reserve them for the uses
indicated.
5. Security Considerations
Confusion and conflict can be caused by the use of a current or
future top level domain name in experimentation or testing, as an
example in documentation, to indicate invalid names, or as a synonym
for the loop back address. Test and experimental software can escape
and end up being run against the global operational DNS. Even
examples used "only" in documentation can end up being coded and
released or cause conflicts due to later real use and the possible
acquisition of intellectual property rights in such "example" names.
The reservation of several top level domain names for these purposes
will minimize such confusion and conflict.
D. Eastlake, A. Panitz [Page 4]
INTERNET-DRAFT Reserved TLDs
References
RFC 1034 - P. Mockapetris, "Domain names - concepts and facilities",
11/01/1987.
RFC 1035 - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
RFC 1591 - J. Postel, "Domain Name System Structure and Delegation",
03/03/1994.
Authors Addresses
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 10512
Telephone: +1 914-276-1668(h)
+1 914-784-7913(w)
FAX: +1 914-784-3833(3)
email: dee3@us.ibm.com
Aliza R. Panitz
500 Stamford Dr. No. 310
Newark, DE 19711 USA
Telephone: +1 302-738-1554
email: buglady@fuschia.net
Expiration and File Name
This draft expires August 1999.
Its file name is draft-ietf-dnsind-test-tlds-13.txt.
D. Eastlake, A. Panitz [Page 5]

795
doc/draft/draft-ietf-dnsind-tsig-08.txt Normal file
View file

@ -0,0 +1,795 @@
DNSIND Working Group Paul Vixie (Ed.) (ISC)
INTERNET-DRAFT Olafur Gudmundsson (TISLabs)
Donald Eastlake 3rd (IBM)
Brian Wellington (TISLabs)
<draft-ietf-dnsind-tsig-08.txt> February 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
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
This protocol allows for transaction level authentication using
shared secrets and one way hashing. It can be used to authenticate
dynamic updates as coming from an approved client, or to authenticate
responses as coming from an approved recursive name server.
No provision has been made here for distributing the shared secrets;
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.
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]
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
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
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
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
mechanisms may be impractical is authenticating dynamic update [RFC2136]
requests. [RFC2065] provides for request signatures but with [RFC2065]
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
used in dynamically updated zones. This document's secret key based
signatures can be used to authenticate DNS update requests as well as
transaction responses, providing a lightweight alternative to the
protocol described by [RFC2137].
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
protect glue records and unsigned records unless SIG(0) (transaction
signature) is used.
Expires August 1999 [Page 2]
INTERNET-DRAFT DNS TSIG February 1999
1.5. The signature mechanism proposed in this document uses shared
secret keys to establish trust relationship between two entities. Such
keys must be protected in a fashion similar to private keys, lest a
third party masquerade as one of the intended parties (forge
signatures). There is an urgent need to provide simple and efficient
authentication between clients and local servers and this proposal
addresses that need. This proposal is unsuitable for general server to
server authentication for servers which speak with many other servers,
since key management would become unwieldy with the number of shared
keys going up quadratically. But it is suitable for many resolvers on
hosts that only talk to few recursive servers.
1.6. A server acting as an indirect caching resolver -- a ``forwarder''
in common usage -- might use transaction signatures when communicating
with its small number of preconfigured ``upstream'' servers. Other uses
of DNS secret key signatures and possible systems for automatic secret
key distribution may be proposed in separate future documents.
1.7. New Assigned Numbers
RRTYPE = TSIG (250)
ERROR = 0..15 (a DNS RCODE)
ERROR = 16 (BADSIG)
ERROR = 17 (BADKEY)
ERROR = 18 (BADTIME)
ERROR = 19 (BADID)
2 - TSIG RR Format
2.1 TSIG RR Type
To provide secret key signatures, we use a new RR type whose mnemonic is
TSIG and whose type code is 250. TSIG is a meta-RR and can not be
stored. TSIG RRs can be used for authentication between DNS entities
that have established a shared secret key. TSIG RRs are dynamically
computed to cover a particular DNS transaction and are not DNS RRs in
the usual sense.
Expires August 1999 [Page 3]
INTERNET-DRAFT DNS TSIG February 1999
2.2 TSIG Calculation
As the TSIG RRs are related to one DNS request/response, there is no
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]).
2.3. Record Format
NAME A domain-like name of the key used. The name should reflect
the names of the hosts and uniquely identify the key among a
set of keys these two hosts may share at any given time. If
hosts A and B in same zone share a key then the key name could
be A-B-<id>.<zone>. If two hosts in different zones share the
key the key name could be <id>.A.<Azone>.B.<Bzone> It should
be possible for more than one key to be in simultaneous use
among a set of interacting hosts. The name only needs to be
meaningful to the communicating hosts but a meaningful
mnemonic name as above is strongly recommended.
The name may be used as a local index to the key involved and
it is recommended that it be globally unique. Where a key is
just shared between two hosts, its name actually only need
only be meaningful to them but it is recommended that the key
name be mnemonic and incorporate the resolver and server host
names in that order.
TYPE TSIG (250: Transaction SIGnature)
CLASS ANY
TTL 0
RdLen (variable)
Expires August 1999 [Page 4]
INTERNET-DRAFT DNS TSIG February 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.
Fudge u_int16_t seconds of error permitted
in Time Signed.
Signature Size u_int16_t number of octets in Signature.
Signature octet stream defined by Algorithm Name.
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 Data octet stream undefined by this protocol.
2.4. Example
NAME GW-DENVAX-0042.HOME.VIX.COM.
TYPE TSIG
CLASS ANY
TTL 0
RdLen as appropriate
RDATA
Field Name Contents
-------------------------------------------
Algorithm Name HMAC-MD5.SIG-ALG.REG.INT.
Time Signed 853804800
Fudge 300
Signature Size as appropriate
Signature as appropriate
Original ID as appropriate
Error 0 (NOERROR)
Other Len 0
Other Data empty
Expires August 1999 [Page 5]
INTERNET-DRAFT DNS TSIG February 1999
3 - Protocol Operation
3.1. Effects of adding TSIG to outgoing message
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]).
3.2. TSIG processing on incoming messages
Upon receipt of a message with a 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.
3.3. Time values used in TSIG calculations
The data digested includes the two timer values in the TSIG header in
order to prevent replay attacks. If this were not done an attacker
could replay old messages but update the ``Time Signed'' and ``Fudge''
fields to make the message look new. This data is named ``TSIG
Timers'', and for the purpose of digest calculation they are invoked in
their ``on the wire'' format, in the following order: first Time Signed,
then Fudge. For example:
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
are digested, in network byte order or wire format, as appropriate:
3.4.1. DNS Message
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.
3.4.2. TSIG Variables
Source Field Name Notes
------------------------------------------------------------------------
TSIG RR NAME Key name, in canonical wire format
TSIG RR CLASS (Always ANY in the current specification)
TSIG RR TTL (Always 0 in the current specification)
TSIG RDATA Algorithm Name in canonical wire format
TSIG RDATA Time Signed in network byte order
TSIG RDATA Fudge in network byte order
TSIG RDATA Error in network byte order
TSIG RDATA Other Len in network byte order
TSIG RDATA Other Data exactly as transmitted
The RR RDLEN and RDATA Signature Length are not included in the hash
since they are not guaranteed to be knowable before the signature is
generated.
The Original ID field is not included in this section, as it has already
been substituted for the message ID in the DNS header and hashed.
``Canonical wire format'' means uncompressed labels shifted to lower
case. The use of label types other than 00 is not defined for this
specification.
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
octet stream with no interfield padding.
4 - Protocol Details
4.1. TSIG generation on requests
Client performs the message digest operation and appends TSIG to
additional data section and transmits request to server. The client
must store the message digest from the request while awaiting an answer.
Digest components for requests are:
DNS Message (request)
TSIG Variables (response)
Note that some older name servers will not accept requests with a
nonempty additional data section, but clients should only attempt signed
transactions against servers who are known to support TSIG and share
some secret key with the client -- so, this is not a problem in
practice.
4.2. TSIG on Answers
When a server has generated a response to a signed request, it signs the
response using the same algorithm and key. Digest components are:
Request Signature
DNS Message (response)
TSIG Variables (response)
Expires August 1999 [Page 8]
INTERNET-DRAFT DNS TSIG February 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:
Request signature (if the request signature validated)
DNS Message (response)
TSIG Variables (response)
The reason that the request is not included in this digest in some cases
is to make it possible for the client to verify the error. If the error
is not a TSIG error the response MUST be generated as specified in
[4.2].
4.4. TSIG on TCP connection
A DNS TCP session can include multiple DNS envelopes. This is, for
example commonly used by AXFR. TSIG on such a connection can be used to
protect the connection from hijacking and provide data integrity. The
TSIG MUST be included on the first and last DNS envelopes. It can be
optionally placed on any intermediary envelopes. It is expensive to
include it on every envelopes, but it MUST be placed on at least every
100'th envelopes. The first envelope is processed as a standard answer,
and subsequent messages have the following digest components:
Prior Digest (running)
DNS Message (current message)
TSIG Timers (current message)
This allows client to rapidly detect when a transfer has been altered
and it can close the connection at that point and retry. Once client
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.
Expires August 1999 [Page 9]
INTERNET-DRAFT DNS TSIG February 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.
4.5.1. KEY check and error handling
If a non-forwarding server does not recognize the key used by the client
the server MUST generate an error response with RCODE 9 (NOTAUTH) and
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
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
error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 (BADTIME). This
response MUST be signed by the same key. It MUST include the client's
current time in the time signed field, the server's current time in the
other data field, and 6 in the other data length field. This is done so
that the client can verify a message with a BADTIME error without the
verification detecting another BADTIME error. The data signed is
specified in [4.3].
4.5.4. 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,
it first checks if the TSIG RR is present in the response. Otherwise
the response is treated as having a format error and discarded. The
client then extracts the TSIG, adjusts the ARCOUNT, and calculates the
keyed digest in the same way as the server. If the TSIG does not
validate, that response must be discarded, unless the RCODE is 9
(NOTAUTH), in which case the client should attempt to verify the
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
should log an error and continue to wait for a signed response until the
request times out.
4.6.1. Key error handling
If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
validates, and the TSIG key is different from the key used on the
request, then this is a key error. Client should retry the request
using the key specified by server. This should never occur, as a server
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
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
error. This is an indication that client and server are not clock
synchronized. In this case the client should log the event. DNS
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
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
request ID but it would be better to try a different shared key if one
is available. Client SHOULD keep track of how many times each key has
Signature errors. Clients should log this event.
4.7. Special considerations for forwarding servers
A server acting as a Forwarding Server of a DNS message should check for
the existence of the TSIG record. If the name on the TSIG is not of a
secret that the server shares with the originator the server will
forward the message unchanged including the TSIG. If the name of the
TSIG is of a key this server shares with the originator it processes the
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
MUST unset the AD flag before adding the TSIG to the answer.
5 - Shared Secrets
5.1. Secret keys are very sensitive information and all available steps
should be taken to protect them on every host on which they are stored.
Generally such hosts need to be physically protected. If they are
multi-user machines, great care should be taken that unprivileged users
have no access to keying material. Resolvers usually run unprivileged,
which means all users of a host will usually be able to see whatever
configuration data is used by the resolver.
5.2. A name server usually runs privileged, which means its
configuration data need not be visible to all users of the host. For
this reason, a host that implements transaction signatures should
probably be configured with a ``stub resolver'' and a local caching and
forwarding name server. This presents a special problem for [RFC2136]
which otherwise depends on clients to communicate only with a zone's
authoritative name servers.
5.3. Use of strong random shared secrets is essential to the security of
TSIG. See [RFC1750] for a discussion of this issue. The secret should
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
secret key is not compromised, strong authentication is provided for the
last hop from a local name server to the user resolver.
6.2. Secret keys should be changed periodically. If the client host has
been compromised, the server should suspend the use of all secrets known
to that client. If possible, secrets should be stored in encrypted
form. Secrets should never be transmitted in the clear over any
network. This document does not address the issue on how to distribute
secrets. Secrets should never be shared by more than two entities.
6.3. This mechanism does not authenticate source data, only its
transmission between two parties who share some secret. The original
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
available to the client.
7 - IANA Considerations
A new algorithm name should be a valid domain name of the type
algorithm-name.SIG-ALG.REG.INT. This requires an IETF consensus.
Adding new error codes requires an IETF consensus.
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,''
RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1034, ISI, November 1987.
[RFC1321] R. Rivest, ``The MD5 Message-Digest Algorithm,'' RFC 1321,
MIT LCS & RSA Data Security, Inc., April 1992.
[RFC1750] D. Eastlake, S. Crocker, J. Schiller, ``Randomness
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.
[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.
[RFC2137] D. Eastlake 3rd ``Secure Domain Name System Dynamic Update,''
CyberCash, April 1997.
Expires August 1999 [Page 14]
INTERNET-DRAFT DNS TSIG February 1999
9 - Authors' Addresses
Paul Vixie Olafur Gudmundsson
Internet Software Consortium TIS Labs at Network Associates
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>
Donald E. Eastlake 3rd Brian Wellington
IBM TIS Labs at Network Associates
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
<dee3@us.ibm.com> <bwelling@tislabs.com>
Expires August 1999 [Page 15]

158
doc/draft/draft-ietf-dnsind-verify-00.txt Normal file
View file

@ -0,0 +1,158 @@
INTERNET-DRAFT Mark Andrews (ISC)
<draft-ietf-dnsind-verify-00.txt> February 1999
Verifying Resource Records Without Knowing Their Contents
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
DNSSEC [RFC2065] provides a mechanism to cryptographically verify a
DNS resource record provided we can get it into canonical form.
The problem is how do we do this without knowing the contents of all
resource record types?
This document provides one possible solution to this problem.
1 - Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Expires August 1999 [Page 1]
INTERNET-DRAFT draft-ietf-dnsind-verify-00.txt February 1998
2 - Method
In order to be able to canonicalise a resource record a resolver needs
to know where in the data domain names exist so that the resolver can
decompress the domain names and convert the uppercase ASCII in ordinary
labels to lowercase prior to the data being feed into the encryption
routines.
This document propose that all new resource record types defined MUST
have a header at the start of the data section locating where the domain
names are in the data section. A new resource record for the purpose of
this document is any type NOT referenced in section 3 Old Types. Meta
queries such as MAILA (254), MAILB (253), AXFR (252) and IXFR (251) are
not covered by this document as they do not return data of this type.
This table would be a series of unsigned 16 bit words in network order.
The first word contains the length of the table as 16 bit words not
counting the first word. Subsequent words contain the offset from the
start of the data to the start of relevent domain name in the data
assuming all domain names are uncompressed. Offsets in the table are in
the same order as domain names in the data.
3 Old Types
The following types are deemed old and are NOT covered by this document.
A (1), NS (2), MD (3), MF (4), CNAME (5), SOA (6), MB (7), MG (8), MR
(9), NULL (10), WKS (11), PTR (12), HINFO (13), MINFO (14), MX (15), TXT
(16), RP (17), AFSDB (18), X25 (19), ISDN (20), RT (21), NSAP (22),
NSAP-PTR (23), SIG (24), KEY (25), PX (26), GPOS (27), AAAA (28), LOC
(29), NXT (30), EID (31), NIMLOC (32), SRV (33), ATMA (34), NAPTR (35),
KX (36), CERT (37), A6 (38), DNAME (39), UINFO (100), UID (101), GID
(102), UNSPEC (103), OPT (XXX), TKEY (249) and TSIG (250).
4 Security Considerations
It is believed that this document does not introduce any significant
additional security threats other that those that already exist when
using data from the DNS but rather enhances security by allowing new
resource record types to be checked by security aware resolvers.
5 IANA Considerations
This document places no requirements apon IANA.
Expires August 1999 [Page 2]
INTERNET-DRAFT draft-ietf-dnsind-verify-00.txt February 1998
References
[RFC2065]
Eastlake, D. 3rd. and Kaufman, C,. "Domain Name System Security
Extensions," RFC 2065, January 1997
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Lev­
els," BCP 14, RFC 2119, March 1997
Author's Address
Mark Andrews
Internet Software Consortium
1 Seymour St.
Dundas Valley
NSW 2117
AUSTRALIA
+61 2 9871 4742
<Mark_Andrews@isc.org>
Expires August 1999 [Page 3]

618
doc/draft/draft-ietf-dnssec-ar-00.txt Normal file
View file

@ -0,0 +1,618 @@
Domain Name System Security Working Group R. Watson
INTERNET DRAFT November 1997
<draft-ietf-dnssec-ar-00.txt> Expires in six months
DNSsec Authentication Referral Record (AR)
Status of this Document
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
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 (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
Authentication Referrals allow DNS to refer to authentication
mechanisms that supplement or replace the KEY RRs of DNSsec.
Five Authentication Service types are defined: DNSsec, Kerberos IV,
Kerberos V, Network Information Service (NIS+), and Radius.
Watson [Page 1]
Internet DRAFT DNSsec Authentication Referral November 1997
1. Introduction
Domain Name System Security [DNSSEC] extends the Domain Name System
(DNS) [RFC1034, RFC1035] to provide for data origin authentication,
public key distribution, and query and transaction authentication,
all based on public key cryptography and public key based digital
signatures. In many organizations, it is desirable to provide a
centralized source for authentication data, especially in
environments where multiple systems are used (for example, KerberosIV
and NIS+). Systems have been defined for distributing user
information in the DNS name-space [HESIOD], but DNS has traditionally
lacked the security necessary to safely distribute sensitive
authentication information. Authentication Referrals use DNSsec's
authenticated data capabilities to distribute mappings from entities
to authentication mechanisms.
1.1 Keywords Used
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
1.2 Definition of Terms
Service Desiring Authentication (SDA): A service requiring a user to
authenticate before providing access. For example, the login program
on a UNIX host is an SDA.
Authentication Service: A type of authentication system that allows
an SDA to verify the identity of a Client communicating with the SDA.
Services are typically accessed using an Authentication Server such
as a KerberosIV or Radius server. In a referral, both the type of
authentication service and the server address are provided.
Client: An entity that wishes to connect to a service, in particular,
to an SDA. Clients are identified using a unique DNS Fully Qualified
Domain Name (FQDN), which contains records providing information on
verifying authentication. Authentication Client may refer to both
humans and hosts in this document.
Authentication Username: In the event that an Authentication Service
is used, the Username may differ from the Client's FQDN in DNS.
Authentication Realm: Some distributed authentication systems allow
for multiple "realms" in which authentication takes place. Realms
typically represent a set of identities and services over which a
single authority is responsible for authentication. Where
appropriate, referrals contain the name of the realm against which
Watson [Page 2]
Internet DRAFT DNSsec Authentication Referral November 1997
they should be made.
Authentication Server: Many authentication systems rely on a
centralized database, which may be found on the Authentication
Server. This database can be identified using the DNS FQDN for the
host. It is assumed that the Authentication Service type will
provide all other information necessary to communicate with the
Authentication Server.
1.3 Authentication in DNSsec
DNSsec provides a mechanism for the authentication of entities it
describes via KEY records containing public keys. This is adequate
for IP Security [IPSEC] and other key-based protocols (such as Secure
Shell [SSH]), but it is not useful for individual user
authentication. Typically such an authentication process involves
the encryption of data using the Client's public key (extracted from
DNSsec), which must then be decrypted by the Client and returned in
some other form (often encrypted with the SDA's public key to protect
both the challenge and the response). Users may be reluctant to
replace their traditional alpha-numeric password with 514-bit private
keys and then perform computation-intensive key manipulation and
signature-operations in their heads. While devices are available
that perform this function in a more accessible manner, they are not
yet mainstream, and a standard has not yet been proposed for
interaction between these devices and DNSsec-based authentication
systems.
Existing distributed authentication systems commonly rely on a
password (shared secret) or a variable challenge-response mechanism
using a system-specific protocol. For example, both KerberosIV
[KERBEROSIV] and Radius [RADIUS] use protocols employing different
packet formats and privacy mechanisms. Because DNS was designed as a
publicly accessible distributed database, no mechanism for the
distribution of private data is provided, which makes the inclusion
of password data in the system both difficult and inappropriate.
The AR resource record (RR type TBD) allows DNSsec to refer an SDA to
an Authentication Service when direct authentication based on the KEY
RR cannot be used.
2. Authentication Referral Resource Record Format
To provide storage for authentication referral information, a new RR
type is defined with the mnemonic AR. More than one AR RR MAY exist
in an RRset; the RRset MUST contain the complete list of
authentication mechanisms allowed for the DNS name.
Watson [Page 3]
Internet DRAFT DNSsec Authentication Referral November 1997
2.1 Record Format
NAME The domain name of the entity to be authenticated.
TYPE AR (TBD)
CLASS IN (HS may also be appropriate)
TTL (as appropriate)
RdLen (variable)
RDATA
Field Name Data Type Notes
------------------------ ----------- -------------------------
Authentication Server dname FQDN of the server that
will provide
authentication data
Authentication Realm dname Realm in which
authentication occurs
Authentication Service 16-bit int Authentication Service
Type as defined in 2.3
Username Length 16-bit int Length of Authentication
Username string in octets
Authentication Username 8-bit int[] UTF-8 encoded name whose
use is defined by the
service type.
Other Data undefined Ignore any following
RDATA
All integer values are stored in network byte order. The
Authentication Username field is an octet stream of length Username
Length.
Meaning of Authentication Realm, Authentication Server,
Authentication Username are specific to each Authentication Service
type.
2.2 Text Representation
A simple text representation for the AR RR might be:
NAME. IN AR [Server] [Realm] [AuthMnemonic] [Username]
2.3 Authentication Service Types
Different Authentication Services types will be assigned numeric
value. New services MUST be registered with IANA.* A mnemonic is
associated with each type to simplify textual representation.
Watson [Page 4]
Internet DRAFT DNSsec Authentication Referral November 1997
Value Mnemonic Authentication Service Name
------ ----------- ---------------------------
0 DNSSEC DNSsec
1 KERBEROS_V4 Kerberos IV
2 KERBEROS_V5 Kerberos V
3 RADIUS Radius
4 NISPLUS NIS+
* A method for registration will be described in detail in a later
version of this document.
2.3.1 DNSsec Referral
It may be desirable to refer authentication to another FQDN. For
example, an organization may have several user zones defined, but one
Client may exist in several of them. Rather than requiring separate
AR RRs, authentication may be forwarded to one canonical AR RR
containing other useful data, or to a record with a KEY RR. Some
fields defined across the AR record are not used:
Field Name Value
------------------------ ----------------------------------
Authentication Server (empty)
Authentication Realm (empty)
Authentication Service 0 (DNSSEC)
Username Length (as appropriate)
Authentication Username FQDN of the entity referred to
When using DNSsec referrals, it is important to avoid referral loops.
The appropriate interpretation order of coexisting KEY and AR records
is discussed in section 3. Referrals may point to either another AR
record or a record with authentication KEYs. If a DNSsec referral
record points to a non-existent name or no authentication information
is available at that name, the authentication MUST fail.
2.3.1.1 DNSsec Referral Example
NAME ROBERT.USER.WATSON.ORG.
TYPE AR (TBD)
CLASS IN
TTL 3600
RdLen (as appropriate)
Watson [Page 5]
Internet DRAFT DNSsec Authentication Referral November 1997
RDATA
Field Name Value
------------------------ ----------------------------------
Authentication Server (empty)
Authentication Realm (empty)
Authentication Service 0 (DNSSEC)
Username Length 19
Authentication Username rnw.andrew.cmu.edu.
A textual representation of this record in zone USER.WATSON.ORG would
appears as:
ROBERT IN AR (. . DNSSEC "rnw.andrew.cmu.edu.")
2.3.2 Kerberos IV Referral
The Authentication Username is a "principal.instance" pair where
instance may be alphanumeric, null, or the wildcard "*". For
authentication against user robert in realm WATSON.ORG, an
appropriate Authentication Username would be "robert.", indicating
that no instance is to be used. To require authentication against
another instance, the form "robert.admin" is appropriate. In some
circumstances, a wild-card Username entry might be used, "robert.*",
indicating that the Client MAY be prompted for a specific instance.
Field Name Value
----------------------- --------------------------------------
Authentication Server Kerberos IV Server
Authentication Realm Kerberos IV Realm
Authentication Service 1 (Kerberos IV)
Username Length (length of Username in octets)
Authentication Username Kerberos IV principal.instance
2.3.2.1 Kerberos IV Referral Example
NAME ROBERT.USER.WATSON.ORG.
TYPE AR (TBD)
CLASS IN
TTL 3600
RdLen (as appropriate)
Watson [Page 6]
Internet DRAFT DNSsec Authentication Referral November 1997
RDATA
Field Name Value
----------------------- ----------------------
Authentication Server KERBEROS.WATSON.ORG.
Authentication Realm WATSON.ORG.
Authentication Service 1 (KERBEROS_V4)
Username Length 12
Authentication Username robert.admin
A textual representation of this record in zone USER.WATSON.ORG would
appear as:
ROBERT IN AR (KERBEROS.WATSON.ORG. WATSON.ORG.
KERBEROS_V4 "robert.admin")
2.3.3. Kerberos V Referral
The specifics of this type will be specified in a future draft. It
is expected that Kerberos V referrals will be almost identical to
Kerberos IV, but with the "." principal/instance separator replaced
with a "/".
2.3.4 Radius Referral
Field Name Value
----------------------- ---------------------------------
Authentication Server Radius Server
Authentication Realm (empty)
Authentication Service 3 (RADIUS)
Username Length (as appropriate)
Authentication Username Radius Username
2.3.4.1 Radius Referral Example
NAME ROBERT.USER.WATSON.ORG.
TYPE AR (TBD)
CLASS IN
TTL 3600
RdLen (as appropriate)
Watson [Page 7]
Internet DRAFT DNSsec Authentication Referral November 1997
RDATA
Field Name Value
----------------------- ----------------------
Authentication Server RADIUS.WATSON.ORG.
Authentication Realm (empty)
Authentication Service 5 (RADIUS)
Username Length 6
Authentication Username robert
A textual representation of this record in zone USER.WATSON.ORG would
appear as:
ROBERT IN AR (RADIUS.WATSON.ORG. .
RADIUS "robert")
2.3.5 NIS+ Referral
NIS+ referral will be documented in a separate document. Due to the
complex interactions between NIS and DNS, there are additional
concerns that must be addressed in greater detail than is appropriate
here.
2.4 DNS Server Handling of the AR Resource Record
When returning an AR RR as part of an RRset, a DNS server MAY include
Additional Records [RFC1034: Section 3.7] that it anticipates the SDA
requires.
3. AR Resource Record Evaluation
When performing a lookup on a Client's DNS entry, a signed RRset is
returned containing KEY RRs, SIG RRs, other data, and possibly an AR
RR. If KEY RRs are present and are permitted for use in user
authentication, public/private key authentication may take place.
Alternatively, the SDA may choose a different authentication
mechanism from the list of AR RRs.
3.1 Authentication Rules
Multiple AR RRs of different Authentication Service types may exist.
Similarly, multiple RRs of the same type may exist in an RRset. When
multiple RRs are returned, the SDA must select some subset of these
to try. A combination of local policy and and the desire for load
balancing determines the correct use of these RRs.
Where multiple AR RRs of different Authentication Service type exist,
one of the available Services SHOULD be selected. This choice could
Watson [Page 8]
Internet DRAFT DNSsec Authentication Referral November 1997
be made by local site policy (i.e., only to accept authentication by
Kerberos, or to not allow AR referral to another DNSsec name), or
with Client interaction (the user is prompted for the mechanism they
wish to authenticate against). If one Authentication Service fails,
the choice to retry against the same service or against different
Services should be made in accordance with local security policy.
Where multiple RRs with the same Authentication Service Type exist
but different Authentication Realm or Username are present, the SDA
should make a choice in accordance with local site policy. For
example, a site might choose only to accept authentication to their
own Kerberos realm.
Load balancing is desirable in the event that multiple RRs with the
same Authentication Realm, Authentication Service, and Username are
present. Such sets of related AR RRs may be considered to be
redundant records. DNS round-robin may be relied upon to reorder
them.
3.1.1 Successful Authentication
If the chain of signatures validates the initial Client records as
well as any further records referenced if a DNSsec referral is
performed, an authentication attempt MAY be performed. If an
attempted authentication succeeds, the SDA MUST accept the
authentication as valid.
3.1.2 Failure in Authentication
If any break in the signature chain occurs in DNSsec verification of
the records required for authentication, the authentication SHOULD
fail. If alternate mechanisms exist for authenticating the
Authentication Server, they MAY be used.
If an Authentication Service is selected, and the authentication
fails for non-technical reasons [different word?], then the
authentication MUST fail. If a technical failure occurs (such as
being unable to contact the Authentication Server), the SDA MAY
select another AR record to attempt or MAY retry on the same server.
If no further AR records are present and any retries have also
failed, then the authentication MUST fail.
4. Security Considerations
It is expected that some system of access control will be used to
determine what, if any, services are provided to the authenticated
Client.
Watson [Page 9]
Internet DRAFT DNSsec Authentication Referral November 1997
4.1 DNSsec Use
Spoofing of AR RRs could result in unauthorized authentication.
DNSsec MUST be used to verify the authenticity of the AR RRs, as well
as the chain to the DNS root. For example, if an AR refers to
Kerberos IV, DNSsec MUST be used to verify the retrieval of the
Client's AR record, and the retrieval of the Kerberos IV Server's IP
address from Authentication Server FQDN.
4.2 The Weakest Link
While DNSsec provides strong cryptography to protect data
authenticity and to allow expiration, many distributed security
mechanisms are not as strong. For example, while an AR record may be
valid, an NIS server connection may be spoofed, hijacked,
eavesdropped, etc.
4.3 Local Site Policy
Local site policy is relied upon for a number of key decisions in the
authentication process. For example, before attempting to follow an
AR chain, the SDA must first confirm that the initial name provided
is allowed to authenticate to it. It must also determine which
authentication service types in the AR list for the name are
appropriate for use. An SDA MAY choose not to accept authenticatino
to a weak Authentication Service. The definition of weak SHOULD be
defined in a local site policy.
A site might accept initial attempts at authentication to
*.user.watson.org. On a successful and verified referral, it might
then be willing to accept authentication against any strong
Authentication Service (e.g., KerberosIV or KerberosV), but not
against weaker services (e.g., NIS).
If AR information can be verified externally, do so. For example, if
Kerberos IV server to realm mapping information exists in a local
krb.conf, consistency should be verified.
Correct logging practice, as well as approaches for dealing with
various types of failures given the varied mechanisms provided may
also involve significant local determination. All authentication
events SHOULD be logged. Selective reporting of errors to the Client
may also improve security.
Watson [Page 10]
Internet DRAFT DNSsec Authentication Referral November 1997
5. References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and
Facilities,'' RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1034, ISI, November 1987.
[DNSSEC] D. Eastlake, C. Kaufman, ``Domain System Security
Extensions,'' RFC 2065, CyberCash & Irix, January 1997.
[HESIOD] S. Dryer, ``The Hesiod Name Server,'' MIT, January 1988.
[IPSEC] R. Atkinson, ``Security Architecture for the Internet
Protocol,'' RFC 1825, Navy Research Laboratory, August
1995.
[SSH] M. Ylonen, T. Kivinen, M. Saarinen, ``SSH Transport Layer
Protocol,'' draft-ietf-secsh-transport-02.txt, SSH,
October 1997.
[KERBEROSIV] S. Miller, B. Neuman, J. Schiller, J. Saltzer, ``Kerberos
Authentication and Authorization System,'' MIT, December
1988.
[RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, ``Remote
Authentication Dial In User Service (RADIUS),'' RFC 2138,
April 1997.
6. Author's Address
Robert Watson
Carnegie Mellon University
SMC 4105
PO Box 3015
Pittsburgh, PA 15230
Phone: (412) 862-2696
Email: robert+ietf@cyrus.watson.org
Watson [Page 11]

522
doc/draft/draft-ietf-dnssec-as-map-05.txt Normal file
View file

@ -0,0 +1,522 @@
INTERNET-DRAFT Mapping AS Number into the DNS
July 1997
Expires January 1998
Mapping Autonomous Systems Number into the Domain Name System
------- ---------- ------- ------ ---- --- ------ ---- ------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnssec-as-map-05.txt, is intended to
be become a Best Current Practice RFC concerning utilization of the
Domain Name System (DNS) to support routing security. Distribution of
this document is unlimited. Comments should be sent to the DNS
Security Working Group mailing list <dns-security@tis.com> or to the
author.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. 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 learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT Mapping AS Numbers into the DNS
Abstract
One requirement of secure routing is that independent routing
entities, such as those identified by Internet Autonomous System
Numbers, be able to authenticate messages to each other. Additions
have developed to the Domain Name System to enable it to be used for
authenticated public key distribution [RFC 2065]. This draft maps
all Autonomous System numbers into DNS Domain Names so that the DNS
security can be used to distribute their public keys.
[Changes from previous version are to accommodate AS numbers larger
than 16 bits and to delegate on decimal boundaries rather than binary
boundaries.]
Acknowledgements
The contributions of the following persons, listed in alphabetic
order, to this draft are gratefully acknowledged:
Ran Atkinson
Christian Huitema
Tony Li
Michael A. Patton.
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT Mapping AS Numbers into the DNS
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Acknowledgements...........................................2
Table of Contents..........................................3
1. Introduction............................................4
2. Autonomous System Number Mapping........................5
3. Meaning of RRs..........................................6
4. Security Considerations.................................8
References.................................................8
Author's Address...........................................8
Expiration and File Name...................................9
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT Mapping AS Numbers into the DNS
1. Introduction
There are a number of elements required to secure routing in the
Internet. One of these is a way that independently operated routing
domains be able to authenticate messages to each other.
Sharing a private symmetric key between each pair of such domains is
impractical. Assuming 2**16 Autonomous System routing entities,
which is what is allowed in current versions of BGP, [RFC 1771], this
would imply approximately 2**31 pairs, an impractical number of keys
to securely generate, install, and periodically replace.
The solution is to use public key technology whereby each routing
domain has a private key it can use to sign messages. Other domains
that know the corresponding public key can then authenticate these
messages. Such authenticated messages can be used to set up and
maintain efficient symmetric keys on an as needed basis.
But how do the domains securely obtain the Autonomous System number
to public key mapping?
Extensions have been developed for the Domain Name System that enable
it to be conveniently used for authenticated public key distribution
[RFC 2065]. A variety of key types can be supported. All that is
required is a mapping of Autonomous System numbers into domain names,
which is provided by this draft.
It should be noted that the public keys retrieved from DNS will
likely be used primarily to authenticate initial connection set up
messages. Autonomous Systems that need to converse with any
frequency will probably negotiate more efficient symmetric session
keys.
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT Mapping AS Numbers into the DNS
2. Autonomous System Number Mapping
Autonomous System (AS) numbers are usually written as decimal number
and when blocks of AS numbers are delegated to a registry, it is
normally on decimal boundaries. Their current use in BGP is limited
to 16 bits providing a maximum value of 65,535. For example, ANS is
autonomous system 690. However, there is no inherent size limit in
the AS concept. AS numbers are mapped into a domain name as
described below.
Write the AS number, as usual, as a decimal number without any
"thousands" punctuation. If it is less than 5 digits, add leading
zeros to bring it up to five digits. Then simply reverse the order
of the digits, put a period between them, and append ".length.in-
as.arpa" where "length" is the number of AS digits. This mapping is
analogous to the IPv4 address mapping into the in-addr.arpa DNS
domain.
Thus the domain name correspond to Autonomous System 690 (decimal) is
0.9.6.0.0.5.in-as.arpa.
the domain corresponding to the largest possible AS number in BGP is
5.3.5.5.6.5.in-as.arpa.
the domain corresponding to AS number 65,000 is
0.0.0.5.6.5.in-as.arpa.
and the domain correspond to a hypothetical future greater than 16
bit AS number 1,234,567 is
7.6.5.4.3.2.1.7.in-as.arpa.
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT Mapping AS Numbers into the DNS
3. Meaning of RRs
The following guidance is given for some resource record (RR) types
that could be stored under the names mapped from AS numbers. The KEY
RR is given first, followed by the SIG RR, the NXT RR, and then some
additional RR types in alphabetic order.
KEY: This type of RR associates a public key with the owner name
which, in this case, corresponds to an Autonomous System (AS). Under
DNS security as proposed in RFC 2065 the KEY RR can be used to store
a variety of digital keys. A KEY for use in securing routing
communications between ASs will have the end entity flag bit on, the
authentication use prohibited flag bit off, and a protocol byte or
flag bit indicating routing communications use. Such a public key can
be used to authenticate communications with or between ASs. The
existence of such KEY RRs in the primary reason for mapping AS names
into the DNS.
SIG: The SIG signature resource record authenticates the RRs
that it signs as described in RFC 2065. Assuming the signer who
generated the SIG is trustworthy, such as the in-as.arpa zone owner,
then the signed RRs can be trusted.
NXT: An NXT RR is used in DNS security to provide authenticated
denial of the existence of types and names as described in RFC 2065.
A, AAAA: Type A or AAAA RRs SHOULD NOT be placed at AS nodes.
AS domain names are reserved for Autonomous Systems only and should
NOT be used for a host or any type of end entity other than an
Autonomous System.
CNAME: This type of RR is an alias pointing to another domain
name. An AS could have a CNAME pointing to a different AS but this
is not likely to be very useful as AS RRs will normally be looked up
when the AS number is actually encountered in use.
MX: There is no special use for an MX RR for an AS name. It
could point to a host that would accept mail related to that AS.
NS: The presence of NS records under an AS name means that it
has been carved out as a subzone. This gives the AS complete control
over the zone refresh parameters and control over the creation of
inferior names. No special meaning is currently assigned to such
inferior names so, although this is not advised, they could be used
for hosts or whatever. In this case, the will also be a zone KEY at
the AS name, indicated by having the zone flag bit on.
PTR: The part of the forward domain tree that administratively
corresponds to the AS SHOULD be indicated by a PTR RR. If some
entity, say example.xx, has several ASs, there would be PTRs to
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT Mapping AS Numbers into the DNS
example.xx from several names in the in-as.arpa hierarchy.
RP: A Responsible Person RR SHOULD appear under each AS name
telling you who you should contact in the case of problems with that
AS
TXT: Text RRs can be used for comments, postal address, or
similar notes under an AS name.
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT Mapping AS Numbers into the DNS
4. Security Considerations
This document concerns a means to map Internet Autonomous System
numbers into the Domain Name System (DNS) so that DNS can be used to
provide secure distribution of Autonomous System's public keys. The
security of the resulting AS to key mapping is dependent on the
security of the DNS security extensions and of the DNS zone where the
key is stored.
The most obvious way of using the AS keys retrieved from DNS is to
authenticate communications with a directly connected AS. However,
this does not prove that any routing information exchanged is
actually correct and note that routing information communicated over
this secured path may be indirectly forwarded from or to yet other
ASs.
References
[RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987
[RFC 1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987.
[RFC 1771] - Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-
4)", 03/21/1995.
[RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C.
Kaufman, January 1997.
Author's Address
Donald E. Eastlake 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 508 287 4877
+1 703 620-4200 (main office, Reston, VA)
FAX: +1 508 371 7148
EMail: dee@cybercash.com
Donald E. Eastlake 3rd [Page 8]
INTERNET-DRAFT Mapping AS Numbers into the DNS
Expiration and File Name
This draft expires January 1998.
Its file name is draft-ietf-dnssec-as-map-05.txt.
Donald E. Eastlake 3rd [Page 9]

464
doc/draft/draft-ietf-dnssec-indirect-key-01.txt Normal file
View file

@ -0,0 +1,464 @@
INTERNET-DRAFT Indirect KEY RRs
November 1997
Expires May 1998
Indirect KEY RRs in the Domain Name System
-------- --- --- -- --- ------ ---- ------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnssec-indirect-key-01.txt, is
intended to be become a Proposed Standard RFC. Distribution of this
document is unlimited. Comments should be sent to the DNSSEC mailing
list <dns-security@tis.com> or to the author.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. 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 learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Abstract
RFC 2065 defines a means for storing cryptogrpahic public keys in the
Domain Name System. An additional code point is defined for the KEY
resource record (RR) algorithm field to indicate that the key itself
is not stored in the KEY RR but is pointed to by the KEY RR.
Encodings to indicate different types of key and pointer formats are
specified.
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT Indirect KEY RRs
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. The Indirect KEY RR Algorithm...........................4
2.1 The Target Type Field..................................4
2.2 The Target Algorithm Field.............................5
2.3 The Hash Fields........................................5
3. Performance Considerations..............................7
4. Security Considerations.................................7
References.................................................8
Author's Address...........................................8
Expiration and File Name...................................8
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT Indirect KEY RRs
1. Introduction
The Domain Name System (DNS) security extensions [RFC 2065] provide
for the general storage of public keys in the domain name system via
the KEY resource record (RR). These KEY RRs are used in support of
DNS security and may be used to support other security protocols.
KEY RRs can be associated with users, zones, and hosts or other end
entities named in the DNS.
For reasons given below, in many cases it will be desireable to store
a key or keys elsewhere and merely point to it from the KEY RR.
Indirect key storage makes it possible to point to a key service via
a URL, to have a compact pointer to a larger key or set of keys, to
point to a certificate either inside DNS [see draft-ietf-dnssec-
certs-*.txt] or outside the DNS, and where appropriate, to store a
key or key set applicable to many DNS entries in some place and point
to it from those entries.
However, to simplify DNSSEC implementation, this technique MUST NOT
be used for KEY RRs used in for verification in DNSSEC.
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT Indirect KEY RRs
2. The Indirect KEY RR Algorithm
Domain Name System (DNS) KEY Resource Record (RR) [RFC 2065]
algorithm number 252 is defined as the indirect key algorithm. This
algorithm MAY NOT be used for zone keys in support of DNS security.
All KEYs used in DNSSEC validation must be stored directly in the
DNS.
When the algorithm byte of a KEY RR has thae value 252, the "public
key" portion of the RR is formated as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| target type | target alg. | hash type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash size | hash (variable size) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
| /
/ pointer (varible size) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
2.1 The Target Type Field
Target type specifies the type of the key containing data being
pointed at.
Target types 0 and 65535 are reserved.
Target type 1 indicates that the pointer is a domain name from which
KEY RRs [RFC 2065] should be retrieved. Name compression in the
pointer field is prohibited.
Target type 2 indicates that the pointer is a null terminated
character string which is a URL [RFC 1738]. For exisiting data
transfer URL schemes, such as ftp, http, shttp, etc., the data is the
same as the public key portion of a KEY RR. (New URL schmes may be
defined which return multiple keys.)
Target type 2 indicates that the pointer is a domain name from which
CERT RRs [draft-ietf-dnssec-certs-*.txt] should be retrieved. Name
compression in the pointer field is prohibiited.
Target type 3 indicates that the pointer is a null terminated
character string which is a URL [RFC 1738]. For exisiting data
transfer URL schemes, such as ftp, http, shttp, etc., the data is the
same as the entire RDATA portion of a CERT RR [draft-ietf-dnssec-
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT Indirect KEY RRs
certs-*.txt]. (New URL schmes may be defined which return multiple
such data blocks.)
Target type 4 indicates that the pointer is a null terminated
character string which is a URL [RFC 1738]. For exisiting data
transfer URL schemes, such as ftp, http, shttp, etc., the data is a
PKCS#1 format key. (New URL schmes may be defined which return
multiple keys.)
The target types 5 through 255 are available for assignment by IANA.
Target type 256 through 511 (i.e., 256 + n) indicate that the pointer
is a null terminated character string which is a URL [RFC 1738]. For
exisiting data transfer URL schemes, such as ftp, http, shttp, etc.,
the data is a certificate of the type indicated by a CERT RR [draft-
ietf-dnssec-certs-*.txt] certificate type of n. That is, target
types 257, 258, and 259 are PKIX, SPKI, and PGP certificates and
target types 509 and 510 are URL and OID private certificate types.
(New URL schmes may be defined which return multiple such
certificates.)
Target types 512 through 65534 are available for assignment by IANA.
2.2 The Target Algorithm Field
The algorithm field is as defined in RFC 2065. if non-zero, it
specifies the algorithm type of the target key or keys pointed. If
zero, it does not specify what algorithm the target key or keys apply
to.
2.3 The Hash Fields
If the indirecting KEY RR is retrieved from an appropriately secure
DNS zone with a resolver implementing DNS security, then there would
be a high level of confidence in the entire value of the KEY RR
including any direct keys. This may or may not be true of any
indirect key pointed to. If that key is embodied in a certificate or
retrieved via a secure protocol such as SHTTP, it may also be secure.
But an indirecting KEY RR could, for example, simply have an FTP URL
pointing to a binary key stored elsewhere, the retrieval of which
would not be secure.
The hash option in algorithm 252 KEY RRs provides a means of
extending the security of the indirecting KEY RR to the actual key
material pointed at. By inclduing a hash in a secure indirecting RR,
this secure hash can be checked against the hash of the actual keying
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT Indirect KEY RRs
material
Type Hash Algorithm
---- --------------
0 indicates no hash present
1 MD5 [RFC 1321]
2 SHA-1
3 RIPEMD
4-254 available for assignment
255 reserved
The hash size field is an unsigned octet count of the hash size. For
some hash algorithms it may be fixed by the algorithm choice but this
will not always be the case. For example, hash size is used to
distinguish between RIPEMD-128 (16 octets) and RIPEMD-160 (20
octets). If the hash algorithm is 0, the hash size MUST be zero and
no hash octets are present.
The hash field itself is variable size with its length specified by
the hash size field.
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT Indirect KEY RRs
3. Performance Considerations
With current public key technology, an indirect key will sometimes be
shorter than the keying material it points at. This may improve DNS
permformace in the retrieval of the initial KEY RR. However, an
additional retrieval step then needs to be done to get the actualy
keying material which must be added to the overall time to get the
public key.
4. Security Considerations
The indirecting step of using an indirect KEY RR adds complexity and
additional steps where security could go wrong. If the indirect key
RR was retrieved from a zone that was insecure for the resolver, you
have no security. If the indirect key RR, although secure itself,
point to a key which can not be securely retrieved and is not
validatated by a secure hash in the indirect key RR, you have no
security.
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT Indirect KEY RRs
References
PKCS#1
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 1321 - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992.
RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform
Resource Locators (URL)", December 1994.
RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security
Extensions", 01/03/1997.
draft-ietf-dnssec-certs-*.txt
Author's Address
Donald E. Eastlake 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978 287 4877
+1 703 620-4200 (main office, Reston, VA)
FAX: +1 978 371 7148
EMail: dee@cybercash.com
Expiration and File Name
This draft expires May 1998.
Its file name is draft-ietf-dnssec-indirect-key-01.txt.
Donald E. Eastlake 3rd [Page 8]

473
doc/draft/draft-ietf-dnssec-key-handling-00.txt Normal file
View file

@ -0,0 +1,473 @@
Domain Name System Security WG Edward Lewis
INTERNET DRAFT Olafur Gudmundsson
<draft-ietf-dnssec-key-handling-00.txt> Trusted Information Systems
November 21, 1997
Zone KEY RRSet Signing Procedure
<draft-ietf-dnssec-key-handling-00.txt>
0.0 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.
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.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
This Internet Draft expires on 21 May 1998.
Please send comments to the authors and dns-security@tis.com.
1.0 Abstract
Under the security extensions to DNS, as defined in RFC 2065 and
RFC 2137, a secured zone will have a KEY RRSet associated with
the domain name at the apex of the zone. This document covers
the manner in which this RRSet is generated, signed, and inserted
into the name servers.
1.5 Change Log
Version 01 - draft-lewis-dnskey-handling-01.txt:
Minor editorial changes.
Added paragraph in section 3.1 elaborating on off-net versus off-
net signing.
Added paragraph in section 4.0, step 2, requiring proof of
private key ownership.
Added Change Log section.
Version 02 - draft-ietf-dnssec-key-handling-00.txt:
Minor editorial changes.
Dynamic update reference changed from a draft to an RFC.
Expires November 21, 1997 [Page 1]
Internet Draft May 21, 1998
2.0 Introduction
Under the security extensions to DNS, as defined in RFC 2065
[RFC2065] and [RFC2137], a secured zone will have a KEY RRSet
associated with the domain name at the apex of the zone. At
least one of the KEY RR's will be a public key that is used
to verify SIG RR's in the zone. The SIG(KEY) RR covering this
RRSet must itself be signed by some other domain name, "some
other" being required to build a chain of trusted verifications.
(The alternative to requiring a different signer is to have
each name server hold all the public keys it will ever need in
a trusted place, which is not a scaleable solution.) A key
administration protocol external to the existing DNS protocol
is needed to produce the signature of the KEY RR's and to get
it into the DNS name servers.
As this is a first document on the subject, the "administration
protocol" will be described more as an "administrative procedure
or method."
The challenge is to design a secure procedure for handling the
unsigned public keys as they move from the place of generation
to a place where they are signed. The procedure must also
eventually lead to the insertion of the keys and signature into
the zone master file on a primary name server. The place of
generation and the place of the signing are recommended to be
disconnected from the Internet in order to protect the private
keys produced and/or used in the procedure. The two locations
may also be disconnected from each other.
The security of the public keys in this procedure is crucial to
the operation of the secure zone. An attack in which a false
public key is submitted for signing would enable a masquerade of
the true zone data by the attacker.
2.1 Terminology convention
In the literature on DNS, different terms are used to describe
the relationship of zones. "Super-zone and sub-zone," "parent
and child," and "delegator and delegatee" each refer to two
zones joined at a "zone cut." For each of the set of terms, the
former is the zone above the cut point, the latter is below the
cut point. In this document, we use the terms delegator and
delegatee.
3.0 DNSSEC Configuration Variants
There are a number of variants in the way in which DNSSEC can be
configured that impact a discussion of key management. The
discussion in section 4.0 will assume a nominal configuration
(defined in section 3.4) to simplify this document. In this
section, pertinent configuration decisions are described, and
how the choices make a particular configuration differ from the
so-called nominal configuration.
Expires November 21, 1997 [Page 2]
Internet Draft May 21, 1998
3.1 Off/On-Net Signing
In DNSSEC the configuration of DNS operations and signing fall
into two categories. The most secure is the use of an "off-net"
signer. The alternative is to use an "on-net" signer. These
two alternatives correspond to the Mode A and Mode B distinction
in UPDATE. (Mode A's initial zone signing is performed off-
net.)
The decision whether off-net or on-net signing is used is based
upon the risk assessment of the site's network management. An
on-net key is more vulnerable to attack than an off-net key just
by being present somewhere on the network. Off-net signing is
recommended for tighter security. Being behind a firewall might
be deemed insufficient if the administration does not trust the
protection in other parts of the network. This is matter of
choice for sites.
In off-net signing, the machinery performing the act of creating
the keyed signature is not reachable from the network the DNS
(name server set) is serving. I.e., there is no direct
mechanism for data transfer from the signing machine to a name
server. Without loss of generality, the DNS served network may
be thought of as the Internet.
The off-net signer need not be a stand-alone machine it may be
on an "air-gapped" (not physically connected) network. This
network may be just a very local network (i.e., within one
office or machine room), reserved for sensitive network
administration use. For the purposes of this document, this
will be labeled the back-room network (even if just a stand-
alone machine is on it).
The back-room network needs to be able to get information from
the Internet to derive the unsigned zone master files (among
other things). The back-room network generates the signed
files, which are inserted to the Internet DNS servers. The
mechanism to carry this out may be removable "static" media.
ADDED for draft-01:
(The preceding discussion focuses on the original signing of a
zone. Dynamic update requests for both off-net and on-net
situations are signed on-net, in the case of off-net, a
different key is used to sign the updates. The choice of off-
net or on-net is a comparison of the administrative effort to
maintain off-net signing versus the risk of an on-net private-
key compromise.)
For the purposes of this document, if off-net signing is used,
we assume key generation is also performed off-net.
On-net signing simply means the signer is accessible over the
Internet. If the back-room network exists, it is connected to
Expires November 21, 1997 [Page 3]
Internet Draft May 21, 1998
the Internet. In the procedures described below, the steps used
to transfer information from the Internet to the back-room
network are obviously unnecessary.
3.2 Relationship of Zone and Key Signer
In a nominal state, a zone's delegator will also be the signer
of the delegated zone's KEY RR set. E.g., for a zone named
"xz.test." with an NS RRSet at that name, the domain name
"test." would be the delegator of "xz.test." and signer of its
KEY RRSet. However, there may be cases in which some other
entity is the signer.
The role and composition of the "other entity" is not yet
defined, and may or may not ever be defined. This entity has
been referred to as a Signing Authority, whose sole purpose is
to sign records for clients. This may be more or less a
certification authority for DNS KEY RRSets. For the purposes of
this document, this entity will be assumed to be the delegating
zone, and it will be referred to as the "signing entity."
3.3 Name Server Topology
The separation between two delegated zones may mean that the two
do not share any name servers, such as most names under .COM and
.COM itself. In general, the set of name servers for two zones
may overlap. This document will focus on cases in which zones
do not share name servers or other facilities.
If the two zones share the same name servers they likely will
share the mechanism for the generation of zone keys. In this
case, the transfer of information between the zones becomes a
moot point because the problem may degenerate into accessing a
file in a shared file system. For zones sharing a back-room
network, the data for the two zones (between the off-net and on-
net machines) can be transferred together.
3.4 The Nominal Configuration
The nominal configuration used within the context of this
document is that the zones involved (one being the zone
generating the keys and the other zone performs the signing)
each employ off-line signing, and employ distinct sets of name
servers. In addition, the zone performing the signing is the
zone above the delegation point that creates the zone which is
generating and requesting the signing of its keys.
4.0 Key Signing Protocol/Procedure
The steps described here assume the nominal configuration in
section 3.4. In some configurations, the steps listed in this
section may degenerate into null or very simple operations.
Additionally, some steps can be carried out in parallel even
with the nominal configuration, so the strict ordering described
Expires November 21, 1997 [Page 4]
Internet Draft May 21, 1998
here need not be followed.
Step 0. A delegation needs to be instituted. A means to
authenticate both the delegator to the delegatee and vice versa
is also needed.
A delegation may only need to be created once. A NS RRSet and a
KEY RRSet must be installed by the delegating zone. Until a key
pair is generated the KEY RRSet will have a null zone key,
indicating that the delegated zone is initially unsecured.
Instituting means to authenticate the participants must occur
initially, and then again if the means of authentication (e.g.,
a secret key) is ever compromised.
How a delegation comes about is a subject for registries and/or
local network administration policies and procedures. These
groups should be aware of the responsibilities entailed in
instituting DNS security, especially the need for an active
recurring relationship, as the remaining steps describe.
It is assumed that at some point, the delegated zone acquires a
trusted public key(s) for at least one other entity. This could
be for root, the delegating zone, or for a signing authority.
These keys may be DNS zone keys or keys for some application,
e.g., trusted mail. This will enable the use of other secure
services to achieve the following steps. Selecting the services
may be within the scope of this document, but which should be
selected is still open for discussion.
Step 1. Delegated zone generates zone keys. A new pair may be
generated without changing the other pairs in use (assuming
others exist).
Step 2. The delegated zone sends keys to the signing entity.
All of the public key information, encoded in such a way that
the KEY RR's can be generated from it, crosses from the back-
room net to the Internet, and is shipped securely to the signing
entity. (Implementing "securely" is still an open issue.) It
is important that both the delegated zone and the signing entity
authenticate themselves to each other.
All public keys must be included, both newly generated and those
in current use. Keys are retired through omission.
ADDED for draft-01:
The delegated zone must prove ownership of the private keys
corresponding to each public key. This may be done by signing
the collection of public key data with each of the private keys.
Thus the submission would consist of one copy of each public key
and as many signatures as there were public keys. (For example,
submitting five public keys would require sending all five plus
five signatures.) This signing is only done to prove the
Expires November 21, 1997 [Page 5]
Internet Draft May 21, 1998
ownership of the private key, not for authentication.
Step 3. The signing entity signs the key set. The algorithm
used to sign the KEY RRSet need not be the same as the
algorithm(s) for which the keys were generated.
Step 4. The delegated zone receives KEY RRSet and SIG(KEY) RR
from the signing entity. The delegated zone must verify the
keys and signature locally. The zone must also verify that the
KEY RRSet is identical to the set of keys submitted for
signature in step 2, to protect against a masquerader from
submitting keys for signature. Once the records are signed,
there is no requirement for enhanced security while transmitting
the information across the Internet because the DNS signature
provides non-repudiation.
Step 5. Delegating zone gets the KEY RRSet and SIG(KEY) RR.
The KEY RRSet and the SIG(KEY) RR are sent from the signing
entity to the delegating zone's master files and optionally the
name servers. In the nominal case, the signing entity and the
delegating zone are one in the same, so this may be a trivial
step. (The latter is to ensure the public key will be available
for verifications once the signing process - step 7 - is
finished.)
Step 6. The delegating zone signs its zone data. This step may
be done in parallel with steps 2-5. Note: signing a zone does
not require that a new key pair be generated.
Step 7. The new zone data enters DNS. The KEY RRSet, SIG(KEY
RR) and the rest of the signed zone data and signatures traverse
from the back-room network and are inserted into the DNS primary
name server serving the Internet side.
Steps 1 through 7 are repeated whenever a new key pair is
required. Note that the signing in step 6 may not sign all
records; some records may have signature records from older keys
that are sufficient.
5.0 Resigning a KEY RRSet
When the delegating zone resigns itself, the KEY RRSet of a
delegated zone may be resigned. In this case, the newly created
SIG(RR) must be sent to the delegatee for inclusion.
The signing of a delegatee's keys in the manner of the previous
paragraph may be prompted by a request from the delegatee. A
SIG(RR) record may be approaching its expiration date, although
the KEY RRSet it is verifying has not changed.
6.0 Open Issues
This section is intentionally left undeveloped to encourage more
feedback.
Expires November 21, 1997 [Page 6]
Internet Draft May 21, 1998
Timing of steps, required response times.
The signing cycles of zones will likely be out of phase of each
other. If they were not, then there would be "signing crunches"
which would add variability to the spacing of events in the
procedure. One issue is how this should be addressed. Should
there be a recommended limit on signing entity's response?
Should this even be specified?
Can secure e-mail be used? Perhaps, and discussions to this
effect have occurred, using secure e-mail as a conduit for (at
least) the unsigned keys.
7.0 Operational Considerations
A widely delegated zone, such as .COM, or a zone publishing KEY
RR's for others, such as a large Internet access provider,
should expect a huge performance impact in signing the KEY
RRSets for it delegations. Running on a Pentium 166MHz
computer, simply signing the current .COM records, requires 40
hours. (Measured in January 1997.) This covers just the NXT
RRSets and a few other records. Having to sign a KEY RRSet for
each member of the zone will require about the same computing
resources, and much more overhead in the handling of the
individual KEY RRSets.
8.0 Security Considerations
This document discusses a procedure for handling the keys used
by DNS for its security and the keys for applications employing
DNS for key distribution. Once in DNS, keys are protected by
the presence of a keyed hash, which can be used to verify the
source and integrity of the public key data. During the process
described here, the keyed hash is not yet present, leaving the
keys vulnerable to modification. The security of this process
is crucial to the usefulness of DNS as a key distribution
mechanism. At this point many issue remain to be resolved, a
thorough security analysis of the process is premature.
9.0 References
[RFC2065] "Domain Name System Security Extensions," D. Eastlake,
3rd, and C. Kaufman
http://ds.internic.net/rfc/rfc2065.txt
[RFC2137] "Secure Domain Name System Dynamic Update," D.
Eastlake, 3rd
http://ds.internic.net/rfc/rfc2137.txt
Expires November 21, 1997 [Page 7]
Internet Draft May 21, 1998
10.0 Author's Addresses
Edward Lewis Olafur Gudmundsson
Trusted Information Systems Trusted Information Systems
3060 Washington Road 3060 Washington Road
Glenwood, MD 21738 Glenwood, MD 21738
+1 301 854 5794 +1 301 854 5700
<lewis@tis.com> <ogud@tis.com>
Expires November 21, 1997 [Page 8]

521
doc/draft/draft-ietf-dnssec-rollover-00.txt Normal file
View file

@ -0,0 +1,521 @@
INTERNET-DRAFT DNSSEC Key Rollover
October 1998
Expires April 1999
Domain Name System (DNS) Security Key Rollover
------ ---- ------ ----- -------- --- --------
Donald E. Eastlake 3rd, Mark Andrews
Status of This Document
This draft, file name draft-ietf-dnssec-rollover-00.txt, is intended
to be become a Proposed Standard RFC. Distribution of this document
is unlimited. Comments should be sent to the DNS security mailing
list <dns-security@tis.com> or to the authors.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. 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 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).
Abstract
Practical deployment of Domain Name System (DNS) security with good
cryptologic practice will involve large volumes of key rollover
traffic. A standard format and protocol for such messages is
specified.
D. Eastlake 3rd, M. Andrews [Page 1]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. Key Rollover Scenarios..................................3
3. Rollover Operation......................................4
3.1 Rollover to Parent.....................................4
3.2 Rollover to Children...................................5
4. Rollover NOTIFY.........................................6
5. Security Considerations.................................7
References.................................................8
Authors Address............................................8
Expiration and File Name...................................9
D. Eastlake 3rd, M. Andrews [Page 2]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
1. Introduction
The Domain Name System (DNS) [RFC 1034, RFC 1035] is the global
hierarchical replicated distributed database system for Internet
addressing, mail proxy, and other information. The DNS has been
extended to include digital signatures and cryptographic keys as
described in [draft-ietf-dnssec-secext2-*].
The principle security service provided for DNS data is data origin
authentication. The owner of each zone signs the data in that zone
with a private key known only to the zone owner. Anyone that knows
the corresponding public key can then authenticate that zone data is
from the zone owner. To avoid having to preconfigure resolvers with
all zone's public keys, keys are stored in the DNS with each zone's
key signed by its parent (if the parent is secure).
To obtain high levels of security, keys must be periodically changed,
or "rolled over". The longer a private key is used, the more likely
it is to be compromised due to cryptanalysis, accident, or treachery
[draft-ietf-dnssec-secops-*.txt].
In a widely deployed DNS security system, the volume of update
traffic will be large. Just consider the .com zone. If only 10% of
its children are secure and change their keys only once a year, you
are talking about hundreds of thousands of new child public keys that
must be securely sent to the .com manager to sign and return with
their new parent signature. And when .com rolls over its private
key, it will needs to send hundreds of thousands of new signatures on
the existing child public keys to the child zones.
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in RFC 2119.
2. Key Rollover Scenarios
Although DNSSEC provides for the storage of other keys in the DNS for
a variety of purposes, DNSSEC zone keys are included solely for the
purpose of being retrieved to authenticate DNSSEC signatures. Thus,
when a zone key is being rolled over, the old public key should be
left in the zone, along with the addition of the new public key, for
as long as it will reasonably be needed to authenticate old
signatures that have been cached or are held by applications. If
DNSSEC were universally deployed and all DNS server's clocks were
synchronized and zone transfers were instantaneous etc., it might be
possible to avoid ever having duplicate old/new KEY RRsets but they
will be necessary in practical cases. Security aware DNS servers
decrease the TTL of secure RRs served as the expiration of their
authenticating SIG(s) approaches but some dithered fudge must
D. Eastlake 3rd, M. Andrews [Page 3]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
generally be left due to clock skew and to avoid massive load on
large zones due to the signatures on their entire contents expiring
simultaneously.
Assume a zone with a secure parent and secure children wishes to role
over its KEY RRset. This RRset would probably be one KEY RR per
crypto algorithm used to secure the zone, but for this scenario, we
will simply assume it is one KEY RR. The old KEY RR and two SIG RRs
will exist at the apex of the zone and these RRs may also exist at
the leaf node for this zone in its parent. The contents of the zone
and the zone KEY RRs of its secure children will have SIGs under the
old key.
The zone owner needs to communicate with its parent to obtain a new
parental signature covering both the old and new KEY RRs and covering
just the new KEY RR. It would probably want to obtain these in
advance so that it can install them at the right time along with its
new SIG RRs covering the content of the zone. Finally, it needs to
give new SIG RRs to its children that cover their KEY RRs if it has
these, or signal its children to ask for such SIG RRs.
3. Rollover Operation
Rollover operations use a DNS request syntactically identical to the
UPDATE request [RFC 2136] except that the operation is ROLLOVER which
is equal to TBD. Considerations for such request to the parent and
children of a zone are given in the subsections.
[This draft does not currently consider cross-certification key
rollover.]
3.1 Rollover to Parent
A zone rolling over its KEY RRset sends a ROLLOVER command to the
parent. The Zone should be specified as the parent zone and no
Prerequisites are included. The Update section has the KEY RRset on
which the parent signature is requested along with the requesting
zone's SIG(s) under its old KEY(s) as RRs to be added to the parent
zone. The inception and expiration times in this SIG are the
requested inception and expiration times for the parent SIG.
If the ROLLOVER command is erroneous or violates parental policy, an
Error response is returned.
If the ROLLOVER command is OK and the parent can sign online, its
response may include the new parent SIG(s) in the Update section.
D. Eastlake 3rd, M. Andrews [Page 4]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
This response MUST be sent to the originator of the request.
If the parent can not sign online, it should return a response with
an empty Update section and queue the SIG(s) calculation request.
This response MUST be sent to the originator of the request.
Regardless of whether the server has sent the new signatures above,
it MUST, once it has calculated the new SIG(s), send a ROLLOVER to
the child zone using the DNS port (53) and the server selection
algorithm defined in RFC 2136, Section 4. This ROLLOVER reqeust
contains the KEY RRset that triggered it and the new SIG(s). This
downward ROLLOVER request is distinguished from those in Section 3.2
below in that the Zone section is the parental zone.
The reason for sending the ROLLOVER request regardless of whether the
new SIG RR(s) were sent in the original response is to provide an
indication to the operators of the zone in the event someone is
trying to hijack the zone.
Although the parent zone need not hold or serve the child's key, the
ROLLOVER command MUST NOT actually update the parent zone. A later
UPDATE command can be used to actually put the new KEY into the
parent zone if desired and supported by parent policy.
This document does not cover the question of parental policy on key
rollovers. Parents may have restrictions on how far into the future
they will sign KEY RRsets, what algorithms or key lengths they will
support, might require payment for the service, etc. The signing of
a future KEY by a parent is, to some extent a granting to the
controller of the child private key of future authoritative existence
even if the child zone ownership should change. The only effective
way of invalidating such future signed child public keys would be for
the parent to roll over its key(s), which might be an expensive
operation.
3.2 Rollover to Children
When a zone is going to rollover its key(s), it needs to re-sign the
zone keys of any secure children under its new key(s).
If the parent holds the KEY RRset for the child (whether or not it
actually serves it from the parent zone), it can simply do a ROLLOVER
request to to child specifying the child as the Zone in the request
and the new SIG(KEY)s to be added in the Update section. The
inception and expiration times in the SIG(s) indicate the time during
which the parent will be utilizing the new parent key. It is up to
the child when and how it adds the new parental SIG(s). The ROLLOVER
request may optionally indicate the deletion of old parental SIG(s)
D. Eastlake 3rd, M. Andrews [Page 5]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
but SHOULD only do so if the corresponding key is being withdrawn by
the parent in advance of the expiration time in the old SIG(s). It
is up to the child when and how it deletes the old parental SIG(s).
Even if the expiration of the old SIG(s) equals the inception time of
the new SIG(s), the child should serve both signatures for a fudge
time to account for clock skew.
A ROLLOVER request is used instead of an UPDATE because serves may
wish to support ROLLOVER via special techniques, such as notification
to the operator, even when they have not implemented UPDATE. With
adequate advance notice, even manual cut and paste editing of the
master file and restarting of a DNS server process could work.
If the parent does not retain knowledge of the child KEY RRset, then
the parent simply notifies the child via a ROLLOVER NOTIFY (see
Section 4 below) that the parent KEY(s) have changed. The child then
proceeds to do an upward ROLLOVER request to obtain the new parental
SIG(s). (This requires that a different method, such as TSIG, be
used to secure such ROLLOVER requests since we are assuming the
parent does not have authoritative knowledge of the child public key.
See Section 5 below.)
The NOTIFY technique MAY also be used by parents who retain knowledge
of their children's KEY RRsets.
4. Rollover NOTIFY
A ROLLOVER NOTIFY informs a child zone that the parent zone want it
to resubmit its keys for resigning.
A ROLLOVER NOTIFY MUST be signed and if not signed a BADAUTH response
generated.
A ROLLOVER NOTIFY is a NOTIFY reqeust [RFC 1996] that has a QTYPE of
SIG and the owner name of the child zone. The answer section is
empty.
The ROLLOVER NOTIFY can be sent to any of the nameservers for the
child using the nameserver selection algorithm defined in RFC 2136,
Section 4.
Nameservers for the child zone receiving a ROLLOVER NOTIFY query will
forward the ROLLOVER NOTIFY in the saem manner as an UPDATE is
forwarded.
Unless the master server is configured to initiate an automatic
ROLLOVER it MUST seek to inform its operators that a ROLLOVER NOTIFY
request has been received. This could be done by a number of methods
D. Eastlake 3rd, M. Andrews [Page 6]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
including generating a log message, generating an email request to
the child zone's SOA RNAME or any other method defined in the
server's configuration for the zone. The default should be to send
mail to the zone's SOA RNAME. Care should be taken to rate limit
these message so prevent them being used to facilitate a denial of
service attack.
Once the message has been sent (or suppressed) to the child zone's
administrator the master server for the child zone is free to respond
to the ROLLOVER NOTIFY request.
5. Security Considerations
The security of ROLLOVER or UPDATE requests is essential, otherwise
false children could steal parental authorization or a false parent
could cause a child to install an invalid signature on its zone key,
etc.
A ROLLOVER request can be authentication by request SIG(s)under the
old zone KEY(s) of the requestor [draft-ietf-dnssec-secext2-*.txt].
The response SHOULD have transaction SIG(s) under the old zone KEY(s)
of the responder. (This public key security could be used to
rollover a zone to the unsecured state but at that point it would
generally not be possible to roll back without manual intervention.)
Alternatively, if there is a prior arrangement between a child and a
parent, ROLLOVER requests and responses can be secured and
authenticated using TSIG [draft-ietf-dnssec-tsig-*.txt]. (TSIG
security could be used to rollover a zone to unsecured and to
rollover an unsecured zone to the secured state.)
A server that implements online signing SHOULD have the ability to
black list a zone and force manual processing or demand that a
particular signature be used to generate the ROLLOVER request. This
it to allow ROLLOVER to be used even after a private key has been
compromised.
D. Eastlake 3rd, M. Andrews [Page 7]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
References
[RFC 1034] - P. Mockapetris, "Domain names - concepts and
facilities", 11/01/1987.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", August 1996.
[RFC 2136] - Dynamic Updates in the Domain Name System (DNS UPDATE).
P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997.
[draft-ietf-dnsind-tsig-*.txt]
[draft-ietf-dnssec-update2-*.txt]
[draft-ietf-dnssec-secext2-*.txt]
[draft-ietf-dnssec-secops-*.txt]
Authors Address
Donald E. Eastlake 3rd
IBM
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978-287-4877
+1 914-784-7913
FAX: +1 978-371-7148
EMail: dee3@us.ibm.com
Mark Andrews
Internet Software Consortium
1 Seymour Street
Dundas Valley, NSW 2117
AUSTRALIA
Telephone: +61-2-9871-4742
Email: marka@isc.org
D. Eastlake 3rd, M. Andrews [Page 8]
INTERNET-DRAFT October 1998 DNSSEC Key Rollover
Expiration and File Name
This draft expires in April 1999.
Its file name is draft-ietf-dnssec-rollover-00.txt.
D. Eastlake 3rd, M. Andrews [Page 9]

291
doc/draft/draft-ietf-dnssec-secfail-00.txt Normal file
View file

@ -0,0 +1,291 @@
Internet-Draft B. Wellington, O. Gudmundsson
DNSSEC Working Group TISLabs
<draft-ietf-dnssec-secfail-00.txt> August 1998
Intermediate Security Failures in DNSSEC
<draft-ietf-dnssec-secfail-00.txt>
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.
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."
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).
Distribution of this memo is unlimited.
Abstract
This document identifies the situations where a signature
verification fails in a recursive security aware DNS server, and
how DNS servers should handle these cases, and the errors that
should be reported to DNS resolvers. This document proposes a new
error to be returned by DNSSEC capable servers.
A DNSSEC server acting as a recursive server MUST validate the
signatures on RRsets in a response it passes on; this draft
addresses the case when the data it receives fails signature
Wellington, Gudmundsson Expires February 1999 [Page 1]
Internet-Draft dnssec-secfail-00.txt August 1998
verification. The end resolver must be notified of this occurence
in such a way that it will not confuse it with another error.
1. Description
A DNS [RFC1034, RFC1035] transaction is defined by a query/response
pair. The resolver (client) sends a query to a name server. The
name server will respond if it contains the necessary information,
or forward the request to an authoritative server. The response
consists of the answer to the query, as well as authority records
showing that the response came from a valid source, and additional
records.
DNSSEC [RFC2065, SECEXT2] adds security to the DNS protocol. Each
RRset (set of DNS records with the same name/class/type) is
digitally signed, and the signature is verified by any server or
resolver who receives it. The receiver must therefore have a valid
key for verifying that data, as specified by a name/footprint pair.
A key's validity is determined by recursively verifying that it was
signed by a valid key; this recursion ends when a trusted key is
reached. Trusted keys must be obtained out of band, for example
through manual configuration.
Consider a recursive name server (R) that forwards a query to
another server (S). R receives an response from S, and attempts to
verify the included RRsets using a key that it trusts. Note that
this key may either be implicitly trusted or authenticated. The
signature verification fails for one or more RRsets in the answer
or authority section. The name server must communicate this error
in its response. To do this, a new return code (RCODE) will be
used, denoted SECFAIL (value TBD).
When a resolver receives a DNS response with an RCODE of SECFAIL,
that one of the following is true:
1) server S has sent invalid data to server R.
2) the data has been corrupted (possibly maliciously) between R and S.
3) server R has preconfigured S's key incorrectly.
4) There is more than one KEY with the same footprint and algorithm
for that name, and server R contains one different from the one used
by S to sign the data. This should not happen.
None of the current RCODE values sufficiently describe the case
where the data exists, but cannot be successfully retrieved and/or
transmitted. It is the responsibility of both R and the resolver
to attempt to identify the source of the problem.
Wellington, Gudmundsson Expires February 1999 [Page 2]
Internet-Draft dnssec-secfail-00.txt August 1998
2. Proposal
When the recursive name server (R) fails to verify a signed RRset
in the answer or authority section of a response that it receives,
it sets the RCODE of the response to SECFAIL before forwarding the
response to the entity that originated the query. There are
several possible modifications that could be made to the data by R:
1) all records could be passed unchanged
2) all records could be dropped
3) only the records that failed verification could be dropped
4) the SIGs of all records that failed verification could be dropped
A solution to this problem has not yet been decided.
If R receives a response with SECFAIL set, it does no processing on
the response, simply forwarding it if necessary. An intelligent
resolver MAY use additional queries to determine which of the
RRsets was invalid. The ERR record [ERR] or EDNS [EDNS] could also
be used to provide a more fine-grained description of the error.
When R fails to verify an RRset, it can determine whether or not
the key used has successfully verified other data (a flag or
timestamp could be stored along with the key). If it has, then the
key has not been misconfigured, and the error is due to data
corruption (possibly malicious) or a data error on the
authoritative server (S). R cannot further quantify the problem.
If the key has never successfully verified data, then the problem
may be a misconfigured key, or it could be due to malicious
corruption or a very unreliable network. In any case, this should
be logged, and the maintainer of R should determine (out of band)
whether the preconfigured key is erroneous. R MAY elect to retry
the query; this would succeed if the error was due to transient
network problems or a partial attack. Unless a retransmission
yields success, R should always send a response with SECFAIL set.
3. Limitations
If the path between a resolver and an authoritative server is
several hops, there is no way to determine at which recursive
server the SECFAIL error occurred. The data will be passed through
successive servers unchanged.
There is no way to distinguish a server continuously reporting
invalid data from an active attack. For instance, if a server has
an preconfigured key that is invalid, all queries using that key
will fail. An attack could easily simulate this behavior. There
is no way to split SECFAIL into more specific errors, since the
Wellington, Gudmundsson Expires February 1999 [Page 3]
Internet-Draft dnssec-secfail-00.txt August 1998
cause of the error cannot always be determined.
4. Security Considerations
Unless transaction signatures of some form are used [RFC2065,
TSIG], the RCODE field of a DNS response is not protected, so the
SECFAIL RCODE could be added or stripped by an attacker.
5. References
[EDNS] P. Vixie, "Extensions to DNS (EDNS)", Internet
Draft <draft-ietf-dnsind-edns-02.txt>, March 1998
[ERR] R. Watson, O. Gudmundsson, "Error Record (ERR)
for DNS" Internet Draft <draft-ietf-dnsind-dns-
error-00.txt>, March 1998
[RFC1034] P. Mockapetris, "Domain Names - Concepts and
Facilities", RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, "Domain Names - Implementation
and Specification", RFC 1034, ISI, November 1987.
[RFC2065] D. Eastlake, C. Kaufman, "Domain Name System
Security Extensions", RFC 2065, January 1997.
[SECEXT2] D. Eastlake, "Domain Name System Security Exten­
sions", Internet Draft <draft-ietf-dnssec-
secext2-05.txt>, April 1998.
[TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret
Key Transaction Signatures for DNS (TSIG)" Inter­
net Draft <draft-ietf-dnsind-tsig-05.txt>, June
1998.
Wellington, Gudmundsson Expires February 1999 [Page 4]
Internet-Draft dnssec-secfail-00.txt August 1998
6. Author address
Brian Wellington, Olafur Gudmundsson
TIS Labs at Network Associates
3060 Washington Road
Glenwood, MD 21738
+1 301 854 6889
bwelling@tis.com, ogud@tis.com
Wellington, Gudmundsson Expires February 1999 [Page 5]

278
doc/draft/draft-ietf-dnssec-simple-update-01.txt Normal file
View file

@ -0,0 +1,278 @@
DNSSEC Working Group Brian Wellington (TISLabs)
INTERNET-DRAFT February 1999
<draft-ietf-dnssec-simple-update-01.txt>
Updates: RFC 2065, RFC 2136, [TSIG]
Replaces: RFC 2137, [update2]
Simple Secure Domain Name System (DNS) Dynamic Update
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
This draft proposes an alternative method for performing secure
Domain Name System (DNS) dynamic updates. The method described here
is both simple and flexible enough to represent any policy decisions.
Secure communication based on request/transaction signatures [TSIG]
is used to provide authentication and authorization.
Expires August 1999 [Page 1]
INTERNET-DRAFT Simple Secure Dynamic Update February 1999
1 - Introduction
Dynamic update operations for the Domain Name System are defined in
[RFC2136], but no mechanisms for security have been defined. Request
and transaction signatures are defined in [TSIG].
Familiarity with the DNS system [RFC1034, RFC1035] as well as the
proposals mentioned above is assumed. Familiarity with DNS Security
[RFC2065, secext2] is assumed in section (4).
1.1 - Overview of DNS Dynamic Update
DNS dynamic update defines a new DNS opcode and a new interpretation of
the DNS message if that opcode is used. An update can specify
insertions or deletions of data, along with prerequisites necessary for
the updates to occur. All tests and changes for a DNS update request
are restricted to a single zone, and are performed at the primary server
for the zone. The primary server for a dynamic zone must increment the
zone SOA serial number when an update occurs or before the next
retrieval of the SOA.
1.2 - Overview of DNS Transaction Security
[TSIG] provides a means for two processes that share a secret key to
authenticate DNS requests and responses sent between them. This is done
by appending TSIG digital signature (keyed hash) RRs to those messages.
Keyed hashes are simple to calculate and verify, and do not require
caching of data.
2 - Authentication
TSIG records are attached to all secure dynamic update messages. This
allows the server to verifiably determine the originator of the message.
It can then use this information in the decision of whether to accept
the update. DNSSEC SIG records may be included in an update message,
but MAY NOT be used for authentication purposes in the update protocol.
If a message fails the authentication test due to an unauthorized key,
the failure is indicated with the REFUSED rcode. Other TSIG or dynamic
update errors are returned unchanged.
Expires August 1999 [Page 2]
INTERNET-DRAFT Simple Secure Dynamic Update February 1999
3 - Policy
All policy is dictated by the server and is configurable by the zone
administrator. The server's policy defines criteria which determine if
the key used to sign the update is permitted to update the records
requested. By default, a key cannot make any changes to the zone; the
key's scope must be explicitly enabled. There are several reasons that
this process is implemented in the server and not the protocol (as in
[RFC2137, update2], where the signatory bits of KEY records may define
the policy).
3.1 - Flexibility
Storing policy in the signatory fields of DNS keys is overly
restrictive. Only a fixed number of bits are present, which means that
only a fixed number of policy decisions are representable. There are
many decisions that do not fit into the framework imposed by the
signatory field; a zone administrator cannot effectively impose a policy
not implemented in the draft defining the field.
There may be any number of policies applied in the process of
authorization, and there are no restrictions on the scope of these
policies. Implementation of the policies is beyond the scope of this
document.
3.2 - Simplicity
Policy decisions in the server could be used as an adjunct to policy
fields in the KEY records. This could lead to confusion if the policies
are inconsistent. Furthermore, since there is no need to expose
policies, a central configuration point is more logical.
3.3 - Extendibility
If a policy is changed, there are no changes made to the DNS protocol or
the data on the wire. This means that new policies can be defined at
any point without adverse effects or interoperability concerns.
Expires August 1999 [Page 3]
INTERNET-DRAFT Simple Secure Dynamic Update February 1999
4 - Interaction with DNSSEC
A successful update request may or may not include SIG records for each
RRset. Since SIG records are not used for authentication in this
protocol, they are not required. If the updated zone is signed, the
server will generate SIG records for each incoming RRset with the Zone
key (which MUST be online). If there are any non-DNSSEC SIG records
present, they are retained. If there are SIG records that have been
generated by the appropriate zone KEY, these SIGs are verified and
retained if the verification is successful. DNSSEC SIG records
generated by other KEYs are dropped. The server will generate SIG
records for each set with the Zone key, unless one has already been
verified. The server will also generate a new SOA record and possibly
new NXT records, and sign these with the Zone key.
The server MUST update the SOA record and MAY generate new NXT records
when an update is received. Unlike traditional dynamic update, the
client is forbidden from updating SOA 1 NXT records.
5 - Security considerations
For a secure zone to support dynamic update, the Zone key MUST be online
(unlike [RFC2137]). No additional protection is offered by having the
Zone key offline and an Update key online, since compromising any key
that can sign the zone's data compromises the zone itself.
6 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987.
[RFC2065] D. Eastlake, C. Kaufman, ``Domain Name System Security
Extensions,'' RFC 2065, CyberCash & Iris, January 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.
[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
2137, CyberCash, April 1997.
[secext2] D. Eastlake ``Domain Name System Security Extensions,''
draft-ietf-dnssec-secext2-07.txt, IBM, December 1998.
Expires August 1999 [Page 4]
INTERNET-DRAFT Simple Secure Dynamic Update February 1999
[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington
``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs,
February 1999.
[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic
Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite
Systems Company, August 1998.
7 - Author's Address
Brian Wellington
TISLabs at Network Associates
3060 Washington Road, Route 97
Glenwood, MD 21738
+1 443 259 2369
<bwelling@tislabs.com>
Expires August 1999 [Page 5]

1045
doc/draft/draft-ietf-dnssec-tkey-01.txt Normal file
View file

File diff suppressed because it is too large Load diff

871
doc/draft/draft-ietf-dnssec-update2-00.txt Normal file
View file

@ -0,0 +1,871 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
OBSOLETES RFC 2137 Transfinite Systems Company
Expires: February 1999 August 1998
Secure Domain Name System (DNS) Dynamic Update
------ ------ ---- ------ ----- ------- ------
Status of This Document
This draft, file name draft-ietf-dnssec-update2-00.txt, is intended
to become a Proposed Standard RFC obsoleting RFC 2137. Distribution
of this document is unlimited. Comments should be sent to the DNS
security mailing list <dns-security@tis.com> or the author.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. 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 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).
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT Secure DNS Update August 1998
Abstract
Revised Domain Name System (DNS) protocol extensions to authenticate
the data in DNS and provide key distribution services have been
defined in draft-ietf-dnssec-secext2-*.txt, which obsoletes the
original DNS security protocol definition in RFC 2065. In addition,
symetric key DNS transaction signatures have been defined in draft-
ietf-dnsind-tsig-*.txt. Secure DNS Dynamic Update operations were
also been defined [RFC 2137] in connection RFC 2065. This document
updates secure dynamic update in light of draft-ietf-dnssec-secext2-
*.txt and draft-ietf-dnsind-tsig-*.txt. It describes how to use
digital signatures covering requests and data to secure updates and
restrict updates to those authorized to perform them as indicated by
the updater's possession of cryptographic keys.
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT Secure DNS Update August 1998
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Table of Contents..........................................3
1. Introduction............................................4
1.1. Overview of DNS Dynamic Update........................4
1.2. Overview of Public Key DNS Security...................4
1.3 Overview of Secret Key DNS Security....................5
2. Two Basic Modes.........................................6
2.1. Mode A................................................6
2.2. Mode B................................................7
3. Keys....................................................8
3.1. Update Keys...........................................8
3.1.1. Public Update Key Name Scope........................8
3.1.2. Public Update Key Class Scope.......................8
3.1.3. Public Update Key Signatory Field...................9
3.2. Zone Keys and Update Modes...........................10
3.3. Wildcard Public Key Punch Through....................11
4. Update Signatures......................................13
4.1. Update Request Signatures............................13
4.2. Update Data Signatures...............................13
5. Security Considerations................................14
6. IANA Considerations....................................14
References................................................15
Author's Address..........................................15
Expiration and File Name..................................15
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT Secure DNS Update August 1998
1. Introduction
Dynamic update operations have been defined for the Domain Name
System (DNS) in RFC 2136 but that RFC does not include a description
of security for those updates. Public key means of securing DNS data
and transactions and using it for public key distribution were
defined in RFC 2065 which has been updated by draft-ietf-dnssec-
sexect2-*.txt, and secret key means of securing DNS transactions are
defined in draft-ietf-dnsind-tsig-*.txt.
This document provides techniques based on the updated DNS security
RFC draft-ietf-dnssec-sexect2-*.txt and draft-ietf-dnsind-tsig-*.txt
to authenticate DNS updates of secure zones. (Secret key signatures
could be used to authenticate updates on non-secured DNS zones. That
case In not considered in this document.)
Familiarity with the DNS system [RFC 1034, 1035] is assumed.
Familiarity with the DNS security and dynamic update will be helpful.
1.1. Overview of DNS Dynamic Update
DNS dynamic update defines a new DNS opcode, new DNS request and
response structure if that opcode is used, and new error codes. An
update can specify complex combinations of deletion and insertion
(with or without pre-existence testing) of resource records (RRs)
with one or more owner names; however, all testing and changes for
any particular DNS update request are restricted to a single zone.
Updates occur at the primary server for a zone.
The primary server for a dynamic zone must increment the zone SOA
serial number when an update occurs or the next time the SOA is
retrieved if one or more updates have occurred since the previous SOA
retrieval and the updates themselves did not update the SOA.
1.2. Overview of Public Key DNS Security
DNS security authenticates data in the DNS by also storing digital
signatures in the DNS as SIG resource records (RRs). A SIG RR
provides a digital signature on the set of all RRs with the same
owner name and class as the SIG and whose type is the type covered by
the SIG. The SIG RR cryptographically binds the covered RR set to
the signer, signature inception and expiration date, etc. There are
one or more keys associated with every secure zone and all data in
the secure zone is signed either by a zone key or by a dynamic update
key tracing its authority to a zone key.
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT Secure DNS Update August 1998
DNS security also defines transaction SIGs and request SIGs.
Transaction SIGs appear at the end of a response. They authenticate
the response and bind it to the corresponding request using the key
of the host where the responding DNS server is.
Request SIGs appear at the end of a request and authenticate the
request with the key of the submitting entity.
DNS security also permits the storage of public keys in the DNS via
KEY RRs. These KEY RRs are also, of course, authenticated by SIG
RRs. KEY RRs for zones may be stored in their superzone and/or their
authoritive subzone servers so that the secure DNS tree of zones can
be traversed by a security aware resolver.
1.3 Overview of Secret Key DNS Security
draft-ietf-dnsind-tsig-*.txt provides a means for two processes that
share a secret key to authenticate DNS requests and responses sent
between them by appending TSIG digital signature RRs to those
requests and responses. Secret key digital signatures are generally
much faster to calculate and verify than public key digital
signatures. In addition, the need, in general, to cache KEY RRs and
perform the KEY-SIG chain verifications is avoided.
However, the cost for this speed and simplicity in TSIG use is the
requirement to securely achieve key distribution or agreement between
the communicating processes and to achieve agreement as to the
authority represented by a correct TSIG on a requested using a
partciular key.
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT Secure DNS Update August 1998
2. Two Basic Modes
A dynamic secure zone is any secure DNS zone that
(1) has a zone KEY RR signatory field indicates that updates are
implemented and either
(2a) contains one or more KEY RRs that can authorize dynamic
updates, i.e., entity or user KEY RRs with the signatory field
non-zero, or
(2b) has a primary server with one or more secret keys configured
to authorize updates requests and shared with one or more
update requesters.
Note: 2a and 2b can both be true for a zone.
There are two basic modes of dynamic secure zone which relate to the
update strategy, mode A and mode B. A summary comparison table is
given below and then each mode is described.
SUMMARY OF DYNAMIC SECURE ZONE MODES
CRITERIA: | MODE A | MODE B
=========================+====================+===================
Definition: | Zone Key Off line | Zone Key On line
=========================+====================+===================
Server Workload | Medium | High
-------------------------+--------------------+-------------------
Key Restrictions | Fine grain | Coarse grain
-------------------------+--------------------+-------------------
Dynamic Data Temporality | Transient | Permanent
-------------------------+--------------------+-------------------
Dynamic Key Rollover | No | Yes
-------------------------+--------------------+-------------------
NOTE: The Mode A / Mode B distinction only effects the validation
and performance of update requests. It has no effect on retrievals.
2.1. Mode A
For mode A, the zone owner private key and static zone master file
are kept off-line for maximum security of the static zone contents.
As a consequence, any dynamicly added or changed RRs are signed in
the secure zone by their authorizing dynamic update key and they are
backed up, along with this SIG RR, in a separate online dynamic
master file. In this type of zone, server computation is generally
reduced since the server need only check signatures on the update
data and request, which have already been signed by the updater
(generally a much faster operation than signing data) and update the
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT Secure DNS Update August 1998
NXT RRs which need to be changed, if any. Because the dynamicly
added RRs retain their update KEY signed SIG, finer grained control
of updates can be implemented via the KEY RR signatory field (unique
name restriction and weak update key restriction). Because dynamic
data is only stored in the online dynamic master file and only
authenticated by dynamic keys which expire, updates are transient in
nature. Key rollover for an entity that can authorize dynamic
updates is more cumbersome since the authority of their key must be
traceable to a zone key and so, in general, they must securely
communicate a new key to the zone authority for manual transfer to
the off line static master file. NOTE: for this mode the zone SOA and
NXT RRs must be signed by a dynamic update key, which will be an end
entity key with an owner name of the zone name, and that private key
must be kept on line so that the SOA and NXTs can be changed for
updates.
2.2. Mode B
For mode B, the zone owner private key and master file are kept on-
line at the zone primary server. When authenticated updates succeed,
SIGs under the zone key for the resulting data (as well as possible
NXT and SOA changes) are calculated and these SIG (and possible
SOA/NXT) changes are entered into the zone and the unified on-line
master file.
As a consequence, this mode generally requires more computational
effort on the part of the server as it computes zone data signatures
in addition to verifying the signatures on requests. Because signing
generally takes more effort than verification, these signatures
generally will take more effort to calculate than it would take to
verify the data signatures required in Mode A. Because the zone key
is used to sign all the zone data, the information as to who
originated the current state of dynamic RR sets and even that data is
the result of a dynamic update as opposed to coming from an original
master file, is lost, making unavailable the fine grain control of
some values of the KEY RR signatory field. In addition, the
incorporation of the updates into the primary master file and their
authentication by the zone key makes them permanent in nature.
Maintaining the zone key on-line also means that dynamic update keys
which are signed by the zone key can be dynamically updated in real
time since the zone key is available to dynamically sign new values.
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT Secure DNS Update August 1998
3. Keys
Dynamic update requests depend on update keys as described in section
3.1 below. In addition, the zone secure dynamic update mode and
availability of some options is indicated in the zone KEY(s).
Finally, a special rule is used in searching for KEYs to validate
updates as described in section 3.3.
3.1. Update Keys
All update requests to a secure zone must include signature(s) by one
or more private or secret keys that together can authorize that
update. In order for the Domain Name System (DNS) server executing
the update request to confirm this (1) any secret keys must be know
to it, along with the authority represented by the secret key, and
(2) any private key or keys must have the corresponding public key or
keys available to and authenticatable by that server as specially
flagged KEY Resource Records (RRs).
The scope of authority of any secret keys is as configured at the
Server. Methods of describing and configuring such authority are not
discussed in this document.
The scope of authority of public update keys is indicated by their
KEY RR owner name, class, and signatory field flags as described
below. In addition, such KEY RRs MUST be entity or user keys and not
have the authentication use prohibited bit on.
All parts of the actual update MUST be within the scope/authority of
at least one of the keys used for a request SIG or TSIG on the update
request as described in section 4.
3.1.1. Public Update Key Name Scope
The owner name of any update authorizing KEY RR must (1) be the same
as the owner name of any RRs being added or deleted or (2) a wildcard
name including within its extended scope (see section 3.3) the name
of any RRs being added or deleted and those RRs must be in the same
zone.
3.1.2. Public Update Key Class Scope
The class of any update authorizing KEY RR must be the same as the
class of any RR's being added or deleted.
Donald E. Eastlake 3rd [Page 8]
INTERNET-DRAFT Secure DNS Update August 1998
3.1.3. Public Update Key Signatory Field
The four bit "signatory field" (see draft-ietf-dnssec-secext2-*.txt)
of any update authorizing KEY RR must be non-zero. The bits have the
meanings described below for non-zone keys (see section 3.2 for zone
type keys).
UPDATE KEY RR SIGNATORY FIELD BITS
0 1 2 3
+-----------+-----------+-----------+-----------+
| zone | strong | unique | general |
+-----------+-----------+-----------+-----------+
Bit 0, zone control - If nonzero, this key is authorized to attach,
detach, and move zones by creating and deleting NS, glue A, and
zone KEY RR(s). If zero, the key can not authorize any update
that would effect such RRs. This bit is meaningful for both
type A and type B dynamic secure zones. An update attempting to
add an NS or zone KEY RR to a node (i.e., make the node a
delegation point) is illegal if there are any deeper nodes in
the zone.
NOTE: do not confuse the "zone" signatory field bit with the
"zone" key type bit.
Bit 1, strong update - If zero, the key can only authorize updates
where any existing RRs of the same owner and class are
authenticated by a SIG using the same key. If nonzero, this key
is authorized to add and delete RRs even if there are other RRs
with the same owner name and class that are authenticated by a
SIG signed with a different dynamic update KEY. This bit is
meaningful only for type A dynamic zones that have a zone KEY
advertising that the feature is available. It is ignored in
type B dynamic zones.
Keeping this bit zero on multiple KEY RRs with the same or
nested wild card owner names permits multiple entities to exist
that can create and delete names but can not effect RRs with
different owner names from any they created. In effect, this
creates two levels of dynamic update key, strong and weak, where
weak keys are prohibited from interfering with each other but a
strong key can interfere with any weak keys or other strong
keys.
Bit 2, unique name update - This bit is useful only if the owner name
is a wildcard. (Any dynamic update KEY with a non-wildcard name
is, in effect, a unique name update key.) If zero, this key is
authorized to add and updates RRs for any number of names within
its wildcard scope. If nonzero, this key is authorized to add
Donald E. Eastlake 3rd [Page 9]
INTERNET-DRAFT Secure DNS Update August 1998
and update RRs for only a single owner name. If there already
exist RRs with one or more names signed by this key, they may be
updated but no new name created until the number of existing
names is reduced to zero. This bit is meaningful only for mode
A dynamic zones that have a zone KEY advertising that the
feature is available. It is ignored in mode B dynamic zones.
This bit can be used to restrict a KEY from flooding a zone with
new names. In conjunction with a local administratively imposed
limit on the number of dynamic RRs with a particular name, it
can completely restrict a KEY from flooding a zone with RRs.
Bit 3, general update - The general update signatory field bit has no
special meaning. If the other three bits are all zero, it must
be one so that the field is non-zero to designate that the key
is an update key. The meaning of all values of the signatory
field with the general bit on and one or more other signatory
field bits on is reserved.
All the signatory bit update authorizations described above only
apply if the update is within the name and class scope as per
sections 3.1.1 and 3.1.2.
3.2. Zone Keys and Update Modes
Zone type keys are automatically authorized to sign anything in their
zone, of course, regardless of the value of their signatory field.
For zone keys, the signatory field bits have different means than
they they do for update keys, as shown below. The signatory field
MUST be zero if dynamic update is not supported for a secure zone and
MUST be non-zero if it is.
ZONE KEY RR SIGNATORY FIELD BITS
0 1 2 3
+-----------+-----------+-----------+-----------+
| mode | strong | unique | general |
+-----------+-----------+-----------+-----------+
Bit 0, mode - This bit indicates the update mode for this zone. Zero
indicates mode A while a one indicates mode B.
Bit 1, strong update - If nonzero, this indicates that the "strong"
key feature described in section 3.1.3 above is implemented and
enabled for this secure zone. If zero, the feature is not
available and all update keys are treated as strong. Has no
effect if the zone is a mode B secure update zone.
Donald E. Eastlake 3rd [Page 10]
INTERNET-DRAFT Secure DNS Update August 1998
Bit 2, unique name update - If nonzero, this indicates that the
"unique name" feature described in section 3.1.3 above is
implemented and enabled for this secure zone. If zero, this
feature is not available and no wildcard update key is treated
as restricted to a single name. Has no effect if the zone is a
mode B secure update zone.
Bit 3, general - This bit has no special meaning. If dynamic update
for a zone is supported and the other bits in the zone key
signatory field are zero, it must be a one. The meaning of zone
keys where the signatory field has the general bit and one or
more other bits on is reserved.
If there are multiple zone KEY RRs with non-zero signatory fields and
zone policy is in transition, they might have different signatory
field values. In that case, strong and unique name restrictions MUST
be enforced as long as there is a non-expired zone key being
advertised that indicates mode A with the strong or unique name bit
on respectively. Mode B updates (i.e., no data signatures) MUST be
supported as long as there is a non-expired zone key that indicates
mode B. Mode A or mode ambiguous updates may be treated as mode B
updates at server option if non-expired zone keys indicate that both
are supported.
A server that will be executing update operations on a zone, that is,
the primary master server, MUST NOT advertize a zone key that will
attract requests for a mode or features that it can not support.
3.3. Wildcard Public Key Punch Through
Just as a zone key is valid throughout the entire zone, public update
keys with wildcard names are valid throughout their extended scope,
within the zone. That is, they remain valid for any name that would
match them, even existing specific names within their apparent scope.
(If this were not so, then whenever a name within a wildcard scope
was created by dynamic update using a wildcard named public update
key for authorization, it would be necessary to first create a copy
of the KEY RR with this name, because otherwise the existence of the
more specific name would hide the authorizing KEY RR and would make
later updates impossible. An updater could create such a KEY RR but
could not zone sign it with their authorizing signer. They would
have to sign it with the same key using the wildcard name as signer.
(This would create update KEYs signed by update KEYs which was
permitted in RFC 2065 but, for simplicity, is prohibit in draft-
ietf-dnssec-secext2-*.txt which requires all KEYs to be signed by
zone keys.) Thus in creating, for example, one hundred type A RRs
authorized by a *.1.1.1.in-addr.arpa KEY RR, without key punch
Donald E. Eastlake 3rd [Page 11]
INTERNET-DRAFT Secure DNS Update August 1998
through 100 As, 100 KEYs, and 200 SIGs would have to be created as
opposed to merely 100 As and 100 SIGs with wildcard key punch
through.)
Donald E. Eastlake 3rd [Page 12]
INTERNET-DRAFT Secure DNS Update August 1998
4. Update Signatures
Two kinds of signatures can appear in updates. Request signatures,
which are always required, cover the entire request and authenticate
the DNS header, including opcode, counts, etc., as well as the data.
Data signatures, on the other hand, appear only among the RRs to be
added and are only required for mode A operation. These two types of
signatures are described further below.
4.1. Update Request Signatures
An update can effect multiple owner names in a zone. It may be that
these different names are covered by different public or secret
dynamic update keys. For every owner name effected, the updater must
know a private or secret key valid to authorize updates for that name
(and the zone's class) and must prove this by appending request SIG
and/or TSIG RRs under each such key.
Request signatures occur in the Additional Information section. As
specified in draft-ietf-dnssec-secext2-*.txt, a public request
signature is a SIG RR occurring at the end of a request with a type
covered field of zero. As specified in draft-ietf-dnsind-tsig-*.txt,
a secret key request signature is a TSIG RR occuring at the end of
the request. Each request SIG or TSIG signs the entire request,
including DNS header, but excluding any other request signatures and
with the ARCOUNT in the DNS header set to what it would be without
the request signatures.
4.2. Update Data Signatures
Mode A dynamic secure zones require that the update requester provide
SIG RRs that will authenticate the after-update state of all RR sets
that are changed by the update and are non-empty after the update.
These SIG RRs appear in the request as RRs to be added and the
request must delete any previous data SIG RRs that are invalidated by
the request.
In Mode B dynamic secure zones, all zone data is authenticated by
zone key SIG RRs. In this case, data signatures need not be included
with the update. A prospective updater can determine which mode an
updatable secure zone is using by examining the signatory field bits
of the zone KEY RR or RRs (see section 3.2).
Donald E. Eastlake 3rd [Page 13]
INTERNET-DRAFT Secure DNS Update August 1998
5. Security Considerations
Any secure zone permitting dynamic updates is inherently less secure
than a static secure zone maintained off line as recommended in
draft-ietf-dnssec-secops-*.txt. If nothing else, secure dynamic
update requires on line change to and re-signing of the zone SOA
resource record (RR) to increase the SOA serial number. This means
that compromise of the primary server host could lead to arbitrary
serial number changes.
Isolation of dynamic RRs to separate zones from those holding most
static RRs can limit the damage that could occur from breach of a
dynamic zone's security.
6. IANA Considerations
Allocations of values of the KEY RR Signatory field described herein
as "reserved" requires an IETF consensus.
Donald E. Eastlake 3rd [Page 14]
INTERNET-DRAFT Secure DNS Update August 1998
References
[RFC1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987.
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987.
[RFC2065] - Domain Name System Security Extensions. D. Eastlake, 3rd,
C. Kaufman. January 1997
[RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE).
P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997.
[RFC2137] - Secure Domain Name System Dynamic Update. D. Eastlake.
April 1997.
draft-ietf-dnsind-tsig-*.txt
draft-ietf-dnssec-secext2-*.txt.
draft-ietf-dnssec-secops-*.txt.
Author's Address
Donald E. Eastlake, 3rd
Transfinite Systems Company
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 978-287-4877
+1 978-371-7148 (fax)
email: dee3@torque.pothole.com
Expiration and File Name
This draft expires February 1999.
Its file name is draft-ietf-dnssec-update2-00.txt.
Donald E. Eastlake 3rd [Page 15]

2176
doc/draft/draft-ietf-ipngwg-bsd-api-new-06.txt Normal file
View file

File diff suppressed because it is too large Load diff

838
doc/draft/draft-ietf-ipngwg-dns-lookups-03.txt Normal file
View file

@ -0,0 +1,838 @@
IPng Working Group Matt Crawford
Internet Draft Fermilab
Christian Huitema
Susan Thomson
Bellcore
December 15, 1998
DNS Extensions to Support IP Version 6
<draft-ietf-ipngwg-dns-lookups-03.txt>
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.
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."
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).
Distribution of this memo is unlimited.
1. Abstract
This document defines the changes that need to be made to the Domain
Name System to support hosts running IP version 6 (IPv6). The
changes include a new resource record type to store an IPv6 address
in a manner which expedites network renumbering, and updated
definitions of existing query types that return Internet addresses
as part of additional section processing.
For lookups keyed on IPv6 addresses (often called reverse lookups),
this document defines a new domain to hold the top-level delegation
information and a zone structure which allows a zone to be used
without modification for parallel copies of an address space (as for
a multihomed provider or site) and across network renumbering
events.
Expires June 20, 1999 Crawford et al. [Page 1]
Internet Draft IPv6 DNS December 15, 1998
2. Introduction
Current support for the storage of Internet addresses in the Domain
Name System (DNS) [DNSCF, DNSIS] cannot easily be extended to
support IPv6 addresses [AARCH] since applications assume that
address queries return 32-bit IPv4 addresses only. In addition,
maintenance of address information in the DNS is one of several
obstacles which have prevented site and provider renumbering from
being feasible.
To support the storage of IPv6 addresses without impeding
renumbering we define the following extensions.
o A new resource record type, "A6", is defined to map a domain
name to an IPv6 address, with a provision for indirection for
leading "prefix" bits.
o Existing queries that perform additional section processing to
locate IPv4 addresses are redefined to do that processing for
both IPv4 and IPv6 addresses.
o A new domain, IP6.INT, is defined to support lookups based on
IPv6 address.
o A new prefix-delegation method is defined, relying on new DNS
features [BITLBL, DNAME].
The changes are designed to be compatible with existing
applications. The existing support for IPv4 addresses is retained.
Transition issues related to the coexistence of both IPv4 and IPv6
addresses in DNS are discussed in [TRANS].
This memo proposes a replacement for the specification in RFC 1886
and a departure from current implementation practices. The changes
are designed to facilitate network renumbering and multihoming.
Domains employing the A6 record for IPv6 addresses can have
automatically-genrerated AAAA records to ease transition. It is
expected that after a reasonable period, RFC 1886 will become
Historic.
The next three major sections of this document are an overview of
the facilities defined or employed by this specification, the
specification itself, and examples of use.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KWORD]. The key
word "SUGGESTED" signifies a strength between MAY and SHOULD: it is
Expires June 20, 1999 Crawford et al. [Page 2]
Internet Draft IPv6 DNS December 15, 1998
believed that compliance with the suggestion has tangible benefits
in most instances.
3. Overview
This section provides an overview of the DNS facilities for storage
of IPv6 addresses and for lookups based on IPv6 address, including
those defined here and elsewhere.
3.1. Name-to-Address Lookup
IPv6 addresses are stored in one or more A6 resource records. A
single A6 record may include a complete IPv6 address, or a
contiguous portion of an address and information leading to one or
more prefixes. Prefix information comprises a prefix length and a
DNS name which is in turn the owner of one or more A6 records
defining the prefix or prefixes which are needed to form one or more
complete IPv6 addresses. When the prefix length is zero, no DNS
name is present and all the leading bits of the address are
significant. There may be multiples levels of indirection and the
existence of multiple A6 records at any level multiplies the number
of IPv6 addresses which are formed.
An application looking up an IPv6 address will generally cause the
DNS resolver to access several A6 records, and multiple IPv6
addresses may be returned even if the queried name was the owner of
only one A6 record. The authenticity [DNSSEC] of the returned
address(es) cannot be directly verified. The A6 records which
contributed to the address(es) may of course be verified if signed.
3.2. Underlying Mechanisms for Reverse Lookups
This section describes the new DNS features which this document
exploits. This section is an overview, not a specification of those
features. The reader is directed to the referenced documents for
more details on each.
3.2.1. Delegation on Arbitrary Boundaries
This new scheme for reverse lookups relies on a new type of DNS
label called the "bit-string label" [BITLBL]. This label compactly
represents an arbitrary string of bits which is treated as a
hierarchical sequence of one-bit domain labels. Resource records
can thereby be stored on arbitrary bit-boundaries.
Expires June 20, 1999 Crawford et al. [Page 3]
Internet Draft IPv6 DNS December 15, 1998
Examples in section 6 will employ the following textual
representation for bit-string labels, which is a subset of the
syntax defined in [BITLBL]. A base indicator "x" for hexadecimal
and a sequence of hexadecimal digits is enclosed between "\[" and
"]". The bits denoted by the digits represent a sequence of one-bit
domain labels ordered from most to least significant. (This is the
opposite of the order they would appear if listed one bit at a time,
but it appears to be a convenient notation.) The digit string may
be followed by a slash ("/") and a decimal count. If omitted, the
implicit count is equal to four times the number of hexadecimal
digits.
Consecutive bit-string labels are equivalent (up to the limit
imposed by the size of the bit count field) to a single bit-string
label containing all the bits of the consecutive labels in the
proper order. As an example, either of the following domain names
could be used in a QCLASS=IN, QTYPE=PTR query to find the name of
the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
\[x3FFE07C0004000090A0020FFFE812B32/128].IP6.INT.
\[x0A0020FFFE812B32/64].\[x0009/16].
\[x07C00040/32].\[xFFF0/13].\[x2/3].IP6.INT.
Note that bits are left-justified in a hexadecimal string.
3.2.2. Reusable Zones
DNS address space delegation is implemented not by zone cuts and NS
records, but by a new analogue to the CNAME record, called the DNAME
resource record [DNAME]. The DNAME record provides alternate naming
to an entire subtree of the domain name space, rather than to a
single node. It causes some suffix of a queried name to be
substituted with a name from the DNAME record's RDATA.
For example, a resolver or server providing recursion, while looking
up a QNAME a.b.c.d.e.f may encounter a DNAME record
d.e.f. DNAME w.xy.
which will cause it to look for a.b.c.w.xy.
Expires June 20, 1999 Crawford et al. [Page 4]
Internet Draft IPv6 DNS December 15, 1998
4. Specifications
4.1. The A6 Record Type
The A6 record type is specific to the IN (Internet) class and has
type number 38 (decimal).
4.1.1. Format
The RDATA portion of the A6 record contains two or three fields.
+-----------+------------------+-------------------+
|Prefix len.| Address suffix | Prefix name |
| (1 octet) | (0..16 octets) | (0..255 octets) |
+-----------+------------------+-------------------+
o A prefix length, encoded as an eight-bit unsigned integer with
value between 0 and 128 inclusive.
o An IPv6 address suffix, encoded in network order (high-order
octet first). There MUST be exactly enough octets in this field
to contain a number of bits equal to 128 minus prefix length,
with 0 to 7 leading pad bits to make this field an integral
number of octets.
o The name of the prefix, encoded as a domain name. This name
MUST NOT be compressed unless some future specification permits
it, and then possibly only under certain circumstances.
The domain name component SHALL NOT be present if the prefix length
is zero. The address suffix component SHALL NOT be present if the
prefix length is 128.
It is SUGGESTED that an A6 record intended for use as a prefix for
other A6 records have all the insignificant trailing bits in its
address suffix field set to zero.
4.1.2. Processing
A query with QTYPE=A6 causes type A and type AAAA additional section
processing for the QNAME, and type A6 and type NS additional section
processing for the DNS name, if present, in its RDATA field. When
and if the type AAAA record becomes deprecated, the type AAAA
additional section processing for type A6 queries SHOULD be omitted
Expires June 20, 1999 Crawford et al. [Page 5]
Internet Draft IPv6 DNS December 15, 1998
from new implementations of this specification.
It is an error for a A6 record with prefix length L1 > 0 to refer to
a domain name which owns a A6 record with a prefix length L2 > L1.
If such a situation is encountered by a resolver, the A6 record with
the offending (larger) prefix length MUST be ignored. Robustness
precludes signalling an error if addresses can still be formed from
valid A6 records, but it is SUGGESTED that zone maintainers from
time to time check all the A6 records their zones reference.
4.1.3. Textual Representation
The textual representation of the RDATA portion of the A6 resource
record in a zone file comprises two or three fields separated by
whitespace.
o A prefix length, represented as a decimal number between 0 and
128 inclusive,
o the textual representation of the host's IPv6 address as defined
in [AARCH], or a suffix of that address, and
o a domain name, if the prefix length is not zero.
The domain name MUST be absent if the prefix length is zero. The
IPv6 address MAY be be absent if the prefix length is 128. A number
of leading address bits equal to the prefix length SHOULD be zero,
either implicitly (through the :: notation) or explicitly, as
specified in section 4.1.1.
4.1.4. Name Resolution Procedure
To obtain the IPv6 address or addresses which belong to a given
hostname, a DNS client MUST obtain one or more complete chains of A6
records, each chain beginning with a record owned by the given
hostname and including a record owned by the prefix name in that
record, and so on recursively, ending with an A6 record with a
prefix length of zero. One IPv6 address is formed from one such
chain by taking the value of each bit position from the earliest A6
record which validly covers that position, as indicated by the
prefix length. The set of all IPv6 records for the given hostname
comprises the addresses formed from all complete chains of A6
records beginning at that hostname, discarding records which have
invalid prefix lengths as defined in section 4.1.2.
Expires June 20, 1999 Crawford et al. [Page 6]
Internet Draft IPv6 DNS December 15, 1998
4.2. Zone Structure for Reverse Lookups
Very little of the new scheme's data actually appears under IP6.INT;
only the first level of delegation needs to be under that domain.
More levels of delegation could be placed under IP6.INT if some
top-level delegations were done via NS records instead of DNAME
records, but this would incur some cost in renumbering ease at the
level of TLAs [AGGR]. Therefore, it is declared here that all
address space delegations SHOULD be done by the DNAME mechanism
rather than NS.
In addition, since uniformity in deployment will simplify
maintenance of address delegations, it is SUGGESTED that address and
prefix information be stored immediately below a DNS label "IP6".
Stated another way, conformance with this suggestion would mean that
"IP6" is the first label in the RDATA field of DNAME records which
support IPv6 reverse lookups.
When any "reserved" or "must be zero" bits are adjacent to a
delegation boundary, the higher-level entity MUST retain those bits
in its own control and delegate only the bits over which the lower-
level entity has authority.
To find the name of a node given its IPv6 address, a DNS client MUST
perform a query with QCLASS=IN, QTYPE=PTR on the name formed from
the 128 bit address as one or more bit-string labels [BITLBL],
followed by the two standard labels "IP6.INT". If recursive service
was not obtained from a server and the desired PTR record was not
returned, the resolver MUST handle returned DNAME records as
specified in [DNAME] and iterate.
5. Modifications to Existing Query Types
All existing query types that perform type A additional section
processing, i.e. the name server (NS), mail exchange (MX), and
mailbox (MB) query types, and the experimental AFS data base (AFSDB)
and route through (RT) types, must be redefined to perform both type
A and type A6 additional section processing. These new definitions
mean that a name server may add any relevant IPv4 addresses and any
relevant A6 records available locally to the additional section of a
response when processing any one of the above queries.
6. Usage Illustrations
This section provides examples of use of the mechanisms defined in
the previous section. All addresses and domains mentioned here are
Expires June 20, 1999 Crawford et al. [Page 7]
Internet Draft IPv6 DNS December 15, 1998
intended to be fictitious and for illustrative purposes only.
Example delegations will be on 4-bit boundaries solely for
readability; this specification is indifferent to bit alignment.
Use of the IPv6 aggregatable address format [AGGR] is assumed in the
examples.
6.1. A6 Record Chains
Let's take the example of a site X that is multi-homed to two
"intermediate" providers A and B. The provider A is itself multi-
homed to two "transit" providers, C and D. The provider B gets its
transit service from a single provider, E. For simplicity suppose
that C, D and E all belong to the same top-level aggregate (TLA)
with identifier (including format prefix) '2345', and the TLA
authority at ALPHA-TLA.ORG assigns to C, D and E respectively the
next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28
and 2345:000E::/32.
C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
B.
A assigns to X the subscriber identification '11' and B assigns the
subscriber identification '22'. As a result, the site X inherits
three address prefixes:
o 2345:00C1:CA11::/48 from A, for routes through C.
o 2345:00D2:DA11::/48 from A, for routes through D.
o 2345:000E:EB22::/48 from B, for routes through E.
Let us suppose that N is a node in the site X, that it is assigned
to subnet number 1 in this site, and that it uses the interface
identifier '1234:5678:9ABC:DEF0'. In our configuration, this node
will have three addresses:
o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
We will assume that the site X is represented in the DNS by the
domain name X.EXAMPLE, while A, B, C, D and E are represented by
A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we
assume a subdomain "IP6" that will hold the corresponding prefixes.
The node N is identified by the domain name N.X.EXAMPLE. The
Expires June 20, 1999 Crawford et al. [Page 8]
Internet Draft IPv6 DNS December 15, 1998
following records would then appear in X's DNS.
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
And elsewhere there would appear
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
Several more-or-less arbitrary assumptions are reflected in the
above structure. All of the following choices could have been made
differently, according to someone's notion of convenience or an
agreement between two parties.
First, that site X has chosen to put subnet information in a
separate A6 record rather than incorporate it into each node's
A6 records.
Second, that site X is referred to as "SUBSCRIBER-X" by both of
its providers A and B.
Third, that site X chose to indirect its provider information
through A6 records at IP6.X.EXAMPLE containing no significant
bits. An alternative would have been to replicate each subnet
record for each provider.
Fourth, B and E used a slightly different prefix naming
convention between themselves than did A, C and D. Each
hierarchical pair of network entities must arrange this naming
between themselves.
Fifth, that the upward prefix referral chain topped out at
Expires June 20, 1999 Crawford et al. [Page 9]
Internet Draft IPv6 DNS December 15, 1998
ALPHA-TLA.ORG. There could have been another level which
assigned the TLA values and holds A6 records containing those
bits.
Finally, the above structure reflects an assumption that address
fields assigned by a given entity are recorded only in A6 records
held by that entity. Those bits could be entered into A6 records in
the lower-level entity's zone instead, thus:
IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET.
IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET.
IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET.
and so on.
Or the higher-level entity could hold both sorts of A6 records and
allow the lower-level entity to choose to record a copy of the
delegated bits or refer to the higher-level entity's copy. But the
general rule of avoiding data duplication suggests that the proper
place to store assigned values is with the entity that assigned
them.
It is possible, but not necessarily recommended, for a zone
maintainer to forego the renumbering support afforded by the chaning
of A6 records and to record entire IPv6 addresses within one zone
file.
6.2. Reverse Mapping Zones
Supposing that address space assignments in the TLAs with Format
Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
the IP6.INT zone would include
$ORIGIN IP6.INT.
\[x234500/24] DNAME IP6.ALPHA-TLA.ORG.
\[x267800/24] DNAME IP6.BRAVO-TLA.ORG.
\[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.
Eight trailing zero bits have been included in each TLA ID to
reflect the eight reserved bits in the current aggregatable global
unicast addresses format [AGGR].
Expires June 20, 1999 Crawford et al. [Page 10]
Internet Draft IPv6 DNS December 15, 1998
6.2.1. The TLA level
ALPHA-TLA's assignments to network providers C, D and E are
reflected in the reverse data as follows.
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
\[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET.
\[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET.
6.2.2. The ISP level
The providers A through E carry the following delegation information
in their zone files.
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
\[x2DA/12].IP6.D.NET. DNAME IP6.A.NET.
\[xEB/8].IP6.E.NET. DNAME IP6.B.NET.
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
\[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE.
Note that some domain names appear in the RDATA of more than one
DNAME record. In those cases, one zone is being used to map
multiple prefixes.
6.2.3. The Site Level
Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
name translations. This domain is now referenced by two different
DNAME records held by two different providers.
$ORIGIN IP6.X.EXAMPLE.
\[x0001/16] DNAME SUBNET-1
\[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
and so on.
SUBNET-1 need not have been named in a DNAME record; the subnet bits
could have been joined with the interface identifier. But if
subnets are treated alike in both the A6 records and in the reverse
zone, it will always be possible to keep the forward and reverse
definition data for each prefix in one zone.
Expires June 20, 1999 Crawford et al. [Page 11]
Internet Draft IPv6 DNS December 15, 1998
6.3. Lookups
A DNS resolver looking for a hostname for the address
2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
DNAME records shown above and would form new queries. Assuming that
it began the process knowing servers for IP6.INT, but that no server
it consulted provided recursion and none had other useful additional
information cached, the sequence of queried names and responses
would be (all with QCLASS=IN, QTYPE=PTR):
To a server for IP6.INT:
QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.INT.
Answer:
\[x234500/24].IP6.INT. DNAME IP6.ALPHA-TLA.ORG.
To a server for IP6.ALPHA-TLA.ORG:
QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
Answer:
\[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
To a server for IP6.C.NET.:
QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
Answer:
\[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
To a server for IP6.A.NET.:
QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
Answer:
\[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
To a server for IP6.X.EXAMPLE.:
QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
Answer:
\[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
\[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
All the DNAME (and NS) records acquired along the way can be cached
to expedite resolution of addresses topologically near to this
address. And if another global address of N.X.EXAMPLE were resolved
within the TTL of the final PTR record, that record would not have
to be fetched again.
Expires June 20, 1999 Crawford et al. [Page 12]
Internet Draft IPv6 DNS December 15, 1998
6.4. Deployment Note
In the illustrations in section 6.1, hierarchically adjacent
entities, such as a network provider and a customer, must agree on a
DNS name which will own the definition of the delegated prefix(es).
One simple convention would be to use a bit-string label
representing exactly the bits which are assigned to the lower-level
entity by the higher. For example, "SUBSCRIBER-X" could be replaced
by "\[x11/8]". This would place the A6 record(s) defining the
delegated prefix at exactly the same point in the DNS tree as the
DNAME record associated with that delegation. The cost of this
simplification is that the lower-level zone must update its upward-
pointing A6 records when it is renumbered. This cost may be found
quite acceptable in practice.
7. Transition from AAAA Records
Administrators of zones which contain A6 records can easily
accommodate deployed resolvers which understand AAAA records but not
A6 records. Such administrators can do automatic generation of AAAA
records for all of a zone's names which own A6 records by a process
which mimics the resolution of a hostname to an IPv6 address (see
section 4.1.4). Attention must be paid to the TTL assigned to a
generated AAAA record, which MUST be no more than the minimum of the
TTLs of the A6 records that were used to form the IPv6 address in
that records If the zone is secure [DNSSEC], the generated AAAA
records SHOULD be signed along with the rest of the zone data.
A zone-specific heuristic MAY be used to avoid generation of AAAA
records for A6 records which record prefixes, although such
superfluous records would be relatively few in number and harmless.
Examples of such heuristics include omitting A6 records with a
prefix length less than the largest value found in the zone file, or
records with an address suffix field with a certain number of
trailing zero bits.
A server providing recursive service MAY be configurable to
synthesize AAAA records from A6 records in response to clients' AAAA
queries.
8. Security Considerations
The signing authority [DNSSEC] for the A6 records which determine an
IPv6 address is distributed among several entities, reflecting the
delegation path of the address space which that address occupies.
DNS Security is fully applicable to bit-string labels and DNAME
Expires June 20, 1999 Crawford et al. [Page 13]
Internet Draft IPv6 DNS December 15, 1998
records. However, just as with IPv4's IN-ADDR.ARPA, authentication
of data in the reverse zones is not equivalent to authentication of
any forward data.
9. Acknowledgments
The authors would like to thank the following persons for valuable
discussions and reviews: Jim Bound, Steve Deering, Robert Elz, Bob
Fink, Olafur Gudmundsson, Bob Hinden, Bill Manning, Mike O'Dell and
Ken Powell.
10. References
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373.
[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6
Aggregatable Global Unicast Address Format". RFC 2374.
[BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
currently draft-ietf-dnsind-binary-labels-03.txt.
[DNAME] Crawford, M., "Non-Terminal DNS Name Redirection",
currently draft-ietf-dnsind-dname-00.txt.
[DNSCF] Mockapetris, P. V., "Domain names - concepts and
facilities", RFC 1034.
[DNSIS] Mockapetris, P. V., "Domain names - implementation and
specification", RFC 1035.
[DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System
Security Extensions", RFC 2065.
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[LOCOMP] Koch, P., "A New Scheme for the Compression of Domain
Names", currently draft-ietf-dnsind-local-compression-
01.txt.
[TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
Expires June 20, 1999 Crawford et al. [Page 14]
Internet Draft IPv6 DNS December 15, 1998
IPv6 Hosts and Routers", RFC 1933.
11. Authors' Addresses
Matt Crawford Christian Huitema Susan Thomson
Fermilab Bellcore Bellcore
MS 368 MCC 1J236B MCC 1C259B
PO Box 500 445 South Street 445 South Street
Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960
USA USA USA
+1 630 840-3461 +1 201 829-4266 +1 201 829-4514
crawdad@fnal.gov huitema@bellcore.com set@bellcore.com
Expires June 20, 1999 Crawford et al. [Page 15]

781
doc/rfc/rfc1032.txt Normal file
View file

@ -0,0 +1,781 @@
Network Working Group M. Stahl
Request for Comments: 1032 SRI International
November 1987
DOMAIN ADMINISTRATORS GUIDE
STATUS OF THIS MEMO
This memo describes procedures for registering a domain with the
Network Information Center (NIC) of Defense Data Network (DDN), and
offers guidelines on the establishment and administration of a domain
in accordance with the requirements specified in RFC-920. It is
intended for use by domain administrators. This memo should be used
in conjunction with RFC-920, which is an official policy statement of
the Internet Activities Board (IAB) and the Defense Advanced Research
Projects Agency (DARPA). Distribution of this memo is unlimited.
BACKGROUND
Domains are administrative entities that provide decentralized
management of host naming and addressing. The domain-naming system
is distributed and hierarchical.
The NIC is designated by the Defense Communications Agency (DCA) to
provide registry services for the domain-naming system on the DDN and
DARPA portions of the Internet.
As registrar of top-level and second-level domains, as well as
administrator of the root domain name servers on behalf of DARPA and
DDN, the NIC is responsible for maintaining the root server zone
files and their binary equivalents. In addition, the NIC is
responsible for administering the top-level domains of "ARPA," "COM,"
"EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it
becomes feasible for other appropriate organizations to assume those
responsibilities.
It is recommended that the guidelines described in this document be
used by domain administrators in the establishment and control of
second-level domains.
THE DOMAIN ADMINISTRATOR
The role of the domain administrator (DA) is that of coordinator,
manager, and technician. If his domain is established at the second
level or lower in the tree, the DA must register by interacting with
the management of the domain directly above his, making certain that
Stahl [Page 1]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
his domain satisfies all the requirements of the administration under
which his domain would be situated. To find out who has authority
over the name space he wishes to join, the DA can ask the NIC
Hostmaster. Information on contacts for the top-level and second-
level domains can also be found on line in the file NETINFO:DOMAIN-
CONTACTS.TXT, which is available from the NIC via anonymous FTP.
The DA should be technically competent; he should understand the
concepts and procedures for operating a domain server, as described
in RFC-1034, and make sure that the service provided is reliable and
uninterrupted. It is his responsibility or that of his delegate to
ensure that the data will be current at all times. As a manager, the
DA must be able to handle complaints about service provided by his
domain name server. He must be aware of the behavior of the hosts in
his domain, and take prompt action on reports of problems, such as
protocol violations or other serious misbehavior. The administrator
of a domain must be a responsible person who has the authority to
either enforce these actions himself or delegate them to someone
else.
Name assignments within a domain are controlled by the DA, who should
verify that names are unique within his domain and that they conform
to standard naming conventions. He furnishes access to names and
name-related information to users both inside and outside his domain.
He should work closely with the personnel he has designated as the
"technical and zone" contacts for his domain, for many administrative
decisions will be made on the basis of input from these people.
THE DOMAIN TECHNICAL AND ZONE CONTACT
A zone consists of those contiguous parts of the domain tree for
which a domain server has complete information and over which it has
authority. A domain server may be authoritative for more than one
zone. The domain technical/zone contact is the person who tends to
the technical aspects of maintaining the domain's name server and
resolver software, and database files. He keeps the name server
running, and interacts with technical people in other domains and
zones to solve problems that affect his zone.
POLICIES
Domain or host name choices and the allocation of domain name space
are considered to be local matters. In the event of conflicts, it is
the policy of the NIC not to get involved in local disputes or in the
local decision-making process. The NIC will not act as referee in
disputes over such matters as who has the "right" to register a
particular top-level or second-level domain for an organization. The
NIC considers this a private local matter that must be settled among
Stahl [Page 2]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
the parties involved prior to their commencing the registration
process with the NIC. Therefore, it is assumed that the responsible
person for a domain will have resolved any local conflicts among the
members of his domain before registering that domain with the NIC.
The NIC will give guidance, if requested, by answering specific
technical questions, but will not provide arbitration in disputes at
the local level. This policy is also in keeping with the distributed
hierarchical nature of the domain-naming system in that it helps to
distribute the tasks of solving problems and handling questions.
Naming conventions for hosts should follow the rules specified in
RFC-952. From a technical standpoint, domain names can be very long.
Each segment of a domain name may contain up to 64 characters, but
the NIC strongly advises DAs to choose names that are 12 characters
or fewer, because behind every domain system there is a human being
who must keep track of the names, addresses, contacts, and other data
in a database. The longer the name, the more likely the data
maintainer is to make a mistake. Users also will appreciate shorter
names. Most people agree that short names are easier to remember and
type; most domain names registered so far are 12 characters or fewer.
Domain name assignments are made on a first-come-first-served basis.
The NIC has chosen not to register individual hosts directly under
the top-level domains it administers. One advantage of the domain
naming system is that administration and data maintenance can be
delegated down a hierarchical tree. Registration of hosts at the
same level in the tree as a second-level domain would dilute the
usefulness of this feature. In addition, the administrator of a
domain is responsible for the actions of hosts within his domain. We
would not want to find ourselves in the awkward position of policing
the actions of individual hosts. Rather, the subdomains registered
under these top-level domains retain the responsibility for this
function.
Countries that wish to be registered as top-level domains are
required to name themselves after the two-letter country code listed
in the international standard ISO-3166. In some cases, however, the
two-letter ISO country code is identical to a state code used by the
U.S. Postal Service. Requests made by countries to use the three-
letter form of country code specified in the ISO-3166 standard will
be considered in such cases so as to prevent possible conflicts and
confusion.
Stahl [Page 3]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
HOW TO REGISTER
Obtain a domain questionnaire from the NIC hostmaster, or FTP the
file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA.
Fill out the questionnaire completely. Return it via electronic mail
to HOSTMASTER@SRI-NIC.ARPA.
The APPENDIX to this memo contains the application form for
registering a top-level or second-level domain with the NIC. It
supersedes the version of the questionnaire found in RFC-920. The
application should be submitted by the person administratively
responsible for the domain, and must be filled out completely before
the NIC will authorize establishment of a top-level or second-level
domain. The DA is responsible for keeping his domain's data current
with the NIC or with the registration agent with which his domain is
registered. For example, the CSNET and UUCP managements act as
domain filters, processing domain applications for their own
organizations. They pass pertinent information along periodically to
the NIC for incorporation into the domain database and root server
files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT
outlines this procedure. It is highly recommended that the DA review
this information periodically and provide any corrections or
additions. Corrections should be submitted via electronic mail.
WHICH DOMAIN NAME?
The designers of the domain-naming system initiated several general
categories of names as top-level domain names, so that each could
accommodate a variety of organizations. The current top-level
domains registered with the DDN Network Information Center are ARPA,
COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country
domains. To join one of these, a DA needs to be aware of the purpose
for which it was intended.
"ARPA" is a temporary domain. It is by default appended to the
names of hosts that have not yet joined a domain. When the system
was begun in 1984, the names of all hosts in the Official DoD
Internet Host Table maintained by the NIC were changed by adding
of the label ".ARPA" in order to accelerate a transition to the
domain-naming system. Another reason for the blanket name changes
was to force hosts to become accustomed to using the new style
names and to modify their network software, if necessary. This
was done on a network-wide basis and was directed by DCA in DDN
Management Bulletin No. 22. Hosts that fall into this domain will
eventually move to other branches of the domain tree.
Stahl [Page 4]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
"COM" is meant to incorporate subdomains of companies and
businesses.
"EDU" was initiated to accommodate subdomains set up by
universities and other educational institutions.
"GOV" exists to act as parent domain for subdomains set up by
government agencies.
"MIL" was initiated to act as parent to subdomains that are
developed by military organizations.
"NET" was introduced as a parent domain for various network-type
organizations. Organizations that belong within this top-level
domain are generic or network-specific, such as network service
centers and consortia. "NET" also encompasses network
management-related organizations, such as information centers and
operations centers.
"ORG" exists as a parent to subdomains that do not clearly fall
within the other top-level domains. This may include technical-
support groups, professional societies, or similar organizations.
One of the guidelines in effect in the domain-naming system is that a
host should have only one name regardless of what networks it is
connected to. This implies, that, in general, domain names should
not include routing information or addresses. For example, a host
that has one network connection to the Internet and another to BITNET
should use the same name when talking to either network. For a
description of the syntax of domain names, please refer to Section 3
of RFC-1034.
VERIFICATION OF DATA
The verification process can be accomplished in several ways. One of
these is through the NIC WHOIS server. If he has access to WHOIS,
the DA can type the command "whois domain <domain name><return>".
The reply from WHOIS will supply the following: the name and address
of the organization "owning" the domain; the name of the domain; its
administrative, technical, and zone contacts; the host names and
network addresses of sites providing name service for the domain.
Stahl [Page 5]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
Example:
@whois domain rice.edu<Return>
Rice University (RICE-DOM)
Advanced Studies and Research
Houston, TX 77001
Domain Name: RICE.EDU
Administrative Contact:
Kennedy, Ken (KK28) Kennedy@LLL-CRG.ARPA (713) 527-4834
Technical Contact, Zone Contact:
Riffle, Vicky R. (VRR) rif@RICE.EDU
(713) 527-8101 ext 3844
Domain servers:
RICE.EDU 128.42.5.1
PENDRAGON.CS.PURDUE.EDU 128.10.2.5
Alternatively, the DA can send an electronic mail message to
SERVICE@SRI-NIC.ARPA. In the subject line of the message header, the
DA should type "whois domain <domain name>". The requested
information will be returned via electronic mail. This method is
convenient for sites that do not have access to the NIC WHOIS
service.
The initial application for domain authorization should be submitted
via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA. The
questionnaire described in the appendix may be used or a separate
application can be FTPed from host SRI-NIC.ARPA. The information
provided by the administrator will be reviewed by hostmaster
personnel for completeness. There will most likely be a few
exchanges of correspondence via electronic mail, the preferred method
of communication, prior to authorization of the domain.
HOW TO GET MORE INFORMATION
An informational table of the top-level domains and their root
servers is contained in the file NETINFO:DOMAINS.TXT online at SRI-
NIC.ARPA. This table can be obtained by FTPing the file.
Alternatively, the information can be acquired by opening a TCP or
UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA,
and invoking the command "ALL-DOM".
Stahl [Page 6]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
The following online files, all available by FTP from SRI-NIC.ARPA,
contain pertinent domain information:
- NETINFO:DOMAINS.TXT, a table of all top-level domains and the
network addresses of the machines providing domain name
service for them. It is updated each time a new top-level
domain is approved.
- NETINFO:DOMAIN-INFO.TXT contains a concise list of all
top-level and second-level domain names registered with the
NIC and is updated monthly.
- NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the
top level and second-level domains, but includes the
administrative, technical and zone contacts for each as well.
- NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be
completed before registering a top-level or second-level
domain.
For either general or specific information on the domain system, do
one or more of the following:
1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA
2. Call the toll-free NIC hotline at (800) 235-3155
3. Use FTP to get background RFCs and other files maintained
online at the NIC. Some pertinent RFCs are listed below in
the REFERENCES section of this memo.
Stahl [Page 7]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
REFERENCES
The references listed here provide important background information
on the domain-naming system. Path names of the online files
available via anonymous FTP from the SRI-NIC.ARPA host are noted in
brackets.
1. Defense Communications Agency DDN Defense Communications
System, DDN Management Bulletin No. 22, Domain Names
Transition, March 1984.
[ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]
2. Defense Communications Agency DDN Defense Communications
System, DDN Management Bulletin No. 32, Phase I of the Domain
Name Implementation, January 1987.
[ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]
3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname
Server", RFC-953, DDN Network Information Center, SRI
International, October 1985. [ RFC:RFC953.TXT ]
4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD
Internet Host Table Specification", RFC-952, DDN Network
Information Center, SRI International, October 1985.
[ RFC:RFC952.TXT ]
5. ISO, "Codes for the Representation of Names of Countries",
ISO-3166, International Standards Organization, May 1981.
[ Not online ]
6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031,
Mitre Corporation, October 1987. [ RFC:RFC1031.TXT ]
7. Lottor, M.K., "Domain Administrators Operations Guide",
RFC-1033, DDN Network Information Center, SRI International,
July 1987. [ RFC:RFC1033.TXT ]
8. Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC-1034, USC Information Sciences Institute, October 1987.
[ RFC:RFC1034.TXT ]
9. Mockapetris, P., "Domain Names - Implementation and
Specification", RFC-1035, USC Information Sciences Institute,
October 1987. [ RFC:RFC1035.TXT ]
10. Mockapetris, P., "The Domain Name System", Proceedings of the
IFIP 6.5 Working Conference on Computer Message Services,
Nottingham, England, May 1984. Also as ISI/RS-84-133, June
Stahl [Page 8]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
1984. [ Not online ]
11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server
Design for Distributed Systems", Proceedings of the Seventh
International Conference on Computer Communication, October
30 to November 3 1984, Sidney, Australia. Also as
ISI/RS-84-132, June 1984. [ Not online ]
12. Partridge, C., "Mail Routing and the Domain System", RFC-974,
CSNET-CIC, BBN Laboratories, January 1986.
[ RFC:RFC974.TXT ]
13. Postel, J., "The Domain Names Plan and Schedule", RFC-881,
USC Information Sciences Institute, November 1983.
[ RFC:RFC881.TXT ]
14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010
USC Information Sciences Institute, May 1986.
[ RFC:RFC1010.TXT ]
15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020,
SRI, November 1987.
[ RFC:RFC1020.TXT ]
Stahl [Page 9]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
APPENDIX
The following questionnaire may be FTPed from SRI-NIC.ARPA as
NETINFO:DOMAIN-TEMPLATE.TXT.
---------------------------------------------------------------------
To establish a domain, the following information must be sent to the
NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
NOTE: The key people must have electronic mailboxes and NIC
"handles," unique NIC database identifiers. If you have access to
"WHOIS", please check to see if you are registered and if so, make
sure the information is current. Include only your handle and any
changes (if any) that need to be made in your entry. If you do not
have access to "WHOIS", please provide all the information indicated
and a NIC handle will be assigned.
(1) The name of the top-level domain to join.
For example: COM
(2) The NIC handle of the administrative head of the organization.
Alternately, the person's name, title, mailing address, phone number,
organization, and network mailbox. This is the contact point for
administrative and policy questions about the domain. In the case of
a research project, this should be the principal investigator.
For example:
Administrator
Organization The NetWorthy Corporation
Name Penelope Q. Sassafrass
Title President
Mail Address The NetWorthy Corporation
4676 Andrews Way, Suite 100
Santa Clara, CA 94302-1212
Phone Number (415) 123-4567
Net Mailbox Sassafrass@ECHO.TNC.COM
NIC Handle PQS
(3) The NIC handle of the technical contact for the domain.
Alternately, the person's name, title, mailing address, phone number,
organization, and network mailbox. This is the contact point for
problems concerning the domain or zone, as well as for updating
information about the domain or zone.
Stahl [Page 10]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
For example:
Technical and Zone Contact
Organization The NetWorthy Corporation
Name Ansel A. Aardvark
Title Executive Director
Mail Address The NetWorthy Corporation
4676 Andrews Way, Suite 100
Santa Clara, CA. 94302-1212
Phone Number (415) 123-6789
Net Mailbox Aardvark@ECHO.TNC.COM
NIC Handle AAA2
(4) The name of the domain (up to 12 characters). This is the name
that will be used in tables and lists associating the domain with the
domain server addresses. [While, from a technical standpoint, domain
names can be quite long (programmers beware), shorter names are
easier for people to cope with.]
For example: TNC
(5) A description of the servers that provide the domain service for
translating names to addresses for hosts in this domain, and the date
they will be operational.
A good way to answer this question is to say "Our server is
supplied by person or company X and does whatever their standard
issue server does."
For example: Our server is a copy of the one operated by
the NIC; it will be installed and made operational on
1 November 1987.
(6) Domains must provide at least two independent servers for the
domain. Establishing the servers in physically separate locations
and on different PSNs is strongly recommended. A description of the
server machine and its backup, including
Stahl [Page 11]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
(a) Hardware and software (using keywords from the Assigned
Numbers RFC).
(b) Host domain name and network addresses (which host on which
network for each connected network).
(c) Any domain-style nicknames (please limit your domain-style
nickname request to one)
For example:
- Hardware and software
VAX-11/750 and UNIX, or
IBM-PC and MS-DOS, or
DEC-1090 and TOPS-20
- Host domain names and network addresses
BAR.FOO.COM 10.9.0.193 on ARPANET
- Domain-style nickname
BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)
(7) Planned mapping of names of any other network hosts, other than
the server machines, into the new domain's naming space.
For example:
BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM
BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM
BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM
(8) An estimate of the number of hosts that will be in the domain.
(a) Initially
(b) Within one year
(c) Two years
(d) Five years.
For example:
(a) Initially = 50
(b) One year = 100
(c) Two years = 200
(d) Five years = 500
Stahl [Page 12]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
(9) The date you expect the fully qualified domain name to become
the official host name in HOSTS.TXT.
Please note: If changing to a fully qualified domain name (e.g.,
FOO.BAR.COM) causes a change in the official host name of an
ARPANET or MILNET host, DCA approval must be obtained beforehand.
Allow 10 working days for your requested changes to be processed.
ARPANET sites should contact ARPANETMGR@DDN1.ARPA. MILNET sites
should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for
further instructions.
(10) Please describe your organization briefly.
For example: The NetWorthy Corporation is a consulting
organization of people working with UNIX and the C language in an
electronic networking environment. It sponsors two technical
conferences annually and distributes a bimonthly newsletter.
---------------------------------------------------------------------
This example of a completed application corresponds to the examples
found in the companion document RFC-1033, "Domain Administrators
Operations Guide."
(1) The name of the top-level domain to join.
COM
(2) The NIC handle of the administrative contact person.
NIC Handle JAKE
(3) The NIC handle of the domain's technical and zone
contact person.
NIC Handle DLE6
(4) The name of the domain.
SRI
(5) A description of the servers.
Our server is the TOPS20 server JEEVES supplied by ISI; it
will be installed and made operational on 1 July 1987.
Stahl [Page 13]
RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
(6) A description of the server machine and its backup:
(a) Hardware and software
DEC-1090T and TOPS20
DEC-2065 and TOPS20
(b) Host domain name and network address
KL.SRI.COM 10.1.0.2 on ARPANET, 128.18.10.6 on SRINET
STRIPE.SRI.COM 10.4.0.2 on ARPANET, 128.18.10.4 on SRINET
(c) Domain-style nickname
None
(7) Planned mapping of names of any other network hosts, other than
the server machines, into the new domain's naming space.
SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM
SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM
(8) An estimate of the number of hosts that will be directly within
this domain.
(a) Initially = 50
(b) One year = 100
(c) Two years = 200
(d) Five years = 500
(9) A date when you expect the fully qualified domain name to become
the official host name in HOSTS.TXT.
31 September 1987
(10) Brief description of organization.
SRI International is an independent, nonprofit, scientific
research organization. It performs basic and applied research
for government and commercial clients, and contributes to
worldwide economic, scientific, industrial, and social progress
through research and related services.
Stahl [Page 14]

1229
doc/rfc/rfc1033.txt Normal file
View file

File diff suppressed because it is too large Load diff

3077
doc/rfc/rfc1034.txt Normal file
View file

File diff suppressed because it is too large Load diff

3077
doc/rfc/rfc1035.txt Normal file
View file

File diff suppressed because it is too large Load diff

787
doc/rfc/rfc1101.txt Normal file
View file

@ -0,0 +1,787 @@
Network Working Group P. Mockapetris
Request for Comments: 1101 ISI
Updates: RFCs 1034, 1035 April 1989
DNS Encoding of Network Names and Other Types
1. STATUS OF THIS MEMO
This RFC proposes two extensions to the Domain Name System:
- A specific method for entering and retrieving RRs which map
between network names and numbers.
- Ideas for a general method for describing mappings between
arbitrary identifiers and numbers.
The method for mapping between network names and addresses is a
proposed standard, the ideas for a general method are experimental.
This RFC assumes that the reader is familiar with the DNS [RFC 1034,
RFC 1035] and its use. The data shown is for pedagogical use and
does not necessarily reflect the real Internet.
Distribution of this memo is unlimited.
2. INTRODUCTION
The DNS is extensible and can be used for a virtually unlimited
number of data types, name spaces, etc. New type definitions are
occasionally necessary as are revisions or deletions of old types
(e.g., MX replacement of MD and MF [RFC 974]), and changes described
in [RFC 973]. This RFC describes changes due to the general need to
map between identifiers and values, and a specific need for network
name support.
Users wish to be able to use the DNS to map between network names and
numbers. This need is the only capability found in HOSTS.TXT which
is not available from the DNS. In designing a method to do this,
there were two major areas of concern:
- Several tradeoffs involving control of network names, the
syntax of network names, backward compatibility, etc.
- A desire to create a method which would be sufficiently
general to set a good precedent for future mappings,
for example, between TCP-port names and numbers,
Mockapetris [Page 1]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
autonomous system names and numbers, X.500 Relative
Distinguished Names (RDNs) and their servers, or whatever.
It was impossible to reconcile these two areas of concern for network
names because of the desire to unify network number support within
existing IP address to host name support. The existing support is
the IN-ADDR.ARPA section of the DNS name space. As a result this RFC
describes one structure for network names which builds on the
existing support for host names, and another family of structures for
future yellow pages (YP) functions such as conversions between TCP-
port numbers and mnemonics.
Both structures are described in following sections. Each structure
has a discussion of design issues and specific structure
recommendations.
We wish to avoid defining structures and methods which can work but
do not because of indifference or errors on the part of system
administrators when maintaining the database. The WKS RR is an
example. Thus, while we favor distribution as a general method, we
also recognize that centrally maintained tables (such as HOSTS.TXT)
are usually more consistent though less maintainable and timely.
Hence we recommend both specific methods for mapping network names,
addresses, and subnets, as well as an instance of the general method
for mapping between allocated network numbers and network names.
(Allocation is centrally performed by the SRI Network Information
Center, aka the NIC).
3. NETWORK NAME ISSUES AND DISCUSSION
The issues involved in the design were the definition of network name
syntax, the mappings to be provided, and possible support for similar
functions at the subnet level.
3.1. Network name syntax
The current syntax for network names, as defined by [RFC 952] is an
alphanumeric string of up to 24 characters, which begins with an
alpha, and may include "." and "-" except as first and last
characters. This is the format which was also used for host names
before the DNS. Upward compatibility with existing names might be a
goal of any new scheme.
However, the present syntax has been used to define a flat name
space, and hence would prohibit the same distributed name allocation
method used for host names. There is some sentiment for allowing the
NIC to continue to allocate and regulate network names, much as it
allocates numbers, but the majority opinion favors local control of
Mockapetris [Page 2]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
network names. Although it would be possible to provide a flat space
or a name space in which, for example, the last label of a domain
name captured the old-style network name, any such approach would add
complexity to the method and create different rules for network names
and host names.
For these reasons, we assume that the syntax of network names will be
the same as the expanded syntax for host names permitted in [HR].
The new syntax expands the set of names to allow leading digits, so
long as the resulting representations do not conflict with IP
addresses in decimal octet form. For example, 3Com.COM and 3M.COM
are now legal, although 26.0.0.73.COM is not. See [HR] for details.
The price is that network names will get as complicated as host
names. An administrator will be able to create network names in any
domain under his control, and also create network number to name
entries in IN-ADDR.ARPA domains under his control. Thus, the name
for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa-
network.MIL., depending on the preferences of the owner.
3.2. Mappings
The desired mappings, ranked by priority with most important first,
are:
- Mapping a IP address or network number to a network name.
This mapping is for use in debugging tools and status displays
of various sorts. The conversion from IP address to network
number is well known for class A, B, and C IP addresses, and
involves a simple mask operation. The needs of other classes
are not yet defined and are ignored for the rest of this RFC.
- Mapping a network name to a network address.
This facility is of less obvious application, but a
symmetrical mapping seems desirable.
- Mapping an organization to its network names and numbers.
This facility is useful because it may not always be possible
to guess the local choice for network names, but the
organization name is often well known.
- Similar mappings for subnets, even when nested.
The primary application is to be able to identify all of the
subnets involved in a particular IP address. A secondary
Mockapetris [Page 3]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
requirement is to retrieve address mask information.
3.3. Network address section of the name space
The network name syntax discussed above can provide domain names
which will contain mappings from network names to various quantities,
but we also need a section of the name space, organized by network
and subnet number to hold the inverse mappings.
The choices include:
- The same network number slots already assigned and delegated
in the IN-ADDR.ARPA section of the name space.
For example, 10.IN-ADDR.ARPA for class A net 10,
2.128.IN-ADDR.ARPA for class B net 128.2, etc.
- Host-zero addresses in the IN-ADDR.ARPA tree. (A host field
of all zero in an IP address is prohibited because of
confusion related to broadcast addresses, et al.)
For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10,
0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc. Like the
first scheme, it uses in-place name space delegations to
distribute control.
The main advantage of this scheme over the first is that it
allows convenient names for subnets as well as networks. A
secondary advantage is that it uses names which are not in use
already, and hence it is possible to test whether an
organization has entered this information in its domain
database.
- Some new section of the name space.
While this option provides the most opportunities, it creates
a need to delegate a whole new name space. Since the IP
address space is so closely related to the network number
space, most believe that the overhead of creating such a new
space is overwhelming and would lead to the WKS syndrome. (As
of February, 1989, approximately 400 sections of the
IN-ADDR.ARPA tree are already delegated, usually at network
boundaries.)
Mockapetris [Page 4]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
4. SPECIFICS FOR NETWORK NAME MAPPINGS
The proposed solution uses information stored at:
- Names in the IN-ADDR.ARPA tree that correspond to host-zero IP
addresses. The same method is used for subnets in a nested
fashion. For example, 0.0.0.10.IN-ADDR.ARPA. for net 10.
Two types of information are stored here: PTR RRs which point
to the network name in their data sections, and A RRs, which
are present if the network (or subnet) is subnetted further.
If a type A RR is present, then it has the address mask as its
data. The general form is:
<reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
<reversed-host-zero-number>.IN-ADDR.ARPA. A <subnet-mask>
For example:
0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
or
0.0.2.128.IN-ADDR.ARPA. PTR cmu-net.cmu.edu.
A 255.255.255.0
In general, this information will be added to an existing
master file for some IN-ADDR.ARPA domain for each network
involved. Similar RRs can be used at host-zero subnet
entries.
- Names which are network names.
The data stored here is PTR RRs pointing at the host-zero
entries. The general form is:
<network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA
For example:
ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
or
isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA.
In general, this information will be inserted in the master
file for the domain name of the organization; this is a
Mockapetris [Page 5]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
different file from that which holds the information below
IN-ADDR.ARPA. Similar PTR RRs can be used at subnet names.
- Names corresponding to organizations.
The data here is one or more PTR RRs pointing at the
IN-ADDR.ARPA names corresponding to host-zero entries for
networks.
For example:
ISI.EDU. PTR 0.0.9.128.IN-ADDR.ARPA.
MCC.COM. PTR 0.167.5.192.IN-ADDR.ARPA.
PTR 0.168.5.192.IN-ADDR.ARPA.
PTR 0.169.5.192.IN-ADDR.ARPA.
PTR 0.0.62.128.IN-ADDR.ARPA.
4.1. A simple example
The ARPANET is a Class A network without subnets. The RRs which
would be added, assuming the ARPANET.ARPA was selected as a network
name, would be:
ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
The first RR states that the organization named ARPA owns net 10 (It
might also own more network numbers, and these would be represented
with an additional RR per net.) The second states that the network
name ARPANET.ARPA. maps to net 10. The last states that net 10 is
named ARPANET.ARPA.
Note that all of the usual host and corresponding IN-ADDR.ARPA
entries would still be required.
4.2. A complicated, subnetted example
The ISI network is 128.9, a class B number. Suppose the ISI network
was organized into two levels of subnet, with the first level using
an additional 8 bits of address, and the second level using 4 bits,
for address masks of x'FFFFFF00' and X'FFFFFFF0'.
Then the following RRs would be entered in ISI's master file for the
ISI.EDU zone:
Mockapetris [Page 6]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
; Define network entry
isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA.
; Define first level subnets
div1-subnet.isi.edu. PTR 0.1.9.128.IN-ADDR.ARPA.
div2-subnet.isi.edu. PTR 0.2.9.128.IN-ADDR.ARPA.
; Define second level subnets
inc-subsubnet.isi.edu. PTR 16.2.9.128.IN-ADDR.ARPA.
in the 9.128.IN-ADDR.ARPA zone:
; Define network number and address mask
0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
A 255.255.255.0 ;aka X'FFFFFF00'
; Define one of the first level subnet numbers and masks
0.1.9.128.IN-ADDR.ARPA. PTR div1-subnet.isi.edu.
A 255.255.255.240 ;aka X'FFFFFFF0'
; Define another first level subnet number and mask
0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
A 255.255.255.240 ;aka X'FFFFFFF0'
; Define second level subnet number
16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
This assumes that the ISI network is named isi-net.isi.edu., first
level subnets are named div1-subnet.isi.edu. and div2-
subnet.isi.edu., and a second level subnet is called inc-
subsubnet.isi.edu. (In a real system as complicated as this there
would be more first and second level subnets defined, but we have
shown enough to illustrate the ideas.)
4.3. Procedure for using an IP address to get network name
Depending on whether the IP address is class A, B, or C, mask off the
high one, two, or three bytes, respectively. Reverse the octets,
suffix IN-ADDR.ARPA, and do a PTR query.
For example, suppose the IP address is 10.0.0.51.
1. Since this is a class A address, use a mask x'FF000000' and
get 10.0.0.0.
2. Construct the name 0.0.0.10.IN-ADDR.ARPA.
3. Do a PTR query. Get back
Mockapetris [Page 7]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
4. Conclude that the network name is "ARPANET.ARPA."
Suppose that the IP address is 128.9.2.17.
1. Since this is a class B address, use a mask of x'FFFF0000'
and get 128.9.0.0.
2. Construct the name 0.0.9.128.IN-ADDR.ARPA.
3. Do a PTR query. Get back
0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu
4. Conclude that the network name is "isi-net.isi.edu."
4.4. Procedure for finding all subnets involved with an IP address
This is a simple extension of the IP address to network name method.
When the network entry is located, do a lookup for a possible A RR.
If the A RR is found, look up the next level of subnet using the
original IP address and the mask in the A RR. Repeat this procedure
until no A RR is found.
For example, repeating the use of 128.9.2.17.
1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA.
Retrieve:
0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
A 255.255.255.0
2. Since an A RR was found, repeat using mask from RR
(255.255.255.0), constructing a query for
0.2.9.128.IN-ADDR.ARPA. Retrieve:
0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
A 255.255.255.240
3. Since another A RR was found, repeat using mask
255.255.255.240 (x'FFFFFFF0'). constructing a query for
16.2.9.128.IN-ADDR.ARPA. Retrieve:
16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there
are no more subnet levels.
Mockapetris [Page 8]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
5. YP ISSUES AND DISCUSSION
The term "Yellow Pages" is used in almost as many ways as the term
"domain", so it is useful to define what is meant herein by YP. The
general problem to be solved is to create a method for creating
mappings from one kind of identifier to another, often with an
inverse capability. The traditional methods are to search or use a
precomputed index of some kind.
Searching is impractical when the search is too large, and
precomputed indexes are possible only when it is possible to specify
search criteria in advance, and pay for the resources necessary to
build the index. For example, it is impractical to search the entire
domain tree to find a particular address RR, so we build the IN-
ADDR.ARPA YP. Similarly, we could never build an Internet-wide index
of "hosts with a load average of less than 2" in less time than it
would take for the data to change, so indexes are a useless approach
for that problem.
Such a precomputed index is what we mean by YP, and we regard the
IN-ADDR.ARPA domain as the first instance of a YP in the DNS.
Although a single, centrally-managed YP for well-known values such as
TCP-port is desirable, we regard organization-specific YPs for, say,
locally defined TCP ports as a natural extension, as are combinations
of YPs using search lists to merge the two.
In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC
1010], it is clear that there are several mappings which might be of
value. For example:
<assigned-network-name> <==> <IP-address>
<autonomous-system-id> <==> <number>
<protocol-id> <==> <number>
<port-id> <==> <number>
<ethernet-type> <==> <number>
<public-data-net> <==> <IP-address>
Following the IN-ADDR example, the YP takes the form of a domain tree
organized to optimize retrieval by search key and distribution via
normal DNS rules. The name used as a key must include:
1. A well known origin. For example, IN-ADDR.ARPA is the
current IP-address to host name YP.
2. A "from" data type. This identifies the input type of the
mapping. This is necessary because we may be mapping
something as anonymous as a number to any number of
mnemonics, etc.
Mockapetris [Page 9]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
3. A "to" data type. Since we assume several symmetrical
mnemonic <==> number mappings, this is also necessary.
This ordering reflects the natural scoping of control, and hence the
order of the components in a domain name. Thus domain names would be
of the form:
<from-value>.<to-data-type>.<from-data-type>.<YP-origin>
To make this work, we need to define well-know strings for each of
these metavariables, as well as encoding rules for converting a
<from-value> into a domain name. We might define:
<YP-origin> :=YP
<from-data-type>:=TCP-port | IN-ADDR | Number |
Assigned-network-number | Name
<to-data-type> :=<from-data-type>
Note that "YP" is NOT a valid country code under [ISO 3166] (although
we may want to worry about the future), and the existence of a
syntactically valid <to-data-type>.<from-data-type> pair does not
imply that a meaningful mapping exists, or is even possible.
The encoding rules might be:
TCP-port Six character alphanumeric
IN-ADDR Reversed 4-octet decimal string
Number decimal integer
Assigned-network-number
Reversed 4-octet decimal string
Name Domain name
6. SPECIFICS FOR YP MAPPINGS
6.1. TCP-PORT
$origin Number.TCP-port.YP.
23 PTR TELNET.TCP-port.Number.YP.
25 PTR SMTP.TCP-port.Number.YP.
$origin TCP-port.Number.YP.
TELNET PTR 23.Number.TCP-port.YP.
Mockapetris [Page 10]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
SMTP PTR 25.Number.TCP-port.YP.
Thus the mapping between 23 and TELNET is represented by a pair of
PTR RRs, one for each direction of the mapping.
6.2. Assigned networks
Network numbers are assigned by the NIC and reported in "Internet
Numbers" RFCs. To create a YP, the NIC would set up two domains:
Name.Assigned-network-number.YP and Assigned-network-number.YP
The first would contain entries of the form:
$origin Name.Assigned-network-number.YP.
0.0.0.4 PTR SATNET.Assigned-network-number.Name.YP.
0.0.0.10 PTR ARPANET.Assigned-network-number.Name.YP.
The second would contain entries of the form:
$origin Assigned-network-number.Name.YP.
SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP.
ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP.
These YPs are not in conflict with the network name support described
in the first half of this RFC since they map between ASSIGNED network
names and numbers, not those allocated by the organizations
themselves. That is, they document the NIC's decisions about
allocating network numbers but do not automatically track any
renaming performed by the new owners.
As a practical matter, we might want to create both of these domains
to enable users on the Internet to experiment with centrally
maintained support as well as the distributed version, or might want
to implement only the allocated number to name mapping and request
organizations to convert their allocated network names to the network
names described in the distributed model.
6.3. Operational improvements
We could imagine that all conversion routines using these YPs might
be instructed to use "YP.<local-domain>" followed by "YP." as a
search list. Thus, if the organization ISI.EDU wished to define
locally meaningful TCP-PORT, it would define the domains:
<TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.
Mockapetris [Page 11]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
We could add another level of indirection in the YP lookup, defining
the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the
YP tree, rather than being the YP tree directly. This would enable
entries of the form:
IN-ADDR.Netname.YP. PTR IN-ADDR.ARPA.
to splice in YPs from other origins or existing spaces.
Another possibility would be to shorten the RDATA section of the RRs
which map back and forth by deleting the origin. This could be done
either by allowing the domain name in the RDATA portion to not
identify a real domain name, or by defining a new RR which used a
simple text string rather than a domain name.
Thus, we might replace
$origin Assigned-network-number.Name.YP.
SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP.
ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP.
with
$origin Assigned-network-number.Name.YP.
SATNET. PTR 0.0.0.4.
ARPANET. PTR 0.0.0.10.
or
$origin Assigned-network-number.Name.YP.
SATNET. PTT "0.0.0.4"
ARPANET. PTT "0.0.0.10"
where PTT is a new type whose RDATA section is a text string.
7. ACKNOWLEDGMENTS
Drew Perkins, Mark Lottor, and Rob Austein contributed several of the
ideas in this RFC. Numerous contributions, criticisms, and
compromises were produced in the IETF Domain working group and the
NAMEDROPPERS mailing list.
Mockapetris [Page 12]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
8. REFERENCES
[HR] Braden, B., editor, "Requirements for Internet Hosts",
RFC in preparation.
[ISO 3166] ISO, "Codes for the Representation of Names of
Countries", 1981.
[RFC 882] Mockapetris, P., "Domain names - Concepts and
Facilities", RFC 882, USC/Information Sciences Institute,
November 1983.
Superseded by RFC 1034.
[RFC 883] Mockapetris, P.,"Domain names - Implementation and
Specification", RFC 883, USC/Information Sciences
Institute, November 1983.
Superceeded by RFC 1035.
[RFC 920] Postel, J. and J. Reynolds, "Domain Requirements", RFC
920, October 1984.
Explains the naming scheme for top level domains.
[RFC 952] Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet
Host Table Specification", RFC 952, SRI, October 1985.
Specifies the format of HOSTS.TXT, the host/address table
replaced by the DNS
[RFC 973] Mockapetris, P., "Domain System Changes and
Observations", RFC 973, USC/Information Sciences
Institute, January 1986.
Describes changes to RFCs 882 and 883 and reasons for
them.
[RFC 974] Partridge, C., "Mail routing and the domain system", RFC
974, CSNET CIC BBN Labs, January 1986.
Describes the transition from HOSTS.TXT based mail
addressing to the more powerful MX system used with the
domain system.
Mockapetris [Page 13]
RFC 1101 DNS Encoding of Network Names and Other Types April 1989
[RFC 997] Reynolds, J., and J. Postel, "Internet Numbers", RFC 997,
USC/Information Sciences Institute, March 1987
Contains network numbers, autonomous system numbers, etc.
[RFC 1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
1010, USC/Information Sciences Institute, May 1987
Contains socket numbers and mnemonics for host names,
operating systems, etc.
[RFC 1034] Mockapetris, P., "Domain names - Concepts and
Facilities", RFC 1034, USC/Information Sciences
Institute, November 1987.
Introduction/overview of the DNS.
[RFC 1035] Mockapetris, P., "Domain names - Implementation and
Specification", RFC 1035, USC/Information Sciences
Institute, November 1987.
DNS implementation instructions.
Author's Address:
Paul Mockapetris
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: (213) 822-1511
Email: PVM@ISI.EDU
Mockapetris [Page 14]

6844
doc/rfc/rfc1122.txt Normal file
View file

File diff suppressed because it is too large Load diff

5782
doc/rfc/rfc1123.txt Normal file
View file

File diff suppressed because it is too large Load diff

619
doc/rfc/rfc1183.txt Normal file
View file

@ -0,0 +1,619 @@
Network Working Group C. Everhart
Request for Comments: 1183 Transarc
Updates: RFCs 1034, 1035 L. Mamakos
University of Maryland
R. Ullmann
Prime Computer
P. Mockapetris, Editor
ISI
October 1990
New DNS RR Definitions
Status of this Memo
This memo defines five new DNS types for experimental purposes. This
RFC describes an Experimental Protocol for the Internet community,
and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
Table of Contents
Introduction.................................................... 1
1. AFS Data Base location....................................... 2
2. Responsible Person........................................... 3
2.1. Identification of the guilty party......................... 3
2.2. The Responsible Person RR.................................. 4
3. X.25 and ISDN addresses, Route Binding....................... 6
3.1. The X25 RR................................................. 6
3.2. The ISDN RR................................................ 7
3.3. The Route Through RR....................................... 8
REFERENCES and BIBLIOGRAPHY..................................... 9
Security Considerations......................................... 10
Authors' Addresses.............................................. 11
Introduction
This RFC defines the format of new Resource Records (RRs) for the
Domain Name System (DNS), and reserves corresponding DNS type
mnemonics and numerical codes. The definitions are in three
independent sections: (1) location of AFS database servers, (2)
location of responsible persons, and (3) representation of X.25 and
ISDN addresses and route binding. All are experimental.
This RFC assumes that the reader is familiar with the DNS [3,4]. The
data shown is for pedagogical use and does not necessarily reflect
the real Internet.
Everhart, Mamakos, Ullmann & Mockapetris [Page 1]
RFC 1183 New DNS RR Definitions October 1990
1. AFS Data Base location
This section defines an extension of the DNS to locate servers both
for AFS (AFS is a registered trademark of Transarc Corporation) and
for the Open Software Foundation's (OSF) Distributed Computing
Environment (DCE) authenticated naming system using HP/Apollo's NCA,
both to be components of the OSF DCE. The discussion assumes that
the reader is familiar with AFS [5] and NCA [6].
The AFS (originally the Andrew File System) system uses the DNS to
map from a domain name to the name of an AFS cell database server.
The DCE Naming service uses the DNS for a similar function: mapping
from the domain name of a cell to authenticated name servers for that
cell. The method uses a new RR type with mnemonic AFSDB and type
code of 18 (decimal).
AFSDB has the following format:
<owner> <ttl> <class> AFSDB <subtype> <hostname>
Both RDATA fields are required in all AFSDB RRs. The <subtype> field
is a 16 bit integer. The <hostname> field is a domain name of a host
that has a server for the cell named by the owner name of the RR.
The format of the AFSDB RR is class insensitive. AFSDB records cause
type A additional section processing for <hostname>. This, in fact,
is the rationale for using a new type code, rather than trying to
build the same functionality with TXT RRs.
Note that the format of AFSDB in a master file is identical to MX.
For purposes of the DNS itself, the subtype is merely an integer.
The present subtype semantics are discussed below, but changes are
possible and will be announced in subsequent RFCs.
In the case of subtype 1, the host has an AFS version 3.0 Volume
Location Server for the named AFS cell. In the case of subtype 2,
the host has an authenticated name server holding the cell-root
directory node for the named DCE/NCA cell.
The use of subtypes is motivated by two considerations. First, the
space of DNS RR types is limited. Second, the services provided are
sufficiently distinct that it would continue to be confusing for a
client to attempt to connect to a cell's servers using the protocol
for one service, if the cell offered only the other service.
As an example of the use of this RR, suppose that the Toaster
Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE. Their
cell, named toaster.com, has three "AFS 3.0 cell database server"
Everhart, Mamakos, Ullmann & Mockapetris [Page 2]
RFC 1183 New DNS RR Definitions October 1990
machines: bigbird.toaster.com, ernie.toaster.com, and
henson.toaster.com. These three machines would be listed in three
AFSDB RRs. These might appear in a master file as:
toaster.com. AFSDB 1 bigbird.toaster.com.
toaster.com. AFSDB 1 ernie.toaster.com.
toaster.com. AFSDB 1 henson.toaster.com.
As another example use of this RR, suppose that Femto College (domain
name femto.edu) has deployed DCE, and that their DCE cell root
directory is served by processes running on green.femto.edu and
turquoise.femto.edu. Furthermore, their DCE file servers also run
AFS 3.0-compatible volume location servers, on the hosts
turquoise.femto.edu and orange.femto.edu. These machines would be
listed in four AFSDB RRs, which might appear in a master file as:
femto.edu. AFSDB 2 green.femto.edu.
femto.edu. AFSDB 2 turquoise.femto.edu.
femto.edu. AFSDB 1 turquoise.femto.edu.
femto.edu. AFSDB 1 orange.femto.edu.
2. Responsible Person
The purpose of this section is to provide a standard method for
associating responsible person identification to any name in the DNS.
The domain name system functions as a distributed database which
contains many different form of information. For a particular name
or host, you can discover it's Internet address, mail forwarding
information, hardware type and operating system among others.
A key aspect of the DNS is that the tree-structured namespace can be
divided into pieces, called zones, for purposes of distributing
control and responsibility. The responsible person for zone database
purposes is named in the SOA RR for that zone. This section
describes an extension which allows different responsible persons to
be specified for different names in a zone.
2.1. Identification of the guilty party
Often it is desirable to be able to identify the responsible entity
for a particular host. When that host is down or malfunctioning, it
is difficult to contact those parties which might resolve or repair
the host. Mail sent to POSTMASTER may not reach the person in a
timely fashion. If the host is one of a multitude of workstations,
there may be no responsible person which can be contacted on that
host.
Everhart, Mamakos, Ullmann & Mockapetris [Page 3]
RFC 1183 New DNS RR Definitions October 1990
The POSTMASTER mailbox on that host continues to be a good contact
point for mail problems, and the zone contact in the SOA record for
database problem, but the RP record allows us to associate a mailbox
to entities that don't receive mail or are not directly connected
(namespace-wise) to the problem (e.g., GATEWAY.ISI.EDU might want to
point at HOTLINE@BBN.COM, and GATEWAY doesn't get mail, nor does the
ISI zone administrator have a clue about fixing gateways).
2.2. The Responsible Person RR
The method uses a new RR type with mnemonic RP and type code of 17
(decimal).
RP has the following format:
<owner> <ttl> <class> RP <mbox-dname> <txt-dname>
Both RDATA fields are required in all RP RRs.
The first field, <mbox-dname>, is a domain name that specifies the
mailbox for the responsible person. Its format in master files uses
the DNS convention for mailbox encoding, identical to that used for
the RNAME mailbox field in the SOA RR. The root domain name (just
".") may be specified for <mbox-dname> to indicate that no mailbox is
available.
The second field, <txt-dname>, is a domain name for which TXT RR's
exist. A subsequent query can be performed to retrieve the
associated TXT resource records at <txt-dname>. This provides a
level of indirection so that the entity can be referred to from
multiple places in the DNS. The root domain name (just ".") may be
specified for <txt-dname> to indicate that the TXT_DNAME is absent,
and no associated TXT RR exists.
The format of the RP RR is class insensitive. RP records cause no
additional section processing. (TXT additional section processing
for <txt-dname> is allowed as an option, but only if it is disabled
for the root, i.e., ".").
The Responsible Person RR can be associated with any node in the
Domain Name System hierarchy, not just at the leaves of the tree.
The TXT RR associated with the TXT_DNAME contain free format text
suitable for humans. Refer to [4] for more details on the TXT RR.
Multiple RP records at a single name may be present in the database.
They should have identical TTLs.
Everhart, Mamakos, Ullmann & Mockapetris [Page 4]
RFC 1183 New DNS RR Definitions October 1990
EXAMPLES
Some examples of how the RP record might be used.
sayshell.umd.edu. A 128.8.1.14
MX 10 sayshell.umd.edu.
HINFO NeXT UNIX
WKS 128.8.1.14 tcp ftp telnet smtp
RP louie.trantor.umd.edu. LAM1.people.umd.edu.
LAM1.people.umd.edu. TXT (
"Louis A. Mamakos, (301) 454-2946, don't call me at home!" )
In this example, the responsible person's mailbox for the host
SAYSHELL.UMD.EDU is louie@trantor.umd.edu. The TXT RR at
LAM1.people.umd.edu provides additional information and advice.
TERP.UMD.EDU. A 128.8.10.90
MX 10 128.8.10.90
HINFO MICROVAX-II UNIX
WKS 128.8.10.90 udp domain
WKS 128.8.10.90 tcp ftp telnet smtp domain
RP louie.trantor.umd.edu. LAM1.people.umd.edu.
RP root.terp.umd.edu. ops.CS.UMD.EDU.
TRANTOR.UMD.EDU. A 128.8.10.14
MX 10 trantor.umd.edu.
HINFO MICROVAX-II UNIX
WKS 128.8.10.14 udp domain
WKS 128.8.10.14 tcp ftp telnet smtp domain
RP louie.trantor.umd.edu. LAM1.people.umd.edu.
RP petry.netwolf.umd.edu. petry.people.UMD.EDU.
RP root.trantor.umd.edu. ops.CS.UMD.EDU.
RP gregh.sunset.umd.edu. .
LAM1.people.umd.edu. TXT "Louis A. Mamakos (301) 454-2946"
petry.people.umd.edu. TXT "Michael G. Petry (301) 454-2946"
ops.CS.UMD.EDU. TXT "CS Operations Staff (301) 454-2943"
This set of resource records has two hosts, TRANTOR.UMD.EDU and
TERP.UMD.EDU, as well as a number of TXT RRs. Note that TERP.UMD.EDU
and TRANTOR.UMD.EDU both reference the same pair of TXT resource
records, although the mail box names (root.terp.umd.edu and
root.trantor.umd.edu) differ.
Here, we obviously care much more if the machine flakes out, as we've
specified four persons which might want to be notified of problems or
other events involving TRANTOR.UMD.EDU. In this example, the last RP
Everhart, Mamakos, Ullmann & Mockapetris [Page 5]
RFC 1183 New DNS RR Definitions October 1990
RR for TRANTOR.UMD.EDU specifies a mailbox (gregh.sunset.umd.edu),
but no associated TXT RR.
3. X.25 and ISDN addresses, Route Binding
This section describes an experimental representation of X.25 and
ISDN addresses in the DNS, as well as a route binding method,
analogous to the MX for mail routing, for very large scale networks.
There are several possible uses, all experimental at this time.
First, the RRs provide simple documentation of the correct addresses
to use in static configurations of IP/X.25 [11] and SMTP/X.25 [12].
The RRs could also be used automatically by an internet network-layer
router, typically IP. The procedure would be to map IP address to
domain name, then name to canonical name if needed, then following RT
records, and finally attempting an IP/X.25 call to the address found.
Alternately, configured domain names could be resolved to identify IP
to X.25/ISDN bindings for a static but periodically refreshed routing
table.
This provides a function similar to ARP for wide area non-broadcast
networks that will scale well to a network with hundreds of millions
of hosts.
Also, a standard address binding reference will facilitate other
experiments in the use of X.25 and ISDN, especially in serious
inter-operability testing. The majority of work in such a test is
establishing the n-squared entries in static tables.
Finally, the RRs are intended for use in a proposal [13] by one of
the authors for a possible next-generation internet.
3.1. The X25 RR
The X25 RR is defined with mnemonic X25 and type code 19 (decimal).
X25 has the following format:
<owner> <ttl> <class> X25 <PSDN-address>
<PSDN-address> is required in all X25 RRs.
<PSDN-address> identifies the PSDN (Public Switched Data Network)
address in the X.121 [10] numbering plan associated with <owner>.
Its format in master files is a <character-string> syntactically
identical to that used in TXT and HINFO.
Everhart, Mamakos, Ullmann & Mockapetris [Page 6]
RFC 1183 New DNS RR Definitions October 1990
The format of X25 is class insensitive. X25 RRs cause no additional
section processing.
The <PSDN-address> is a string of decimal digits, beginning with the
4 digit DNIC (Data Network Identification Code), as specified in
X.121. National prefixes (such as a 0) MUST NOT be used.
For example:
Relay.Prime.COM. X25 311061700956
3.2. The ISDN RR
The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal).
An ISDN (Integrated Service Digital Network) number is simply a
telephone number. The intent of the members of the CCITT is to
upgrade all telephone and data network service to a common service.
The numbering plan (E.163/E.164) is the same as the familiar
international plan for POTS (an un-official acronym, meaning Plain
Old Telephone Service). In E.166, CCITT says "An E.163/E.164
telephony subscriber may become an ISDN subscriber without a number
change."
ISDN has the following format:
<owner> <ttl> <class> ISDN <ISDN-address> <sa>
The <ISDN-address> field is required; <sa> is optional.
<ISDN-address> identifies the ISDN number of <owner> and DDI (Direct
Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and
PSTN (Public Switched Telephone Network) numbering plan. E.163
defines the country codes, and E.164 the form of the addresses. Its
format in master files is a <character-string> syntactically
identical to that used in TXT and HINFO.
<sa> specifies the subaddress (SA). The format of <sa> in master
files is a <character-string> syntactically identical to that used in
TXT and HINFO.
The format of ISDN is class insensitive. ISDN RRs cause no
additional section processing.
The <ISDN-address> is a string of characters, normally decimal
digits, beginning with the E.163 country code and ending with the DDI
if any. Note that ISDN, in Q.931, permits any IA5 character in the
Everhart, Mamakos, Ullmann & Mockapetris [Page 7]
RFC 1183 New DNS RR Definitions October 1990
general case.
The <sa> is a string of hexadecimal digits. For digits 0-9, the
concrete encoding in the Q.931 call setup information element is
identical to BCD.
For example:
Relay.Prime.COM. IN ISDN 150862028003217
sh.Prime.COM. IN ISDN 150862028003217 004
(Note: "1" is the country code for the North American Integrated
Numbering Area, i.e., the system of "area codes" familiar to people
in those countries.)
The RR data is the ASCII representation of the digits. It is encoded
as one or two <character-string>s, i.e., count followed by
characters.
CCITT recommendation E.166 [9] defines prefix escape codes for the
representation of ISDN (E.163/E.164) addresses in X.121, and PSDN
(X.121) addresses in E.164. It specifies that the exact codes are a
"national matter", i.e., different on different networks. A host
connected to the ISDN may be able to use both the X25 and ISDN
addresses, with the local prefix added.
3.3. The Route Through RR
The Route Through RR is defined with mnemonic RT and type code 21
(decimal).
The RT resource record provides a route-through binding for hosts
that do not have their own direct wide area network addresses. It is
used in much the same way as the MX RR.
RT has the following format:
<owner> <ttl> <class> RT <preference> <intermediate-host>
Both RDATA fields are required in all RT RRs.
The first field, <preference>, is a 16 bit integer, representing the
preference of the route. Smaller numbers indicate more preferred
routes.
<intermediate-host> is the domain name of a host which will serve as
an intermediate in reaching the host specified by <owner>. The DNS
RRs associated with <intermediate-host> are expected to include at
Everhart, Mamakos, Ullmann & Mockapetris [Page 8]
RFC 1183 New DNS RR Definitions October 1990
least one A, X25, or ISDN record.
The format of the RT RR is class insensitive. RT records cause type
X25, ISDN, and A additional section processing for <intermediate-
host>.
For example,
sh.prime.com. IN RT 2 Relay.Prime.COM.
IN RT 10 NET.Prime.COM.
*.prime.com. IN RT 90 Relay.Prime.COM.
When a host is looking up DNS records to attempt to route a datagram,
it first looks for RT records for the destination host, which point
to hosts with address records (A, X25, ISDN) compatible with the wide
area networks available to the host. If it is itself in the set of
RT records, it discards any RTs with preferences higher or equal to
its own. If there are no (remaining) RTs, it can then use address
records of the destination itself.
Wild-card RTs are used exactly as are wild-card MXs. RT's do not
"chain"; that is, it is not valid to use the RT RRs found for a host
referred to by an RT.
The concrete encoding is identical to the MX RR.
REFERENCES and BIBLIOGRAPHY
[1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
Information Center, SRI International, November 1987.
[2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
Network Information Center, SRI International, November, 1987.
[3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
1034, USC/Information Sciences Institute, November 1987.
[4] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, USC/Information Sciences Institute,
November 1987.
[5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review,
7(3), pp. 61-69, March 1989.
[6] Zahn, et al., "Network Computing Architecture", Prentice-Hall,
1989.
[7] International Telegraph and Telephone Consultative Committee,
Everhart, Mamakos, Ullmann & Mockapetris [Page 9]
RFC 1183 New DNS RR Definitions October 1990
"Numbering Plan for the International Telephone Service", CCITT
Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988,
Fascicle II.2 ("Blue Book").
[8] International Telegraph and Telephone Consultative Committee,
"Numbering Plan for the ISDN Era", CCITT Recommendations E.164.,
IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue
Book").
[9] International Telegraph and Telephone Consultative Committee.
"Numbering Plan Interworking in the ISDN Era", CCITT
Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988,
Fascicle II.2 ("Blue Book").
[10] International Telegraph and Telephone Consultative Committee,
"International Numbering Plan for the Public Data Networks",
CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne,
1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978;
amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne,
1988.
[11] Korb, J., "Standard for the Transmission of IP datagrams Over
Public Data Networks", RFC 877, Purdue University, September
1983.
[12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February
1989.
[13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer
(unpublished), July 1990.
[14] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
RFC 1101, USC/Information Sciences Institute, April 1989.
Security Considerations
Security issues are not addressed in this memo.
Everhart, Mamakos, Ullmann & Mockapetris [Page 10]
RFC 1183 New DNS RR Definitions October 1990
Authors' Addresses
Craig F. Everhart
Transarc Corporation
The Gulf Tower
707 Grant Street
Pittsburgh, PA 15219
Phone: +1 412 338 4467
EMail: Craig_Everhart@transarc.com
Louis A. Mamakos
Network Infrastructure Group
Computer Science Center
University of Maryland
College Park, MD 20742-2411
Phone: +1-301-405-7836
Email: louie@Sayshell.UMD.EDU
Robert Ullmann 10-30
Prime Computer, Inc.
500 Old Connecticut Path
Framingham, MA 01701
Phone: +1 508 620 2800 ext 1736
Email: Ariel@Relay.Prime.COM
Paul Mockapetris
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 213-822-1511
EMail: pvm@isi.edu
Everhart, Mamakos, Ullmann & Mockapetris [Page 11]

283
doc/rfc/rfc1535.txt Normal file
View file

@ -0,0 +1,283 @@
Network Working Group E. Gavron
Request for Comments: 1535 ACES Research Inc.
Category: Informational October 1993
A Security Problem and Proposed Correction
With Widely Deployed DNS Software
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
Abstract
This document discusses a flaw in some of the currently distributed
name resolver clients. The flaw exposes a security weakness related
to the search heuristic invoked by these same resolvers when users
provide a partial domain name, and which is easy to exploit (although
not by the masses). This document points out the flaw, a case in
point, and a solution.
Background
Current Domain Name Server clients are designed to ease the burden of
remembering IP dotted quad addresses. As such they translate human-
readable names into addresses and other resource records. Part of
the translation process includes understanding and dealing with
hostnames that are not fully qualified domain names (FQDNs).
An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
domain name is of the format {name}
A domain name may have many parts and typically these include the
host, domain, and type. Example: foobar.company.com or
fooschool.university.edu.
Flaw
The problem with most widely distributed resolvers based on the BSD
BIND resolver is that they attempt to resolve a partial name by
processing a search list of partial domains to be added to portions
of the specified host name until a DNS record is found. This
"feature" is disabled by default in the official BIND 4.9.2 release.
Example: A TELNET attempt by User@Machine.Tech.ACES.COM
to UnivHost.University.EDU
Gavron [Page 1]
RFC 1535 DNS Software Enhancements October 1993
The resolver client will realize that since "UnivHost.University.EDU"
does not end with a ".", it is not an absolute "rooted" FQDN. It
will then try the following combinations until a resource record is
found:
UnivHost.University.EDU.Tech.ACES.COM.
UnivHost.University.EDU.ACES.COM.
UnivHost.University.EDU.COM.
UnivHost.University.EDU.
Security Issue
After registering the EDU.COM domain, it was discovered that an
unliberal application of one wildcard CNAME record would cause *all*
connects from any .COM site to any .EDU site to terminate at one
target machine in the private edu.com sub-domain.
Further, discussion reveals that specific hostnames registered in
this private subdomain, or any similarly named subdomain may be used
to spoof a host.
Example: harvard.edu.com. CNAME targethost
Thus all connects to Harvard.edu from all .com sites would end up at
targthost, a machine which could provide a Harvard.edu login banner.
This is clearly unacceptable. Further, it could only be made worse
with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
Public vs. Local Name Space Administration
The specification of the Domain Name System and the software that
implements it provides an undifferentiated hierarchy which permits
delegation of administration for subordinate portions of the name
space. Actual administration of the name space is divided between
"public" and "local" portions. Public administration pertains to all
top-level domains, such as .COM and .EDU. For some domains, it also
pertains to some number of sub-domain levels. The multi-level nature
of the public administration is most evident for top-level domains
for countries. For example in the Fully Qualified Domain Name,
dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
of public administration. Only the left-most portion is subject to
local administration.
Gavron [Page 2]
RFC 1535 DNS Software Enhancements October 1993
The danger of the heuristic search common in current practise is that
it it is possible to "intercept" the search by matching against an
unintended value while walking up the search list. While this is
potentially dangerous at any level, it is entirely unacceptable when
the error impacts users outside of a local administration.
When attempting to resolve a partial domain name, DNS resolvers use
the Domain Name of the searching host for deriving the search list.
Existing DNS resolvers do not distinguish the portion of that name
which is in the locally administered scope from the part that is
publically administered.
Solution(s)
At a minimum, DNS resolvers must honor the BOUNDARY between local and
public administration, by limiting any search lists to locally-
administered portions of the Domain Name space. This requires a
parameter which shows the scope of the name space controlled by the
local administrator.
This would permit progressive searches from the most qualified to
less qualified up through the locally controlled domain, but not
beyond.
For example, if the local user were trying to reach:
User@chief.admin.DESERTU.EDU from
starburst,astro.DESERTU.EDU,
it is reasonable to permit the user to enter just chief.admin, and
for the search to cover:
chief.admin.astro.DESERTU.EDU
chief.admin.DESERTU.EDU
but not
chief.admin.EDU
In this case, the value of "search" should be set to "DESERTU.EDU"
because that's the scope of the name space controlled by the local
DNS administrator.
This is more than a mere optimization hack. The local administrator
has control over the assignment of names within the locally
administered domain, so the administrator can make sure that
abbreviations result in the right thing. Outside of the local
control, users are necessarily at risk.
Gavron [Page 3]
RFC 1535 DNS Software Enhancements October 1993
A more stringent mechanism is implemented in BIND 4.9.2, to respond
to this problem:
The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
to only try the first and the last of the examples shown.
Any additional search alternatives must be configured into the
resolver EXPLICITLY.
DNS Name resolver software SHOULD NOT use implicit search lists in
attempts to resolve partial names into absolute FQDNs other than the
hosts's immediate parent domain.
Resolvers which continue to use implicit search lists MUST limit
their scope to locally administered sub-domains.
DNS Name resolver software SHOULD NOT come pre-configured with
explicit search lists that perpetuate this problem.
Further, in any event where a "." exists in a specified name it
should be assumed to be a fully qualified domain name (FQDN) and
SHOULD be tried as a rooted name first.
Example: Given user@a.b.c.d connecting to e.f.g.h only two tries
should be attempted as a result of using an implicit
search list:
e.f.g.h. and e.f.g.h.b.c.d.
Given user@a.b.c.d. connecting to host those same two
tries would appear as:
x.b.c.d. and x.
Some organizations make regular use of multi-part, partially
qualified Domain Names. For example, host foo.loc1.org.city.state.us
might be used to making references to bar.loc2, or mumble.loc3, all
of which refer to whatever.locN.org.city.state.us
The stringent implicit search rules for BIND 4.9.2 will now cause
these searches to fail. To return the ability for them to succeed,
configuration of the client resolvers must be changed to include an
explicit search rule for org.city.state.us. That is, it must contain
an explicit rule for any -- and each -- portion of the locally-
administered sub-domain that it wishes to have as part of the search
list.
Gavron [Page 4]
RFC 1535 DNS Software Enhancements October 1993
References
[1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
RFC 1034, USC/Information Sciences Institute, November 1987.
[2] Mockapetris, P., "Domain Names Implementation and Specification",
STD 13, RFC 1035, USC/Information Sciences Institute, November
1987.
[3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
974, CSNET CIC BBN, January 1986.
[4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
"Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
USC/Information Sciences Institute, USC, October 1993.
[5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
1537, CWI, October 1993.
Security Considerations
This memo indicates vulnerabilities with all too-forgiving DNS
clients. It points out a correction that would eliminate the future
potential of the problem.
Author's Address
Ehud Gavron
ACES Research Inc.
PO Box 14546
Tucson, AZ 85711
Phone: (602) 743-9841
EMail: gavron@aces.com
Gavron [Page 5]

675
doc/rfc/rfc1536.txt Normal file
View file

@ -0,0 +1,675 @@
Network Working Group A. Kumar
Request for Comments: 1536 J. Postel
Category: Informational C. Neuman
ISI
P. Danzig
S. Miller
USC
October 1993
Common DNS Implementation Errors and Suggested Fixes
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
Abstract
This memo describes common errors seen in DNS implementations and
suggests some fixes. Where applicable, violations of recommendations
from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo
also describes, where relevant, the algorithms followed in BIND
(versions 4.8.3 and 4.9 which the authors referred to) to serve as an
example.
Introduction
The last few years have seen, virtually, an explosion of DNS traffic
on the NSFnet backbone. Various DNS implementations and various
versions of these implementations interact with each other, producing
huge amounts of unnecessary traffic. Attempts are being made by
researchers all over the internet, to document the nature of these
interactions, the symptomatic traffic patterns and to devise remedies
for the sick pieces of software.
This draft is an attempt to document fixes for known DNS problems so
people know what problems to watch out for and how to repair broken
software.
1. Fast Retransmissions
DNS implements the classic request-response scheme of client-server
interaction. UDP is, therefore, the chosen protocol for communication
though TCP is used for zone transfers. The onus of requerying in case
no response is seen in a "reasonable" period of time, lies with the
client. Although RFC 1034 and 1035 do not recommend any
Kumar, Postel, Neuman, Danzig & Miller [Page 1]
RFC 1536 Common DNS Implementation Errors October 1993
retransmission policy, RFC 1035 does recommend that the resolvers
should cycle through a list of servers. Both name servers and stub
resolvers should, therefore, implement some kind of a retransmission
policy based on round trip time estimates of the name servers. The
client should back-off exponentially, probably to a maximum timeout
value.
However, clients might not implement either of the two. They might
not wait a sufficient amount of time before retransmitting or they
might not back-off their inter-query times sufficiently.
Thus, what the server would see will be a series of queries from the
same querying entity, spaced very close together. Of course, a
correctly implemented server discards all duplicate queries but the
queries contribute to wide-area traffic, nevertheless.
We classify a retransmission of a query as a pure Fast retry timeout
problem when a series of query packets meet the following conditions.
a. Query packets are seen within a time less than a "reasonable
waiting period" of each other.
b. No response to the original query was seen i.e., we see two or
more queries, back to back.
c. The query packets share the same query identifier.
d. The server eventually responds to the query.
A GOOD IMPLEMENTATION:
BIND (we looked at versions 4.8.3 and 4.9) implements a good
retransmission algorithm which solves or limits all of these
problems. The Berkeley stub-resolver queries servers at an interval
that starts at the greater of 4 seconds and 5 seconds divided by the
number of servers the resolver queries. The resolver cycles through
servers and at the end of a cycle, backs off the time out
exponentially.
The Berkeley full-service resolver (built in with the program
"named") starts with a time-out equal to the greater of 4 seconds and
two times the round-trip time estimate of the server. The time-out
is backed off with each cycle, exponentially, to a ceiling value of
45 seconds.
Kumar, Postel, Neuman, Danzig & Miller [Page 2]
RFC 1536 Common DNS Implementation Errors October 1993
FIXES:
a. Estimate round-trip times or set a reasonably high initial
time-out.
b. Back-off timeout periods exponentially.
c. Yet another fundamental though difficult fix is to send the
client an acknowledgement of a query, with a round-trip time
estimate.
Since UDP is used, no response is expected by the client until the
query is complete. Thus, it is less likely to have information about
previous packets on which to estimate its back-off time. Unless, you
maintain state across queries, so subsequent queries to the same
server use information from previous queries. Unfortunately, such
estimates are likely to be inaccurate for chained requests since the
variance is likely to be high.
The fix chosen in the ARDP library used by Prospero is that the
server will send an initial acknowledgement to the client in those
cases where the server expects the query to take a long time (as
might be the case for chained queries). This initial acknowledgement
can include an expected time to wait before retrying.
This fix is more difficult since it requires that the client software
also be trained to expect the acknowledgement packet. This, in an
internet of millions of hosts is at best a hard problem.
2. Recursion Bugs
When a server receives a client request, it first looks up its zone
data and the cache to check if the query can be answered. If the
answer is unavailable in either place, the server seeks names of
servers that are more likely to have the information, in its cache or
zone data. It then does one of two things. If the client desires the
server to recurse and the server architecture allows recursion, the
server chains this request to these known servers closest to the
queried name. If the client doesn't seek recursion or if the server
cannot handle recursion, it returns the list of name servers to the
client assuming the client knows what to do with these records.
The client queries this new list of name servers to get either the
answer, or names of another set of name servers to query. This
process repeats until the client is satisfied. Servers might also go
through this chaining process if the server returns a CNAME record
for the queried name. Some servers reprocess this name to try and get
the desired record type.
Kumar, Postel, Neuman, Danzig & Miller [Page 3]
RFC 1536 Common DNS Implementation Errors October 1993
However, in certain cases, this chain of events may not be good. For
example, a broken or malicious name server might list itself as one
of the name servers to query again. The unsuspecting client resends
the same query to the same server.
In another situation, more difficult to detect, a set of servers
might form a loop wherein A refers to B and B refers to A. This loop
might involve more than two servers.
Yet another error is where the client does not know how to process
the list of name servers returned, and requeries the same server
since that is one (of the few) servers it knows.
We, therefore, classify recursion bugs into three distinct
categories:
a. Ignored referral: Client did not know how to handle NS records
in the AUTHORITY section.
b. Too many referrals: Client called on a server too many times,
beyond a "reasonable" number, with same query. This is
different from a Fast retransmission problem and a Server
Failure detection problem in that a response is seen for every
query. Also, the identifiers are always different. It implies
client is in a loop and should have detected that and broken
it. (RFC 1035 mentions that client should not recurse beyond
a certain depth.)
c. Malicious Server: a server refers to itself in the authority
section. If a server does not have an answer now, it is very
unlikely it will be any better the next time you query it,
specially when it claims to be authoritative over a domain.
RFC 1034 warns against such situations, on page 35.
"Bound the amount of work (packets sent, parallel processes
started) so that a request can't get into an infinite loop or
start off a chain reaction of requests or queries with other
implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
SOME DATA."
A GOOD IMPLEMENTATION:
BIND fixes at least one of these problems. It places an upper limit
on the number of recursive queries it will make, to answer a
question. It chases a maximum of 20 referral links and 8 canonical
name translations.
Kumar, Postel, Neuman, Danzig & Miller [Page 4]
RFC 1536 Common DNS Implementation Errors October 1993
FIXES:
a. Set an upper limit on the number of referral links and CNAME
links you are willing to chase.
Note that this is not guaranteed to break only recursion loops.
It could, in a rare case, prune off a very long search path,
prematurely. We know, however, with high probability, that if
the number of links cross a certain metric (two times the depth
of the DNS tree), it is a recursion problem.
b. Watch out for self-referring servers. Avoid them whenever
possible.
c. Make sure you never pass off an authority NS record with your
own name on it!
d. Fix clients to accept iterative answers from servers not built
to provide recursion. Such clients should either be happy with
the non-authoritative answer or be willing to chase the
referral links themselves.
3. Zero Answer Bugs:
Name servers sometimes return an authoritative NOERROR with no
ANSWER, AUTHORITY or ADDITIONAL records. This happens when the
queried name is valid but it does not have a record of the desired
type. Of course, the server has authority over the domain.
However, once again, some implementations of resolvers do not
interpret this kind of a response reasonably. They always expect an
answer record when they see an authoritative NOERROR. These entities
continue to resend their queries, possibly endlessly.
A GOOD IMPLEMENTATION
BIND resolver code does not query a server more than 3 times. If it
is unable to get an answer from 4 servers, querying them three times
each, it returns error.
Of course, it treats a zero-answer response the way it should be
treated; with respect!
FIXES:
a. Set an upper limit on the number of retransmissions for a given
query, at the very least.
Kumar, Postel, Neuman, Danzig & Miller [Page 5]
RFC 1536 Common DNS Implementation Errors October 1993
b. Fix resolvers to interpret such a response as an authoritative
statement of non-existence of the record type for the given
name.
4. Inability to detect server failure:
Servers in the internet are not very reliable (they go down every
once in a while) and resolvers are expected to adapt to the changed
scenario by not querying the server for a while. Thus, when a server
does not respond to a query, resolvers should try another server.
Also, non-stub resolvers should update their round trip time estimate
for the server to a large value so that server is not tried again
before other, faster servers.
Stub resolvers, however, cycle through a fixed set of servers and if,
unfortunately, a server is down while others do not respond for other
reasons (high load, recursive resolution of query is taking more time
than the resolver's time-out, ....), the resolver queries the dead
server again! In fact, some resolvers might not set an upper limit on
the number of query retransmissions they will send and continue to
query dead servers indefinitely.
Name servers running system or chained queries might also suffer from
the same problem. They store names of servers they should query for a
given domain. They cycle through these names and in case none of them
answers, hit each one more than one. It is, once again, important
that there be an upper limit on the number of retransmissions, to
prevent network overload.
This behavior is clearly in violation of the dictum in RFC 1035 (page
46)
"If a resolver gets a server error or other bizarre response
from a name server, it should remove it from SLIST, and may
wish to schedule an immediate transmission to the next
candidate server address."
Removal from SLIST implies that the server is not queried again for
some time.
Correctly implemented full-service resolvers should, as pointed out
before, update round trip time values for servers that do not respond
and query them only after other, good servers. Full-service resolvers
might, however, not follow any of these common sense directives. They
query dead servers, and they query them endlessly.
Kumar, Postel, Neuman, Danzig & Miller [Page 6]
RFC 1536 Common DNS Implementation Errors October 1993
A GOOD IMPLEMENTATION:
BIND places an upper limit on the number of times it queries a
server. Both the stub-resolver and the full-service resolver code do
this. Also, since the full-service resolver estimates round-trip
times and sorts name server addresses by these estimates, it does not
query a dead server again, until and unless all the other servers in
the list are dead too! Further, BIND implements exponential back-off
too.
FIXES:
a. Set an upper limit on number of retransmissions.
b. Measure round-trip time from servers (some estimate is better
than none). Treat no response as a "very large" round-trip
time.
c. Maintain a weighted rtt estimate and decay the "large" value
slowly, with time, so that the server is eventually tested
again, but not after an indefinitely long period.
d. Follow an exponential back-off scheme so that even if you do
not restrict the number of queries, you do not overload the
net excessively.
5. Cache Leaks:
Every resource record returned by a server is cached for TTL seconds,
where the TTL value is returned with the RR. Full-service (or stub)
resolvers cache the RR and answer any queries based on this cached
information, in the future, until the TTL expires. After that, one
more query to the wide-area network gets the RR in cache again.
Full-service resolvers might not implement this caching mechanism
well. They might impose a limit on the cache size or might not
interpret the TTL value correctly. In either case, queries repeated
within a TTL period of a RR constitute a cache leak.
A GOOD/BAD IMPLEMENTATION:
BIND has no restriction on the cache size and the size is governed by
the limits on the virtual address space of the machine it is running
on. BIND caches RRs for the duration of the TTL returned with each
record.
It does, however, not follow the RFCs with respect to interpretation
of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses
Kumar, Postel, Neuman, Danzig & Miller [Page 7]
RFC 1536 Common DNS Implementation Errors October 1993
the minimum TTL value, for that zone, from the SOA record and caches
it for that duration. This, though it saves some traffic on the
wide-area network, is not correct behavior.
FIXES:
a. Look over your caching mechanism to ensure TTLs are interpreted
correctly.
b. Do not restrict cache sizes (come on, memory is cheap!).
Expired entries are reclaimed periodically, anyway. Of course,
the cache size is bound to have some physical limit. But, when
possible, this limit should be large (run your name server on
a machine with a large amount of physical memory).
c. Possibly, a mechanism is needed to flush the cache, when it is
known or even suspected that the information has changed.
6. Name Error Bugs:
This bug is very similar to the Zero Answer bug. A server returns an
authoritative NXDOMAIN when the queried name is known to be bad, by
the server authoritative for the domain, in the absence of negative
caching. This authoritative NXDOMAIN response is usually accompanied
by the SOA record for the domain, in the authority section.
Resolvers should recognize that the name they queried for was a bad
name and should stop querying further.
Some resolvers might, however, not interpret this correctly and
continue to query servers, expecting an answer record.
Some applications, in fact, prompt NXDOMAIN answers! When given a
perfectly good name to resolve, they append the local domain to it
e.g., an application in the domain "foo.bar.com", when trying to
resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then
"usc.edu.bar.com" and finally the good name "usc.edu". This causes at
least two queries that return NXDOMAIN, for every good query. The
problem is aggravated since the negative answers from the previous
queries are not cached. When the same name is sought again, the
process repeats.
Some DNS resolver implementations suffer from this problem, too. They
append successive sub-parts of the local domain using an implicit
searchlist mechanism, when certain conditions are satisfied and try
the original name, only when this first set of iterations fails. This
behavior recently caused pandemonium in the Internet when the domain
"edu.com" was registered and a wildcard "CNAME" record placed at the
Kumar, Postel, Neuman, Danzig & Miller [Page 8]
RFC 1536 Common DNS Implementation Errors October 1993
top level. All machines from "com" domains trying to connect to hosts
in the "edu" domain ended up with connections to the local machine in
the "edu.com" domain!
GOOD/BAD IMPLEMENTATIONS:
Some local versions of BIND already implement negative caching. They
typically cache negative answers with a very small TTL, sufficient to
answer a burst of queries spaced close together, as is typically
seen.
The next official public release of BIND (4.9.2) will have negative
caching as an ifdef'd feature.
The BIND resolver appends local domain to the given name, when one of
two conditions is met:
i. The name has no periods and the flag RES_DEFNAME is set.
ii. There is no trailing period and the flag RES_DNSRCH is set.
The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in
BIND, but can be changed at compile time.
Only if the name, so generated, returns an NXDOMAIN is the original
name tried as a Fully Qualified Domain Name. And only if it contains
at least one period.
FIXES:
a. Fix the resolver code.
b. Negative Caching. Negative caching servers will restrict the
traffic seen on the wide-area network, even if not curb it
altogether.
c. Applications and resolvers should not append the local domain to
names they seek to resolve, as far as possible. Names
interspersed with periods should be treated as Fully Qualified
Domain Names.
In other words, Use searchlists only when explicitly specified.
No implicit searchlists should be used. A name that contains
any dots should first be tried as a FQDN and if that fails, with
the local domain name (or searchlist if specified) appended. A
name containing no dots can be appended with the searchlist right
away, but once again, no implicit searchlists should be used.
Kumar, Postel, Neuman, Danzig & Miller [Page 9]
RFC 1536 Common DNS Implementation Errors October 1993
Associated with the name error bug is another problem where a server
might return an authoritative NXDOMAIN, although the name is valid. A
secondary server, on start-up, reads the zone information from the
primary, through a zone transfer. While it is in the process of
loading the zones, it does not have information about them, although
it is authoritative for them. Thus, any query for a name in that
domain is answered with an NXDOMAIN response code. This problem might
not be disastrous were it not for negative caching servers that cache
this answer and so propagate incorrect information over the internet.
BAD IMPLEMENTATION:
BIND apparently suffers from this problem.
Also, a new name added to the primary database will take a while to
propagate to the secondaries. Until that time, they will return
NXDOMAIN answers for a good name. Negative caching servers store this
answer, too and aggravate this problem further. This is probably a
more general DNS problem but is apparently more harmful in this
situation.
FIX:
a. Servers should start answering only after loading all the zone
data. A failed server is better than a server handing out
incorrect information.
b. Negative cache records for a very small time, sufficient only
to ward off a burst of requests for the same bad name. This
could be related to the round-trip time of the server from
which the negative answer was received. Alternatively, a
statistical measure of the amount of time for which queries
for such names are received could be used. Minimum TTL value
from the SOA record is not advisable since they tend to be
pretty large.
c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed
and implemented, to allow the primary server to inform
secondaries that the database has been modified since it last
transferred zone data. To alleviate the problem of "too many
zone transfers" that this might cause, Incremental Zone
Transfers should also be part of DNS. Also, the primary should
not NOTIFY/PUSH with every update but bunch a good number
together.
Kumar, Postel, Neuman, Danzig & Miller [Page 10]
RFC 1536 Common DNS Implementation Errors October 1993
7. Format Errors:
Some resolvers issue query packets that do not necessarily conform to
standards as laid out in the relevant RFCs. This unnecessarily
increases net traffic and wastes server time.
FIXES:
a. Fix resolvers.
b. Each resolver verify format of packets before sending them out,
using a mechanism outside of the resolver. This is, obviously,
needed only if step 1 cannot be followed.
References
[1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
RFC 1034, USC/Information Sciences Institute, November 1987.
[2] Mockapetris, P., "Domain Names Implementation and Specification",
STD 13, RFC 1035, USC/Information Sciences Institute, November
1987.
[3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
974, CSNET CIC BBN, January 1986.
[4] Gavron, E., "A Security Problem and Proposed Correction With
Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
October 1993.
[5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
1537, CWI, October 1993.
Security Considerations
Security issues are not discussed in this memo.
Kumar, Postel, Neuman, Danzig & Miller [Page 11]
RFC 1536 Common DNS Implementation Errors October 1993
Authors' Addresses
Anant Kumar
USC Information Sciences Institute
4676 Admiralty Way
Marina Del Rey CA 90292-6695
Phone:(310) 822-1511
FAX: (310) 823-6741
EMail: anant@isi.edu
Jon Postel
USC Information Sciences Institute
4676 Admiralty Way
Marina Del Rey CA 90292-6695
Phone:(310) 822-1511
FAX: (310) 823-6714
EMail: postel@isi.edu
Cliff Neuman
USC Information Sciences Institute
4676 Admiralty Way
Marina Del Rey CA 90292-6695
Phone:(310) 822-1511
FAX: (310) 823-6714
EMail: bcn@isi.edu
Peter Danzig
Computer Science Department
University of Southern California
University Park
EMail: danzig@caldera.usc.edu
Steve Miller
Computer Science Department
University of Southern California
University Park
Los Angeles CA 90089
EMail: smiller@caldera.usc.edu
Kumar, Postel, Neuman, Danzig & Miller [Page 12]

507
doc/rfc/rfc1537.txt Normal file
View file

@ -0,0 +1,507 @@
Network Working Group P. Beertema
Request for Comments: 1537 CWI
Category: Informational October 1993
Common DNS Data File Configuration Errors
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
Abstract
This memo describes errors often found in DNS data files. It points
out common mistakes system administrators tend to make and why they
often go unnoticed for long periods of time.
Introduction
Due to the lack of extensive documentation and automated tools, DNS
zone files have mostly been configured by system administrators, by
hand. Some of the rules for writing the data files are rather subtle
and a few common mistakes are seen in domains worldwide.
This document is an attempt to list "surprises" that administrators
might find hidden in their zone files. It describes the symptoms of
the malady and prescribes medicine to cure that. It also gives some
general recommendations and advice on specific nameserver and zone
file issues and on the (proper) use of the Domain Name System.
1. SOA records
A problem I've found in quite some nameservers is that the various
timers have been set (far) too low. Especially for top level domain
nameservers this causes unnecessary traffic over international and
intercontinental links.
Unfortunately the examples given in the BIND manual, in RFC's and in
some expert documents give those very short timer values, and that's
most likely what people have modeled their SOA records after.
First of all a short explanation of the timers used in the SOA
record:
Beertema [Page 1]
RFC 1537 Common DNS Data File Configuration Errors October 1993
- Refresh: The SOA record of the primary server is checked
every "refresh" time by the secondary servers;
if it has changed, a zone transfer is done.
- Retry: If a secondary server cannot reach the primary
server, it tries it again every "retry" time.
- Expire: If for "expire" time the primary server cannot
be reached, all information about the zone is
invalidated on the secondary servers (i.e., they
are no longer authoritative for that zone).
- Minimum TTL: The default TTL value for all records in the
zone file; a different TTL value may be given
explicitly in a record when necessary.
(This timer is named "Minimum", and that's
what it's function should be according to
STD 13, RFC 1035, but most (all?)
implementations take it as the default value
exported with records without an explicit TTL
value).
For top level domain servers I would recommend the following values:
86400 ; Refresh 24 hours
7200 ; Retry 2 hours
2592000 ; Expire 30 days
345600 ; Minimum TTL 4 days
For other servers I would suggest:
28800 ; Refresh 8 hours
7200 ; Retry 2 hours
604800 ; Expire 7 days
86400 ; Minimum TTL 1 day
but here the frequency of changes, the required speed of propagation,
the reachability of the primary server etc. play a role in optimizing
the timer values.
2. Glue records
Quite often, people put unnecessary glue (A) records in their zone
files. Even worse is that I've even seen *wrong* glue records for an
external host in a primary zone file! Glue records need only be in a
zone file if the server host is within the zone and there is no A
record for that host elsewhere in the zone file.
Beertema [Page 2]
RFC 1537 Common DNS Data File Configuration Errors October 1993
Old BIND versions ("native" 4.8.3 and older versions) showed the
problem that wrong glue records could enter secondary servers in a
zone transfer.
3. "Secondary server surprise"
I've seen it happen on various occasions that hosts got bombarded by
nameserver requests without knowing why. On investigation it turned
out then that such a host was supposed to (i.e., the information was
in the root servers) run secondary for some domain (or reverse (in-
addr.arpa)) domain, without that host's nameserver manager having
been asked or even been told so!
Newer BIND versions (4.9 and later) solved this problem. At the same
time though the fix has the disadvantage that it's far less easy to
spot this problem.
Practice has shown that most domain registrars accept registrations
of nameservers without checking if primary (!) and secondary servers
have been set up, informed, or even asked. It should also be noted
that a combination of long-lasting unreachability of primary
nameservers, (therefore) expiration of zone information, plus static
IP routing, can lead to massive network traffic that can fill up
lines completely.
4. "MX records surprise"
In a sense similar to point 3. Sometimes nameserver managers enter MX
records in their zone files that point to external hosts, without
first asking or even informing the systems managers of those external
hosts. This has to be fought out between the nameserver manager and
the systems managers involved. Only as a last resort, if really
nothing helps to get the offending records removed, can the systems
manager turn to the naming authority of the domain above the
offending domain to get the problem sorted out.
5. "Name extension surprise"
Sometimes one encounters weird names, which appear to be an external
name extended with a local domain. This is caused by forgetting to
terminate a name with a dot: names in zone files that don't end with
a dot are always expanded with the name of the current zone (the
domain that the zone file stands for or the last $ORIGIN).
Example: zone file for foo.xx:
pqr MX 100 relay.yy.
xyz MX 100 relay.yy (no trailing dot!)
Beertema [Page 3]
RFC 1537 Common DNS Data File Configuration Errors October 1993
When fully written out this stands for:
pqr.foo.xx. MX 100 relay.yy.
xyz.foo.xx. MX 100 relay.yy.foo.xx. (name extension!)
6. Missing secondary servers
It is required that there be a least 2 nameservers for a domain. For
obvious reasons the nameservers for top level domains need to be very
well reachable from all over the Internet. This implies that there
must be more than just 2 of them; besides, most of the (secondary)
servers should be placed at "strategic" locations, e.g., close to a
point where international and/or intercontinental lines come
together. To keep things manageable, there shouldn't be too many
servers for a domain either.
Important aspects in selecting the location of primary and secondary
servers are reliability (network, host) and expedient contacts: in
case of problems, changes/fixes must be carried out quickly. It
should be considered logical that primary servers for European top
level domains should run on a host in Europe, preferably (if
possible) in the country itself. For each top level domain there
should be 2 secondary servers in Europe and 2 in the USA, but there
may of course be more on either side. An excessive number of
nameservers is not a good idea though; a recommended maximum is 7
nameservers. In Europe, EUnet has offered to run secondary server
for each European top level domain.
7. Wildcard MX records
Wildcard MX records should be avoided where possible. They often
cause confusion and errors: especially beginning nameserver managers
tend to overlook the fact that a host/domain listed with ANY type of
record in a zone file is NOT covered by an overall wildcard MX record
in that zone; this goes not only for simple domain/host names, but
also for names that cover one or more domains. Take the following
example in zone foo.bar:
* MX 100 mailhost
pqr MX 100 mailhost
abc.def MX 100 mailhost
This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
domains, but the wildcard MX record covers NONE of them, nor anything
below them. To cover everything by MX records, the required entries
are:
Beertema [Page 4]
RFC 1537 Common DNS Data File Configuration Errors October 1993
* MX 100 mailhost
pqr MX 100 mailhost
*.pqr MX 100 mailhost
abc.def MX 100 mailhost
*.def MX 100 mailhost
*.abc.def MX 100 mailhost
An overall wildcard MX record is almost never useful.
In particular the zone file of a top level domain should NEVER
contain only an overall wildcard MX record (*.XX). The effect of such
a wildcard MX record can be that mail is unnecessarily sent across
possibly expensive links, only to fail at the destination or gateway
that the record points to. Top level domain zone files should
explicitly list at least all the officially registered primary
subdomains.
Whereas overall wildcard MX records should be avoided, wildcard MX
records are acceptable as an explicit part of subdomain entries,
provided they are allowed under a given subdomain (to be determined
by the naming authority for that domain).
Example:
foo.xx. MX 100 gateway.xx.
MX 200 fallback.yy.
*.foo.xx. MX 100 gateway.xx.
MX 200 fallback.yy.
8. Hostnames
People appear to sometimes look only at STD 11, RFC 822 to determine
whether a particular hostname is correct or not. Hostnames should
strictly conform to the syntax given in STD 13, RFC 1034 (page 11),
with *addresses* in addition conforming to RFC 822. As an example
take "c&w.blues" which is perfectly legal according to RFC 822, but
which can have quite surprising effects on particular systems, e.g.,
"telnet c&w.blues" on a Unix system.
9. HINFO records
There appears to be a common misunderstanding that one of the data
fields (usually the second field) in HINFO records is optional. A
recent scan of all reachable nameservers in only one country revealed
some 300 incomplete HINFO records. Specifying two data fields in a
HINFO record is mandatory (RFC 1033), but note that this does *not*
mean that HINFO records themselves are mandatory.
Beertema [Page 5]
RFC 1537 Common DNS Data File Configuration Errors October 1993
10. Safety measures and specialties
Nameservers and resolvers aren't flawless. Bogus queries should be
kept from being forwarded to the root servers, since they'll only
lead to unnecessary intercontinental traffic. Known bogus queries
that can easily be dealt with locally are queries for 0 and broadcast
addresses. To catch such queries, every nameserver should run
primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone
files need only contain a SOA and an NS record.
Also each nameserver should run primary for 0.0.127.in-addr.arpa;
that zone file should contain a SOA and NS record and an entry:
1 PTR localhost.
There has been extensive discussion about whether or not to append
the local domain to it. The conclusion was that "localhost." would be
the best solution; reasons given were:
- "localhost" itself is used and expected to work on some systems.
- translating 127.0.0.1 into "localhost.my_domain" can cause some
software to connect to itself using the loopback interface when
it didn't want to.
Note that all domains that contain hosts should have a "localhost" A
record in them.
People maintaining zone files with the Serial number given in dotted
decimal notation (e.g., when SCCS is used to maintain the files)
should beware of a bug in all BIND versions: if the serial number is
in Release.Version (dotted decimal) notation, then it is virtually
impossible to change to a higher release: because of the wrong way
that notation is turned into an integer, it results in a serial
number that is LOWER than that of the former release.
For this reason and because the Serial is an (unsigned) integer
according to STD 13, RFC 1035, it is recommended not to use the
dotted decimal notation. A recommended notation is to use the date
(yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is
or can be more than one change per day in a zone file.
Very old versions of DNS resolver code have a bug that causes queries
for A records with domain names like "192.16.184.3" to go out. This
happens when users type in IP addresses and the resolver code does
not catch this case before sending out a DNS query. This problem has
been fixed in all resolver implementations known to us but if it
still pops up it is very serious because all those queries will go to
Beertema [Page 6]
RFC 1537 Common DNS Data File Configuration Errors October 1993
the root servers looking for top level domains like "3" etc. It is
strongly recommended to install the latest (publicly) available BIND
version plus all available patches to get rid of these and other
problems.
Running secondary nameserver off another secondary nameserver is
possible, but not recommended unless really necessary: there are
known cases where it has led to problems like bogus TTL values. This
can be caused by older or flawed implementations, but secondary
nameservers in principle should always transfer their zones from the
official primary nameserver.
11. Some general points
The Domain Name System and nameserver are purely technical tools, not
meant in any way to exert control or impose politics. The function of
a naming authority is that of a clearing house. Anyone registering a
subdomain under a particular (top level) domain becomes naming
authority and therewith the sole responsible for that subdomain.
Requests to enter MX or NS records concerning such a subdomain
therefore always MUST be honored by the registrar of the next higher
domain.
Examples of practices that are not allowed are:
- imposing specific mail routing (MX records) when registering
a subdomain.
- making registration of a subdomain dependent on to the use of
certain networks or services.
- using TXT records as a means of (free) commercial advertising.
In the latter case a network service provider could decide to cut off
a particular site until the offending TXT records have been removed
from the site's zone file.
Of course there are obvious cases where a naming authority can refuse
to register a particular subdomain and can require a proposed name to
be changed in order to get it registered (think of DEC trying to
register a domain IBM.XX).
There are also cases were one has to probe the authority of the
person: sending in the application - not every systems manager should
be able to register a domain name for a whole university. The naming
authority can impose certain extra rules as long as they don't
violate or conflict with the rights and interest of the registrars of
subdomains; a top level domain registrar may e.g., require that there
Beertema [Page 7]
RFC 1537 Common DNS Data File Configuration Errors October 1993
be primary subdomain "ac" and "co" only and that subdomains be
registered under those primary subdomains.
The naming authority can also interfere in exceptional cases like the
one mentioned in point 4, e.g., by temporarily removing a domain's
entry from the nameserver zone files; this of course should be done
only with extreme care and only as a last resort.
When adding NS records for subdomains, top level domain nameserver
managers should realize that the people setting up the nameserver for
a subdomain often are rather inexperienced and can make mistakes that
can easily lead to the subdomain becoming completely unreachable or
that can cause unnecessary DNS traffic (see point 1). It is therefore
highly recommended that, prior to entering such an NS record, the
(top level) nameserver manager does a couple of sanity checks on the
new nameserver (SOA record and timers OK?, MX records present where
needed? No obvious errors made? Listed secondary servers
operational?). Things that cannot be caught though by such checks
are:
- resolvers set up to use external hosts as nameservers
- nameservers set up to use external hosts as forwarders
without permission from those hosts.
Care should also be taken when registering 2-letter subdomains.
Although this is allowed, an implication is that abbreviated
addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in
and under that subdomain. When requested to register such a domain,
one should always notify the people of this consequence. As an
example take the name "cs", which is commonly used for Computer
Science departments: it is also the name of the top level domain for
Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is
ambiguous in that in can denote both a user on the host
host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia.
(This example does not take into account the recent political changes
in the mentioned country).
References
[1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
RFC 1034, USC/Information Sciences Institute, November 1987.
[2] Mockapetris, P., "Domain Names Implementation and Specification",
STD 13, RFC 1035, USC/Information Sciences Institute, November
1987.
Beertema [Page 8]
RFC 1537 Common DNS Data File Configuration Errors October 1993
[3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
974, CSNET CIC BBN, January 1986.
[4] Gavron, E., "A Security Problem and Proposed Correction With
Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
October 1993.
[5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
"Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
USC/Information Sciences Institute, USC, October 1993.
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Piet Beertema
CWI
Kruislaan 413
NL-1098 SJ Amsterdam
The Netherlands
Phone: +31 20 592 4112
FAX: +31 20 592 4199
EMail: Piet.Beertema@cwi.nl
Editor's Address
Anant Kumar
USC Information Sciences Institute
4676 Admiralty Way
Marina Del Rey CA 90292-6695
Phone:(310) 822-1511
FAX: (310) 823-6741
EMail: anant@isi.edu
Beertema [Page 9]

395
doc/rfc/rfc1591.txt Normal file
View file

@ -0,0 +1,395 @@
Network Working Group J. Postel
Request for Comments: 1591 ISI
Category: Informational March 1994
Domain Name System Structure and Delegation
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
1. Introduction
This memo provides some information on the structure of the names in
the Domain Name System (DNS), specifically the top-level domain
names; and on the administration of domains. The Internet Assigned
Numbers Authority (IANA) is the overall authority for the IP
Addresses, the Domain Names, and many other parameters, used in the
Internet. The day-to-day responsibility for the assignment of IP
Addresses, Autonomous System Numbers, and most top and second level
Domain Names are handled by the Internet Registry (IR) and regional
registries.
2. The Top Level Structure of the Domain Names
In the Domain Name System (DNS) naming of computers there is a
hierarchy of names. The root of system is unnamed. There are a set
of what are called "top-level domain names" (TLDs). These are the
generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
letter country codes from ISO-3166. It is extremely unlikely that
any other TLDs will be created.
Under each TLD may be created a hierarchy of names. Generally, under
the generic TLDs the structure is very flat. That is, many
organizations are registered directly under the TLD, and any further
structure is up to the individual organizations.
In the country TLDs, there is a wide variation in the structure, in
some countries the structure is very flat, in others there is
substantial structural organization. In some country domains the
second levels are generic categories (such as, AC, CO, GO, and RE),
in others they are based on political geography, and in still others,
organization names are listed directly under the country code. The
organization for the US country domain is described in RFC 1480 [1].
Postel [Page 1]
RFC 1591 Domain Name System Structure and Delegation March 1994
Each of the generic TLDs was created for a general category of
organizations. The country code domains (for example, FR, NL, KR,
US) are each organized by an administrator for that country. These
administrators may further delegate the management of portions of the
naming tree. These administrators are performing a public service on
behalf of the Internet community. Descriptions of the generic
domains and the US country domain follow.
Of these generic domains, five are international in nature, and two
are restricted to use by entities in the United States.
World Wide Generic Domains:
COM - This domain is intended for commercial entities, that is
companies. This domain has grown very large and there is
concern about the administrative load and system performance if
the current growth pattern is continued. Consideration is
being taken to subdivide the COM domain and only allow future
commercial registrations in the subdomains.
EDU - This domain was originally intended for all educational
institutions. Many Universities, colleges, schools,
educational service organizations, and educational consortia
have registered here. More recently a decision has been taken
to limit further registrations to 4 year colleges and
universities. Schools and 2-year colleges will be registered
in the country domains (see US Domain, especially K12 and CC,
below).
NET - This domain is intended to hold only the computers of network
providers, that is the NIC and NOC computers, the
administrative computers, and the network node computers. The
customers of the network provider would have domain names of
their own (not in the NET TLD).
ORG - This domain is intended as the miscellaneous TLD for
organizations that didn't fit anywhere else. Some non-
government organizations may fit here.
INT - This domain is for organizations established by international
treaties, or international databases.
United States Only Generic Domains:
GOV - This domain was originally intended for any kind of government
office or agency. More recently a decision was taken to
register only agencies of the US Federal government in this
domain. State and local agencies are registered in the country
Postel [Page 2]
RFC 1591 Domain Name System Structure and Delegation March 1994
domains (see US Domain, below).
MIL - This domain is used by the US military.
Example country code Domain:
US - As an example of a country domain, the US domain provides for
the registration of all kinds of entities in the United States
on the basis of political geography, that is, a hierarchy of
<entity-name>.<locality>.<state-code>.US. For example,
"IBM.Armonk.NY.US". In addition, branches of the US domain are
provided within each state for schools (K12), community colleges
(CC), technical schools (TEC), state government agencies
(STATE), councils of governments (COG),libraries (LIB), museums
(MUS), and several other generic types of entities (see RFC 1480
for details [1]).
To find a contact for a TLD use the "whois" program to access the
database on the host rs.internic.net. Append "-dom" to the name of
TLD you are interested in. For example:
whois -h rs.internic.net us-dom
or
whois -h rs.internic.net edu-dom
3. The Administration of Delegated Domains
The Internet Assigned Numbers Authority (IANA) is responsible for the
overall coordination and management of the Domain Name System (DNS),
and especially the delegation of portions of the name space called
top-level domains. Most of these top-level domains are two-letter
country codes taken from the ISO standard 3166.
A central Internet Registry (IR) has been selected and designated to
handled the bulk of the day-to-day administration of the Domain Name
System. Applications for new top-level domains (for example, country
code domains) are handled by the IR with consultation with the IANA.
The central IR is INTERNIC.NET. Second level domains in COM, EDU,
ORG, NET, and GOV are registered by the Internet Registry at the
InterNIC. The second level domains in the MIL are registered by the
DDN registry at NIC.DDN.MIL. Second level names in INT are
registered by the PVM at ISI.EDU.
While all requests for new top-level domains must be sent to the
Internic (at hostmaster@internic.net), the regional registries are
often enlisted to assist in the administration of the DNS, especially
in solving problems with a country administration. Currently, the
RIPE NCC is the regional registry for Europe and the APNIC is the
Postel [Page 3]
RFC 1591 Domain Name System Structure and Delegation March 1994
regional registry for the Asia-Pacific region, while the INTERNIC
administers the North America region, and all the as yet undelegated
regions.
The contact mailboxes for these regional registries are:
INTERNIC hostmaster@internic.net
APNIC hostmaster@apnic.net
RIPE NCC ncc@ripe.net
The policy concerns involved when a new top-level domain is
established are described in the following. Also mentioned are
concerns raised when it is necessary to change the delegation of an
established domain from one party to another.
A new top-level domain is usually created and its management
delegated to a "designated manager" all at once.
Most of these same concerns are relevant when a sub-domain is
delegated and in general the principles described here apply
recursively to all delegations of the Internet DNS name space.
The major concern in selecting a designated manager for a domain is
that it be able to carry out the necessary responsibilities, and have
the ability to do a equitable, just, honest, and competent job.
1) The key requirement is that for each domain there be a designated
manager for supervising that domain's name space. In the case of
top-level domains that are country codes this means that there is
a manager that supervises the domain names and operates the domain
name system in that country.
The manager must, of course, be on the Internet. There must be
Internet Protocol (IP) connectivity to the nameservers and email
connectivity to the management and staff of the manager.
There must be an administrative contact and a technical contact
for each domain. For top-level domains that are country codes at
least the administrative contact must reside in the country
involved.
2) These designated authorities are trustees for the delegated
domain, and have a duty to serve the community.
The designated manager is the trustee of the top-level domain for
both the nation, in the case of a country code, and the global
Internet community.
Postel [Page 4]
RFC 1591 Domain Name System Structure and Delegation March 1994
Concerns about "rights" and "ownership" of domains are
inappropriate. It is appropriate to be concerned about
"responsibilities" and "service" to the community.
3) The designated manager must be equitable to all groups in the
domain that request domain names.
This means that the same rules are applied to all requests, all
requests must be processed in a non-discriminatory fashion, and
academic and commercial (and other) users are treated on an equal
basis. No bias shall be shown regarding requests that may come
from customers of some other business related to the manager --
e.g., no preferential service for customers of a particular data
network provider. There can be no requirement that a particular
mail system (or other application), protocol, or product be used.
There are no requirements on subdomains of top-level domains
beyond the requirements on higher-level domains themselves. That
is, the requirements in this memo are applied recursively. In
particular, all subdomains shall be allowed to operate their own
domain name servers, providing in them whatever information the
subdomain manager sees fit (as long as it is true and correct).
4) Significantly interested parties in the domain should agree that
the designated manager is the appropriate party.
The IANA tries to have any contending parties reach agreement
among themselves, and generally takes no action to change things
unless all the contending parties agree; only in cases where the
designated manager has substantially mis-behaved would the IANA
step in.
However, it is also appropriate for interested parties to have
some voice in selecting the designated manager.
There are two cases where the IANA and the central IR may
establish a new top-level domain and delegate only a portion of
it: (1) there are contending parties that cannot agree, or (2) the
applying party may not be able to represent or serve the whole
country. The later case sometimes arises when a party outside a
country is trying to be helpful in getting networking started in a
country -- this is sometimes called a "proxy" DNS service.
The Internet DNS Names Review Board (IDNB), a committee
established by the IANA, will act as a review panel for cases in
which the parties can not reach agreement among themselves. The
IDNB's decisions will be binding.
Postel [Page 5]
RFC 1591 Domain Name System Structure and Delegation March 1994
5) The designated manager must do a satisfactory job of operating the
DNS service for the domain.
That is, the actual management of the assigning of domain names,
delegating subdomains and operating nameservers must be done with
technical competence. This includes keeping the central IR (in
the case of top-level domains) or other higher-level domain
manager advised of the status of the domain, responding to
requests in a timely manner, and operating the database with
accuracy, robustness, and resilience.
There must be a primary and a secondary nameserver that have IP
connectivity to the Internet and can be easily checked for
operational status and database accuracy by the IR and the IANA.
In cases when there are persistent problems with the proper
operation of a domain, the delegation may be revoked, and possibly
delegated to another designated manager.
6) For any transfer of the designated manager trusteeship from one
organization to another, the higher-level domain manager (the IANA
in the case of top-level domains) must receive communications from
both the old organization and the new organization that assure the
IANA that the transfer in mutually agreed, and that the new
organization understands its responsibilities.
It is also very helpful for the IANA to receive communications
from other parties that may be concerned or affected by the
transfer.
4. Rights to Names
1) Names and Trademarks
In case of a dispute between domain name registrants as to the
rights to a particular name, the registration authority shall have
no role or responsibility other than to provide the contact
information to both parties.
The registration of a domain name does not have any Trademark
status. It is up to the requestor to be sure he is not violating
anyone else's Trademark.
2) Country Codes
The IANA is not in the business of deciding what is and what is
not a country.
Postel [Page 6]
RFC 1591 Domain Name System Structure and Delegation March 1994
The selection of the ISO 3166 list as a basis for country code
top-level domain names was made with the knowledge that ISO has a
procedure for determining which entities should be and should not
be on that list.
5. Security Considerations
Security issues are not discussed in this memo.
6. Acknowledgements
Many people have made comments on draft version of these descriptions
and procedures. Steve Goldstein and John Klensin have been
particularly helpful.
7. Author's Address
Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 310-822-1511
Fax: 310-823-6714
EMail: Postel@ISI.EDU
7. References
[1] Cooper, A., and J. Postel, "The US Domain", RFC 1480,
USC/Information Sciences Institute, June 1993.
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[4] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
974, CSNET CIC BBN, January 1986.
[7] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, Internet Engineering
Task Force, October 1989.
Postel [Page 7]

1683
doc/rfc/rfc1750.txt Normal file
View file

File diff suppressed because it is too large Load diff

394
doc/rfc/rfc1982.txt Normal file
View file

@ -0,0 +1,394 @@
Network Working Group R. Elz
Request for Comments: 1982 University of Melbourne
Updates: 1034, 1035 R. Bush
Category: Standards Track RGnet, Inc.
August 1996
Serial Number Arithmetic
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This memo defines serial number arithmetic, as used in the Domain
Name System. The DNS has long relied upon serial number arithmetic,
a concept which has never really been defined, certainly not in an
IETF document, though which has been widely understood. This memo
supplies the missing definition. It is intended to update RFC1034
and RFC1035.
1. Introduction
The serial number field of the SOA resource record is defined in
RFC1035 as
SERIAL The unsigned 32 bit version number of the original copy of
the zone. Zone transfers preserve this value. This value
wraps and should be compared using sequence space
arithmetic.
RFC1034 uses the same terminology when defining secondary server zone
consistency procedures.
Unfortunately the term "sequence space arithmetic" is not defined in
either RFC1034 or RFC1035, nor do any of their references provide
further information.
This phrase seems to have been intending to specify arithmetic as
used in TCP sequence numbers [RFC793], and defined in [IEN-74].
Unfortunately, the arithmetic defined in [IEN-74] is not adequate for
the purposes of the DNS, as no general comparison operator is
Elz & Bush Standards Track [Page 1]
RFC 1982 Serial Number Arithmetic August 1996
defined.
To avoid further problems with this simple field, this document
defines the field and the operations available upon it. This
definition is intended merely to clarify the intent of RFC1034 and
RFC1035, and is believed to generally agree with current
implementations. However, older, superseded, implementations are
known to have treated the serial number as a simple unsigned integer,
with no attempt to implement any kind of "sequence space arithmetic",
however that may have been interpreted, and further, ignoring the
requirement that the value wraps. Nothing can be done with these
implementations, beyond extermination.
2. Serial Number Arithmetic
Serial numbers are formed from non-negative integers from a finite
subset of the range of all integer values. The lowest integer in
every subset used for this purpose is zero, the maximum is always one
less than a power of two.
When considered as serial numbers however no value has any particular
significance, there is no minimum or maximum serial number, every
value has a successor and predecessor.
To define a serial number to be used in this way, the size of the
serial number space must be given. This value, called "SERIAL_BITS",
gives the power of two which results in one larger than the largest
integer corresponding to a serial number value. This also specifies
the number of bits required to hold every possible value of a serial
number of the defined type. The operations permitted upon serial
numbers are defined in the following section.
3. Operations upon the serial number
Only two operations are defined upon serial numbers, addition of a
positive integer of limited range, and comparison with another serial
number.
3.1. Addition
Serial numbers may be incremented by the addition of a positive
integer n, where n is taken from the range of integers
[0 .. (2^(SERIAL_BITS - 1) - 1)]. For a sequence number s, the
result of such an addition, s', is defined as
s' = (s + n) modulo (2 ^ SERIAL_BITS)
Elz & Bush Standards Track [Page 2]
RFC 1982 Serial Number Arithmetic August 1996
where the addition and modulus operations here act upon values that
are non-negative values of unbounded size in the usual ways of
integer arithmetic.
Addition of a value outside the range
[0 .. (2^(SERIAL_BITS - 1) - 1)] is undefined.
3.2. Comparison
Any two serial numbers, s1 and s2, may be compared. The definition
of the result of this comparison is as follows.
For the purposes of this definition, consider two integers, i1 and
i2, from the unbounded set of non-negative integers, such that i1 and
s1 have the same numeric value, as do i2 and s2. Arithmetic and
comparisons applied to i1 and i2 use ordinary unbounded integer
arithmetic.
Then, s1 is said to be equal to s2 if and only if i1 is equal to i2,
in all other cases, s1 is not equal to s2.
s1 is said to be less than s2 if, and only if, s1 is not equal to s2,
and
(i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or
(i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1))
s1 is said to be greater than s2 if, and only if, s1 is not equal to
s2, and
(i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or
(i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1))
Note that there are some pairs of values s1 and s2 for which s1 is
not equal to s2, but for which s1 is neither greater than, nor less
than, s2. An attempt to use these ordering operators on such pairs
of values produces an undefined result.
The reason for this is that those pairs of values are such that any
simple definition that were to define s1 to be less than s2 where
(s1, s2) is such a pair, would also usually cause s2 to be less than
s1, when the pair is (s2, s1). This would mean that the particular
order selected for a test could cause the result to differ, leading
to unpredictable implementations.
While it would be possible to define the test in such a way that the
inequality would not have this surprising property, while being
defined for all pairs of values, such a definition would be
Elz & Bush Standards Track [Page 3]
RFC 1982 Serial Number Arithmetic August 1996
unnecessarily burdensome to implement, and difficult to understand,
and would still allow cases where
s1 < s2 and (s1 + 1) > (s2 + 1)
which is just as non-intuitive.
Thus the problem case is left undefined, implementations are free to
return either result, or to flag an error, and users must take care
not to depend on any particular outcome. Usually this will mean
avoiding allowing those particular pairs of numbers to co-exist.
The relationships greater than or equal to, and less than or equal
to, follow in the natural way from the above definitions.
4. Corollaries
These definitions give rise to some results of note.
4.1. Corollary 1
For any sequence number s and any integer n such that addition of n
to s is well defined, (s + n) >= s. Further (s + n) == s only when
n == 0, in all other defined cases, (s + n) > s.
4.2. Corollary 2
If s' is the result of adding the non-zero integer n to the sequence
number s, and m is another integer from the range defined as able to
be added to a sequence number, and s" is the result of adding m to
s', then it is undefined whether s" is greater than, or less than s,
though it is known that s" is not equal to s.
4.3. Corollary 3
If s" from the previous corollary is further incremented, then there
is no longer any known relationship between the result and s.
4.4. Corollary 4
If in corollary 2 the value (n + m) is such that addition of the sum
to sequence number s would produce a defined result, then corollary 1
applies, and s" is known to be greater than s.
Elz & Bush Standards Track [Page 4]
RFC 1982 Serial Number Arithmetic August 1996
5. Examples
5.1. A trivial example
The simplest meaningful serial number space has SERIAL_BITS == 2. In
this space, the integers that make up the serial number space are 0,
1, 2, and 3. That is, 3 == 2^SERIAL_BITS - 1.
In this space, the largest integer that it is meaningful to add to a
sequence number is 2^(SERIAL_BITS - 1) - 1, or 1.
Then, as defined 0+1 == 1, 1+1 == 2, 2+1 == 3, and 3+1 == 0.
Further, 1 > 0, 2 > 1, 3 > 2, and 0 > 3. It is undefined whether
2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1.
5.2. A slightly larger example
Consider the case where SERIAL_BITS == 8. In this space the integers
that make up the serial number space are 0, 1, 2, ... 254, 255.
255 == 2^SERIAL_BITS - 1.
In this space, the largest integer that it is meaningful to add to a
sequence number is 2^(SERIAL_BITS - 1) - 1, or 127.
Addition is as expected in this space, for example: 255+1 == 0,
100+100 == 200, and 200+100 == 44.
Comparison is more interesting, 1 > 0, 44 > 0, 100 > 0, 100 > 44,
200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, and 44 > 200.
Note that 100+100 > 100, but that (100+100)+100 < 100. Incrementing
a serial number can cause it to become "smaller". Of course,
incrementing by a smaller number will allow many more increments to
be made before this occurs. However this is always something to be
aware of, it can cause surprising errors, or be useful as it is the
only defined way to actually cause a serial number to decrease.
The pairs of values 0 and 128, 1 and 129, 2 and 130, etc, to 127 and
255 are not equal, but in each pair, neither number is defined as
being greater than, or less than, the other.
It could be defined (arbitrarily) that 128 > 0, 129 > 1,
130 > 2, ..., 255 > 127, by changing the comparison operator
definitions, as mentioned above. However note that that would cause
255 > 127, while (255 + 1) < (127 + 1), as 0 < 128. Such a
definition, apart from being arbitrary, would also be more costly to
implement.
Elz & Bush Standards Track [Page 5]
RFC 1982 Serial Number Arithmetic August 1996
6. Citation
As this defined arithmetic may be useful for purposes other than for
the DNS serial number, it may be referenced as Serial Number
Arithmetic from RFC1982. Any such reference shall be taken as
implying that the rules of sections 2 to 5 of this document apply to
the stated values.
7. The DNS SOA serial number
The serial number in the DNS SOA Resource Record is a Serial Number
as defined above, with SERIAL_BITS being 32. That is, the serial
number is a non negative integer with values taken from the range
[0 .. 4294967295]. That is, a 32 bit unsigned integer.
The maximum defined increment is 2147483647 (2^31 - 1).
Care should be taken that the serial number not be incremented, in
one or more steps, by more than this maximum within the period given
by the value of SOA.expire. Doing so may leave some secondary
servers with out of date copies of the zone, but with a serial number
"greater" than that of the primary server. Of course, special
circumstances may require this rule be set aside, for example, when
the serial number needs to be set lower for some reason. If this
must be done, then take special care to verify that ALL servers have
correctly succeeded in following the primary server's serial number
changes, at each step.
Note that each, and every, increment to the serial number must be
treated as the start of a new sequence of increments for this
purpose, as well as being the continuation of all previous sequences
started within the period specified by SOA.expire.
Caution should also be exercised before causing the serial number to
be set to the value zero. While this value is not in any way special
in serial number arithmetic, or to the DNS SOA serial number, many
DNS implementations have incorrectly treated zero as a special case,
with special properties, and unusual behaviour may be expected if
zero is used as a DNS SOA serial number.
Elz & Bush Standards Track [Page 6]
RFC 1982 Serial Number Arithmetic August 1996
8. Document Updates
RFC1034 and RFC1035 are to be treated as if the references to
"sequence space arithmetic" therein are replaced by references to
serial number arithmetic, as defined in this document.
9. Security Considerations
This document does not consider security.
It is not believed that anything in this document adds to any
security issues that may exist with the DNS, nor does it do anything
to lessen them.
References
[RFC1034] Domain Names - Concepts and Facilities,
P. Mockapetris, STD 13, ISI, November 1987.
[RFC1035] Domain Names - Implementation and Specification
P. Mockapetris, STD 13, ISI, November 1987
[RFC793] Transmission Control protocol
Information Sciences Institute, STD 7, USC, September 1981
[IEN-74] Sequence Number Arithmetic
William W. Plummer, BB&N Inc, September 1978
Acknowledgements
Thanks to Rob Austein for suggesting clarification of the undefined
comparison operators, and to Michael Patton for attempting to locate
another reference for this procedure. Thanks also to members of the
IETF DNSIND working group of 1995-6, in particular, Paul Mockapetris.
Authors' Addresses
Robert Elz Randy Bush
Computer Science RGnet, Inc.
University of Melbourne 10361 NE Sasquatch Lane
Parkville, Vic, 3052 Bainbridge Island, Washington, 98110
Australia. United States.
EMail: kre@munnari.OZ.AU EMail: randy@psg.com
Elz & Bush Standards Track [Page 7]

451
doc/rfc/rfc1995.txt Normal file
View file

@ -0,0 +1,451 @@
Network Working Group M. Ohta
Request for Comments: 1995 Tokyo Institute of Technology
Updates: 1035 August 1996
Category: Standards Track
Incremental Zone Transfer in DNS
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document proposes extensions to the DNS protocols to provide an
incremental zone transfer (IXFR) mechanism.
1. Introduction
For rapid propagation of changes to a DNS database [STD13], it is
necessary to reduce latency by actively notifying servers of the
change. This is accomplished by the NOTIFY extension of the DNS
[NOTIFY].
The current full zone transfer mechanism (AXFR) is not an efficient
means to propagate changes to a small part of a zone, as it transfers
the entire zone file.
Incremental transfer (IXFR) as proposed is a more efficient
mechanism, as it transfers only the changed portion(s) of a zone.
In this document, a secondary name server which requests IXFR is
called an IXFR client and a primary or secondary name server which
responds to the request is called an IXFR server.
2. Brief Description of the Protocol
If an IXFR client, which likely has an older version of a zone,
thinks it needs new information about the zone (typically through SOA
refresh timeout or the NOTIFY mechanism), it sends an IXFR message
containing the SOA serial number of its, presumably outdated, copy of
the zone.
Ohta Standards Track [Page 1]
RFC 1995 Incremental Zone Transfer in DNS August 1996
An IXFR server should keep record of the newest version of the zone
and the differences between that copy and several older versions.
When an IXFR request with an older version number is received, the
IXFR server needs to send only the differences required to make that
version current. Alternatively, the server may choose to transfer
the entire zone just as in a normal full zone transfer.
When a zone has been updated, it should be saved in stable storage
before the new version is used to respond to IXFR (or AXFR) queries.
Otherwise, if the server crashes, data which is no longer available
may have been distributed to secondary servers, which can cause
persistent database inconsistencies.
If an IXFR query with the same or newer version number than that of
the server is received, it is replied to with a single SOA record of
the server's current version, just as in AXFR.
Transport of a query may be by either UDP or TCP. If an IXFR query
is via UDP, the IXFR server may attempt to reply using UDP if the
entire response can be contained in a single DNS packet. If the UDP
reply does not fit, the query is responded to with a single SOA
record of the server's current version to inform the client that a
TCP query should be initiated.
Thus, a client should first make an IXFR query using UDP. If the
query type is not recognized by the server, an AXFR (preceded by a
UDP SOA query) should be tried, ensuring backward compatibility. If
the query response is a single packet with the entire new zone, or if
the server does not have a newer version than the client, everything
is done. Otherwise, a TCP IXFR query should be tried.
To ensure integrity, servers should use UDP checksums for all UDP
responses. A cautious client which receives a UDP packet with a
checksum value of zero should ignore the result and try a TCP IXFR
instead.
The query type value of IXFR assigned by IANA is 251.
3. Query Format
The IXFR query packet format is the same as that of a normal DNS
query, but with the query type being IXFR and the authority section
containing the SOA record of client's version of the zone.
Ohta Standards Track [Page 2]
RFC 1995 Incremental Zone Transfer in DNS August 1996
4. Response Format
If incremental zone transfer is not available, the entire zone is
returned. The first and the last RR of the response is the SOA
record of the zone. I.e. the behavior is the same as an AXFR
response except the query type is IXFR.
If incremental zone transfer is available, one or more difference
sequences is returned. The list of difference sequences is preceded
and followed by a copy of the server's current version of the SOA.
Each difference sequence represents one update to the zone (one SOA
serial change) consisting of deleted RRs and added RRs. The first RR
of the deleted RRs is the older SOA RR and the first RR of the added
RRs is the newer SOA RR.
Modification of an RR is performed first by removing the original RR
and then adding the modified one.
The sequences of differential information are ordered oldest first
newest last. Thus, the differential sequences are the history of
changes made since the version known by the IXFR client up to the
server's current version.
RRs in the incremental transfer messages may be partial. That is, if
a single RR of multiple RRs of the same RR type changes, only the
changed RR is transferred.
An IXFR client, should only replace an older version with a newer
version after all the differences have been successfully processed.
An incremental response is different from that of a non-incremental
response in that it begins with two SOA RRs, the server's current SOA
followed by the SOA of the client's version which is about to be
replaced.
5. Purging Strategy
An IXFR server can not be required to hold all previous versions
forever and may delete them anytime. In general, there is a trade-off
between the size of storage space and the possibility of using IXFR.
Information about older versions should be purged if the total length
of an IXFR response would be longer than that of an AXFR response.
Given that the purpose of IXFR is to reduce AXFR overhead, this
strategy is quite reasonable. The strategy assures that the amount
of storage required is at most twice that of the current zone
information.
Ohta Standards Track [Page 3]
RFC 1995 Incremental Zone Transfer in DNS August 1996
Information older than the SOA expire period may also be purged.
6. Optional Condensation of Multiple Versions
An IXFR server may optionally condense multiple difference sequences
into a single difference sequence, thus, dropping information on
intermediate versions.
This may be beneficial if a lot of versions, not all of which are
useful, are generated. For example, if multiple ftp servers share a
single DNS name and the IP address associated with the name is
changed once a minute to balance load between the ftp servers, it is
not so important to keep track of all the history of changes.
But, this feature may not be so useful if an IXFR client has access
to two IXFR servers: A and B, with inconsistent condensation results.
The current version of the IXFR client, received from server A, may
be unknown to server B. In such a case, server B can not provide
incremental data from the unknown version and a full zone transfer is
necessary.
Condensation is completely optional. Clients can't detect from the
response whether the server has condensed the reply or not.
For interoperability, IXFR servers, including those without the
condensation feature, should not flag an error even if it receives a
client's IXFR request with a unknown version number and should,
instead, attempt to perform a full zone transfer.
7. Example
Given the following three generations of data with the current serial
number of 3,
JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
1 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP. IN A 133.69.136.1
NEZU.JAIN.AD.JP. IN A 133.69.136.5
NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added.
jain.ad.jp. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
2 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP. IN A 133.69.136.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4
IN A 192.41.197.2
Ohta Standards Track [Page 4]
RFC 1995 Incremental Zone Transfer in DNS August 1996
One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.
JAIN.AD.JP. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
3 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP. IN A 133.69.136.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3
IN A 192.41.197.2
The following IXFR query
+---------------------------------------------------+
Header | OPCODE=SQUERY |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | JAIN.AD.JP. IN SOA serial=1 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
could be replied to with the following full zone transfer message:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
| JAIN.AD.JP. IN NS NS.JAIN.AD.JP. |
| NS.JAIN.AD.JP. IN A 133.69.136.1 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
| JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
Ohta Standards Track [Page 5]
RFC 1995 Incremental Zone Transfer in DNS August 1996
or with the following incremental message:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
| JAIN.AD.JP. IN SOA serial=1 |
| NEZU.JAIN.AD.JP. IN A 133.69.136.5 |
| JAIN.AD.JP. IN SOA serial=2 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
| JAIN.AD.JP. IN SOA serial=2 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 |
| JAIN.AD.JP. IN SOA serial=3 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
| JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
or with the following condensed incremental message:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
| JAIN.AD.JP. IN SOA serial=1 |
| NEZU.JAIN.AD.JP. IN A 133.69.136.5 |
| JAIN.AD.JP. IN SOA serial=3 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
| JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
Ohta Standards Track [Page 6]
RFC 1995 Incremental Zone Transfer in DNS August 1996
or, if UDP packet overflow occurs, with the following message:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
8. Acknowledgements
The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
and Jon Postel.
For the refinement of the protocol and documentation, many people
have contributed including, but not limited to, Anant Kumar, Robert
Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the
members of the IETF DNSIND working group.
9. References
[NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt
Notification of Zone Changes", RFC 1996, August 1996.
[STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and
RFC 1035), November 1987.
10. Security Considerations
Though DNS is related to several security problems, no attempt is
made to fix them in this document.
This document is believed to introduce no additional security
problems to the current DNS protocol.
Ohta Standards Track [Page 7]
RFC 1995 Incremental Zone Transfer in DNS August 1996
11. Author's Address
Masataka Ohta
Computer Center
Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN
Phone: +81-3-5734-3299
Fax: +81-3-5734-3415
EMail: mohta@necom830.hpcl.titech.ac.jp
Ohta Standards Track [Page 8]

395
doc/rfc/rfc1996.txt Normal file
View file

@ -0,0 +1,395 @@
Network Working Group P. Vixie
Request for Comments: 1996 ISC
Updates: 1035 August 1996
Category: Standards Track
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This memo describes the NOTIFY opcode for DNS, by which a master
server advises a set of slave servers that the master's data has been
changed and that a query should be initiated to discover the new
data.
1. Rationale and Scope
1.1. Slow propagation of new and changed data in a DNS zone can be
due to a zone's relatively long refresh times. Longer refresh times
are beneficial in that they reduce load on the master servers, but
that benefit comes at the cost of long intervals of incoherence among
authority servers whenever the zone is updated.
1.2. The DNS NOTIFY transaction allows master servers to inform slave
servers when the zone has changed -- an interrupt as opposed to poll
model -- which it is hoped will reduce propagation delay while not
unduly increasing the masters' load. This specification only allows
slaves to be notified of SOA RR changes, but the architechture of
NOTIFY is intended to be extensible to other RR types.
1.3. This document intentionally gives more definition to the roles
of "Master," "Slave" and "Stealth" servers, their enumeration in NS
RRs, and the SOA MNAME field. In that sense, this document can be
considered an addendum to [RFC1035].
Vixie Standards Track [Page 1]
RFC 1996 DNS NOTIFY August 1996
2. Definitions and Invariants
2.1. The following definitions are used in this document:
Slave an authoritative server which uses zone transfer to
retrieve the zone. All slave servers are named in
the NS RRs for the zone.
Master any authoritative server configured to be the source
of zone transfer for one or more slave servers.
Primary Master master server at the root of the zone transfer
dependency graph. The primary master is named in the
zone's SOA MNAME field and optionally by an NS RR.
There is by definition only one primary master server
per zone.
Stealth like a slave server except not listed in an NS RR for
the zone. A stealth server, unless explicitly
configured to do otherwise, will set the AA bit in
responses and be capable of acting as a master. A
stealth server will only be known by other servers if
they are given static configuration data indicating
its existence.
Notify Set set of servers to be notified of changes to some
zone. Default is all servers named in the NS RRset,
except for any server also named in the SOA MNAME.
Some implementations will permit the name server
administrator to override this set or add elements to
it (such as, for example, stealth servers).
2.2. The zone's servers must be organized into a dependency graph
such that there is a primary master, and all other servers must use
AXFR or IXFR either from the primary master or from some slave which
is also a master. No loops are permitted in the AXFR dependency
graph.
3. NOTIFY Message
3.1. When a master has updated one or more RRs in which slave servers
may be interested, the master may send the changed RR's name, class,
type, and optionally, new RDATA(s), to each known slave server using
a best efforts protocol based on the NOTIFY opcode.
3.2. NOTIFY uses the DNS Message Format, although it uses only a
subset of the available fields. Fields not otherwise described
herein are to be filled with binary zero (0), and implementations
Vixie Standards Track [Page 2]
RFC 1996 DNS NOTIFY August 1996
must ignore all messages for which this is not the case.
3.3. NOTIFY is similar to QUERY in that it has a request message with
the header QR flag "clear" and a response message with QR "set". The
response message contains no useful information, but its reception by
the master is an indication that the slave has received the NOTIFY
and that the master can remove the slave from any retry queue for
this NOTIFY event.
3.4. The transport protocol used for a NOTIFY transaction will be UDP
unless the master has reason to believe that TCP is necessary; for
example, if a firewall has been installed between master and slave,
and only TCP has been allowed; or, if the changed RR is too large to
fit in a UDP/DNS datagram.
3.5. If TCP is used, both master and slave must continue to offer
name service during the transaction, even when the TCP transaction is
not making progress. The NOTIFY request is sent once, and a
"timeout" is said to have occurred if no NOTIFY response is received
within a reasonable interval.
3.6. If UDP is used, a master periodically sends a NOTIFY request to
a slave until either too many copies have been sent (a "timeout"), an
ICMP message indicating that the port is unreachable, or until a
NOTIFY response is received from the slave with a matching query ID,
QNAME, IP source address, and UDP source port number.
Note:
The interval between transmissions, and the total number of
retransmissions, should be operational parameters specifiable by
the name server administrator, perhaps on a per-zone basis.
Reasonable defaults are a 60 second interval (or timeout if
using TCP), and a maximum of 5 retransmissions (for UDP). It is
considered reasonable to use additive or exponential backoff for
the retry interval.
3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
ADCOUNT>=0. If ANCOUNT>0, then the answer section represents an
unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>. A
slave receiving such a hint is free to treat equivilence of this
answer section with its local data as a "no further work needs to be
done" indication. If ANCOUNT=0, or ANCOUNT>0 and the answer section
differs from the slave's local data, then the slave should query its
known masters to retrieve the new data.
3.8. In no case shall the answer section of a NOTIFY request be used
to update a slave's local data, or to indicate that a zone transfer
needs to be undertaken, or to change the slave's zone refresh timers.
Vixie Standards Track [Page 3]
RFC 1996 DNS NOTIFY August 1996
Only a "data present; data same" condition can lead a slave to act
differently if ANCOUNT>0 than it would if ANCOUNT=0.
3.9. This version of the NOTIFY specification makes no use of the
authority or additional data sections, and so conforming
implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting
requests. Since a future revision of this specification may define a
backwards compatible use for either or both of these sections,
current implementations must ignore these sections, but not the
entire message, if AUCOUNT>0 and/or ADCOUNT>0.
3.10. If a slave receives a NOTIFY request from a host that is not a
known master for the zone containing the QNAME, it should ignore the
request and produce an error message in its operations log.
Note:
This implies that slaves of a multihomed master must either know
their master by the "closest" of the master's interface
addresses, or must know all of the master's interface addresses.
Otherwise, a valid NOTIFY request might come from an address
that is not on the slave's state list of masters for the zone,
which would be an error.
3.11. The only defined NOTIFY event at this time is that the SOA RR
has changed. Upon completion of a NOTIFY transaction for QTYPE=SOA,
the slave should behave as though the zone given in the QNAME had
reached its REFRESH interval (see [RFC1035]), i.e., it should query
its masters for the SOA of the zone given in the NOTIFY QNAME, and
check the answer to see if the SOA SERIAL has been incremented since
the last time the zone was fetched. If so, a zone transfer (either
AXFR or IXFR) should be initiated.
Note:
Because a deep server dependency graph may have multiple paths
from the primary master to any given slave, it is possible that
a slave will receive a NOTIFY from one of its known masters even
though the rest of its known masters have not yet updated their
copies of the zone. Therefore, when issuing a QUERY for the
zone's SOA, the query should be directed at the known master who
was the source of the NOTIFY event, and not at any of the other
known masters. This represents a departure from [RFC1035],
which specifies that upon expiry of the SOA REFRESH interval,
all known masters should be queried in turn.
3.12. If a NOTIFY request is received by a slave who does not
implement the NOTIFY opcode, it will respond with a NOTIMP
(unimplemented feature error) message. A master server who receives
such a NOTIMP should consider the NOTIFY transaction complete for
Vixie Standards Track [Page 4]
RFC 1996 DNS NOTIFY August 1996
that slave.
4. Details and Examples
4.1. Retaining query state information across host reboots is
optional, but it is reasonable to simply execute an SOA NOTIFY
transaction on each authority zone when a server first starts.
4.2. Each slave is likely to receive several copies of the same
NOTIFY request: One from the primary master, and one from each other
slave as that slave transfers the new zone and notifies its potential
peers. The NOTIFY protocol supports this multiplicity by requiring
that NOTIFY be sent by a slave/master only AFTER it has updated the
SOA RR or has determined that no update is necessary, which in
practice means after a successful zone transfer. Thus, barring
delivery reordering, the last NOTIFY any slave receives will be the
one indicating the latest change. Since a slave always requests SOAs
and AXFR/IXFRs only from its known masters, it will have an
opportunity to retry its QUERY for the SOA after each of its masters
have completed each zone update.
4.3. If a master server seeks to avoid causing a large number of
simultaneous outbound zone transfers, it may delay for an arbitrary
length of time before sending a NOTIFY message to any given slave.
It is expected that the time will be chosen at random, so that each
slave will begin its transfer at a unique time. The delay shall not
in any case be longer than the SOA REFRESH time.
Note:
This delay should be a parameter that each primary master name
server can specify, perhaps on a per-zone basis. Random delays
of between 30 and 60 seconds would seem adequate if the servers
share a LAN and the zones are of moderate size.
4.4. A slave which receives a valid NOTIFY should defer action on any
subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
completed the transaction begun by the first NOTIFY. This duplicate
rejection is necessary to avoid having multiple notifications lead to
pummeling the master server.
Vixie Standards Track [Page 5]
RFC 1996 DNS NOTIFY August 1996
4.5 Zone has Updated on Primary Master
Primary master sends a NOTIFY request to all servers named in Notify
Set. The NOTIFY request has the following characteristics:
query ID: (new)
op: NOTIFY (4)
resp: NOERROR
flags: AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_SOA
4.6 Zone has Updated on a Slave that is also a Master
As above in 4.5, except that this server's Notify Set may be
different from the Primary Master's due to optional static
specification of local stealth servers.
4.7 Slave Receives a NOTIFY Request from a Master
When a slave server receives a NOTIFY request from one of its locally
designated masters for the zone enclosing the given QNAME, with
QTYPE=SOA and QR=0, it should enter the state it would if the zone's
refresh timer had expired. It will also send a NOTIFY response back
to the NOTIFY request's source, with the following characteristics:
query ID: (same)
op: NOTIFY (4)
resp: NOERROR
flags: QR AA
qcount: 1
qname: (zone name)
qclass: (zone class)
qtype: T_SOA
This is intended to be identical to the NOTIFY request, except that
the QR bit is also set. The query ID of the response must be the
same as was received in the request.
4.8 Master Receives a NOTIFY Response from Slave
When a master server receives a NOTIFY response, it deletes this
query from the retry queue, thus completing the "notification
process" of "this" RRset change to "that" server.
Vixie Standards Track [Page 6]
RFC 1996 DNS NOTIFY August 1996
5. Security Considerations
We believe that the NOTIFY operation's only security considerations
are:
1. That a NOTIFY request with a forged IP/UDP source address can
cause a slave to send spurious SOA queries to its masters,
leading to a benign denial of service attack if the forged
requests are sent very often.
2. That TCP spoofing could be used against a slave server given
NOTIFY as a means of synchronizing an SOA query and UDP/DNS
spoofing as a means of forcing a zone transfer.
6. References
[RFC1035]
Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[IXFR]
Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
7. Author's Address
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
Phone: +1 415 747 0204
EMail: paul@vix.com
Vixie Standards Track [Page 7]

563
doc/rfc/rfc2052.txt Normal file
View file

@ -0,0 +1,563 @@
Network Working Group A. Gulbrandsen
Request for Comments: 2052 Troll Technologies
Updates: 1035, 1183 P. Vixie
Category: Experimental Vixie Enterprises
October 1996
A DNS RR for specifying the location of services (DNS SRV)
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Abstract
This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain (like a more general
form of MX).
Overview and rationale
Currently, one must either know the exact address of a server to
contact it, or broadcast a question. This has led to, for example,
ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC-
level broadcasts to locate servers.
The SRV RR allows administrators to use several servers for a single
domain, to move services from host to host with little fuss, and to
designate some hosts as primary servers for a service and others as
backups.
Clients ask for a specific service/protocol for a specific domain
(the word domain is used here in the strict RFC 1034 sense), and get
back the names of any available servers.
Introductory example
When a SRV-cognizant web-browser wants to retrieve
http://www.asdf.com/
it does a lookup of
http.tcp.www.asdf.com
Gulbrandsen & Vixie Experimental [Page 1]
RFC 2052 DNS SRV RR October 1996
and retrieves the document from one of the servers in the reply. The
example zone file near the end of the memo contains answering RRs for
this query.
The format of the SRV RR
Here is the format of the SRV RR, whose DNS type code is 33:
Service.Proto.Name TTL Class SRV Priority Weight Port Target
(There is an example near the end of this document.)
Service
The symbolic name of the desired service, as defined in Assigned
Numbers or locally.
Some widely used services, notably POP, don't have a single
universal name. If Assigned Numbers names the service
indicated, that name is the only name which is legal for SRV
lookups. Only locally defined services may be named locally.
The Service is case insensitive.
Proto
TCP and UDP are at present the most useful values
for this field, though any name defined by Assigned Numbers or
locally may be used (as for Service). The Proto is case
insensitive.
Name
The domain this RR refers to. The SRV RR is unique in that the
name one searches for is not this name; the example near the end
shows this clearly.
TTL
Standard DNS meaning.
Class
Standard DNS meaning.
Priority
As for MX, the priority of this target host. A client MUST
attempt to contact the target host with the lowest-numbered
priority it can reach; target hosts with the same priority
SHOULD be tried in pseudorandom order. The range is 0-65535.
Gulbrandsen & Vixie Experimental [Page 2]
RFC 2052 DNS SRV RR October 1996
Weight
Load balancing mechanism. When selecting a target host among
the those that have the same priority, the chance of trying this
one first SHOULD be proportional to its weight. The range of
this number is 1-65535. Domain administrators are urged to use
Weight 0 when there isn't any load balancing to do, to make the
RR easier to read for humans (less noisy).
Port
The port on this target host of this service. The range is
0-65535. This is often as specified in Assigned Numbers but
need not be.
Target
As for MX, the domain name of the target host. There MUST be
one or more A records for this name. Implementors are urged, but
not required, to return the A record(s) in the Additional Data
section. Name compression is to be used for this field.
A Target of "." means that the service is decidedly not
available at this domain.
Domain administrator advice
Asking everyone to update their telnet (for example) clients when the
first internet site adds a SRV RR for Telnet/TCP is futile (even if
desirable). Therefore SRV will have to coexist with A record lookups
for a long time, and DNS administrators should try to provide A
records to support old clients:
- Where the services for a single domain are spread over several
hosts, it seems advisable to have a list of A RRs at the same
DNS node as the SRV RR, listing reasonable (if perhaps
suboptimal) fallback hosts for Telnet, NNTP and other protocols
likely to be used with this name. Note that some programs only
try the first address they get back from e.g. gethostbyname(),
and we don't know how widespread this behaviour is.
- Where one service is provided by several hosts, one can either
provide A records for all the hosts (in which case the round-
robin mechanism, where available, will share the load equally)
or just for one (presumably the fastest).
- If a host is intended to provide a service only when the main
server(s) is/are down, it probably shouldn't be listed in A
records.
Gulbrandsen & Vixie Experimental [Page 3]
RFC 2052 DNS SRV RR October 1996
- Hosts that are referenced by backup A records must use the port
number specified in Assigned Numbers for the service.
Currently there's a practical limit of 512 bytes for DNS replies.
Until all resolvers can handle larger responses, domain
administrators are strongly advised to keep their SRV replies below
512 bytes.
All round numbers, wrote Dr. Johnson, are false, and these numbers
are very round: A reply packet has a 30-byte overhead plus the name
of the service ("telnet.tcp.asdf.com" for instance); each SRV RR adds
20 bytes plus the name of the target host; each NS RR in the NS
section is 15 bytes plus the name of the name server host; and
finally each A RR in the additional data section is 20 bytes or so,
and there are A's for each SRV and NS RR mentioned in the answer.
This size estimate is extremely crude, but shouldn't underestimate
the actual answer size by much. If an answer may be close to the
limit, using e.g. "dig" to look at the actual answer is a good idea.
The "Weight" field
Weight, the load balancing field, is not quite satisfactory, but the
actual load on typical servers changes much too quickly to be kept
around in DNS caches. It seems to the authors that offering
administrators a way to say "this machine is three times as fast as
that one" is the best that can practically be done.
The only way the authors can see of getting a "better" load figure is
asking a separate server when the client selects a server and
contacts it. For short-lived services like SMTP an extra step in the
connection establishment seems too expensive, and for long-lived
services like telnet, the load figure may well be thrown off a minute
after the connection is established when someone else starts or
finishes a heavy job.
The Port number
Currently, the translation from service name to port number happens
at the client, often using a file such as /etc/services.
Moving this information to the DNS makes it less necessary to update
these files on every single computer of the net every time a new
service is added, and makes it possible to move standard services out
of the "root-only" port range on unix
Gulbrandsen & Vixie Experimental [Page 4]
RFC 2052 DNS SRV RR October 1996
Usage rules
A SRV-cognizant client SHOULD use this procedure to locate a list of
servers and connect to the preferred one:
Do a lookup for QNAME=service.protocol.target, QCLASS=IN,
QTYPE=SRV.
If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
RR which specifies the requested Service and Protocol in the
reply:
If there is precisely one SRV RR, and its Target is "."
(the root domain), abort.
Else, for all such RR's, build a list of (Priority, Weight,
Target) tuples
Sort the list by priority (lowest number first)
Create a new empty list
For each distinct priority level
While there are still elements left at this priority
level
Select an element randomly, with probability
Weight, and move it to the tail of the new list
For each element in the new list
query the DNS for A RR's for the Target or use any
RR's found in the Additional Data secion of the
earlier SRV query.
for each A RR found, try to connect to the (protocol,
address, service).
else if the service desired is SMTP
skip to RFC 974 (MX).
else
Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
for each A RR found, try to connect to the (protocol,
address, service)
Gulbrandsen & Vixie Experimental [Page 5]
RFC 2052 DNS SRV RR October 1996
Notes:
- Port numbers SHOULD NOT be used in place of the symbolic service
or protocol names (for the same reason why variant names cannot
be allowed: Applications would have to do two or more lookups).
- If a truncated response comes back from an SRV query, and the
Additional Data section has at least one complete RR in it, the
answer MUST be considered complete and the client resolver
SHOULD NOT retry the query using TCP, but use normal UDP queries
for A RR's missing from the Additional Data section.
- A client MAY use means other than Weight to choose among target
hosts with equal Priority.
- A client MUST parse all of the RR's in the reply.
- If the Additional Data section doesn't contain A RR's for all
the SRV RR's and the client may want to connect to the target
host(s) involved, the client MUST look up the A RR(s). (This
happens quite often when the A RR has shorter TTL than the SRV
or NS RR's.)
- A future standard could specify that a SRV RR whose Protocol was
TCP and whose Service was SMTP would override RFC 974's rules
with regard to the use of an MX RR. This would allow firewalled
organizations with several SMTP relays to control the load
distribution using the Weight field.
- Future protocols could be designed to use SRV RR lookups as the
means by which clients locate their servers.
Fictional example
This is (part of) the zone file for asdf.com, a still-unused domain:
$ORIGIN asdf.com.
@ SOA server.asdf.com. root.asdf.com. (
1995032001 3600 3600 604800 86400 )
NS server.asdf.com.
NS ns1.ip-provider.net.
NS ns2.ip-provider.net.
ftp.tcp SRV 0 0 21 server.asdf.com.
finger.tcp SRV 0 0 79 server.asdf.com.
; telnet - use old-slow-box or new-fast-box if either is
; available, make three quarters of the logins go to
; new-fast-box.
telnet.tcp SRV 0 1 23 old-slow-box.asdf.com.
Gulbrandsen & Vixie Experimental [Page 6]
RFC 2052 DNS SRV RR October 1996
SRV 0 3 23 new-fast-box.asdf.com.
; if neither old-slow-box or new-fast-box is up, switch to
; using the sysdmin's box and the server
SRV 1 0 23 sysadmins-box.asdf.com.
SRV 1 0 23 server.asdf.com.
; HTTP - server is the main server, new-fast-box is the backup
; (On new-fast-box, the HTTP daemon runs on port 8000)
http.tcp SRV 0 0 80 server.asdf.com.
SRV 10 0 8000 new-fast-box.asdf.com.
; since we want to support both http://asdf.com/ and
; http://www.asdf.com/ we need the next two RRs as well
http.tcp.www SRV 0 0 80 server.asdf.com.
SRV 10 0 8000 new-fast-box.asdf.com.
; SMTP - mail goes to the server, and to the IP provider if
; the net is down
smtp.tcp SRV 0 0 25 server.asdf.com.
SRV 1 0 25 mailhost.ip-provider.net.
@ MX 0 server.asdf.com.
MX 1 mailhost.ip-provider.net.
; NNTP - use the IP providers's NNTP server
nntp.tcp SRV 0 0 119 nntphost.ip-provider.net.
; IDB is an locally defined protocol
idb.tcp SRV 0 0 2025 new-fast-box.asdf.com.
; addresses
server A 172.30.79.10
old-slow-box A 172.30.79.11
sysadmins-box A 172.30.79.12
new-fast-box A 172.30.79.13
; backup A records - new-fast-box and old-slow-box are
; included, naturally, and server is too, but might go
; if the load got too bad
@ A 172.30.79.10
A 172.30.79.11
A 172.30.79.13
; backup A RR for www.asdf.com
www A 172.30.79.10
; NO other services are supported
*.tcp SRV 0 0 0 .
*.udp SRV 0 0 0 .
In this example, a telnet connection to "asdf.com." needs an SRV
lookup of "telnet.tcp.asdf.com." and possibly A lookups of "new-
fast-box.asdf.com." and/or the other hosts named. The size of the
SRV reply is approximately 365 bytes:
30 bytes general overhead
20 bytes for the query string, "telnet.tcp.asdf.com."
130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
Gulbrandsen & Vixie Experimental [Page 7]
RFC 2052 DNS SRV RR October 1996
fast-box", "old-slow-box", "server" and "sysadmins-box" -
"asdf.com" in the query section is quoted here and doesn't
need to be counted again.
75 bytes for 3 NS RRs, 15 bytes each plus the lengths of
"server", "ns1.ip-provider.net." and "ns2" - again, "ip-
provider.net." is quoted and only needs to be counted once.
120 bytes for the 6 A RR's mentioned by the SRV and NS RR's.
Refererences
RFC 1918: Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
RFC 1918, February 1996.
RFC 1916 Berkowitz, H., Ferguson, P, Leland, W. and P. Nesser,
"Enterprise Renumbering: Experience and Information
Solicitation", RFC 1916, February 1996.
RFC 1912 Barr, D., "Common DNS Operational and Configuration
Errors", RFC 1912, February 1996.
RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
RFC 1900, February 1996.
RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS",
STD 1, RFC 1920, March 1996.
RFC 1814: Gerich, E., "Unique Addresses are Good", RFC 1814, June
1995.
RFC 1794: Brisco, T., "DNS Support for Load Balancing", April 1995.
RFC 1713: Romao, A., "Tools for DNS debugging", November 1994.
RFC 1712: Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni,
"DNS Encoding of Geographical Location", RFC 1712, November
1994.
RFC 1706: Manning, B. and R. Colella, "DNS NSAP Resource Records",
RFC 1706, October 1994.
RFC 1700: Reynolds, J., and J. Postel, "ASSIGNED NUMBERS",
STD 2, RFC 1700, October 1994.
RFC 1183: Ullmann, R., Mockapetris, P., Mamakos, L., and
C. Everhart, "New DNS RR Definitions", RFC 1183, November
1990.
Gulbrandsen & Vixie Experimental [Page 8]
RFC 2052 DNS SRV RR October 1996
RFC 1101: Mockapetris, P., "DNS encoding of network names and other
types", RFC 1101, April 1989.
RFC 1035: Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
RFC 1034: Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
RFC 1033: Lottor, M., "Domain administrators operations guide",
RFC 1033, November 1987.
RFC 1032: Stahl, M., "Domain administrators guide", RFC 1032,
November 1987.
RFC 974: Partridge, C., "Mail routing and the domain system",
STD 14, RFC 974, January 1986.
Security Considerations
The authors believes this RR to not cause any new security problems.
Some problems become more visible, though.
- The ability to specify ports on a fine-grained basis obviously
changes how a router can filter packets. It becomes impossible
to block internal clients from accessing specific external
services, slightly harder to block internal users from running
unautorised services, and more important for the router
operations and DNS operations personnel to cooperate.
- There is no way a site can keep its hosts from being referenced
as servers (as, indeed, some sites become unwilling secondary
MXes today). This could lead to denial of service.
- With SRV, DNS spoofers can supply false port numbers, as well as
host names and addresses. The authors do not see any practical
effect of this.
We assume that as the DNS-security people invent new features, DNS
servers will return the relevant RRs in the Additional Data section
when answering an SRV query.
Gulbrandsen & Vixie Experimental [Page 9]
RFC 2052 DNS SRV RR October 1996
Authors' Addresses
Arnt Gulbrandsen
Troll Tech
Postboks 6133 Etterstad
N-0602 Oslo
Norway
Phone: +47 22646966
EMail: agulbra@troll.no
Paul Vixie
Vixie Enterprises
Star Route 159A
Woodside, CA 94062
Phone: (415) 747-0204
EMail: paul@vix.com
Gulbrandsen & Vixie Experimental [Page 10]

620
doc/rfc/rfc2104.txt Normal file
View file

@ -0,0 +1,620 @@
Network Working Group H. Krawczyk
Request for Comments: 2104 IBM
Category: Informational M. Bellare
UCSD
R. Canetti
IBM
February 1997
HMAC: Keyed-Hashing for Message Authentication
Status of This Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document describes HMAC, a mechanism for message authentication
using cryptographic hash functions. HMAC can be used with any
iterative cryptographic hash function, e.g., MD5, SHA-1, in
combination with a secret shared key. The cryptographic strength of
HMAC depends on the properties of the underlying hash function.
1. Introduction
Providing a way to check the integrity of information transmitted
over or stored in an unreliable medium is a prime necessity in the
world of open computing and communications. Mechanisms that provide
such integrity check based on a secret key are usually called
"message authentication codes" (MAC). Typically, message
authentication codes are used between two parties that share a secret
key in order to validate information transmitted between these
parties. In this document we present such a MAC mechanism based on
cryptographic hash functions. This mechanism, called HMAC, is based
on work by the authors [BCK1] where the construction is presented and
cryptographically analyzed. We refer to that work for the details on
the rationale and security analysis of HMAC, and its comparison to
other keyed-hash methods.
Krawczyk, et. al. Informational [Page 1]
RFC 2104 HMAC February 1997
HMAC can be used in combination with any iterated cryptographic hash
function. MD5 and SHA-1 are examples of such hash functions. HMAC
also uses a secret key for calculation and verification of the
message authentication values. The main goals behind this
construction are
* To use, without modifications, available hash functions.
In particular, hash functions that perform well in software,
and for which code is freely and widely available.
* To preserve the original performance of the hash function without
incurring a significant degradation.
* To use and handle keys in a simple way.
* To have a well understood cryptographic analysis of the strength of
the authentication mechanism based on reasonable assumptions on the
underlying hash function.
* To allow for easy replaceability of the underlying hash function in
case that faster or more secure hash functions are found or
required.
This document specifies HMAC using a generic cryptographic hash
function (denoted by H). Specific instantiations of HMAC need to
define a particular hash function. Current candidates for such hash
functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD].
These different realizations of HMAC will be denoted by HMAC-SHA1,
HMAC-MD5, HMAC-RIPEMD, etc.
Note: To the date of writing of this document MD5 and SHA-1 are the
most widely used cryptographic hash functions. MD5 has been recently
shown to be vulnerable to collision search attacks [Dobb]. This
attack and other currently known weaknesses of MD5 do not compromise
the use of MD5 within HMAC as specified in this document (see
[Dobb]); however, SHA-1 appears to be a cryptographically stronger
function. To this date, MD5 can be considered for use in HMAC for
applications where the superior performance of MD5 is critical. In
any case, implementers and users need to be aware of possible
cryptanalytic developments regarding any of these cryptographic hash
functions, and the eventual need to replace the underlying hash
function. (See section 6 for more information on the security of
HMAC.)
Krawczyk, et. al. Informational [Page 2]
RFC 2104 HMAC February 1997
2. Definition of HMAC
The definition of HMAC requires a cryptographic hash function, which
we denote by H, and a secret key K. We assume H to be a cryptographic
hash function where data is hashed by iterating a basic compression
function on blocks of data. We denote by B the byte-length of such
blocks (B=64 for all the above mentioned examples of hash functions),
and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
SHA-1). The authentication key K can be of any length up to B, the
block length of the hash function. Applications that use keys longer
than B bytes will first hash the key using H and then use the
resultant L byte string as the actual key to HMAC. In any case the
minimal recommended length for K is L bytes (as the hash output
length). See section 3 for more information on keys.
We define two fixed and different strings ipad and opad as follows
(the 'i' and 'o' are mnemonics for inner and outer):
ipad = the byte 0x36 repeated B times
opad = the byte 0x5C repeated B times.
To compute HMAC over the data `text' we perform
H(K XOR opad, H(K XOR ipad, text))
Namely,
(1) append zeros to the end of K to create a B byte string
(e.g., if K is of length 20 bytes and B=64, then K will be
appended with 44 zero bytes 0x00)
(2) XOR (bitwise exclusive-OR) the B byte string computed in step
(1) with ipad
(3) append the stream of data 'text' to the B byte string resulting
from step (2)
(4) apply H to the stream generated in step (3)
(5) XOR (bitwise exclusive-OR) the B byte string computed in
step (1) with opad
(6) append the H result from step (4) to the B byte string
resulting from step (5)
(7) apply H to the stream generated in step (6) and output
the result
For illustration purposes, sample code based on MD5 is provided as an
appendix.
Krawczyk, et. al. Informational [Page 3]
RFC 2104 HMAC February 1997
3. Keys
The key for HMAC can be of any length (keys longer than B bytes are
first hashed using H). However, less than L bytes is strongly
discouraged as it would decrease the security strength of the
function. Keys longer than L bytes are acceptable but the extra
length would not significantly increase the function strength. (A
longer key may be advisable if the randomness of the key is
considered weak.)
Keys need to be chosen at random (or using a cryptographically strong
pseudo-random generator seeded with a random seed), and periodically
refreshed. (Current attacks do not indicate a specific recommended
frequency for key changes as these attacks are practically
infeasible. However, periodic key refreshment is a fundamental
security practice that helps against potential weaknesses of the
function and keys, and limits the damage of an exposed key.)
4. Implementation Note
HMAC is defined in such a way that the underlying hash function H can
be used with no modification to its code. In particular, it uses the
function H with the pre-defined initial value IV (a fixed value
specified by each iterative hash function to initialize its
compression function). However, if desired, a performance
improvement can be achieved at the cost of (possibly) modifying the
code of H to support variable IVs.
The idea is that the intermediate results of the compression function
on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed
only once at the time of generation of the key K, or before its first
use. These intermediate results are stored and then used to
initialize the IV of H each time that a message needs to be
authenticated. This method saves, for each authenticated message,
the application of the compression function of H on two B-byte blocks
(i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be
significant when authenticating short streams of data. We stress
that the stored intermediate values need to be treated and protected
the same as secret keys.
Choosing to implement HMAC in the above way is a decision of the
local implementation and has no effect on inter-operability.
Krawczyk, et. al. Informational [Page 4]
RFC 2104 HMAC February 1997
5. Truncated output
A well-known practice with message authentication codes is to
truncate the output of the MAC and output only part of the bits
(e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some
analytical advantages of truncating the output of hash-based MAC
functions. The results in this area are not absolute as for the
overall security advantages of truncation. It has advantages (less
information on the hash result available to an attacker) and
disadvantages (less bits to predict for the attacker). Applications
of HMAC can choose to truncate the output of HMAC by outputting the t
leftmost bits of the HMAC computation for some parameter t (namely,
the computation is carried in the normal way as defined in section 2
above but the end result is truncated to t bits). We recommend that
the output length t be not less than half the length of the hash
output (to match the birthday attack bound) and not less than 80 bits
(a suitable lower bound on the number of bits that need to be
predicted by an attacker). We propose denoting a realization of HMAC
that uses a hash function H with t bits of output as HMAC-H-t. For
example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
and with the output truncated to 80 bits. (If the parameter t is not
specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
hash are output.)
6. Security
The security of the message authentication mechanism presented here
depends on cryptographic properties of the hash function H: the
resistance to collision finding (limited to the case where the
initial value is secret and random, and where the output of the
function is not explicitly available to the attacker), and the
message authentication property of the compression function of H when
applied to single blocks (in HMAC these blocks are partially unknown
to an attacker as they contain the result of the inner H computation
and, in particular, cannot be fully chosen by the attacker).
These properties, and actually stronger ones, are commonly assumed
for hash functions of the kind used with HMAC. In particular, a hash
function for which the above properties do not hold would become
unsuitable for most (probably, all) cryptographic applications,
including alternative message authentication schemes based on such
functions. (For a complete analysis and rationale of the HMAC
function the reader is referred to [BCK1].)
Krawczyk, et. al. Informational [Page 5]
RFC 2104 HMAC February 1997
Given the limited confidence gained so far as for the cryptographic
strength of candidate hash functions, it is important to observe the
following two properties of the HMAC construction and its secure use
for message authentication:
1. The construction is independent of the details of the particular
hash function H in use and then the latter can be replaced by any
other secure (iterative) cryptographic hash function.
2. Message authentication, as opposed to encryption, has a
"transient" effect. A published breaking of a message authentication
scheme would lead to the replacement of that scheme, but would have
no adversarial effect on information authenticated in the past. This
is in sharp contrast with encryption, where information encrypted
today may suffer from exposure in the future if, and when, the
encryption algorithm is broken.
The strongest attack known against HMAC is based on the frequency of
collisions for the hash function H ("birthday attack") [PV,BCK2], and
is totally impractical for minimally reasonable hash functions.
As an example, if we consider a hash function like MD5 where the
output length equals L=16 bytes (128 bits) the attacker needs to
acquire the correct message authentication tags computed (with the
_same_ secret key K!) on about 2**64 known plaintexts. This would
require the processing of at least 2**64 blocks under H, an
impossible task in any realistic scenario (for a block length of 64
bytes this would take 250,000 years in a continuous 1Gbps link, and
without changing the secret key K during all this time). This attack
could become realistic only if serious flaws in the collision
behavior of the function H are discovered (e.g. collisions found
after 2**30 messages). Such a discovery would determine the immediate
replacement of the function H (the effects of such failure would be
far more severe for the traditional uses of H in the context of
digital signatures, public key certificates, etc.).
Note: this attack needs to be strongly contrasted with regular
collision attacks on cryptographic hash functions where no secret key
is involved and where 2**64 off-line parallelizable (!) operations
suffice to find collisions. The latter attack is approaching
feasibility [VW] while the birthday attack on HMAC is totally
impractical. (In the above examples, if one uses a hash function
with, say, 160 bit of output then 2**64 should be replaced by 2**80.)
Krawczyk, et. al. Informational [Page 6]
RFC 2104 HMAC February 1997
A correct implementation of the above construction, the choice of
random (or cryptographically pseudorandom) keys, a secure key
exchange mechanism, frequent key refreshments, and good secrecy
protection of keys are all essential ingredients for the security of
the integrity verification mechanism provided by HMAC.
Krawczyk, et. al. Informational [Page 7]
RFC 2104 HMAC February 1997
Appendix -- Sample Code
For the sake of illustration we provide the following sample code for
the implementation of HMAC-MD5 as well as some corresponding test
vectors (the code is based on MD5 code as described in [MD5]).
/*
** Function: hmac_md5
*/
void
hmac_md5(text, text_len, key, key_len, digest)
unsigned char* text; /* pointer to data stream */
int text_len; /* length of data stream */
unsigned char* key; /* pointer to authentication key */
int key_len; /* length of authentication key */
caddr_t digest; /* caller digest to be filled in */
{
MD5_CTX context;
unsigned char k_ipad[65]; /* inner padding -
* key XORd with ipad
*/
unsigned char k_opad[65]; /* outer padding -
* key XORd with opad
*/
unsigned char tk[16];
int i;
/* if key is longer than 64 bytes reset it to key=MD5(key) */
if (key_len > 64) {
MD5_CTX tctx;
MD5Init(&tctx);
MD5Update(&tctx, key, key_len);
MD5Final(tk, &tctx);
key = tk;
key_len = 16;
}
/*
* the HMAC_MD5 transform looks like:
*
* MD5(K XOR opad, MD5(K XOR ipad, text))
*
* where K is an n byte key
* ipad is the byte 0x36 repeated 64 times
Krawczyk, et. al. Informational [Page 8]
RFC 2104 HMAC February 1997
* opad is the byte 0x5c repeated 64 times
* and text is the data being protected
*/
/* start out by storing key in pads */
bzero( k_ipad, sizeof k_ipad);
bzero( k_opad, sizeof k_opad);
bcopy( key, k_ipad, key_len);
bcopy( key, k_opad, key_len);
/* XOR key with ipad and opad values */
for (i=0; i<64; i++) {
k_ipad[i] ^= 0x36;
k_opad[i] ^= 0x5c;
}
/*
* perform inner MD5
*/
MD5Init(&context); /* init context for 1st
* pass */
MD5Update(&context, k_ipad, 64) /* start with inner pad */
MD5Update(&context, text, text_len); /* then text of datagram */
MD5Final(digest, &context); /* finish up 1st pass */
/*
* perform outer MD5
*/
MD5Init(&context); /* init context for 2nd
* pass */
MD5Update(&context, k_opad, 64); /* start with outer pad */
MD5Update(&context, digest, 16); /* then results of 1st
* hash */
MD5Final(digest, &context); /* finish up 2nd pass */
}
Test Vectors (Trailing '\0' of a character string not included in test):
key = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
key_len = 16 bytes
data = "Hi There"
data_len = 8 bytes
digest = 0x9294727a3638bb1c13f48ef8158bfc9d
key = "Jefe"
data = "what do ya want for nothing?"
data_len = 28 bytes
digest = 0x750c783e6ab0b503eaa86e310a5db738
key = 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Krawczyk, et. al. Informational [Page 9]
RFC 2104 HMAC February 1997
key_len 16 bytes
data = 0xDDDDDDDDDDDDDDDDDDDD...
..DDDDDDDDDDDDDDDDDDDD...
..DDDDDDDDDDDDDDDDDDDD...
..DDDDDDDDDDDDDDDDDDDD...
..DDDDDDDDDDDDDDDDDDDD
data_len = 50 bytes
digest = 0x56be34521d144c88dbb8c733f0e8b3f6
Acknowledgments
Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided
useful comments on early drafts, and ran the first interoperability
tests of this specification. Jeff and Pau-Chen kindly provided the
sample code and test vectors that appear in the appendix. Burt
Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van
Oorschot have provided useful comments and suggestions during the
investigation of the HMAC construction.
References
[ANSI] ANSI X9.9, "American National Standard for Financial
Institution Message Authentication (Wholesale)," American
Bankers Association, 1981. Revised 1986.
[Atk] Atkinson, R., "IP Authentication Header", RFC 1826, August
1995.
[BCK1] M. Bellare, R. Canetti, and H. Krawczyk,
"Keyed Hash Functions and Message Authentication",
Proceedings of Crypto'96, LNCS 1109, pp. 1-15.
(http://www.research.ibm.com/security/keyed-md5.html)
[BCK2] M. Bellare, R. Canetti, and H. Krawczyk,
"Pseudorandom Functions Revisited: The Cascade Construction",
Proceedings of FOCS'96.
[Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack",
RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
http://www.rsa.com/rsalabs/pubs/cryptobytes.html
[PV] B. Preneel and P. van Oorschot, "Building fast MACs from hash
functions", Advances in Cryptology -- CRYPTO'95 Proceedings,
Lecture Notes in Computer Science, Springer-Verlag Vol.963,
1995, pp. 1-14.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
Krawczyk, et. al. Informational [Page 10]
RFC 2104 HMAC February 1997
[MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,
1982.
[RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A
strengthened version of RIPEMD", Fast Software Encryption,
LNCS Vol 1039, pp. 71-82.
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.
[SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[Tsu] G. Tsudik, "Message authentication with one-way hash
functions", In Proceedings of Infocom'92, May 1992.
(Also in "Access Control and Policy Enforcement in
Internetworks", Ph.D. Dissertation, Computer Science
Department, University of Southern California, April 1991.)
[VW] P. van Oorschot and M. Wiener, "Parallel Collision
Search with Applications to Hash Functions and Discrete
Logarithms", Proceedings of the 2nd ACM Conf. Computer and
Communications Security, Fairfax, VA, November 1994.
Authors' Addresses
Hugo Krawczyk
IBM T.J. Watson Research Center
P.O.Box 704
Yorktown Heights, NY 10598
EMail: hugo@watson.ibm.com
Mihir Bellare
Dept of Computer Science and Engineering
Mail Code 0114
University of California at San Diego
9500 Gilman Drive
La Jolla, CA 92093
EMail: mihir@cs.ucsd.edu
Ran Canetti
IBM T.J. Watson Research Center
P.O.Box 704
Yorktown Heights, NY 10598
EMail: canetti@watson.ibm.com
Krawczyk, et. al. Informational [Page 11]

171
doc/rfc/rfc2119.txt Normal file
View file

@ -0,0 +1,171 @@
Network Working Group S. Bradner
Request for Comments: 2119 Harvard University
BCP: 14 March 1997
Category: Best Current Practice
Key words for use in RFCs to Indicate Requirement Levels
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Abstract
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
Bradner Best Current Practice [Page 1]
RFC 2119 RFC Key Words March 1997
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
7. Security Considerations
These terms are frequently used to specify behavior with security
implications. The effects on security of not implementing a MUST or
SHOULD, or doing something the specification says MUST NOT or SHOULD
NOT be done may be very subtle. Document authors should take the time
to elaborate the security implications of not following
recommendations or requirements as most implementors will not have
had the benefit of the experience and discussion that produced the
specification.
8. Acknowledgments
The definitions of these terms are an amalgam of definitions taken
from a number of RFCs. In addition, suggestions have been
incorporated from a number of people including Robert Ullmann, Thomas
Narten, Neal McBurnett, and Robert Elz.
Bradner Best Current Practice [Page 2]
RFC 2119 RFC Key Words March 1997
9. Author's Address
Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138
phone - +1 617 495 3864
email - sob@harvard.edu
Bradner Best Current Practice [Page 3]

1460
doc/rfc/rfc2136.txt Normal file
View file

File diff suppressed because it is too large Load diff

619
doc/rfc/rfc2137.txt Normal file
View file

@ -0,0 +1,619 @@
Network Working Group D. Eastlake 3rd
Request for Comments: 2137 CyberCash, Inc.
Updates: 1035 April 1997
Category: Standards Track
Secure Domain Name System Dynamic Update
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
Domain Name System (DNS) protocol extensions have been defined to
authenticate the data in DNS and provide key distribution services
[RFC2065]. DNS Dynamic Update operations have also been defined
[RFC2136], but without a detailed description of security for the
update operation. This memo describes how to use DNSSEC digital
signatures covering requests and data to secure updates and restrict
updates to those authorized to perform them as indicated by the
updater's possession of cryptographic keys.
Acknowledgements
The contributions of the following persons (who are listed in
alphabetic order) to this memo are gratefully acknowledged:
Olafur Gudmundsson (ogud@tis.com>
Charlie Kaufman <Charlie_Kaufman@iris.com>
Stuart Kwan <skwan@microsoft.com>
Edward Lewis <lewis@tis.com>
Table of Contents
1. Introduction............................................2
1.1 Overview of DNS Dynamic Update.........................2
1.2 Overview of DNS Security...............................2
2. Two Basic Modes.........................................3
3. Keys....................................................5
3.1 Update Keys............................................6
3.1.1 Update Key Name Scope................................6
3.1.2 Update Key Class Scope...............................6
3.1.3 Update Key Signatory Field...........................6
Eastlake Standards Track [Page 1]
RFC 2137 SDNSDU April 1997
3.2 Zone Keys and Update Modes.............................8
3.3 Wildcard Key Punch Through.............................9
4. Update Signatures.......................................9
4.1 Update Request Signatures..............................9
4.2 Update Data Signatures................................10
5. Security Considerations................................10
References................................................10
Author's Address..........................................11
1. Introduction
Dynamic update operations have been defined for the Domain Name
System (DNS) in RFC 2136, but without a detailed description of
security for those updates. Means of securing the DNS and using it
for key distribution have been defined in RFC 2065.
This memo proposes techniques based on the defined DNS security
mechanisms to authenticate DNS updates.
Familiarity with the DNS system [RFC 1034, 1035] is assumed.
Familiarity with the DNS security and dynamic update proposals will
be helpful.
1.1 Overview of DNS Dynamic Update
DNS dynamic update defines a new DNS opcode, new DNS request and
response structure if that opcode is used, and new error codes. An
update can specify complex combinations of deletion and insertion
(with or without pre-existence testing) of resource records (RRs)
with one or more owner names; however, all testing and changes for
any particular DNS update request are restricted to a single zone.
Updates occur at the primary server for a zone.
The primary server for a secure dynamic zone must increment the zone
SOA serial number when an update occurs or the next time the SOA is
retrieved if one or more updates have occurred since the previous SOA
retrieval and the updates themselves did not update the SOA.
1.2 Overview of DNS Security
DNS security authenticates data in the DNS by also storing digital
signatures in the DNS as SIG resource records (RRs). A SIG RR
provides a digital signature on the set of all RRs with the same
owner name and class as the SIG and whose type is the type covered by
the SIG. The SIG RR cryptographically binds the covered RR set to
the signer, time signed, signature expiration date, etc. There are
one or more keys associated with every secure zone and all data in
the secure zone is signed either by a zone key or by a dynamic update
Eastlake Standards Track [Page 2]
RFC 2137 SDNSDU April 1997
key tracing its authority to a zone key.
DNS security also defines transaction SIGs and request SIGs.
Transaction SIGs appear at the end of a response. Transaction SIGs
authenticate the response and bind it to the corresponding request
with the key of the host where the responding DNS server is. Request
SIGs appear at the end of a request and authenticate the request with
the key of the submitting entity.
Request SIGs are the primary means of authenticating update requests.
DNS security also permits the storage of public keys in the DNS via
KEY RRs. These KEY RRs are also, of course, authenticated by SIG
RRs. KEY RRs for zones are stored in their superzone and subzone
servers, if any, so that the secure DNS tree of zones can be
traversed by a security aware resolver.
2. Two Basic Modes
A dynamic secure zone is any secure DNS zone containing one or more
KEY RRs that can authorize dynamic updates, i.e., entity or user KEY
RRs with the signatory field non-zero, and whose zone KEY RR
signatory field indicates that updates are implemented. There are two
basic modes of dynamic secure zone which relate to the update
strategy, mode A and mode B. A summary comparison table is given
below and then each mode is described.
Eastlake Standards Track [Page 3]
RFC 2137 SDNSDU April 1997
SUMMARY OF DYNAMIC SECURE ZONE MODES
CRITERIA: | MODE A | MODE B
=========================+====================+===================
Definition: | Zone Key Off line | Zone Key On line
=========================+====================+===================
Server Workload | Low | High
-------------------------+--------------------+-------------------
Static Data Security | Very High | Medium-High
-------------------------+--------------------+-------------------
Dynamic Data Security | Medium | Medium-High
-------------------------+--------------------+-------------------
Key Restrictions | Fine grain | Coarse grain
-------------------------+--------------------+-------------------
Dynamic Data Temporality | Transient | Permanent
-------------------------+--------------------+-------------------
Dynamic Key Rollover | No | Yes
-------------------------+--------------------+-------------------
For mode A, the zone owner key and static zone master file are always
kept off-line for maximum security of the static zone contents.
As a consequence, any dynamicly added or changed RRs are signed in
the secure zone by their authorizing dynamic update key and they are
backed up, along with this SIG RR, in a separate online dynamic
master file. In this type of zone, server computation is minimized
since the server need only check signatures on the update data and
request, which have already been signed by the updater, generally a
much faster operation than signing data. However, the AXFR SIG and
NXT RRs which covers the zone under the zone key will not cover
dynamically added data. Thus, for type A dynamic secure zones, zone
transfer security is not automatically provided for dynamically added
RRs, where they could be omitted, and authentication is not provided
for the server denial of the existence of a dynamically added type.
Because the dynamicly added RRs retain their update KEY signed SIG,
finer grained control of updates can be implemented via bits in the
KEY RR signatory field. Because dynamic data is only stored in the
online dynamic master file and only authenticated by dynamic keys
which expire, updates are transient in nature. Key rollover for an
entity that can authorize dynamic updates is more cumbersome since
the authority of their key must be traceable to a zone key and so, in
general, they must securely communicate a new key to the zone
authority for manual transfer to the off line static master file.
NOTE: for this mode the zone SOA must be signed by a dynamic update
key and that private key must be kept on line so that the SOA can be
changed for updates.
Eastlake Standards Track [Page 4]
RFC 2137 SDNSDU April 1997
For mode B, the zone owner key and master file are kept on-line at
the zone primary server. When authenticated updates succeed, SIGs
under the zone key for the resulting data (including the possible NXT
type bit map changes) are calculated and these SIG (and possible NXT)
changes are entered into the zone and the unified on-line master
file. (The zone transfer AXFR SIG may be recalculated for each
update or on demand when a zone transfer is requested and it is out
of date.)
As a consequence, this mode requires considerably more computational
effort on the part of the server as the public/private keys are
generally arranged so that signing (calculating a SIG) is more effort
than verifying a signature. The security of static data in the zone
is decreased because the ultimate state of the static data being
served and the ultimate zone authority private key are all on-line on
the net. This means that if the primary server is subverted, false
data could be authenticated to secondaries and other
servers/resolvers. On the other hand, this mode of operation means
that data added dynamically is more secure than in mode A. Dynamic
data will be covered by the AXFR SIG and thus always protected during
zone transfers and will be included in NXT RRs so that it can be
falsely denied by a server only to the same extent that static data
can (i.e., if it is within a wild card scope). Because the zone key
is used to sign all the zone data, the information as to who
originated the current state of dynamic RR sets is lost, making
unavailable the effects of some of the update control bits in the KEY
RR signatory field. In addition, the incorporation of the updates
into the primary master file and their authentication by the zone key
makes then permanent in nature. Maintaining the zone key on-line
also means that dynamic update keys which are signed by the zone key
can be dynamically updated since the zone key is available to
dynamically sign new values.
NOTE: The Mode A / Mode B distinction only effects the validation
and performance of update requests. It has no effect on retrievals.
One reasonable operational scheme may be to keep a mostly static main
zone operating in Mode A and have one or more dynamic subzones
operating in Mode B.
3. Keys
Dynamic update requests depend on update keys as described in section
3.1 below. In addition, the zone secure dynamic update mode and
availability of some options is indicated in the zone key. Finally,
a special rule is used in searching for KEYs to validate updates as
described in section 3.3.
Eastlake Standards Track [Page 5]
RFC 2137 SDNSDU April 1997
3.1 Update Keys
All update requests to a secure zone must include signatures by one
or more key(s) that together can authorize that update. In order for
the Domain Name System (DNS) server receiving the request to confirm
this, the key or keys must be available to and authenticated by that
server as a specially flagged KEY Resource Record.
The scope of authority of such keys is indicated by their KEY RR
owner name, class, and signatory field flags as described below. In
addition, such KEY RRs must be entity or user keys and not have the
authentication use prohibited bit on. All parts of the actual update
must be within the scope of at least one of the keys used for a
request SIG on the update request as described in section 4.
3.1.1 Update Key Name Scope
The owner name of any update authorizing KEY RR must (1) be the same
as the owner name of any RRs being added or deleted or (2) a wildcard
name including within its extended scope (see section 3.3) the name
of any RRs being added or deleted and those RRs must be in the same
zone.
3.1.2 Update Key Class Scope
The class of any update authorizing KEY RR must be the same as the
class of any RR's being added or deleted.
3.1.3 Update Key Signatory Field
The four bit "signatory field" (see RFC 2065) of any update
authorizing KEY RR must be non-zero. The bits have the meanings
described below for non-zone keys (see section 3.2 for zone type
keys).
UPDATE KEY RR SIGNATORY FIELD BITS
0 1 2 3
+-----------+-----------+-----------+-----------+
| zone | strong | unique | general |
+-----------+-----------+-----------+-----------+
Bit 0, zone control - If nonzero, this key is authorized to attach,
detach, and move zones by creating and deleting NS, glue A, and
zone KEY RR(s). If zero, the key can not authorize any update
that would effect such RRs. This bit is meaningful for both
type A and type B dynamic secure zones.
Eastlake Standards Track [Page 6]
RFC 2137 SDNSDU April 1997
NOTE: do not confuse the "zone" signatory field bit with the
"zone" key type bit.
Bit 1, strong update - If nonzero, this key is authorized to add and
delete RRs even if there are other RRs with the same owner name
and class that are authenticated by a SIG signed with a
different dynamic update KEY. If zero, the key can only
authorize updates where any existing RRs of the same owner and
class are authenticated by a SIG using the same key. This bit
is meaningful only for type A dynamic zones and is ignored in
type B dynamic zones.
Keeping this bit zero on multiple KEY RRs with the same or
nested wild card owner names permits multiple entities to exist
that can create and delete names but can not effect RRs with
different owner names from any they created. In effect, this
creates two levels of dynamic update key, strong and weak, where
weak keys are limited in interfering with each other but a
strong key can interfere with any weak keys or other strong
keys.
Bit 2, unique name update - If nonzero, this key is authorized to add
and update RRs for only a single owner name. If there already
exist RRs with one or more names signed by this key, they may be
updated but no new name created until the number of existing
names is reduced to zero. This bit is meaningful only for mode
A dynamic zones and is ignored in mode B dynamic zones. This bit
is meaningful only if the owner name is a wildcard. (Any
dynamic update KEY with a non-wildcard name is, in effect, a
unique name update key.)
This bit can be used to restrict a KEY from flooding a zone with
new names. In conjunction with a local administratively imposed
limit on the number of dynamic RRs with a particular name, it
can completely restrict a KEY from flooding a zone with RRs.
Bit 3, general update - The general update signatory field bit has no
special meaning. If the other three bits are all zero, it must
be one so that the field is non-zero to designate that the key
is an update key. The meaning of all values of the signatory
field with the general bit and one or more other signatory field
bits on is reserved.
All the signatory bit update authorizations described above only
apply if the update is within the name and class scope as per
sections 3.1.1 and 3.1.2.
Eastlake Standards Track [Page 7]
RFC 2137 SDNSDU April 1997
3.2 Zone Keys and Update Modes
Zone type keys are automatically authorized to sign anything in their
zone, of course, regardless of the value of their signatory field.
For zone keys, the signatory field bits have different means than
they they do for update keys, as shown below. The signatory field
MUST be zero if dynamic update is not supported for a zone and MUST
be non-zero if it is.
ZONE KEY RR SIGNATORY FIELD BITS
0 1 2 3
+-----------+-----------+-----------+-----------+
| mode | strong | unique | general |
+-----------+-----------+-----------+-----------+
Bit 0, mode - This bit indicates the update mode for this zone. Zero
indicates mode A while a one indicates mode B.
Bit 1, strong update - If nonzero, this indicates that the "strong"
key feature described in section 3.1.3 above is implemented and
enabled for this secure zone. If zero, the feature is not
available. Has no effect if the zone is a mode B secure update
zone.
Bit 2, unique name update - If nonzero, this indicates that the
"unique name" feature described in section 3.1.3 above is
implemented and enabled for this secure zone. If zero, this
feature is not available. Has no effect if the zone is a mode B
secure update zone.
Bit 3, general - This bit has no special meeting. If dynamic update
for a zone is supported and the other bits in the zone key
signatory field are zero, it must be a one. The meaning of zone
keys where the signatory field has the general bit and one or
more other bits on is reserved.
If there are multiple dynamic update KEY RRs for a zone and zone
policy is in transition, they might have different non-zero signatory
fields. In that case, strong and unique name restrictions must be
enforced as long as there is a non-expired zone key being advertised
that indicates mode A with the strong or unique name bit on
respectively. Mode B updates MUST be supported as long as there is a
non-expired zone key that indicates mode B. Mode A updates may be
treated as mode B updates at server option if non-expired zone keys
indicate that both are supported.
Eastlake Standards Track [Page 8]
RFC 2137 SDNSDU April 1997
A server that will be executing update operations on a zone, that is,
the primary master server, MUST not advertize a zone key that will
attract requests for a mode or features that it can not support.
3.3 Wildcard Key Punch Through
Just as a zone key is valid throughout the entire zone, update keys
with wildcard names are valid throughout their extended scope, within
the zone. That is, they remain valid for any name that would match
them, even existing specific names within their apparent scope.
If this were not so, then whenever a name within a wildcard scope was
created by dynamic update, it would be necessary to first create a
copy of the KEY RR with this name, because otherwise the existence of
the more specific name would hide the authorizing KEY RR and would
make later updates impossible. An updater could create such a KEY RR
but could not zone sign it with their authorizing signer. They would
have to sign it with the same key using the wildcard name as signer.
Thus in creating, for example, one hundred type A RRs authorized by a
*.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100
KEYs, and 200 SIGs would have to be created as opposed to merely 100
As and 100 SIGs with key punch through.
4. Update Signatures
Two kinds of signatures can appear in updates. Request signatures,
which are always required, cover the entire request and authenticate
the DNS header, including opcode, counts, etc., as well as the data.
Data signatures, on the other hand, appear only among the RRs to be
added and are only required for mode A operation. These two types of
signatures are described further below.
4.1 Update Request Signatures
An update can effect multiple owner names in a zone. It may be that
these different names are covered by different dynamic update keys.
For every owner name effected, the updater must know a private key
valid for that name (and the zone's class) and must prove this by
appending request SIG RRs under each such key.
As specified in RFC 2065, a request signature is a SIG RR occurring
at the end of a request with a type covered field of zero. For an
update, request signatures occur in the Additional information
section. Each request SIG signs the entire request, including DNS
header, but excluding any other request SIG(s) and with the ARCOUNT
in the DNS header set to what it wold be without the request SIGs.
Eastlake Standards Track [Page 9]
RFC 2137 SDNSDU April 1997
4.2 Update Data Signatures
Mode A dynamic secure zones require that the update requester provide
SIG RRs that will authenticate the after update state of all RR sets
that are changed by the update and are non-empty after the update.
These SIG RRs appear in the request as RRs to be added and the
request must delete any previous data SIG RRs that are invalidated by
the request.
In Mode B dynamic secure zones, all zone data is authenticated by
zone key SIG RRs. In this case, data signatures need not be included
with the update. A resolver can determine which mode an updatable
secure zone is using by examining the signatory field bits of the
zone KEY RR (see section 3.2).
5. Security Considerations
Any zone permitting dynamic updates is inherently less secure than a
static secure zone maintained off line as recommended in RFC 2065. If
nothing else, secure dynamic update requires on line change to and
re-signing of the zone SOA resource record (RR) to increase the SOA
serial number. This means that compromise of the primary server host
could lead to arbitrary serial number changes.
Isolation of dynamic RRs to separate zones from those holding most
static RRs can limit the damage that could occur from breach of a
dynamic zone's security.
References
[RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, CyberCash, Iris, January 1997.
[RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
Eastlake Standards Track [Page 10]
RFC 2137 SDNSDU April 1997
Author's Address
Donald E. Eastlake, 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Phone: +1 508-287-4877
+1 508-371-7148 (fax)
+1 703-620-4200 (main office, Reston, Virginia, USA)
EMail: dee@cybercash.com
Eastlake Standards Track [Page 11]

842
doc/rfc/rfc2181.txt Normal file
View file

@ -0,0 +1,842 @@
Network Working Group R. Elz
Request for Comments: 2181 University of Melbourne
Updates: 1034, 1035, 1123 R. Bush
Category: Standards Track RGnet, Inc.
July 1997
Clarifications to the DNS Specification
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
1. Abstract
This document considers some areas that have been identified as
problems with the specification of the Domain Name System, and
proposes remedies for the defects identified. Eight separate issues
are considered:
+ IP packet header address usage from multi-homed servers,
+ TTLs in sets of records with the same name, class, and type,
+ correct handling of zone cuts,
+ three minor issues concerning SOA records and their use,
+ the precise definition of the Time to Live (TTL)
+ Use of the TC (truncated) header bit
+ the issue of what is an authoritative, or canonical, name,
+ and the issue of what makes a valid DNS label.
The first six of these are areas where the correct behaviour has been
somewhat unclear, we seek to rectify that. The other two are already
adequately specified, however the specifications seem to be sometimes
ignored. We seek to reinforce the existing specifications.
Elz & Bush Standards Track [Page 1]
RFC 2181 Clarifications to the DNS Specification July 1997
Contents
1 Abstract ................................................... 1
2 Introduction ............................................... 2
3 Terminology ................................................ 3
4 Server Reply Source Address Selection ...................... 3
5 Resource Record Sets ....................................... 4
6 Zone Cuts .................................................. 8
7 SOA RRs .................................................... 10
8 Time to Live (TTL) ......................................... 10
9 The TC (truncated) header bit .............................. 11
10 Naming issues .............................................. 11
11 Name syntax ................................................ 13
12 Security Considerations .................................... 14
13 References ................................................. 14
14 Acknowledgements ........................................... 15
15 Authors' Addresses ......................................... 15
2. Introduction
Several problem areas in the Domain Name System specification
[RFC1034, RFC1035] have been noted through the years [RFC1123]. This
document addresses several additional problem areas. The issues here
are independent. Those issues are the question of which source
address a multi-homed DNS server should use when replying to a query,
the issue of differing TTLs for DNS records with the same label,
class and type, and the issue of canonical names, what they are, how
CNAME records relate, what names are legal in what parts of the DNS,
and what is the valid syntax of a DNS name.
Clarifications to the DNS specification to avoid these problems are
made in this memo. A minor ambiguity in RFC1034 concerned with SOA
records is also corrected, as is one in the definition of the TTL
(Time To Live) and some possible confusion in use of the TC bit.
Elz & Bush Standards Track [Page 2]
RFC 2181 Clarifications to the DNS Specification July 1997
3. Terminology
This memo does not use the oft used expressions MUST, SHOULD, MAY, or
their negative forms. In some sections it may seem that a
specification is worded mildly, and hence some may infer that the
specification is optional. That is not correct. Anywhere that this
memo suggests that some action should be carried out, or must be
carried out, or that some behaviour is acceptable, or not, that is to
be considered as a fundamental aspect of this specification,
regardless of the specific words used. If some behaviour or action
is truly optional, that will be clearly specified by the text.
4. Server Reply Source Address Selection
Most, if not all, DNS clients, expect the address from which a reply
is received to be the same address as that to which the query
eliciting the reply was sent. This is true for servers acting as
clients for the purposes of recursive query resolution, as well as
simple resolver clients. The address, along with the identifier (ID)
in the reply is used for disambiguating replies, and filtering
spurious responses. This may, or may not, have been intended when
the DNS was designed, but is now a fact of life.
Some multi-homed hosts running DNS servers generate a reply using a
source address that is not the same as the destination address from
the client's request packet. Such replies will be discarded by the
client because the source address of the reply does not match that of
a host to which the client sent the original request. That is, it
appears to be an unsolicited response.
4.1. UDP Source Address Selection
To avoid these problems, servers when responding to queries using UDP
must cause the reply to be sent with the source address field in the
IP header set to the address that was in the destination address
field of the IP header of the packet containing the query causing the
response. If this would cause the response to be sent from an IP
address that is not permitted for this purpose, then the response may
be sent from any legal IP address allocated to the server. That
address should be chosen to maximise the possibility that the client
will be able to use it for further queries. Servers configured in
such a way that not all their addresses are equally reachable from
all potential clients need take particular care when responding to
queries sent to anycast, multicast, or similar, addresses.
Elz & Bush Standards Track [Page 3]
RFC 2181 Clarifications to the DNS Specification July 1997
4.2. Port Number Selection
Replies to all queries must be directed to the port from which they
were sent. When queries are received via TCP this is an inherent
part of the transport protocol. For queries received by UDP the
server must take note of the source port and use that as the
destination port in the response. Replies should always be sent from
the port to which they were directed. Except in extraordinary
circumstances, this will be the well known port assigned for DNS
queries [RFC1700].
5. Resource Record Sets
Each DNS Resource Record (RR) has a label, class, type, and data. It
is meaningless for two records to ever have label, class, type and
data all equal - servers should suppress such duplicates if
encountered. It is however possible for most record types to exist
with the same label, class and type, but with different data. Such a
group of records is hereby defined to be a Resource Record Set
(RRSet).
5.1. Sending RRs from an RRSet
A query for a specific (or non-specific) label, class, and type, will
always return all records in the associated RRSet - whether that be
one or more RRs. The response must be marked as "truncated" if the
entire RRSet will not fit in the response.
5.2. TTLs of RRs in an RRSet
Resource Records also have a time to live (TTL). It is possible for
the RRs in an RRSet to have different TTLs. No uses for this have
been found that cannot be better accomplished in other ways. This
can, however, cause partial replies (not marked "truncated") from a
caching server, where the TTLs for some but not all the RRs in the
RRSet have expired.
Consequently the use of differing TTLs in an RRSet is hereby
deprecated, the TTLs of all RRs in an RRSet must be the same.
Should a client receive a response containing RRs from an RRSet with
differing TTLs, it should treat this as an error. If the RRSet
concerned is from a non-authoritative source for this data, the
client should simply ignore the RRSet, and if the values were
required, seek to acquire them from an authoritative source. Clients
that are configured to send all queries to one, or more, particular
servers should treat those servers as authoritative for this purpose.
Should an authoritative source send such a malformed RRSet, the
Elz & Bush Standards Track [Page 4]
RFC 2181 Clarifications to the DNS Specification July 1997
client should treat the RRs for all purposes as if all TTLs in the
RRSet had been set to the value of the lowest TTL in the RRSet. In
no case may a server send an RRSet with TTLs not all equal.
5.3. DNSSEC Special Cases
Two of the record types added by DNS Security (DNSSEC) [RFC2065]
require special attention when considering the formation of Resource
Record Sets. Those are the SIG and NXT records. It should be noted
that DNS Security is still very new, and there is, as yet, little
experience with it. Readers should be prepared for the information
related to DNSSEC contained in this document to become outdated as
the DNS Security specification matures.
5.3.1. SIG records and RRSets
A SIG record provides signature (validation) data for another RRSet
in the DNS. Where a zone has been signed, every RRSet in the zone
will have had a SIG record associated with it. The data type of the
RRSet is included in the data of the SIG RR, to indicate with which
particular RRSet this SIG record is associated. Were the rules above
applied, whenever a SIG record was included with a response to
validate that response, the SIG records for all other RRSets
associated with the appropriate node would also need to be included.
In some cases, this could be a very large number of records, not
helped by their being rather large RRs.
Thus, it is specifically permitted for the authority section to
contain only those SIG RRs with the "type covered" field equal to the
type field of an answer being returned. However, where SIG records
are being returned in the answer section, in response to a query for
SIG records, or a query for all records associated with a name
(type=ANY) the entire SIG RRSet must be included, as for any other RR
type.
Servers that receive responses containing SIG records in the
authority section, or (probably incorrectly) as additional data, must
understand that the entire RRSet has almost certainly not been
included. Thus, they must not cache that SIG record in a way that
would permit it to be returned should a query for SIG records be
received at that server. RFC2065 actually requires that SIG queries
be directed only to authoritative servers to avoid the problems that
could be caused here, and while servers exist that do not understand
the special properties of SIG records, this will remain necessary.
However, careful design of SIG record processing in new
implementations should permit this restriction to be relaxed in the
future, so resolvers do not need to treat SIG record queries
specially.
Elz & Bush Standards Track [Page 5]
RFC 2181 Clarifications to the DNS Specification July 1997
It has been occasionally stated that a received request for a SIG
record should be forwarded to an authoritative server, rather than
being answered from data in the cache. This is not necessary - a
server that has the knowledge of SIG as a special case for processing
this way would be better to correctly cache SIG records, taking into
account their characteristics. Then the server can determine when it
is safe to reply from the cache, and when the answer is not available
and the query must be forwarded.
5.3.2. NXT RRs
Next Resource Records (NXT) are even more peculiar. There will only
ever be one NXT record in a zone for a particular label, so
superficially, the RRSet problem is trivial. However, at a zone cut,
both the parent zone, and the child zone (superzone and subzone in
RFC2065 terminology) will have NXT records for the same name. Those
two NXT records do not form an RRSet, even where both zones are
housed at the same server. NXT RRSets always contain just a single
RR. Where both NXT records are visible, two RRSets exist. However,
servers are not required to treat this as a special case when
receiving NXT records in a response. They may elect to notice the
existence of two different NXT RRSets, and treat that as they would
two different RRSets of any other type. That is, cache one, and
ignore the other. Security aware servers will need to correctly
process the NXT record in the received response though.
5.4. Receiving RRSets
Servers must never merge RRs from a response with RRs in their cache
to form an RRSet. If a response contains data that would form an
RRSet with data in a server's cache the server must either ignore the
RRs in the response, or discard the entire RRSet currently in the
cache, as appropriate. Consequently the issue of TTLs varying
between the cache and a response does not cause concern, one will be
ignored. That is, one of the data sets is always incorrect if the
data from an answer differs from the data in the cache. The
challenge for the server is to determine which of the data sets is
correct, if one is, and retain that, while ignoring the other. Note
that if a server receives an answer containing an RRSet that is
identical to that in its cache, with the possible exception of the
TTL value, it may, optionally, update the TTL in its cache with the
TTL of the received answer. It should do this if the received answer
would be considered more authoritative (as discussed in the next
section) than the previously cached answer.
Elz & Bush Standards Track [Page 6]
RFC 2181 Clarifications to the DNS Specification July 1997
5.4.1. Ranking data
When considering whether to accept an RRSet in a reply, or retain an
RRSet already in its cache instead, a server should consider the
relative likely trustworthiness of the various data. An
authoritative answer from a reply should replace cached data that had
been obtained from additional information in an earlier reply.
However additional information from a reply will be ignored if the
cache contains data from an authoritative answer or a zone file.
The accuracy of data available is assumed from its source.
Trustworthiness shall be, in order from most to least:
+ Data from a primary zone file, other than glue data,
+ Data from a zone transfer, other than glue,
+ The authoritative data included in the answer section of an
authoritative reply.
+ Data from the authority section of an authoritative answer,
+ Glue from a primary zone, or glue from a zone transfer,
+ Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative
answers,
+ Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.
Note that the answer section of an authoritative answer normally
contains only authoritative data. However when the name sought is an
alias (see section 10.1.1) only the record describing that alias is
necessarily authoritative. Clients should assume that other records
may have come from the server's cache. Where authoritative answers
are required, the client should query again, using the canonical name
associated with the alias.
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.
When DNS security [RFC2065] is in use, and an authenticated reply has
been received and verified, the data thus authenticated shall be
considered more trustworthy than unauthenticated data of the same
type. Note that throughout this document, "authoritative" means a
reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY
Elz & Bush Standards Track [Page 7]
RFC 2181 Clarifications to the DNS Specification July 1997
records to determine the authenticity of data, the AA bit is almost
irrelevant. However DNSSEC aware servers must still correctly set
the AA bit in responses to enable correct operation with servers that
are not security aware (almost all currently).
Note that, glue excluded, it is impossible for data from two
correctly configured primary zone files, two correctly configured
secondary zones (data from zone transfers) or data from correctly
configured primary and secondary zones to ever conflict. Where glue
for the same name exists in multiple zones, and differs in value, the
nameserver should select data from a primary zone file in preference
to secondary, but otherwise may choose any single set of such data.
Choosing that which appears to come from a source nearer the
authoritative data source may make sense where that can be
determined. Choosing primary data over secondary allows the source
of incorrect glue data to be discovered more readily, when a problem
with such data exists. Where a server can detect from two zone files
that one or more are incorrectly configured, so as to create
conflicts, it should refuse to load the zones determined to be
erroneous, and issue suitable diagnostics.
"Glue" above includes any record in a zone file that is not properly
part of that zone, including nameserver records of delegated sub-
zones (NS records), address records that accompany those NS records
(A, AAAA, etc), and any other stray data that might appear.
5.5. Sending RRSets (reprise)
A Resource Record Set should only be included once in any DNS reply.
It may occur in any of the Answer, Authority, or Additional
Information sections, as required. However it should not be repeated
in the same, or any other, section, except where explicitly required
by a specification. For example, an AXFR response requires the SOA
record (always an RRSet containing a single RR) be both the first and
last record of the reply. Where duplicates are required this way,
the TTL transmitted in each case must be the same.
6. Zone Cuts
The DNS tree is divided into "zones", which are collections of
domains that are treated as a unit for certain management purposes.
Zones are delimited by "zone cuts". Each zone cut separates a
"child" zone (below the cut) from a "parent" zone (above the cut).
The domain name that appears at the top of a zone (just below the cut
that separates the zone from its parent) is called the zone's
"origin". The name of the zone is the same as the name of the domain
at the zone's origin. Each zone comprises that subset of the DNS
tree that is at or below the zone's origin, and that is above the
Elz & Bush Standards Track [Page 8]
RFC 2181 Clarifications to the DNS Specification July 1997
cuts that separate the zone from its children (if any). The
existence of a zone cut is indicated in the parent zone by the
existence of NS records specifying the origin of the child zone. A
child zone does not contain any explicit reference to its parent.
6.1. Zone authority
The authoritative servers for a zone are enumerated in the NS records
for the origin of the zone, which, along with a Start of Authority
(SOA) record are the mandatory records in every zone. Such a server
is authoritative for all resource records in a zone that are not in
another zone. The NS records that indicate a zone cut are the
property of the child zone created, as are any other records for the
origin of that child zone, or any sub-domains of it. A server for a
zone should not return authoritative answers for queries related to
names in another zone, which includes the NS, and perhaps A, records
at a zone cut, unless it also happens to be a server for the other
zone.
Other than the DNSSEC cases mentioned immediately below, servers
should ignore data other than NS records, and necessary A records to
locate the servers listed in the NS records, that may happen to be
configured in a zone at a zone cut.
6.2. DNSSEC issues
The DNS security mechanisms [RFC2065] complicate this somewhat, as
some of the new resource record types added are very unusual when
compared with other DNS RRs. In particular the NXT ("next") RR type
contains information about which names exist in a zone, and hence
which do not, and thus must necessarily relate to the zone in which
it exists. The same domain name may have different NXT records in
the parent zone and the child zone, and both are valid, and are not
an RRSet. See also section 5.3.2.
Since NXT records are intended to be automatically generated, rather
than configured by DNS operators, servers may, but are not required
to, retain all differing NXT records they receive regardless of the
rules in section 5.4.
For a secure parent zone to securely indicate that a subzone is
insecure, DNSSEC requires that a KEY RR indicating that the subzone
is insecure, and the parent zone's authenticating SIG RR(s) be
present in the parent zone, as they by definition cannot be in the
subzone. Where a subzone is secure, the KEY and SIG records will be
present, and authoritative, in that zone, but should also always be
present in the parent zone (if secure).
Elz & Bush Standards Track [Page 9]
RFC 2181 Clarifications to the DNS Specification July 1997
Note that in none of these cases should a server for the parent zone,
not also being a server for the subzone, set the AA bit in any
response for a label at a zone cut.
7. SOA RRs
Three minor issues concerning the Start of Zone of Authority (SOA)
Resource Record need some clarification.
7.1. Placement of SOA RRs in authoritative answers
RFC1034, in section 3.7, indicates that the authority section of an
authoritative answer may contain the SOA record for the zone from
which the answer was obtained. When discussing negative caching,
RFC1034 section 4.3.4 refers to this technique but mentions the
additional section of the response. The former is correct, as is
implied by the example shown in section 6.2.5 of RFC1034. SOA
records, if added, are to be placed in the authority section.
7.2. TTLs on SOA RRs
It may be observed that in section 3.2.1 of RFC1035, which defines
the format of a Resource Record, that the definition of the TTL field
contains a throw away line which states that the TTL of an SOA record
should always be sent as zero to prevent caching. This is mentioned
nowhere else, and has not generally been implemented.
Implementations should not assume that SOA records will have a TTL of
zero, nor are they required to send SOA records with a TTL of zero.
7.3. The SOA.MNAME field
It is quite clear in the specifications, yet seems to have been
widely ignored, that the MNAME field of the SOA record should contain
the name of the primary (master) server for the zone identified by
the SOA. It should not contain the name of the zone itself. That
information would be useless, as to discover it, one needs to start
with the domain name of the SOA record - that is the name of the
zone.
8. Time to Live (TTL)
The definition of values appropriate to the TTL field in STD 13 is
not as clear as it could be, with respect to how many significant
bits exist, and whether the value is signed or unsigned. It is
hereby specified that a TTL value is an unsigned number, with a
minimum value of 0, and a maximum value of 2147483647. That is, a
maximum of 2^31 - 1. When transmitted, this value shall be encoded
in the less significant 31 bits of the 32 bit TTL field, with the
Elz & Bush Standards Track [Page 10]
RFC 2181 Clarifications to the DNS Specification July 1997
most significant, or sign, bit set to zero.
Implementations should treat TTL values received with the most
significant bit set as if the entire value received was zero.
Implementations are always free to place an upper bound on any TTL
received, and treat any larger values as if they were that upper
bound. The TTL specifies a maximum time to live, not a mandatory
time to live.
9. The TC (truncated) header bit
The TC bit should be set in responses only when an RRSet is required
as a part of the response, but could not be included in its entirety.
The TC bit should not be set merely because some extra information
could have been included, but there was insufficient room. This
includes the results of additional section processing. In such cases
the entire RRSet that will not fit in the response should be omitted,
and the reply sent as is, with the TC bit clear. If the recipient of
the reply needs the omitted data, it can construct a query for that
data and send that separately.
Where TC is set, the partial RRSet that would not completely fit may
be left in the response. When a DNS client receives a reply with TC
set, it should ignore that response, and query again, using a
mechanism, such as a TCP connection, that will permit larger replies.
10. Naming issues
It has sometimes been inferred from some sections of the DNS
specification [RFC1034, RFC1035] that a host, or perhaps an interface
of a host, is permitted exactly one authoritative, or official, name,
called the canonical name. There is no such requirement in the DNS.
10.1. CNAME resource records
The DNS CNAME ("canonical name") record exists to provide the
canonical name associated with an alias name. There may be only one
such canonical name for any one alias. That name should generally be
a name that exists elsewhere in the DNS, though there are some rare
applications for aliases with the accompanying canonical name
undefined in the DNS. An alias name (label of a CNAME record) may,
if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
other data. That is, for any label in the DNS (any domain name)
exactly one of the following is true:
Elz & Bush Standards Track [Page 11]
RFC 2181 Clarifications to the DNS Specification July 1997
+ one CNAME record exists, optionally accompanied by SIG, NXT, and
KEY RRs,
+ one or more records exist, none being CNAME records,
+ the name exists, but has no associated RRs of any type,
+ the name does not exist at all.
10.1.1. CNAME terminology
It has been traditional to refer to the label of a CNAME record as "a
CNAME". This is unfortunate, as "CNAME" is an abbreviation of
"canonical name", and the label of a CNAME record is most certainly
not a canonical name. It is, however, an entrenched usage. Care
must therefore be taken to be very clear whether the label, or the
value (the canonical name) of a CNAME resource record is intended.
In this document, the label of a CNAME resource record will always be
referred to as an alias.
10.2. PTR records
Confusion about canonical names has lead to a belief that a PTR
record should have exactly one RR in its RRSet. This is incorrect,
the relevant section of RFC1034 (section 3.6.2) indicates that the
value of a PTR record should be a canonical name. That is, it should
not be an alias. There is no implication in that section that only
one PTR record is permitted for a name. No such restriction should
be inferred.
Note that while the value of a PTR record must not be an alias, there
is no requirement that the process of resolving a PTR record not
encounter any aliases. The label that is being looked up for a PTR
value might have a CNAME record. That is, it might be an alias. The
value of that CNAME RR, if not another alias, which it should not be,
will give the location where the PTR record is found. That record
gives the result of the PTR type lookup. This final result, the
value of the PTR RR, is the label which must not be an alias.
10.3. MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.
Elz & Bush Standards Track [Page 12]
RFC 2181 Clarifications to the DNS Specification July 1997
Searching for either NS or MX records causes "additional section
processing" in which address records associated with the value of the
record sought are appended to the answer. This helps avoid needless
extra queries that are easily anticipated when the first was made.
Additional section processing does not include CNAME records, let
alone the address records that may be associated with the canonical
name derived from the alias. Thus, if an alias is used as the value
of an NS or MX record, no address will be returned with the NS or MX
value. This can cause extra queries, and extra network burden, on
every query. It is trivial for the DNS administrator to avoid this
by resolving the alias and placing the canonical name directly in the
affected record just once when it is updated or installed. In some
particular hard cases the lack of the additional section address
records in the results of a NS lookup can cause the request to fail.
11. Name syntax
Occasionally it is assumed that the Domain Name System serves only
the purpose of mapping Internet host names to data, and mapping
Internet addresses to host names. This is not correct, the DNS is a
general (if somewhat limited) hierarchical database, and can store
almost any kind of data, for almost any purpose.
The DNS itself places only one restriction on the particular labels
that can be used to identify resource records. That one restriction
relates to the length of the label and the full name. The length of
any one label is limited to between 1 and 63 octets. A full domain
name is limited to 255 octets (including the separators). The zero
length full name is defined as representing the root of the DNS tree,
and is typically written and displayed as ".". Those restrictions
aside, any binary string whatever can be used as the label of any
resource record. Similarly, any binary string can serve as the value
of any record that includes a domain name as some or all of its value
(SOA, NS, MX, PTR, CNAME, and any others that may be added).
Implementations of the DNS protocols must not place any restrictions
on the labels that can be used. In particular, DNS servers must not
refuse to serve a zone because it contains labels that might not be
acceptable to some DNS client programs. A DNS server may be
configurable to issue warnings when loading, or even to refuse to
load, a primary zone containing labels that might be considered
questionable, however this should not happen by default.
Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are
acceptable in their environment. For example, that any binary label
can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address. Clients of the DNS can impose
Elz & Bush Standards Track [Page 13]
RFC 2181 Clarifications to the DNS Specification July 1997
whatever restrictions are appropriate to their circumstances on the
values they use as keys for DNS lookup requests, and on the values
returned by the DNS. If the client has such restrictions, it is
solely responsible for validating the data from the DNS to ensure
that it conforms before it makes any use of that data.
See also [RFC1123] section 6.1.3.5.
12. Security Considerations
This document does not consider security.
In particular, nothing in section 4 is any way related to, or useful
for, any security related purposes.
Section 5.4.1 is also not related to security. Security of DNS data
will be obtained by the Secure DNS [RFC2065], which is mostly
orthogonal to this memo.
It is not believed that anything in this document adds to any
security issues that may exist with the DNS, nor does it do anything
to that will necessarily lessen them. Correct implementation of the
clarifications in this document might play some small part in
limiting the spread of non-malicious bad data in the DNS, but only
DNSSEC can help with deliberate attempts to subvert DNS data.
13. References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - application
and support", STD 3, RFC 1123, January 1989.
[RFC1700] Reynolds, J., Postel, J., "Assigned Numbers",
STD 2, RFC 1700, October 1994.
[RFC2065] Eastlake, D., Kaufman, C., "Domain Name System Security
Extensions", RFC 2065, January 1997.
Elz & Bush Standards Track [Page 14]
RFC 2181 Clarifications to the DNS Specification July 1997
14. Acknowledgements
This memo arose from discussions in the DNSIND working group of the
IETF in 1995 and 1996, the members of that working group are largely
responsible for the ideas captured herein. Particular thanks to
Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
DNSSEC issues in this document, and to John Gilmore for pointing out
where the clarifications were not necessarily clarifying. Bob Halley
suggested clarifying the placement of SOA records in authoritative
answers, and provided the references. Michael Patton, as usual, and
Mark Andrews, Alan Barrett and Stan Barber provided much assistance
with many details. Josh Littlefield helped make sure that the
clarifications didn't cause problems in some irritating corner cases.
15. Authors' Addresses
Robert Elz
Computer Science
University of Melbourne
Parkville, Victoria, 3052
Australia.
EMail: kre@munnari.OZ.AU
Randy Bush
RGnet, Inc.
5147 Crystal Springs Drive NE
Bainbridge Island, Washington, 98110
United States.
EMail: randy@psg.com
Elz & Bush Standards Track [Page 15]

1067
doc/rfc/rfc2308.txt Normal file
View file

File diff suppressed because it is too large Load diff

1459
doc/rfc/rfc2373.txt Normal file
View file

File diff suppressed because it is too large Load diff

675
doc/rfc/rfc2374.txt Normal file
View file

@ -0,0 +1,675 @@
Network Working Group R. Hinden
Request for Comments: 2374 Nokia
Obsoletes: 2073 M. O'Dell
Category: Standards Track UUNET
S. Deering
Cisco
July 1998
An IPv6 Aggregatable Global Unicast Address Format
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
1.0 Introduction
This document defines an IPv6 aggregatable global unicast address
format for use in the Internet. The address format defined in this
document is consistent with the IPv6 Protocol [IPV6] and the "IPv6
Addressing Architecture" [ARCH]. It is designed to facilitate
scalable Internet routing.
This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
Address Format". RFC 2073 will become historic. The Aggregatable
Global Unicast Address Format is an improvement over RFC 2073 in a
number of areas. The major changes include removal of the registry
bits because they are not needed for route aggregation, support of
EUI-64 based interface identifiers, support of provider and exchange
based aggregation, separation of public and site topology, and new
aggregation based terminology.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
Hinden, et. al. Standards Track [Page 1]
RFC 2374 IPv6 Global Unicast Address Format July 1998
2.0 Overview of the IPv6 Address
IPv6 addresses are 128-bit identifiers for interfaces and sets of
interfaces. There are three types of addresses: Unicast, Anycast,
and Multicast. This document defines a specific type of Unicast
address.
In this document, fields in addresses are given specific names, for
example "subnet". When this name is used with the term "ID" (for
"identifier") after the name (e.g., "subnet ID"), it refers to the
contents of the named field. When it is used with the term "prefix"
(e.g. "subnet prefix") it refers to all of the addressing bits to
the left of and including this field.
IPv6 unicast addresses are designed assuming that the Internet
routing system makes forwarding decisions based on a "longest prefix
match" algorithm on arbitrary bit boundaries and does not have any
knowledge of the internal structure of IPv6 addresses. The structure
in IPv6 addresses is for assignment and allocation. The only
exception to this is the distinction made between unicast and
multicast addresses.
The specific type of an IPv6 address is indicated by the leading bits
in the address. The variable-length field comprising these leading
bits is called the Format Prefix (FP).
This document defines an address format for the 001 (binary) Format
Prefix for Aggregatable Global Unicast addresses. The same address
format could be used for other Format Prefixes, as long as these
Format Prefixes also identify IPv6 unicast addresses. Only the "001"
Format Prefix is defined here.
3.0 IPv6 Aggregatable Global Unicast Address Format
This document defines an address format for the IPv6 aggregatable
global unicast address assignment. The authors believe that this
address format will be widely used for IPv6 nodes connected to the
Internet. This address format is designed to support both the
current provider-based aggregation and a new type of exchange-based
aggregation. The combination will allow efficient routing
aggregation for sites that connect directly to providers and for
sites that connect to exchanges. Sites will have the choice to
connect to either type of aggregation entity.
Hinden, et. al. Standards Track [Page 2]
RFC 2374 IPv6 Global Unicast Address Format July 1998
While this address format is designed to support exchange-based
aggregation (in addition to current provider-based aggregation) it is
not dependent on exchanges for it's overall route aggregation
properties. It will provide efficient route aggregation with only
provider-based aggregation.
Aggregatable addresses are organized into a three level hierarchy:
- Public Topology
- Site Topology
- Interface Identifier
Public topology is the collection of providers and exchanges who
provide public Internet transit services. Site topology is local to
a specific site or organization which does not provide public transit
service to nodes outside of the site. Interface identifiers identify
interfaces on links.
______________ ______________
--+/ \+--------------+/ \+----------
( P1 ) +----+ ( P3 ) +----+
+\______________/ | |----+\______________/+--| |--
| +--| X1 | +| X2 |
| ______________ / | |-+ ______________ / | |--
+/ \+ +-+--+ \ / \+ +----+
( P2 ) / \ +( P4 )
--+\______________/ / \ \______________/
| / \ | |
| / | | |
| / | | |
_|_ _/_ _|_ _|_ _|_
/ \ / \ / \ / \ / \
( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C )
\___/ \___/ \___/ \___/ \___/
| / \
_|_ _/_ \ ___
/ \ / \ +-/ \
( S.D ) ( S.E ) ( S.F )
\___/ \___/ \___/
As shown in the figure above, the aggregatable address format is
designed to support long-haul providers (shown as P1, P2, P3, and
P4), exchanges (shown as X1 and X2), multiple levels of providers
(shown at P5 and P6), and subscribers (shown as S.x) Exchanges
(unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses.
Organizations who connect to these exchanges will also subscribe
(directly, indirectly via the exchange, etc.) for long-haul service
from one or more long-haul providers. Doing so, they will achieve
Hinden, et. al. Standards Track [Page 3]
RFC 2374 IPv6 Global Unicast Address Format July 1998
addressing independence from long-haul transit providers. They will
be able to change long-haul providers without having to renumber
their organization. They can also be multihomed via the exchange to
more than one long-haul provider without having to have address
prefixes from each long-haul provider. Note that the mechanisms used
for this type of provider selection and portability are not discussed
in the document.
3.1 Aggregatable Global Unicast Address Structure
The aggregatable global unicast address format is as follows:
| 3| 13 | 8 | 24 | 16 | 64 bits |
+--+-----+---+--------+--------+--------------------------------+
|FP| TLA |RES| NLA | SLA | Interface ID |
| | ID | | ID | ID | |
+--+-----+---+--------+--------+--------------------------------+
<--Public Topology---> Site
<-------->
Topology
<------Interface Identifier----->
Where
FP Format Prefix (001)
TLA ID Top-Level Aggregation Identifier
RES Reserved for future use
NLA ID Next-Level Aggregation Identifier
SLA ID Site-Level Aggregation Identifier
INTERFACE ID Interface Identifier
The following sections specify each part of the IPv6 Aggregatable
Global Unicast address format.
3.2 Top-Level Aggregation ID
Top-Level Aggregation Identifiers (TLA ID) are the top level in the
routing hierarchy. Default-free routers must have a routing table
entry for every active TLA ID and will probably have additional
entries providing routing information for the TLA ID in which they
are located. They may have additional entries in order to optimize
routing for their specific topology, but the routing topology at all
levels must be designed to minimize the number of additional entries
fed into the default free routing tables.
Hinden, et. al. Standards Track [Page 4]
RFC 2374 IPv6 Global Unicast Address Format July 1998
This addressing format supports 8,192 (2^13) TLA ID's. Additional
TLA ID's may be added by either growing the TLA field to the right
into the reserved field or by using this format for additional format
prefixes.
The issues relating to TLA ID assignment are beyond the scope of this
document. They will be described in a document under preparation.
3.3 Reserved
The Reserved field is reserved for future use and must be set to
zero.
The Reserved field allows for future growth of the TLA and NLA fields
as appropriate. See section 4.0 for a discussion.
3.4 Next-Level Aggregation Identifier
Next-Level Aggregation Identifier's are used by organizations
assigned a TLA ID to create an addressing hierarchy and to identify
sites. The organization can assign the top part of the NLA ID in a
manner to create an addressing hierarchy appropriate to its network.
It can use the remainder of the bits in the field to identify sites
it wishes to serve. This is shown as follows:
| n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+
Each organization assigned a TLA ID receives 24 bits of NLA ID space.
This NLA ID space allows each organization to provide service to
approximately as many organizations as the current IPv4 Internet can
support total networks.
Organizations assigned TLA ID's may also support NLA ID's in their
own Site ID space. This allows the organization assigned a TLA ID to
provide service to organizations providing public transit service and
to organizations who do not provide public transit service. These
organizations receiving an NLA ID may also choose to use their Site
ID space to support other NLA ID's. This is shown as follows:
Hinden, et. al. Standards Track [Page 5]
RFC 2374 IPv6 Global Unicast Address Format July 1998
| n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+
| m | 24-n-m | 16 | 64 bits |
+-----+--------------+--------+-----------------+
|NLA2 | Site ID | SLA ID | Interface ID |
+-----+--------------+--------+-----------------+
| o |24-n-m-o| 16 | 64 bits |
+-----+--------+--------+-----------------+
|NLA3 | Site ID| SLA ID | Interface ID |
+-----+--------+--------+-----------------+
The design of the bit layout of the NLA ID space for a specific TLA
ID is left to the organization responsible for that TLA ID. Likewise
the design of the bit layout of the next level NLA ID is the
responsibility of the previous level NLA ID. It is recommended that
organizations assigning NLA address space use "slow start" allocation
procedures similar to [RFC2050].
The design of an NLA ID allocation plan is a tradeoff between routing
aggregation efficiency and flexibility. Creating hierarchies allows
for greater amount of aggregation and results in smaller routing
tables. Flat NLA ID assignment provides for easier allocation and
attachment flexibility, but results in larger routing tables.
3.5 Site-Level Aggregation Identifier
The SLA ID field is used by an individual organization to create its
own local addressing hierarchy and to identify subnets. This is
analogous to subnets in IPv4 except that each organization has a much
greater number of subnets. The 16 bit SLA ID field support 65,535
individual subnets.
Organizations may choose to either route their SLA ID "flat" (e.g.,
not create any logical relationship between the SLA identifiers that
results in larger routing tables), or to create a two or more level
hierarchy (that results in smaller routing tables) in the SLA ID
field. The latter is shown as follows:
Hinden, et. al. Standards Track [Page 6]
RFC 2374 IPv6 Global Unicast Address Format July 1998
| n | 16-n | 64 bits |
+-----+------------+-------------------------------------+
|SLA1 | Subnet | Interface ID |
+-----+------------+-------------------------------------+
| m |16-n-m | 64 bits |
+----+-------+-------------------------------------+
|SLA2|Subnet | Interface ID |
+----+-------+-------------------------------------+
The approach chosen for structuring an SLA ID field is the
responsibility of the individual organization.
The number of subnets supported in this address format should be
sufficient for all but the largest of organizations. Organizations
which need additional subnets can arrange with the organization they
are obtaining Internet service from to obtain additional site
identifiers and use this to create additional subnets.
3.6 Interface ID
Interface identifiers are used to identify interfaces on a link.
They are required to be unique on that link. They may also be unique
over a broader scope. In many cases an interfaces identifier will be
the same or be based on the interface's link-layer address.
Interface IDs used in the aggregatable global unicast address format
are required to be 64 bits long and to be constructed in IEEE EUI-64
format [EUI-64]. These identifiers may have global scope when a
global token (e.g., IEEE 48bit MAC) is available or may have local
scope where a global token is not available (e.g., serial links,
tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE
EUI-64 terminology) in the EUI-64 identifier must be set correctly,
as defined in [ARCH], to indicate global or local scope.
The procedures for creating EUI-64 based Interface Identifiers is
defined in [ARCH]. The details on forming interface identifiers is
defined in the appropriate "IPv6 over <link>" specification such as
"IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
4.0 Technical Motivation
The design choices for the size of the fields in the aggregatable
address format were based on the need to meet a number of technical
requirements. These are described in the following paragraphs.
The size of the Top-Level Aggregation Identifier is 13 bits. This
allows for 8,192 TLA ID's. This size was chosen to insure that the
default-free routing table in top level routers in the Internet is
Hinden, et. al. Standards Track [Page 7]
RFC 2374 IPv6 Global Unicast Address Format July 1998
kept within the limits, with a reasonable margin, of the current
routing technology. The margin is important because default-free
routers will also carry a significant number of longer (i.e., more-
specific) prefixes for optimizing paths internal to a TLA and between
TLAs.
The important issue is not only the size of the default-free routing
table, but the complexity of the topology that determines the number
of copies of the default-free routes that a router must examine while
computing a forwarding table. Current practice with IPv4 it is
common to see a prefix announced fifteen times via different paths.
The complexity of Internet topology is very likely to increase in the
future. It is important that IPv6 default-free routing support
additional complexity as well as a considerably larger internet.
It should be noted for comparison that at the time of this writing
(spring, 1998) the IPv4 default-free routing table contains
approximately 50,000 prefixes. While this shows that it is possible
to support more routes than 8,192 it is matter of debate if the
number of prefixes supported today in IPv4 is already too high for
current routing technology. There are serious issues of route
stability as well as cases of providers not supporting all top level
prefixes. The technical requirement was to pick a TLA ID size that
was below, with a reasonable margin, what was being done with IPv4.
The choice of 13 bits for the TLA field was an engineering
compromise. Fewer bits would have been too small by not supporting
enough top level organizations. More bits would have exceeded what
can be reasonably accommodated, with a reasonable margin, with
current routing technology in order to deal with the issues described
in the previous paragraphs.
If in the future, routing technology improves to support a larger
number of top level routes in the default-free routing tables there
are two choices on how to increase the number TLA identifiers. The
first is to expand the TLA ID field into the reserved field. This
would increase the number of TLA ID's to approximately 2 million.
The second approach is to allocate another format prefix (FP) for use
with this address format. Either or a combination of these
approaches allows the number of TLA ID's to increase significantly.
The size of the Reserved field is 8 bits. This size was chosen to
allow significant growth of either the TLA ID and/or the NLA ID
fields.
The size of the Next-Level Aggregation Identifier field is 24 bits.
Hinden, et. al. Standards Track [Page 8]
RFC 2374 IPv6 Global Unicast Address Format July 1998
This allows for approximately sixteen million NLA ID's if used in a
flat manner. Used hierarchically it allows for a complexity roughly
equivalent to the IPv4 address space (assuming an average network
size of 254 interfaces). If in the future additional room for
complexity is needed in the NLA ID, this may be accommodated by
extending the NLA ID into the Reserved field.
The size of the Site-Level Aggregation Identifier field is 16 bits.
This supports 65,535 individual subnets per site. The design goal
for the size of this field was to be sufficient for all but the
largest of organizations. Organizations which need additional
subnets can arrange with the organization they are obtaining Internet
service from to obtain additional site identifiers and use this to
create additional subnets.
The Site-Level Aggregation Identifier field was given a fixed size in
order to force the length of all prefixes identifying a particular
site to be the same length (i.e., 48 bits). This facilitates
movement of sites in the topology (e.g., changing service providers
and multi-homing to multiple service providers).
The Interface ID Interface Identifier field is 64 bits. This size
was chosen to meet the requirement specified in [ARCH] to support
EUI-64 based Interface Identifiers.
5.0 Acknowledgments
The authors would like to express our thanks to Thomas Narten, Bob
Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
for their review and constructive comments.
6.0 References
[ALLOC] IAB and IESG, "IPv6 Address Allocation Management",
RFC 1881, December 1995.
[ARCH] Hinden, R., "IP Version 6 Addressing Architecture",
RFC 2373, July 1998.
[AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August
1995.
[AUTO] Thompson, S., and T. Narten., "IPv6 Stateless Address
Autoconfiguration", RFC 1971, August 1996.
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", Work in Progress.
Hinden, et. al. Standards Track [Page 9]
RFC 2374 IPv6 Global Unicast Address Format July 1998
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/db/oui/tutorials/EUI64.html,
March 1997.
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", Work in Progress.
[IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
and J. Postel, "Internet Registry IP Allocation
Guidelines", BCP 12, RFC 1466, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.0 Security Considerations
IPv6 addressing documents do not have any direct impact on Internet
infrastructure security. Authentication of IPv6 packets is defined
in [AUTH].
Hinden, et. al. Standards Track [Page 10]
RFC 2374 IPv6 Global Unicast Address Format July 1998
8.0 Authors' Addresses
Robert M. Hinden
Nokia
232 Java Drive
Sunnyvale, CA 94089
USA
Phone: 1 408 990-2004
EMail: hinden@iprg.nokia.com
Mike O'Dell
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22030
USA
Phone: 1 703 206-5890
EMail: mo@uunet.uu.net
Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: 1 408 527-8213
EMail: deering@cisco.com
Hinden, et. al. Standards Track [Page 11]
RFC 2374 IPv6 Global Unicast Address Format July 1998
9.0 Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Hinden, et. al. Standards Track [Page 12]

451
doc/rfc/rfc2375.txt Normal file
View file

@ -0,0 +1,451 @@
Network Working Group R. Hinden
Request for Comments: 2375 Ipsilon Networks
Category: Informational S. Deering
Cisco
July 1998
IPv6 Multicast Address Assignments
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
1.0 Introduction
This document defines the initial assignment of IPv6 multicast
addresses. It is based on the "IP Version 6 Addressing Architecture"
[ADDARCH] and current IPv4 multicast address assignment found in
<ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses>.
It adapts the IPv4 assignments that are relevant to IPv6 assignments.
IPv4 assignments that were not relevant were not converted into IPv6
assignments. Comments are solicited on this conversion.
All other IPv6 multicast addresses are reserved.
Sections 2 and 3 specify reserved and preassigned IPv6 multicast
addresses.
[ADDRARCH] defines rules for assigning new IPv6 multicast addresses.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. Fixed Scope Multicast Addresses
These permanently assigned multicast addresses are valid over a
specified scope value.
Hinden & Deering Informational [Page 1]
RFC 2375 IPv6 Multicast Address Assignments July 1998
2.1 Node-Local Scope
FF01:0:0:0:0:0:0:1 All Nodes Address [ADDARCH]
FF01:0:0:0:0:0:0:2 All Routers Address [ADDARCH]
2.2 Link-Local Scope
FF02:0:0:0:0:0:0:1 All Nodes Address [ADDARCH]
FF02:0:0:0:0:0:0:2 All Routers Address [ADDARCH]
FF02:0:0:0:0:0:0:3 Unassigned [JBP]
FF02:0:0:0:0:0:0:4 DVMRP Routers [RFC1075,JBP]
FF02:0:0:0:0:0:0:5 OSPFIGP [RFC2328,Moy]
FF02:0:0:0:0:0:0:6 OSPFIGP Designated Routers [RFC2328,Moy]
FF02:0:0:0:0:0:0:7 ST Routers [RFC1190,KS14]
FF02:0:0:0:0:0:0:8 ST Hosts [RFC1190,KS14]
FF02:0:0:0:0:0:0:9 RIP Routers [RFC2080]
FF02:0:0:0:0:0:0:A EIGRP Routers [Farinacci]
FF02:0:0:0:0:0:0:B Mobile-Agents [Bill Simpson]
FF02:0:0:0:0:0:0:D All PIM Routers [Farinacci]
FF02:0:0:0:0:0:0:E RSVP-ENCAPSULATION [Braden]
FF02:0:0:0:0:0:1:1 Link Name [Harrington]
FF02:0:0:0:0:0:1:2 All-dhcp-agents [Bound,Perkins]
FF02:0:0:0:0:1:FFXX:XXXX Solicited-Node Address [ADDARCH]
2.3 Site-Local Scope
FF05:0:0:0:0:0:0:2 All Routers Address [ADDARCH]
FF05:0:0:0:0:0:1:3 All-dhcp-servers [Bound,Perkins]
FF05:0:0:0:0:0:1:4 All-dhcp-relays [Bound,Perkins]
FF05:0:0:0:0:0:1:1000 Service Location [RFC2165]
-FF05:0:0:0:0:0:1:13FF
3.0 All Scope Multicast Addresses
These permanently assigned multicast addresses are valid over all
scope ranges. This is shown by an "X" in the scope field of the
address that means any legal scope value.
Note that, as defined in [ADDARCH], IPv6 multicast addresses which
are only different in scope represent different groups. Nodes must
join each group individually.
The IPv6 multicast addresses with variable scope are as follows:
Hinden & Deering Informational [Page 2]
RFC 2375 IPv6 Multicast Address Assignments July 1998
FF0X:0:0:0:0:0:0:0 Reserved Multicast Address [ADDARCH]
FF0X:0:0:0:0:0:0:100 VMTP Managers Group [RFC1045,DRC3]
FF0X:0:0:0:0:0:0:101 Network Time Protocol (NTP) [RFC1119,DLM1]
FF0X:0:0:0:0:0:0:102 SGI-Dogfight [AXC]
FF0X:0:0:0:0:0:0:103 Rwhod [SXD]
FF0X:0:0:0:0:0:0:104 VNP [DRC3]
FF0X:0:0:0:0:0:0:105 Artificial Horizons - Aviator [BXF]
FF0X:0:0:0:0:0:0:106 NSS - Name Service Server [BXS2]
FF0X:0:0:0:0:0:0:107 AUDIONEWS - Audio News Multicast [MXF2]
FF0X:0:0:0:0:0:0:108 SUN NIS+ Information Service [CXM3]
FF0X:0:0:0:0:0:0:109 MTP Multicast Transport Protocol [SXA]
FF0X:0:0:0:0:0:0:10A IETF-1-LOW-AUDIO [SC3]
FF0X:0:0:0:0:0:0:10B IETF-1-AUDIO [SC3]
FF0X:0:0:0:0:0:0:10C IETF-1-VIDEO [SC3]
FF0X:0:0:0:0:0:0:10D IETF-2-LOW-AUDIO [SC3]
FF0X:0:0:0:0:0:0:10E IETF-2-AUDIO [SC3]
FF0X:0:0:0:0:0:0:10F IETF-2-VIDEO [SC3]
FF0X:0:0:0:0:0:0:110 MUSIC-SERVICE [Guido van Rossum]
FF0X:0:0:0:0:0:0:111 SEANET-TELEMETRY [Andrew Maffei]
FF0X:0:0:0:0:0:0:112 SEANET-IMAGE [Andrew Maffei]
FF0X:0:0:0:0:0:0:113 MLOADD [Braden]
FF0X:0:0:0:0:0:0:114 any private experiment [JBP]
FF0X:0:0:0:0:0:0:115 DVMRP on MOSPF [Moy]
FF0X:0:0:0:0:0:0:116 SVRLOC [Veizades]
FF0X:0:0:0:0:0:0:117 XINGTV <hgxing@aol.com>
FF0X:0:0:0:0:0:0:118 microsoft-ds <arnoldm@microsoft.com>
FF0X:0:0:0:0:0:0:119 nbc-pro <bloomer@birch.crd.ge.com>
FF0X:0:0:0:0:0:0:11A nbc-pfn <bloomer@birch.crd.ge.com>
FF0X:0:0:0:0:0:0:11B lmsc-calren-1 [Uang]
FF0X:0:0:0:0:0:0:11C lmsc-calren-2 [Uang]
FF0X:0:0:0:0:0:0:11D lmsc-calren-3 [Uang]
FF0X:0:0:0:0:0:0:11E lmsc-calren-4 [Uang]
FF0X:0:0:0:0:0:0:11F ampr-info [Janssen]
FF0X:0:0:0:0:0:0:120 mtrace [Casner]
FF0X:0:0:0:0:0:0:121 RSVP-encap-1 [Braden]
FF0X:0:0:0:0:0:0:122 RSVP-encap-2 [Braden]
FF0X:0:0:0:0:0:0:123 SVRLOC-DA [Veizades]
FF0X:0:0:0:0:0:0:124 rln-server [Kean]
FF0X:0:0:0:0:0:0:125 proshare-mc [Lewis]
FF0X:0:0:0:0:0:0:126 dantz [Yackle]
FF0X:0:0:0:0:0:0:127 cisco-rp-announce [Farinacci]
FF0X:0:0:0:0:0:0:128 cisco-rp-discovery [Farinacci]
FF0X:0:0:0:0:0:0:129 gatekeeper [Toga]
FF0X:0:0:0:0:0:0:12A iberiagames [Marocho]
Hinden & Deering Informational [Page 3]
RFC 2375 IPv6 Multicast Address Assignments July 1998
FF0X:0:0:0:0:0:0:201 "rwho" Group (BSD) (unofficial) [JBP]
FF0X:0:0:0:0:0:0:202 SUN RPC PMAPPROC_CALLIT [BXE1]
FF0X:0:0:0:0:0:2:0000
-FF0X:0:0:0:0:0:2:7FFD Multimedia Conference Calls [SC3]
FF0X:0:0:0:0:0:2:7FFE SAPv1 Announcements [SC3]
FF0X:0:0:0:0:0:2:7FFF SAPv0 Announcements (deprecated) [SC3]
FF0X:0:0:0:0:0:2:8000
-FF0X:0:0:0:0:0:2:FFFF SAP Dynamic Assignments [SC3]
5.0 References
[ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[AUTORFC] Thompson, S., and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 1971, August 1996.
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", Work in Progress.
[RFC1045] Cheriton, D., "VMTP: Versatile Message Transaction Protocol
Specification", RFC 1045, February 1988.
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", RFC 1075, November
1988.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, Stanford University, August 1989.
[RFC1119] Mills, D., "Network Time Protocol (Version 1),
Specification and Implementation", STD 12, RFC 1119, July
1988.
[RFC1190] Topolcic, C., Editor, "Experimental Internet Stream
Protocol, Version 2 (ST-II)", RFC 1190, October 1990.
[RFC2080] Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan
"Service Location Protocol", RFC 2165 June 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
Hinden & Deering Informational [Page 4]
RFC 2375 IPv6 Multicast Address Assignments July 1998
6. People
<arnoldm@microsoft.com>
[AXC] Andrew Cherenson <arc@SGI.COM>
[Braden] Bob Braden, <braden@isi.edu>, April 1996.
[Bob Brenner]
[Bressler] David J. Bressler, <bressler@tss.com>, April 1996.
<bloomer@birch.crd.ge.com>
[Bound] Jim Bound <bound@zk3.dec.com>
[BXE1] Brendan Eic <brendan@illyria.wpd.sgi.com>
[BXF] Bruce Factor <ahi!bigapple!bruce@uunet.UU.NET>
[BXS2] Bill Schilit <schilit@parc.xerox.com>
[Casner] Steve Casner, <casner@isi.edu>, January 1995.
[CXM3] Chuck McManis <cmcmanis@sun.com>
[Tim Clark]
[DLM1] David Mills <Mills@HUEY.UDEL.EDU>
[DRC3] Dave Cheriton <cheriton@PESCADERO.STANFORD.EDU>
[DXS3] Daniel Steinber <Daniel.Steinberg@Eng.Sun.COM>
[Farinacci] Dino Farinacci, <dino@cisco.com>
[GSM11] Gary S. Malkin <GMALKIN@XYLOGICS.COM>
[Harrington] Dan Harrington, <dan@lucent.com>, July 1996.
<hgxing@aol.com>
[IANA] IANA <iana@iana.org>
[Janssen] Rob Janssen, <rob@pe1chl.ampr.org>, January 1995.
[JBP] Jon Postel <postel@isi.edu>
Hinden & Deering Informational [Page 5]
RFC 2375 IPv6 Multicast Address Assignments July 1998
[JXM1] Jim Miner <miner@star.com>
[Kean] Brian Kean, <bkean@dca.com>, August 1995.
[KS14] <mystery contact>
[Lee] Choon Lee, <cwl@nsd.3com.com>, April 1996.
[Lewis] Mark Lewis, <Mark_Lewis@ccm.jf.intel.com>, October 1995.
[Malamud] Carl Malamud, <carl@radio.com>, January 1996.
[Andrew Maffei]
[Marohco] Jose Luis Marocho, <73374.313@compuserve.com>, July 1996.
[Moy] John Moy <jmoy@casc.com>
[MXF2] Martin Forssen <maf@dtek.chalmers.se>
[Perkins] Charlie Perkins, <cperkins@corp.sun.com>
[Guido van Rossum]
[SC3] Steve Casner <casner@isi.edu>
[Simpson] Bill Simpson <bill.simpson@um.cc.umich.edu> November 1994.
[Joel Snyder]
[SXA] Susie Armstrong <Armstrong.wbst128@XEROX.COM>
[SXD] Steve Deering <deering@PARC.XEROX.COM>
[tynan] Dermot Tynan, <dtynan@claddagh.ie>, August 1995.
[Toga] Jim Toga, <jtoga@ibeam.jf.intel.com>, May 1996.
[Uang] Yea Uang <uang@force.decnet.lockheed.com> November 1994.
[Veizades] John Veizades, <veizades@tgv.com>, May 1995.
[Yackle] Dotty Yackle, <ditty_yackle@dantz.com>, February 1996.
Hinden & Deering Informational [Page 6]
RFC 2375 IPv6 Multicast Address Assignments July 1998
7.0 Security Considerations
This document defines the initial assignment of IPv6 multicast
addresses. As such it does not directly impact the security of the
Internet infrastructure or its applications.
8.0 Authors' Addresses
Robert M. Hinden
Ipsilon Networks, Inc.
232 Java Drive
Sunnyvale, CA 94089
USA
Phone: +1 415 990 2004
EMail: hinden@ipsilon.com
Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 527-8213
EMail: deering@cisco.com
Hinden & Deering Informational [Page 7]
RFC 2375 IPv6 Multicast Address Assignments July 1998
9.0 Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Hinden & Deering Informational [Page 8]

1459
doc/rfc/rfc2418.txt Normal file
View file

File diff suppressed because it is too large Load diff

2635
doc/rfc/rfc2535.txt Normal file
View file

File diff suppressed because it is too large Load diff

339
doc/rfc/rfc2536.txt Normal file
View file

@ -0,0 +1,339 @@
Network Working Group D. EastLake
Request for Comments: 2536 IBM
Category: Standards Track March 1999
DSA KEYs and SIGs in the Domain Name System (DNS)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
A standard method for storing US Government Digital Signature
Algorithm keys and signatures in the Domain Name System is described
which utilizes DNS KEY and SIG resource records.
Table of Contents
Abstract...................................................1
1. Introduction............................................1
2. DSA KEY Resource Records................................2
3. DSA SIG Resource Records................................3
4. Performance Considerations..............................3
5. Security Considerations.................................4
6. IANA Considerations.....................................4
References.................................................5
Author's Address...........................................5
Full Copyright Statement...................................6
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. The DNS has been extended to include digital
signatures and cryptographic keys as described in [RFC 2535]. Thus
the DNS can now be secured and can be used for secure key
distribution.
Eastlake Standards Track [Page 1]
RFC 2536 DSA in the DNS March 1999
This document describes how to store US Government Digital Signature
Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
US Digital Signature Algorithm is assumed [Schneier]. Implementation
of DSA is mandatory for DNS security.
2. DSA KEY Resource Records
DSA public keys are stored in the DNS as KEY RRs using algorithm
number 3 [RFC 2535]. The structure of the algorithm specific portion
of the RDATA part of this RR is as shown below. These fields, from Q
through Y are the "public key" part of the DSA KEY RR.
The period of key validity is not in the KEY RR but is indicated by
the SIG RR(s) which signs and authenticates the KEY RR(s) at that
domain name.
Field Size
----- ----
T 1 octet
Q 20 octets
P 64 + T*8 octets
G 64 + T*8 octets
Y 64 + T*8 octets
As described in [FIPS 186] and [Schneier]: T is a key size parameter
chosen such that 0 <= T <= 8. (The meaning for algorithm 3 if the T
octet is greater than 8 is reserved and the remainder of the RDATA
portion may have a different format in that case.) Q is a prime
number selected at key generation time such that 2**159 < Q < 2**160
so Q is always 20 octets long and, as with all other fields, is
stored in "big-endian" network order. P, G, and Y are calculated as
directed by the FIPS 186 key generation algorithm [Schneier]. P is
in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T
octets long. G and Y are quantities modulus P and so can be up to
the same length as P and are allocated fixed size fields with the
same number of octets as P.
During the key generation process, a random number X must be
generated such that 1 <= X <= Q-1. X is the private key and is used
in the final step of public key generation where Y is computed as
Y = G**X mod P
Eastlake Standards Track [Page 2]
RFC 2536 DSA in the DNS March 1999
3. DSA SIG Resource Records
The signature portion of the SIG RR RDATA area, when using the US
Digital Signature Algorithm, is shown below with fields in the order
they occur. See [RFC 2535] for fields in the SIG RR RDATA which
precede the signature itself.
Field Size
----- ----
T 1 octet
R 20 octets
S 20 octets
The data signed is determined as specified in [RFC 2535]. Then the
following steps are taken, as specified in [FIPS 186], where Q, P, G,
and Y are as specified in the public key [Schneier]:
hash = SHA-1 ( data )
Generate a random K such that 0 < K < Q.
R = ( G**K mod P ) mod Q
S = ( K**(-1) * (hash + X*R) ) mod Q
Since Q is 160 bits long, R and S can not be larger than 20 octets,
which is the space allocated.
T is copied from the public key. It is not logically necessary in
the SIG but is present so that values of T > 8 can more conveniently
be used as an escape for extended versions of DSA or other algorithms
as later specified.
4. Performance Considerations
General signature generation speeds are roughly the same for RSA [RFC
2537] and DSA. With sufficient pre-computation, signature generation
with DSA is faster than RSA. Key generation is also faster for DSA.
However, signature verification is an order of magnitude slower than
RSA when the RSA public exponent is chosen to be small as is
recommended for KEY RRs used in domain name system (DNS) data
authentication.
Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including overhead. While larger
transfers will perform correctly and work is underway to make larger
transfers more efficient, it is still advisable at this time to make
reasonable efforts to minimize the size of KEY RR sets stored within
Eastlake Standards Track [Page 3]
RFC 2536 DSA in the DNS March 1999
the DNS consistent with adequate security. Keep in mind that in a
secure zone, at least one authenticating SIG RR will also be
returned.
5. Security Considerations
Many of the general security consideration in [RFC 2535] apply. Keys
retrieved from the DNS should not be trusted unless (1) they have
been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is essential and
dependent on local policy.
The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
current DSA standard may limit the security of DSA. For particularly
critical applications, implementors are encouraged to consider the
range of available algorithms and key sizes.
DSA assumes the ability to frequently generate high quality random
numbers. See [RFC 1750] for guidance. DSA is designed so that if
manipulated rather than random numbers are used, very high bandwidth
covert channels are possible. See [Schneier] and more recent
research. The leakage of an entire DSA private key in only two DSA
signatures has been demonstrated. DSA provides security only if
trusted implementations, including trusted random number generation,
are used.
6. IANA Considerations
Allocation of meaning to values of the T parameter that are not
defined herein requires an IETF standards actions. It is intended
that values unallocated herein be used to cover future extensions of
the DSS standard.
Eastlake Standards Track [Page 4]
RFC 2536 DSA in the DNS March 1999
References
[FIPS 186] U.S. Federal Information Processing Standard: Digital
Signature Standard.
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
System (DNS)", RFC 2537, March 1999.
[Schneier] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996.
Author's Address
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 10512
Phone: +1-914-276-2668(h)
+1-914-784-7913(w)
Fax: +1-914-784-3833(w)
EMail: dee3@us.ibm.com
Eastlake Standards Track [Page 5]
RFC 2536 DSA in the DNS March 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Eastlake Standards Track [Page 6]

339
doc/rfc/rfc2537.txt Normal file
View file

@ -0,0 +1,339 @@
Network Working Group D. Eastlake
Request for Comments: 2537 IBM
Category: Standards Track March 1999
RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
A standard method for storing RSA keys and and RSA/MD5 based
signatures in the Domain Name System is described which utilizes DNS
KEY and SIG resource records.
Table of Contents
Abstract...................................................1
1. Introduction............................................1
2. RSA Public KEY Resource Records.........................2
3. RSA/MD5 SIG Resource Records............................2
4. Performance Considerations..............................3
5. Security Considerations.................................4
References.................................................4
Author's Address...........................................5
Full Copyright Statement...................................6
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. The DNS has been extended to include digital
signatures and cryptographic keys as described in [RFC 2535]. Thus
the DNS can now be secured and used for secure key distribution.
Eastlake Standards Track [Page 1]
RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999
This document describes how to store RSA keys and and RSA/MD5 based
signatures in the DNS. Familiarity with the RSA algorithm is assumed
[Schneier]. Implementation of the RSA algorithm in DNS is
recommended.
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in RFC 2119.
2. RSA Public KEY Resource Records
RSA public keys are stored in the DNS as KEY RRs using algorithm
number 1 [RFC 2535]. The structure of the algorithm specific portion
of the RDATA part of such RRs is as shown below.
Field Size
----- ----
exponent length 1 or 3 octets (see text)
exponent as specified by length field
modulus remaining space
For interoperability, the exponent and modulus are each currently
limited to 4096 bits in length. The public key exponent is a
variable length unsigned integer. Its length in octets is
represented as one octet if it is in the range of 1 to 255 and by a
zero octet followed by a two octet unsigned length if it is longer
than 255 bytes. The public key modulus field is a multiprecision
unsigned integer. The length of the modulus can be determined from
the RDLENGTH and the preceding RDATA fields including the exponent.
Leading zero octets are prohibited in the exponent and modulus.
3. RSA/MD5 SIG Resource Records
The signature portion of the SIG RR RDATA area, when using the
RSA/MD5 algorithm, is calculated as shown below. The data signed is
determined as specified in [RFC 2535]. See [RFC 2535] for fields in
the SIG RR RDATA which precede the signature itself.
hash = MD5 ( data )
signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
Eastlake Standards Track [Page 2]
RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999
where MD5 is the message digest algorithm documented in [RFC 1321],
"|" is concatenation, "e" is the private key exponent of the signer,
and "n" is the modulus of the signer's public key. 01, FF, and 00
are fixed octets of the corresponding hexadecimal value. "prefix" is
the ASN.1 BER MD5 algorithm designator prefix specified in [RFC
2437], that is,
hex 3020300c06082a864886f70d020505000410 [NETSEC].
This prefix is included to make it easier to use RSAREF (or similar
packages such as EuroRef). The FF octet MUST be repeated the maximum
number of times such that the value of the quantity being
exponentiated is the same length in octets as the value of n.
(The above specifications are identical to the corresponding part of
Public Key Cryptographic Standard #1 [RFC 2437].)
The size of n, including most and least significant bits (which will
be 1) MUST be not less than 512 bits and not more than 4096 bits. n
and e SHOULD be chosen such that the public exponent is small.
Leading zero bytes are permitted in the RSA/MD5 algorithm signature.
A public exponent of 3 minimizes the effort needed to verify a
signature. Use of 3 as the public exponent is weak for
confidentiality uses since, if the same data can be collected
encrypted under three different keys with an exponent of 3 then,
using the Chinese Remainder Theorem [NETSEC], the original plain text
can be easily recovered. This weakness is not significant for DNS
security because we seek only authentication, not confidentiality.
4. Performance Considerations
General signature generation speeds are roughly the same for RSA and
DSA [RFC 2536]. With sufficient pre-computation, signature
generation with DSA is faster than RSA. Key generation is also
faster for DSA. However, signature verification is an order of
magnitude slower with DSA when the RSA public exponent is chosen to
be small as is recommended for KEY RRs used in domain name system
(DNS) data authentication.
Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including overhead. While larger
transfers will perform correctly and work is underway to make larger
Eastlake Standards Track [Page 3]
RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999
transfers more efficient, it is still advisable at this time to make
reasonable efforts to minimize the size of KEY RR sets stored within
the DNS consistent with adequate security. Keep in mind that in a
secure zone, at least one authenticating SIG RR will also be
returned.
5. Security Considerations
Many of the general security consideration in [RFC 2535] apply. Keys
retrieved from the DNS should not be trusted unless (1) they have
been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is essential and
dependent on local policy.
For interoperability, the RSA key size is limited to 4096 bits. For
particularly critical applications, implementors are encouraged to
consider the range of available algorithms and key sizes.
References
[NETSEC] Kaufman, C., Perlman, R. and M. Speciner, "Network
Security: PRIVATE Communications in a PUBLIC World",
Series in Computer Networking and Distributed
Communications, 1995.
[RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", RFC 2437, October 1998.
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321
April 1992.
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC 2536] EastLake, D., "DSA KEYs and SIGs in the Domain Name
System (DNS)", RFC 2536, March 1999.
Eastlake Standards Track [Page 4]
RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999
[Schneier] Bruce Schneier, "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996, John
Wiley and Sons, ISBN 0-471-11709-9.
Author's Address
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 10512
Phone: +1-914-276-2668(h)
+1-914-784-7913(w)
Fax: +1-914-784-3833(w)
EMail: dee3@us.ibm.com
Eastlake Standards Track [Page 5]
RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Eastlake Standards Track [Page 6]

563
doc/rfc/rfc2538.txt Normal file
View file

@ -0,0 +1,563 @@
Network Working Group D. Eastlake
Request for Comments: 2538 IBM
Category: Standards Track O. Gudmundsson
TIS Labs
March 1999
Storing Certificates in the Domain Name System (DNS)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
Cryptographic public key are frequently published and their
authenticity demonstrated by certificates. A CERT resource record
(RR) is defined so that such certificates and related certificate
revocation lists can be stored in the Domain Name System (DNS).
Table of Contents
Abstract...................................................1
1. Introduction............................................2
2. The CERT Resource Record................................2
2.1 Certificate Type Values................................3
2.2 Text Representation of CERT RRs........................4
2.3 X.509 OIDs.............................................4
3. Appropriate Owner Names for CERT RRs....................5
3.1 X.509 CERT RR Names....................................5
3.2 PGP CERT RR Names......................................6
4. Performance Considerations..............................6
5. IANA Considerations.....................................7
6. Security Considerations.................................7
References.................................................8
Authors' Addresses.........................................9
Full Copyright Notice.....................................10
Eastlake & Gudmundsson Standards Track [Page 1]
RFC 2538 Storing Certificates in the DNS March 1999
1. Introduction
Public keys are frequently published in the form of a certificate and
their authenticity is commonly demonstrated by certificates and
related certificate revocation lists (CRLs). A certificate is a
binding, through a cryptographic digital signature, of a public key,
a validity interval and/or conditions, and identity, authorization,
or other information. A certificate revocation list is a list of
certificates that are revoked, and incidental information, all signed
by the signer (issuer) of the revoked certificates. Examples are
X.509 certificates/CRLs in the X.500 directory system or PGP
certificates/revocations used by PGP software.
Section 2 below specifies a CERT resource record (RR) for the storage
of certificates in the Domain Name System.
Section 3 discusses appropriate owner names for CERT RRs.
Sections 4, 5, and 6 below cover performance, IANA, and security
considerations, respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. The CERT Resource Record
The CERT resource record (RR) has the structure given below. Its RR
type code is 37.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | key tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | /
+---------------+ certificate or CRL /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The type field is the certificate type as define in section 2.1
below.
The algorithm field has the same meaning as the algorithm field in
KEY and SIG RRs [RFC 2535] except that a zero algorithm field
indicates the algorithm is unknown to a secure DNS, which may simply
be the result of the algorithm not having been standardized for
secure DNS.
Eastlake & Gudmundsson Standards Track [Page 2]
RFC 2538 Storing Certificates in the DNS March 1999
The key tag field is the 16 bit value computed for the key embedded
in the certificate as specified in the DNSSEC Standard [RFC 2535].
This field is used as an efficiency measure to pick which CERT RRs
may be applicable to a particular key. The key tag can be calculated
for the key in question and then only CERT RRs with the same key tag
need be examined. However, the key must always be transformed to the
format it would have as the public key portion of a KEY RR before the
key tag is computed. This is only possible if the key is applicable
to an algorithm (and limits such as key size limits) defined for DNS
security. If it is not, the algorithm field MUST BE zero and the tag
field is meaningless and SHOULD BE zero.
2.1 Certificate Type Values
The following values are defined or reserved:
Value Mnemonic Certificate Type
----- -------- ----------- ----
0 reserved
1 PKIX X.509 as per PKIX
2 SPKI SPKI cert
3 PGP PGP cert
4-252 available for IANA assignment
253 URI URI private
254 OID OID private
255-65534 available for IANA assignment
65535 reserved
The PKIX type is reserved to indicate an X.509 certificate conforming
to the profile being defined by the IETF PKIX working group. The
certificate section will start with a one byte unsigned OID length
and then an X.500 OID indicating the nature of the remainder of the
certificate section (see 2.3 below). (NOTE: X.509 certificates do
not include their X.500 directory type designating OID as a prefix.)
The SPKI type is reserved to indicate a certificate formated as to be
specified by the IETF SPKI working group.
The PGP type indicates a Pretty Good Privacy certificate as described
in RFC 2440 and its extensions and successors.
The URI private type indicates a certificate format defined by an
absolute URI. The certificate portion of the CERT RR MUST begin with
a null terminated URI [RFC 2396] and the data after the null is the
private format certificate itself. The URI SHOULD be such that a
retrieval from it will lead to documentation on the format of the
certificate. Recognition of private certificate types need not be
based on URI equality but can use various forms of pattern matching
Eastlake & Gudmundsson Standards Track [Page 3]
RFC 2538 Storing Certificates in the DNS March 1999
so that, for example, subtype or version information can also be
encoded into the URI.
The OID private type indicates a private format certificate specified
by a an ISO OID prefix. The certificate section will start with a
one byte unsigned OID length and then a BER encoded OID indicating
the nature of the remainder of the certificate section. This can be
an X.509 certificate format or some other format. X.509 certificates
that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
type, not the OID private type. Recognition of private certificate
types need not be based on OID equality but can use various forms of
pattern matching such as OID prefix.
2.2 Text Representation of CERT RRs
The RDATA portion of a CERT RR has the type field as an unsigned
integer or as a mnemonic symbol as listed in section 2.1 above.
The key tag field is represented as an unsigned integer.
The algorithm field is represented as an unsigned integer or a
mnemonic symbol as listed in [RFC 2535].
The certificate / CRL portion is represented in base 64 and may be
divided up into any number of white space separated substrings, down
to single base 64 digits, which are concatenated to obtain the full
signature. These substrings can span lines using the standard
parenthesis.
Note that the certificate / CRL portion may have internal sub-fields
but these do not appear in the master file representation. For
example, with type 254, there will be an OID size, an OID, and then
the certificate / CRL proper. But only a single logical base 64
string will appear in the text representation.
2.3 X.509 OIDs
OIDs have been defined in connection with the X.500 directory for
user certificates, certification authority certificates, revocations
of certification authority, and revocations of user certificates.
The following table lists the OIDs, their BER encoding, and their
length prefixed hex format for use in CERT RRs:
Eastlake & Gudmundsson Standards Track [Page 4]
RFC 2538 Storing Certificates in the DNS March 1999
id-at-userCertificate
= { joint-iso-ccitt(2) ds(5) at(4) 36 }
== 0x 03 55 04 24
id-at-cACertificate
= { joint-iso-ccitt(2) ds(5) at(4) 37 }
== 0x 03 55 04 25
id-at-authorityRevocationList
= { joint-iso-ccitt(2) ds(5) at(4) 38 }
== 0x 03 55 04 26
id-at-certificateRevocationList
= { joint-iso-ccitt(2) ds(5) at(4) 39 }
== 0x 03 55 04 27
3. Appropriate Owner Names for CERT RRs
It is recommended that certificate CERT RRs be stored under a domain
name related to their subject, i.e., the name of the entity intended
to control the private key corresponding to the public key being
certified. It is recommended that certificate revocation list CERT
RRs be stored under a domain name related to their issuer.
Following some of the guidelines below may result in the use in DNS
names of characters that require DNS quoting which is to use a
backslash followed by the octal representation of the ASCII code for
the character such as \000 for NULL.
3.1 X.509 CERT RR Names
Some X.509 versions permit multiple names to be associated with
subjects and issuers under "Subject Alternate Name" and "Issuer
Alternate Name". For example, x.509v3 has such Alternate Names with
an ASN.1 specification as follows:
GeneralName ::= CHOICE {
otherName [0] INSTANCE OF OTHER-NAME,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] EXPLICIT OR-ADDRESS.&Type,
directoryName [4] EXPLICIT Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER
}
The recommended locations of CERT storage are as follows, in priority
order:
Eastlake & Gudmundsson Standards Track [Page 5]
RFC 2538 Storing Certificates in the DNS March 1999
(1) If a domain name is included in the identification in the
certificate or CRL, that should be used.
(2) If a domain name is not included but an IP address is included,
then the translation of that IP address into the appropriate
inverse domain name should be used.
(3) If neither of the above it used but a URI containing a domain
name is present, that domain name should be used.
(4) If none of the above is included but a character string name is
included, then it should be treated as described for PGP names in
3.2 below.
(5) If none of the above apply, then the distinguished name (DN)
should be mapped into a domain name as specified in RFC 2247.
Example 1: Assume that an X.509v3 certificate is issued to /CN=John
Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative
names of (a) string "John (the Man) Doe", (b) domain name john-
doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>. Then
the storage locations recommended, in priority order, would be
(1) john-doe.com,
(2) www.secure.john-doe.com, and
(3) Doe.com.xy.
Example 2: Assume that an X.509v3 certificate is issued to /CN=James
Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
of (a) domain name widget.foo.example, (b) IPv4 address
10.251.13.201, and (c) string "James Hacker
<hacker@mail.widget.foo.example>". Then the storage locations
recommended, in priority order, would be
(1) widget.foo.example,
(2) 201.13.251.10.in-addr.arpa, and
(3) hacker.mail.widget.foo.example.
3.2 PGP CERT RR Names
PGP signed keys (certificates) use a general character string User ID
[RFC 2440]. However, it is recommended by PGP that such names include
the RFC 822 email address of the party, as in "Leslie Example
<Leslie@host.example>". If such a format is used, the CERT should be
under the standard translation of the email address into a domain
name, which would be leslie.host.example in this case. If no RFC 822
name can be extracted from the string name no specific domain name is
recommended.
4. Performance Considerations
Current Domain Name System (DNS) implementations are optimized for
small transfers, typically not more than 512 bytes including
overhead. While larger transfers will perform correctly and work is
Eastlake & Gudmundsson Standards Track [Page 6]
RFC 2538 Storing Certificates in the DNS March 1999
underway to make larger transfers more efficient, it is still
advisable at this time to make every reasonable effort to minimize
the size of certificates stored within the DNS. Steps that can be
taken may include using the fewest possible optional or extensions
fields and using short field values for variable length fields that
must be included.
5. IANA Considerations
Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
only be assigned by an IETF standards action [RFC 2434] (and this
document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE).
Certificate types 0x0100 through 0xFEFF are assigned through IETF
Consensus [RFC 2434] based on RFC documentation of the certificate
type. The availability of private types under 0x00FD and 0x00FE
should satisfy most requirements for proprietary or private types.
6. Security Considerations
By definition, certificates contain their own authenticating
signature. Thus it is reasonable to store certificates in non-secure
DNS zones or to retrieve certificates from DNS with DNS security
checking not implemented or deferred for efficiency. The results MAY
be trusted if the certificate chain is verified back to a known
trusted key and this conforms with the user's security policy.
Alternatively, if certificates are retrieved from a secure DNS zone
with DNS security checking enabled and are verified by DNS security,
the key within the retrieved certificate MAY be trusted without
verifying the certificate chain if this conforms with the user's
security policy.
CERT RRs are not used in connection with securing the DNS security
additions so there are no security considerations related to CERT RRs
and securing the DNS itself.
Eastlake & Gudmundsson Standards Track [Page 7]
RFC 2538 Storing Certificates in the DNS March 1999
References
RFC 1034 Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
RFC 1035 Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC 2247 Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
Sataluri, "Using Domains in LDAP/X.500 Distinguished
Names", RFC 2247, January 1998.
RFC 2396 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
RFC 2440 Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
"OpenPGP Message Format", RFC 2240, November 1998.
RFC 2434 Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
RFC 2535 Eastlake, D., "Domain Name System (DNS) Security
Extensions", RFC 2535, March 1999.
RFC 2459 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, January 1999.
Eastlake & Gudmundsson Standards Track [Page 8]
RFC 2538 Storing Certificates in the DNS March 1999
Authors' Addresses
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road
RR#1
Carmel, NY 10512 USA
Phone: +1-914-784-7913 (w)
+1-914-276-2668 (h)
Fax: +1-914-784-3833 (w-fax)
EMail: dee3@us.ibm.com
Olafur Gudmundsson
TIS Labs at Network Associates
3060 Washington Rd, Route 97
Glenwood MD 21738
Phone: +1 443-259-2389
EMail: ogud@tislabs.com
Eastlake & Gudmundsson Standards Track [Page 9]
RFC 2538 Storing Certificates in the DNS March 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Eastlake & Gudmundsson Standards Track [Page 10]

395
doc/rfc/rfc2539.txt Normal file
View file

@ -0,0 +1,395 @@
Network Working Group D. Eastlake
Request for Comments: 2539 IBM
Category: Standards Track March 1999
Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
A standard method for storing Diffie-Hellman keys in the Domain Name
System is described which utilizes DNS KEY resource records.
Acknowledgements
Part of the format for Diffie-Hellman keys and the description
thereof was taken from a work in progress by:
Ashar Aziz <ashar.aziz@eng.sun.com>
Tom Markson <markson@incog.com>
Hemma Prafullchandra <hemma@eng.sun.com>
In addition, the following person provided useful comments that have
been incorporated:
Ran Atkinson <rja@inet.org>
Thomas Narten <narten@raleigh.ibm.com>
Eastlake Standards Track [Page 1]
RFC 2539 Diffie-Hellman Keys in the DNS March 1999
Table of Contents
Abstract...................................................1
Acknowledgements...........................................1
1. Introduction............................................2
1.1 About This Document....................................2
1.2 About Diffie-Hellman...................................2
2. Diffie-Hellman KEY Resource Records.....................3
3. Performance Considerations..............................4
4. IANA Considerations.....................................4
5. Security Considerations.................................4
References.................................................5
Author's Address...........................................5
Appendix A: Well known prime/generator pairs...............6
A.1. Well-Known Group 1: A 768 bit prime..................6
A.2. Well-Known Group 2: A 1024 bit prime.................6
Full Copyright Notice......................................7
1. Introduction
The Domain Name System (DNS) is the current global hierarchical
replicated distributed database system for Internet addressing, mail
proxy, and similar information. The DNS has been extended to include
digital signatures and cryptographic keys as described in [RFC 2535].
Thus the DNS can now be used for secure key distribution.
1.1 About This Document
This document describes how to store Diffie-Hellman keys in the DNS.
Familiarity with the Diffie-Hellman key exchange algorithm is assumed
[Schneier].
1.2 About Diffie-Hellman
Diffie-Hellman requires two parties to interact to derive keying
information which can then be used for authentication. Since DNS SIG
RRs are primarily used as stored authenticators of zone information
for many different resolvers, no Diffie-Hellman algorithm SIG RR is
defined. For example, assume that two parties have local secrets "i"
and "j". Assume they each respectively calculate X and Y as follows:
X = g**i ( mod p ) Y = g**j ( mod p )
They exchange these quantities and then each calculates a Z as
follows:
Zi = Y**i ( mod p ) Zj = X**j ( mod p )
Eastlake Standards Track [Page 2]
RFC 2539 Diffie-Hellman Keys in the DNS March 1999
shared secret between the two parties that an adversary who does not
know i or j will not be able to learn from the exchanged messages
(unless the adversary can derive i or j by performing a discrete
logarithm mod p which is hard for strong p and g).
The private key for each party is their secret i (or j). The public
key is the pair p and g, which must be the same for the parties, and
their individual X (or Y).
2. Diffie-Hellman KEY Resource Records
Diffie-Hellman keys are stored in the DNS as KEY RRs using algorithm
number 2. The structure of the RDATA portion of this RR is as shown
below. The first 4 octets, including the flags, protocol, and
algorithm fields are common to all KEY RRs as described in [RFC
2535]. The remainder, from prime length through public value is the
"public key" part of the KEY RR. The period of key validity is not in
the KEY RR but is indicated by the SIG RR(s) which signs and
authenticates the KEY RR(s) at that domain name.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEY flags | protocol | algorithm=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prime length (or flag) | prime (p) (or special) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ prime (p) (variable length) | generator length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| generator (g) (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| public value length | public value (variable length)/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ public value (g^i mod p) (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prime length is length of the Diffie-Hellman prime (p) in bytes if it
is 16 or greater. Prime contains the binary representation of the
Diffie-Hellman prime with most significant byte first (i.e., in
network order). If "prime length" field is 1 or 2, then the "prime"
field is actually an unsigned index into a table of 65,536
prime/generator pairs and the generator length SHOULD be zero. See
Appedix A for defined table entries and Section 4 for information on
allocating additional table entries. The meaning of a zero or 3
through 15 value for "prime length" is reserved.
Eastlake Standards Track [Page 3]
RFC 2539 Diffie-Hellman Keys in the DNS March 1999
Generator length is the length of the generator (g) in bytes.
Generator is the binary representation of generator with most
significant byte first. PublicValueLen is the Length of the Public
Value (g**i (mod p)) in bytes. PublicValue is the binary
representation of the DH public value with most significant byte
first.
The corresponding algorithm=2 SIG resource record is not used so no
format for it is defined.
3. Performance Considerations
Current DNS implementations are optimized for small transfers,
typically less than 512 bytes including overhead. While larger
transfers will perform correctly and work is underway to make larger
transfers more efficient, it is still advisable to make reasonable
efforts to minimize the size of KEY RR sets stored within the DNS
consistent with adequate security. Keep in mind that in a secure
zone, an authenticating SIG RR will also be returned.
4. IANA Considerations
Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
an IETF consensus.
Well known prime/generator pairs number 0x0000 through 0x07FF can
only be assigned by an IETF standards action and this Proposed
Standard assigns 0x0001 through 0x0002. Pairs number 0s0800 through
0xBFFF can be assigned based on RFC documentation. Pairs number
0xC000 through 0xFFFF are available for private use and are not
centrally coordinated. Use of such private pairs outside of a closed
environment may result in conflicts.
5. Security Considerations
Many of the general security consideration in [RFC 2535] apply. Keys
retrieved from the DNS should not be trusted unless (1) they have
been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is important and
dependent on local policy.
In addition, the usual Diffie-Hellman key strength considerations
apply. (p-1)/2 should also be prime, g should be primitive mod p, p
should be "large", etc. [Schneier]
Eastlake Standards Track [Page 4]
RFC 2539 Diffie-Hellman Keys in the DNS March 1999
References
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and
Sons
Author's Address
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 10512
Phone: +1-914-276-2668(h)
+1-914-784-7913(w)
Fax: +1-914-784-3833(w)
EMail: dee3@us.ibm.com
Eastlake Standards Track [Page 5]
RFC 2539 Diffie-Hellman Keys in the DNS March 1999
Appendix A: Well known prime/generator pairs
These numbers are copied from the IPSEC effort where the derivation
of these values is more fully explained and additional information is
available. Richard Schroeppel performed all the mathematical and
computational work for this appendix.
A.1. Well-Known Group 1: A 768 bit prime
The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
decimal value is
155251809230070893513091813125848175563133404943451431320235
119490296623994910210725866945387659164244291000768028886422
915080371891804634263272761303128298374438082089019628850917
0691316593175367469551763119843371637221007210577919
Prime modulus: Length (32 bit words): 24, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
A.2. Well-Known Group 2: A 1024 bit prime
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its decimal value is
179769313486231590770839156793787453197860296048756011706444
423684197180216158519368947833795864925541502180565485980503
646440548199239100050792877003355816639229553136239076508735
759914822574862575007425302077447712589550957937778424442426
617334727629299387668709205606050270810842907692932019128194
467627007
Prime modulus: Length (32 bit words): 32, Data (hex):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
Generator: Length (32 bit words): 1, Data (hex): 2
Eastlake Standards Track [Page 6]
RFC 2539 Diffie-Hellman Keys in the DNS March 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Eastlake Standards Track [Page 7]

339
doc/rfc/rfc2540.txt Normal file
View file

@ -0,0 +1,339 @@
Network Working Group D. Eastlake
Request for Comments: 2540 IBM
Category: Experimental March 1999
Detached Domain Name System (DNS) Information
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
A standard format is defined for representing detached DNS
information. This is anticipated to be of use for storing
information retrieved from the Domain Name System (DNS), including
security information, in archival contexts or contexts not connected
to the Internet.
Table of Contents
Abstract...................................................1
1. Introduction............................................1
2. General Format..........................................2
2.1 Binary Format..........................................3
2.2. Text Format...........................................4
3. Usage Example...........................................4
4. IANA Considerations.....................................4
5. Security Considerations.................................4
References.................................................5
Author's Address...........................................5
Full Copyright Statement...................................6
1. Introduction
The Domain Name System (DNS) is a replicated hierarchical distributed
database system [RFC 1034, 1035] that can provide highly available
service. It provides the operational basis for Internet host name to
address translation, automatic SMTP mail routing, and other basic
Internet functions. The DNS has been extended as described in [RFC
2535] to permit the general storage of public cryptographic keys in
Eastlake Experimental [Page 1]
RFC 2540 Detached DNS Information March 1999
the DNS and to enable the authentication of information retrieved
from the DNS though digital signatures.
The DNS was not originally designed for storage of information
outside of the active zones and authoritative master files that are
part of the connected DNS. However there may be cases where this is
useful, particularly in connection with archived security
information.
2. General Format
The formats used for detached Domain Name System (DNS) information
are similar to those used for connected DNS information. The primary
difference is that elements of the connected DNS system (unless they
are an authoritative server for the zone containing the information)
are required to count down the Time To Live (TTL) associated with
each DNS Resource Record (RR) and discard them (possibly fetching a
fresh copy) when the TTL reaches zero. In contrast to this, detached
information may be stored in a off-line file, where it can not be
updated, and perhaps used to authenticate historic data or it might
be received via non-DNS protocols long after it was retrieved from
the DNS. Therefore, it is not practical to count down detached DNS
information TTL and it may be necessary to keep the data beyond the
point where the TTL (which is defined as an unsigned field) would
underflow. To preserve information as to the freshness of this
detached data, it is accompanied by its retrieval time.
Whatever retrieves the information from the DNS must associate this
retrieval time with it. The retrieval time remains fixed thereafter.
When the current time minus the retrieval time exceeds the TTL for
any particular detached RR, it is no longer a valid copy within the
normal connected DNS scheme. This may make it invalid in context for
some detached purposes as well. If the RR is a SIG (signature) RR it
also has an expiration time. Regardless of the TTL, it and any RRs
it signs can not be considered authenticated after the signature
expiration time.
Eastlake Experimental [Page 2]
RFC 2540 Detached DNS Information March 1999
2.1 Binary Format
The standard binary format for detached DNS information is as
follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| first retrieval time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| next retrieval time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hex 20 |
+-+-+-+-+-+-+-+-+
Retrieval time - the time that the immediately following information
was obtained from the connected DNS system. It is an unsigned
number of seconds since the start of 1 January 1970, GMT,
ignoring leap seconds, in network (big-endian) order. Note that
this time can not be before the initial proposal of this
standard. Therefore, the initial byte of an actual retrieval
time, considered as a 32 bit unsigned quantity, would always be
larger than 20 hex. The end of detached DNS information is
indicated by a "retrieval time" field initial byte equal to 0x20.
Use of a "retrieval time" field with a leading unsigned byte of
zero indicates a 64 bit (actually 8 leading zero bits plus a 56
bit quantity). This 64 bit format will be required when
retrieval time is larger than 0xFFFFFFFF, which is some time in
the year 2106. The meaning of retrieval times with an initial
byte between 0x01 and 0x1F is reserved (see section 5).
Retrieval times will not generally be 32 bit aligned with respect
to each other due to the variable length nature of RRs.
RR count - an unsigned integer number (with bytes in network order)
of following resource records retrieved at the preceding
retrieval time.
Eastlake Experimental [Page 3]
RFC 2540 Detached DNS Information March 1999
Resource Records - the actual data which is in the same format as if
it were being transmitted in a DNS response. In particular, name
compression via pointers is permitted with the origin at the
beginning of the particular detached information data section,
just after the RR count.
2.2. Text Format
The standard text format for detached DNS information is as
prescribed for zone master files [RFC 1035] except that the $INCLUDE
control entry is prohibited and the new $DATE entry is required
(unless the information set is empty). $DATE is followed by the date
and time that the following information was obtained from the DNS
system as described for retrieval time in section 2.1 above. It is
in the text format YYYYMMDDHHMMSS where YYYY is the year (which may
be more than four digits to cover years after 9999), the first MM is
the month number (01-12), DD is the day of the month (01-31), HH is
the hour in 24 hours notation (00-23), the second MM is the minute
(00-59), and SS is the second (00-59). Thus a $DATE must appear
before the first RR and at every change in retrieval time through the
detached information.
3. Usage Example
A document might be authenticated by a key retrieved from the DNS in
a KEY resource record (RR). To later prove the authenticity of this
document, it would be desirable to preserve the KEY RR for that
public key, the SIG RR signing that KEY RR, the KEY RR for the key
used to authenticate that SIG, and so on through SIG and KEY RRs
until a well known trusted key is reached, perhaps the key for the
DNS root or some third party authentication service. (In some cases
these KEY RRs will actually be sets of KEY RRs with the same owner
and class because SIGs actually sign such record sets.)
This information could be preserved as a set of detached DNS
information blocks.
4. IANA Considerations
Allocation of meanings to retrieval time fields with a initial byte
of between 0x01 and 0x1F requires an IETF consensus.
5. Security Considerations
The entirety of this document concerns a means to represent detached
DNS information. Such detached resource records may be security
relevant and/or secured information as described in [RFC 2535]. The
detached format provides no overall security for sets of detached
Eastlake Experimental [Page 4]
RFC 2540 Detached DNS Information March 1999
information or for the association between retrieval time and
information. This can be provided by wrapping the detached
information format with some other form of signature. However, if
the detached information is accompanied by SIG RRs, its validity
period is indicated in those SIG RRs so the retrieval time might be
of secondary importance.
References
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] Mockapetris, P., " Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
Author's Address
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 10512
Phone: +1-914-276-2668(h)
+1-914-784-7913(w)
Fax: +1-914-784-3833(w)
EMail: dee3@us.ibm.com
Eastlake Experimental [Page 5]
RFC 2540 Detached DNS Information March 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Eastlake Experimental [Page 6]

395
doc/rfc/rfc2541.txt Normal file
View file

@ -0,0 +1,395 @@
Network Working Group D. Eastlake
Request for Comments: 2541 IBM
Category: Informational March 1999
DNS Security Operational Considerations
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
Secure DNS is based on cryptographic techniques. A necessary part of
the strength of these techniques is careful attention to the
operational aspects of key and signature generation, lifetime, size,
and storage. In addition, special attention must be paid to the
security of the high level zones, particularly the root zone. This
document discusses these operational aspects for keys and signatures
used in connection with the KEY and SIG DNS resource records.
Acknowledgments
The contributions and suggestions of the following persons (in
alphabetic order) are gratefully acknowledged:
John Gilmore
Olafur Gudmundsson
Charlie Kaufman
Eastlake Informational [Page 1]
RFC 2541 DNS Security Operational Considerations March 1999
Table of Contents
Abstract...................................................1
Acknowledgments............................................1
1. Introduction............................................2
2. Public/Private Key Generation...........................2
3. Public/Private Key Lifetimes............................2
4. Public/Private Key Size Considerations..................3
4.1 RSA Key Sizes..........................................3
4.2 DSS Key Sizes..........................................4
5. Private Key Storage.....................................4
6. High Level Zones, The Root Zone, and The Meta-Root Key..5
7. Security Considerations.................................5
References.................................................6
Author's Address...........................................6
Full Copyright Statement...................................7
1. Introduction
This document describes operational considerations for the
generation, lifetime, size, and storage of DNS cryptographic keys and
signatures for use in the KEY and SIG resource records [RFC 2535].
Particular attention is paid to high level zones and the root zone.
2. Public/Private Key Generation
Careful generation of all keys is a sometimes overlooked but
absolutely essential element in any cryptographically secure system.
The strongest algorithms used with the longest keys are still of no
use if an adversary can guess enough to lower the size of the likely
key space so that it can be exhaustively searched. Technical
suggestions for the generation of random keys will be found in [RFC
1750].
Long term keys are particularly sensitive as they will represent a
more valuable target and be subject to attack for a longer time than
short period keys. It is strongly recommended that long term key
generation occur off-line in a manner isolated from the network via
an air gap or, at a minimum, high level secure hardware.
3. Public/Private Key Lifetimes
No key should be used forever. The longer a key is in use, the
greater the probability that it will have been compromised through
carelessness, accident, espionage, or cryptanalysis. Furthermore, if
Eastlake Informational [Page 2]
RFC 2541 DNS Security Operational Considerations March 1999
key rollover is a rare event, there is an increased risk that, when
the time does come to change the key, no one at the site will
remember how to do it or operational problems will have developed in
the key rollover procedures.
While public key lifetime is a matter of local policy, these
considerations imply that, unless there are extraordinary
circumstances, no long term key should have a lifetime significantly
over four years. In fact, a reasonable guideline for long term keys
that are kept off-line and carefully guarded is a 13 month lifetime
with the intent that they be replaced every year. A reasonable
maximum lifetime for keys that are used for transaction security or
the like and are kept on line is 36 days with the intent that they be
replaced monthly or more often. In many cases, a key lifetime of
somewhat over a day may be reasonable.
On the other hand, public keys with too short a lifetime can lead to
excessive resource consumption in re-signing data and retrieving
fresh information because cached information becomes stale. In the
Internet environment, almost all public keys should have lifetimes no
shorter than three minutes, which is a reasonable estimate of maximum
packet delay even in unusual circumstances.
4. Public/Private Key Size Considerations
There are a number of factors that effect public key size choice for
use in the DNS security extension. Unfortunately, these factors
usually do not all point in the same direction. Choice of zone key
size should generally be made by the zone administrator depending on
their local conditions.
For most schemes, larger keys are more secure but slower. In
addition, larger keys increase the size of the KEY and SIG RRs. This
increases the chance of DNS UDP packet overflow and the possible
necessity for using higher overhead TCP in responses.
4.1 RSA Key Sizes
Given a small public exponent, verification (the most common
operation) for the MD5/RSA algorithm will vary roughly with the
square of the modulus length, signing will vary with the cube of the
modulus length, and key generation (the least common operation) will
vary with the fourth power of the modulus length. The current best
algorithms for factoring a modulus and breaking RSA security vary
roughly with the 1.6 power of the modulus itself. Thus going from a
640 bit modulus to a 1280 bit modulus only increases the verification
time by a factor of 4 but may increase the work factor of breaking
the key by over 2^900.
Eastlake Informational [Page 3]
RFC 2541 DNS Security Operational Considerations March 1999
The recommended minimum RSA algorithm modulus size is 704 bits which
is believed by the author to be secure at this time. But high level
zones in the DNS tree may wish to set a higher minimum, perhaps 1000
bits, for security reasons. (Since the United States National
Security Agency generally permits export of encryption systems using
an RSA modulus of up to 512 bits, use of that small a modulus, i.e.
n, must be considered weak.)
For an RSA key used only to secure data and not to secure other keys,
704 bits should be adequate at this time.
4.2 DSS Key Sizes
DSS keys are probably roughly as strong as an RSA key of the same
length but DSS signatures are significantly smaller.
5. Private Key Storage
It is recommended that, where possible, zone private keys and the
zone file master copy be kept and used in off-line, non-network
connected, physically secure machines only. Periodically an
application can be run to add authentication to a zone by adding SIG
and NXT RRs and adding no-key type KEY RRs for subzones/algorithms
where a real KEY RR for the subzone with that algorithm is not
provided. Then the augmented file can be transferred, perhaps by
sneaker-net, to the networked zone primary server machine.
The idea is to have a one way information flow to the network to
avoid the possibility of tampering from the network. Keeping the
zone master file on-line on the network and simply cycling it through
an off-line signer does not do this. The on-line version could still
be tampered with if the host it resides on is compromised. For
maximum security, the master copy of the zone file should be off net
and should not be updated based on an unsecured network mediated
communication.
This is not possible if the zone is to be dynamically updated
securely [RFC 2137]. At least a private key capable of updating the
SOA and NXT chain must be on line in that case.
Secure resolvers must be configured with some trusted on-line public
key information (or a secure path to such a resolver) or they will be
unable to authenticate. Although on line, this public key
information must be protected or it could be altered so that spoofed
DNS data would appear authentic.
Eastlake Informational [Page 4]
RFC 2541 DNS Security Operational Considerations March 1999
Non-zone private keys, such as host or user keys, generally have to
be kept on line to be used for real-time purposes such as DNS
transaction security.
6. High Level Zones, The Root Zone, and The Meta-Root Key
Higher level zones are generally more sensitive than lower level
zones. Anyone controlling or breaking the security of a zone thereby
obtains authority over all of its subdomains (except in the case of
resolvers that have locally configured the public key of a
subdomain). Therefore, extra care should be taken with high level
zones and strong keys used.
The root zone is the most critical of all zones. Someone controlling
or compromising the security of the root zone would control the
entire DNS name space of all resolvers using that root zone (except
in the case of resolvers that have locally configured the public key
of a subdomain). Therefore, the utmost care must be taken in the
securing of the root zone. The strongest and most carefully handled
keys should be used. The root zone private key should always be kept
off line.
Many resolvers will start at a root server for their access to and
authentication of DNS data. Securely updating an enormous population
of resolvers around the world will be extremely difficult. Yet the
guidelines in section 3 above would imply that the root zone private
key be changed annually or more often and if it were staticly
configured at all these resolvers, it would have to be updated when
changed.
To permit relatively frequent change to the root zone key yet
minimize exposure of the ultimate key of the DNS tree, there will be
a "meta-root" key used very rarely and then only to sign a sequence
of regular root key RRsets with overlapping time validity periods
that are to be rolled out. The root zone contains the meta-root and
current regular root KEY RR(s) signed by SIG RRs under both the
meta-root and other root private key(s) themselves.
The utmost security in the storage and use of the meta-root key is
essential. The exact techniques are precautions to be used are
beyond the scope of this document. Because of its special position,
it may be best to continue with the same meta-root key for an
extended period of time such as ten to fifteen years.
7. Security Considerations
The entirety of this document is concerned with operational
considerations of public/private key pair DNS Security.
Eastlake Informational [Page 5]
RFC 2541 DNS Security Operational Considerations March 1999
References
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Requirements for Security", RFC 1750, December 1994.
[RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System
Security Extensions", RFC 2065, January 1997.
[RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic
Update", RFC 2137, April 1997.
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RSA FAQ] RSADSI Frequently Asked Questions periodic posting.
Author's Address
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 10512
Phone: +1-914-276-2668(h)
+1-914-784-7913(w)
Fax: +1-914-784-3833(w)
EMail: dee3@us.ibm.com
Eastlake Informational [Page 6]
RFC 2541 DNS Security Operational Considerations March 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Eastlake Informational [Page 7]