ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

Remove hard copies of RFCs and I-D from BIND repository, the authoritative source is IETF, and our copies doesn't reflect any errata, expired-by, etc.

Browse Source
This commit is contained in:
Ondřej Surý
2018-02-16 15:55:58 +01:00
parent c6b430745b
commit 6336ef1ef3
206 changed files with 0 additions and 186158 deletions
Download Patch File Download Diff File Expand all files Collapse all files

646
doc/draft/draft-faltstrom-uri-08.txt
View File

@@ -1,646 +0,0 @@
Network Working Group P. Faltstrom
Internet-Draft Netnod
Updates: 3404, 3959 (if approved) O. Kolkman
Intended status: Standards Track NLnet Labs
Expires: January 04, 2014 July 5, 2013
The Uniform Resource Identifier (URI) DNS Resource Record
draft-faltstrom-uri-08
Abstract
This document defines a new DNS resource record, called the Uniform
Resource Identifier (URI) RR, for publishing mappings from hostnames
to URIs.
This document updates RFC 3958 and RFC 3404.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 04, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
Faltstrom & Kolkman Expires January 04, 2014 [Page 1]
Internet-Draft URI Resource Record July 2013
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 3
4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 3
4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4
4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 5
5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 5
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Homepage at one domain, but two domains in use . . . . . . 6
7. Relation to S-NAPTR . . . . . . . . . . . . . . . . . . . . . 6
8. Relation to U-NAPTR . . . . . . . . . . . . . . . . . . . . . 6
9. Relation to SRV . . . . . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10.1. Registration of the URI Resource Record Type . . . . . . 7
10.2. Registration of services . . . . . . . . . . . . . . . . 7
11. Security Considerations . . . . . . . . . . . . . . . . . . . 7
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.1. Normative References . . . . . . . . . . . . . . . . . . 8
13.2. Non-normative references . . . . . . . . . . . . . . . . 8
Appendix A. The original RRTYPE Allocation Request . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
This document explains the use of the Domain Name System (DNS) for
the storage of URIs, and how to resolve hostnames to such URIs that
can be used by various applications. For resolution the application
need to know both the hostname and the protocol that the URI is to be
used for. The protocol is registered by IANA.
Currently, looking up URIs given a hostname uses the DDDS [RFC3401]
application framework with the DNS as a database as specified in RFC
3404 [RFC3404]. This has a number of implications such as the
inability to select what NAPTR records that match the query are
interesting. The RRSet returned will always consist of all URIs
"connected" with the domain in question.
The URI resource record specified in this document enables the
querying party to select which ones of the NAPTR records one is
interested in. This because data in the service field of the NAPTR
record is included in the owner part of the URI resource record type.
Faltstrom & Kolkman Expires January 04, 2014 [Page 2]
Internet-Draft URI Resource Record July 2013
Querying for URI resource records is not replacing querying for NAPTR
resource records (or use of S-NAPTR [RFC3958]). Instead, the URI
resource record type provides a complementary mechanism to use when
one already knows what service field is interesting. With it, one
can directly query for the specific subset of the otherwise possibly
large RRSet given back when querying for NAPTR resource records.
This document updates RFC 3958 and RFC 3404 by adding the flag "D" to
the list of defined terminal flags in section 2.2.3 of RFC 3958 and
4.3 of RFC 3404.
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 BCP 14, RFC 2119
[RFC2119].
2. Applicability Statement
In general, it is expected that URI records will be used by clients
for applications where the relevant protocol to be used is known,
but, for example, an extra abstraction is needed in order to separate
a domain name from a point of service (as addressed by the URI). One
example of such a situation is when an organisation has many domain
names, but only one official web page.
Applications MUST know the specific service fields to prepend the
hostname with. Using repetitive queries for URI records MUST NOT be
a replacement for querying for NAPTR records according to the NAPTR
(DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose to
discover the various services and URIs for looking up access points
for a given service. Those are two very different kinds of needs.
3. DNS considerations
Using prefix labels, such as underscored service tags, prevents the
use of wildcards, as constructs as _s2._s1.*.example.net. are not
possible in the DNS, see RFC 4592 [RFC4592]. Besides, underscored
service tags used for the URI RR (based on the NAPTR service
descriptions) may have slightly different semantics than service tags
used for underscored prefix labels that are used in combination with
other (yet unspecified) RR types. This may cause subtle management
problems when delegation structure that has developed within the
context of URI RRs is also to be used for other RR types. Since the
service labels might be overloaded, applications should carefully
check that the application level protocol is indeed the protocol they
expect.
Subtle management issues may also arise when the delegations from
service to sub service label involves several parties and different
stake holders.
4. The format of the URI RR
Faltstrom & Kolkman Expires January 04, 2014 [Page 3]
Internet-Draft URI Resource Record July 2013
This is the presentation format of the URI RR:
Ownername TTL Class URI Priority Weight Target
The URI RR does not cause any kind of Additional Section processing.
4.1. Ownername, class and type
The URI ownername is subject to special conventions.
Just like the SRV RR [RFC2782] the URI RR has service information
encoded in its ownername. In order to encode the service for a
specific owner name one uses service parameters. Valid service
parameters used are those used for SRV resource records, or
registered by IANA for Enumservice Registrations. The Enumservice
Registration parameters are reversed (subtype(s) before type),
prepended with an underscore (_) and prepended to the owner name in
separate labels. The underscore is prepended to the service
parameters to avoid collisions with DNS labels that occur in nature,
and the order is reversed to make it possible to do delegations, if
needed, to different zones (and therefore providers of DNS).
It should be noted that the usage of a prefix must be described in
detail in for example the Enumservice Registration documentation, or
in a specific document that clarifies potential overload of
parameters in the same URI. Specifically, registered URI schemes are
not automatically acceptable as a service. With the HTTP scheme, one
can for example have multiple methods (GET, PUT, etc), and this with
the same URI.
For example, suppose we are looking for the URI for a service with
Service Parameter "A:B:C" for host example.com.. Then we would query
for (QNAME,QTYPE)=("_C._B._A.example.com","URI")
The type number for the URI record is 256.
The URI resource record is class independent.
The URI RR has no special TTL requirements.
4.2. Priority
The priority of the target URI in this RR. Its range is 0-65535. A
client MUST attempt to contact the URI with the lowest-numbered
priority it can reach; URIs with the same priority SHOULD be tried in
Faltstrom & Kolkman Expires January 04, 2014 [Page 4]
Internet-Draft URI Resource Record July 2013
the order defined by the weight field.
4.3. Weight
A server selection mechanism. The weight field specifies a relative
weight for entries with the same priority. Larger weights SHOULD be
given a proportionately higher probability of being selected. The
range of this number is 0-65535.
4.4. Target
The URI of the target, enclosed in double-quote characters ('"').
Resolution of the URI is according to the definitions for the Scheme
of the URI.
Since the URI will not be encoded as a <character-string> (see
RFC1035 section 3.3 [RFC1035]) there is no 255 character size
limitation.
4.5. URI RDATA Wire Format
The RDATA for a URI RR consists of a 2 octet Priority field, a two
octet Weight field, and a variable length target field.
Priority and Weight are unsigned integers in network byte order.
The remaining data in the RDATA contains the Target field. The
Target field contains the URI as a sequence of octets (without the
enclosing double- quote characters used in the presentation format).
The Target field can also contain an IRI, but with the additional
requirements that it are in UTF-8 [RFC3629], and the requirement that
it be possible to convert to a URI according to section 3.1 of RFC
3987 [RFC3987] and back again to an IRI according to section 3.2.
Other character sets than UTF-8 are not allowed. The domain name
part of the IRI can be either an U-LABEL or A-LABEL as defined in RFC
5890 [RFC5890].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Target /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Definition of the flag 'D' for NAPTR records
Faltstrom & Kolkman Expires January 04, 2014 [Page 5]
Internet-Draft URI Resource Record July 2013
This document specifies the flag "D" for use as a flag in NAPTR
records. The flag indicate a terminal NAPTR record because it
denotes the end of the DDDS/NAPTR processing rules. In the case of a
"D" flag, the Replacement field in the NAPTR record, prepended with
the service flags, is used as the Owner of a DNS query for URI
records, and normal URI processing as defined in this document is
applied.
The replacement field MUST NOT include any of the service parameters.
Those are to be prepended (together with underscore) as described in
other places in this document.
The Regexp field in the NAPTR record MUST be empty when the 'D' flag
is in use.
6. Examples
6.1. Homepage at one domain, but two domains in use
An organisation has the domain names example.com and example.net, but
the official URI http://www.example.com/. Given the service type
"web" and subtype "http" (from the IANA registry), the following URI
Resource Records could be made available in the respective zones
(example.com and example.net):
$ORIGIN example.com.
_http._web IN URI 10 1 "http://www.example.com/"
$ORIGIN example.net.
_http._web IN URI 10 1 "http://www.example.com/"
7. Relation to S-NAPTR
The URI resource record type is not a replacement for the S-NAPTR.
It is instead an extension and the seond step of the S-NAPTR
resolution can resolve a URI resource record instead of using SRV
records and yet another algorithm for how to use SRV records for the
specific protocol.
$ORIGIN example.com.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.example.com. ; replacement
_ProtA._tcp IN URI "schemeA:service.example.com/example"
8. Relation to U-NAPTR
Faltstrom & Kolkman Expires January 04, 2014 [Page 6]
Internet-Draft URI Resource Record July 2013
The URI Resource Record Type, together with S-NAPTR, can be viewed as
a replacement for U-NAPTR [RFC4848]. The URI Resource Record Type is
though only interesting when one know a base domain name, a protocol
and service so that one can compose the record to look up. NAPTR
records of any kind are used to look up what services exists for a
certain domain, which is one step before the URI resource record is
used.
9. Relation to SRV
The URI Resource Record Type can be viewed as a replacement for the
SRV record. This because it like the SRV record can only be looked
up if one know the base domain, the protocol and the service. It has
a similar functionality, but instead of returning a hostname and port
number, the URI record return a full URI. As such, it can be viewed
as a more powerful resource record than SRV.
10. IANA Considerations
10.1. Registration of the URI Resource Record Type
After an expert review in February 2011 (see Appendix Appendix A)
IANA has allocated RRTYPE 256 for the URI Resource Record Type in the
registry named Resource Record (RR) TYPEs and QTYPEs as defined in
BCP 42 (at the time RFC 6195 [RFC6195]), located at http://
www.iana.org/assignments/dns-parameters.
IANA is requested to update the reference with that registration to
this RFC.
10.2. Registration of services
No new registry is needed for the registration of services as the
Enumservice Registrations registry is used also for the URI resource
record type.
11. Security Considerations
The authors do not believe this resource record cause any new
security problems. Deployment must though be done in a proper way as
misconfiguration of this resource record might make it impossible to
reach the service that was originally intended to be accessed.
Using the URI resource record together with security mechanisms that
relies on verification of authentication of hostnames, like TLS,
makes it important to choose the correct domain name when doing the
comparison.
The basic mechanism works as follows:
1. Announce the fact example.com is hosted at example.org (with
some URL) in DNS
2. Secure the URI resource record with DNSSEC.
Faltstrom & Kolkman Expires January 04, 2014 [Page 7]
Internet-Draft URI Resource Record July 2013
3. Verify the TLS (for example) certificate for the connection to
example.org matches, i.e. use the hostname in the URI and not
the hostname used originally when looking up the URI resource
record.
4. If needed, do application layer authentication etc over the then
encrypted connection.
What also can happen is that the URI in the resource record type has
errors in it. Applications using the URI resource record type for
resolution should behave similarly as if the user typed (or copy and
pasted) the URI. At least it must be clear to the user that the error
is not due to any error from his side.
One SHOULD NOT include userinfo (see User Information, Section 3.2.1,
in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record
as DNS data must be viewed as publicly available information.
12. Acknowledgements
Ideas on how to split the two different kind of queries "What
services exists for this domain name" and "What is the URI for this
service" came from Scott Bradner and Lawrence Conroy. Other people
that have contributed to this document include Richard Barnes, Leslie
Daigle, Olafur Gudmundsson, Ted Hardie, Peter Koch, Penn Pfautz, and
Willem Toorop.
13. References
13.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[RFC6195] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6195, March 2011.
13.2. Non-normative references
Faltstrom & Kolkman Expires January 04, 2014 [Page 8]
Internet-Draft URI Resource Record July 2013
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", RFC
3403, October 2002.
[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)", RFC
3404, October 2002.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 2006.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007.
[RFC5507] IAB, Faltstrom, P., Austein, R. and P. Koch, "Design
Choices When Expanding the DNS", RFC 5507, April 2009.
Appendix A. The original RRTYPE Allocation Request
On February 22, 2011 IANA assigned RRTYPE 256 for the URI resource
record based on a request that followed the procedure documented in
RFC 6195 [RFC6195]. The DNS RRTYPE PARAMETER ALLOCATION form as
submitted to IANA at thet time is replicated below for reference.
A. Submission Date:
May 23, 2009
B. Submission Type:
[X] New RRTYPE
[ ] Modification to existing RRTYPE
C. Contact Information for submitter:
Name: Patrik Faltstrom
Email Address: paf@cisco.com
International telephone number: +46-8-6859131
Faltstrom & Kolkman Expires January 04, 2014 [Page 9]
Internet-Draft URI Resource Record July 2013
Other contact handles:
(Note: This information will be publicly posted.)
D. Motivation for the new RRTYPE application?
There is no easy way to get from a domain name to a URI (or
IRI). Some mechanisms exists via use of the NAPTR [RFC3403]
resource record. That implies quite complicated rules that are
simplified via the S-NAPTR [RFC3958] specification. But, the
ability to directly look up a URI still exists. This
specification uses a prefix based naming mechanism originated in
the definition of the SRV [RFC2782] resource record, and the
RDATA is a URI, encoded as one text field.
See also above (Section 1).
E. Description of the proposed RR type.
The format of the URI resource record is as follows:
Ownername TTL Class URI Priority Weight Target
The URI RR has service information encoded in its ownername. In
order to encode the service for a specific owner name one uses
service parameters. Valid service parameters used are either
Enumservice Registrations registered by IANA, or prefixes used
for the SRV resource record.
The wire format of the RDATA 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Target /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F. What existing RRTYPE or RRTYPEs come closest to filling that
need and why are they unsatisfactory?
Faltstrom & Kolkman Expires January 04, 2014 [Page 10]
Internet-Draft URI Resource Record July 2013
The RRTYPE that come closest is the NAPTR resource record. It
is for example used in the DDDS and S-NAPTR algorithms. The
main problem with the NAPTR is that selection of what record (or
records) one is interested in is based on data stored in the
RDATA portion of the NAPTR resource record. This, as explained
in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further,
most applications using NAPTR resource records uses regular
expression based rewrite rules for creation of the URI, and that
has shown be complicated to implement.
The second closest RRTYPE is the SRV record that given a
prefixed based naming just like is suggested for the URI
resource record, one get back a port number and domain name.
This can also be used for creation of a URI, but, only URIs
without path components.
G. What mnemonic is requested for the new RRTYPE (optional)?
URI
H. Does the requested RRTYPE make use of any existing IANA Registry
or require the creation of a new IANA sub-registry in DNS
Parameters?
Yes, partially.
One of the mechanisms to select a service is to use the
Enumservice Registry managed by IANA. Another is to use services
and protocols used for SRV records.
I. Does the proposal require/expect any changes in DNS servers/
resolvers that prevent the new type from being processed as an
unknown RRTYPE (see [RFC3597])?
No
J. Comments:
None
Authors' Addresses
Patrik Faltstrom
Netnod
Email: paf@netnod.se
Olaf Kolkman
NLnet Labs
Email: olaf@NLnetLabs.nl
Faltstrom & Kolkman Expires January 04, 2014 [Page 11]

448
doc/draft/draft-ietf-dnsext-dnssec-registry-fixes-08.txt
View File

@@ -1,448 +0,0 @@
DNS Extensions Working Group S. Rose
Internet-Draft NIST
Updates: 2536, 2539, 3110, 4034, 4398, May 26, 2011
5155, 5702, 5933 (if approved)
Intended status: Standards Track
Expires: November 27, 2011
Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA
Registry
draft-ietf-dnsext-dnssec-registry-fixes-08
Abstract
The DNS Security Extensions (DNSSEC) requires the use of
cryptographic algorithm suites for generating digital signatures over
DNS data. There is currently an IANA registry for these algorithms
that is incomplete in that it lacks the implementation status of each
algorithm. This document provides an applicability statement on
algorithm implementation compliance status for DNSSEC
implementations. This status is to measure compliance to this RFC
only. This document replaces that registry table with a new IANA
registry table for Domain Name System Security (DNSSEC) Algorithm
Numbers that lists (or assigns) each algorithm's status based on the
current reference.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 27, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Rose Expires November 27, 2011 [Page 1]
Internet-Draft IANA Registry Fixes May 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. The DNS Security Algorithm Number Sub-registry . . . . . . . . 3
2.1. Updates and Additions . . . . . . . . . . . . . . . . . . . 4
2.2. Domain Name System (DNS) Security Algorithm Number
Registry Table . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Specifying New Algorithms and Updating Status of
Existing Entries . . . . . . . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Rose Expires November 27, 2011 [Page 2]
Internet-Draft IANA Registry Fixes May 2011
1. Introduction
The Domain Name System (DNS) Security Extensions (DNSSEC) [RFC4033],
[RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702] uses
digital signatures over DNS data to provide source authentication and
integrity protection. DNSSEC uses an IANA registry to list codes for
digital signature algorithms (consisting of a cryptographic algorithm
and one-way hash function).
The original list of algorithm status is found in [RFC4034]. Other
DNSSEC RFC's have added new algorithms or changed the status of
algorithms in the registry. However, implementers must read through
all the documents in order to discover which algorithms are
considered wise to implement, which are not, and which algorithms may
become widely used in the future. This document replaces the
original list with a new table that includes the current compliance
status for certain algorithms.
This compliance status indication is only to be considered for
implementation, not deployment or operations. Operators are free to
deploy any digital signature algorithm available in implementations
or algorithms chosen by local security policies. This status is to
measure compliance to this RFC only.
This document replaces the current IANA registry for Domain Name
System Security (DNSSEC) Algorithm Numbers with a newly defined
registry table. This new table (Section 2.2 below) contains a column
that will list the current compliance status of each digital
signature algorithm in the registry at the time of writing and
assigns status for some algorithms used with DNSSEC that did not have
an identified status in their specification. This document updates
the following: [RFC2536], [RFC2539], [RFC3110], [RFC4034], [RFC4398],
[RFC5155], [RFC5702], and [RFC5933].
1.1. Requirements Language
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 DNS Security Algorithm Number Sub-registry
The DNS Security Algorithm Number sub-registry (part of the Domain
Name System (DNS) Security Number registry) will be replaced with the
table below. This table is based on the existing DNS Security
Algorithm Number sub-registry and adds a column that contains the
current implementation status of the given algorithm.
Rose Expires November 27, 2011 [Page 3]
Internet-Draft IANA Registry Fixes May 2011
There are additional differences to entries that are described in
sub-section 2.1. The overall new registry table is in sub-section
2.2. The values for the compliance status were obtained from
[RFC4034] with updates for algorithms specified after the original
DNSSEC specification. If no status was listed in the original
specification, this document assigns one.
2.1. Updates and Additions
This document updates three entries in the Domain Name System
Security (DNSSEC) Algorithm Registry. They are:
The description for assignment number 4 is changed to "Reserved until
2020".
The description for assignment number 9 is changed to "Reserved until
2020".
The description for assignment number 11 is changed to "Reserved
until 2020".
Registry entries 13-251 remains Unassigned.
The status of RSASHA1-NSEC3-SHA1 is set to RECOMMENDED TO IMPLEMENT.
This is due to the fact that RSA/SHA-1 is a MUST IMPLEMENT. The
status of RSA/SHA-256 and RSA/SHA-512 are also set to RECOMMENDED TO
IMPLEMENT as it is believed that these algorithms will replace an
older algorithm (e.g. RSA/SHA-1) that have a perceived weakness in
its hash algorithm (SHA-1).
Rose Expires November 27, 2011 [Page 4]
Internet-Draft IANA Registry Fixes May 2011
2.2. Domain Name System (DNS) Security Algorithm Number Registry Table
The Domain Name System (DNS) Security Algorithm Number registry is
hereby specified as follows below. The new column is titled
"Compliance to RFC TBD" (where TBD will change when published) as the
IANA Registry table is not normative. The IANA registry table is
only a reflection of the RFC, which is normative.
Trans-
Zone action Compliance to
Number Description Mnemonic Sign Sign RFC TBD1 Reference
------ ----------- ------ ---- ----- ------------ ---------
0 Reserved [RFC4398]
1 RSA/MD5 RSAMD5 N Y MUST NOT [RFC2537]
IMPLEMENT
2 Diffie-Hellman DH N Y [RFC2539]
3 DSA/SHA-1 DSASHA1 Y Y [RFC2536]
4 Reserved until
2020
5 RSA/SHA-1 RSASHA1 Y Y MUST [RFC3110]
IMPLEMENT
6 DSA-NSEC3-SHA1 DSA-NSEC3 Y Y [RFC5155]
-SHA1
7 RSASHA1-NSEC3 RSASHA1- Y Y RECOMMENDED [RFC5155]
-SHA1 NSEC3- TO IMPLEMENT
SHA1
8 RSA/SHA-256 RSASHA256 Y * RECOMMENDED [RFC5702]
TO IMPLEMENT
9 Reserved until
2020
10 RSA/SHA-512 RSASHA512 Y * RECOMMENDED [RFC5702]
TO IMPLEMENT
11 Reserved until
2020
12 GOST R GOST-ECC Y * [RFC5933]
34.10-2001
13-251 Unassigned
252 Reserved for INDIRECT N N [RFC4034]
Indirect keys
253 private PRIVATE Y Y [RFC4034]
algorithm
254 private PRIVATEOID Y Y [RFC4034]
algorithm OID
255 Reserved
Table rows where the compliance column is not filled in are left to
the discretion of implementers. Their implementation (or lack
thereof) therefore cannot be included when judging compliance to this
Rose Expires November 27, 2011 [Page 5]
Internet-Draft IANA Registry Fixes May 2011
document.
2.3. Specifying New Algorithms and Updating Status of Existing Entries
[RFC6014] establishes a parallel procedure for adding a registry
entry for a new algorithm other than a standards track document.
Algorithms entered into the registry using that procedure do not have
a listed compliance status. Specifications that follow this path do
not need to obsolete or update this document.
Adding a newly specified algorithm to the registry with a compliance
status SHALL entail obsolescing this document and replacing the
registry table (with the new algorithm entry). Altering the status
column value of any existing algorithm in the registry SHALL entail
obsoleting this document and replacing the registry table.
This document cannot be updated, only made obsolete and replaced by a
successor document.
3. IANA Considerations
This document replaces the Domain Name System (DNS) Security
Algorithm Numbers registry. The new registry table is in Section
2.2. In the column "Compliance to RFC TBD", "RFC TBD" should be
changed to the official RFC when published.
The original Domain Name System (DNS) Security Algorithm Number
registry is available at
http://www.iana.org/assignments/dns-sec-alg-numbers.
4. Security Considerations
This document replaces the Domain Name System (DNS) Security
Algorithm Numbers registry. It is not meant to be a discussion on
algorithm superiority. No new security considerations are raised in
this document.
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
System (DNS)", RFC 2537, March 1999.
Rose Expires November 27, 2011 [Page 6]
Internet-Draft IANA Registry Fixes May 2011
[RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
System (DNS)", RFC 4398, March 2006.
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702,
October 2009.
[RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST
Signature Algorithms in DNSKEY and RRSIG Resource Records
for DNSSEC", RFC 5933, July 2010.
[RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier
Allocation for DNSSEC", RFC 6014, November 2010.
Rose Expires November 27, 2011 [Page 7]
Internet-Draft IANA Registry Fixes May 2011
Author's Address
Scott Rose
NIST
100 Bureau Dr.
Gaithersburg, MD 20899
USA
Phone: +1-301-975-8439
EMail: scottr.nist@gmail.com
Rose Expires November 27, 2011 [Page 8]

928
doc/draft/draft-ietf-dnsext-ecc-key-10.txt
View File

@@ -1,928 +0,0 @@
INTERNET-DRAFT Richard C. Schroeppel
Intended status: Proposed Standard Donald E. Eastlake 3rd
Expires: August 2007 March 2007
Elliptic Curve Keys and Signatures in the Domain Name System (DNS)
-------- ----- ---- --- ---------- -- --- ------ ---- ------ -----
<draft-ietf-dnsext-ecc-key-10.txt>
Richard C. Schroeppel
Donald Eastlake 3rd
Status of This Document
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the DNS mailing list <namedroppers@ops.ietf.org>.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The standard format for storing elliptic curve cryptographic keys and
elliptic curve SHA-1 based signatures in the Domain Name System (DNS)
is specified.
R. Schroeppel, et al [Page 1]
INTERNET-DRAFT ECC in the DNS
Acknowledgement
The assistance of Hilarie K. Orman in the production of this document
is greatfully acknowledged.
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Acknowledgement............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Elliptic Curve Keys in Resource Records.................3
3. The Elliptic Curve Equation.............................9
4. How do I Compute Q, G, and Y?..........................10
5. Elliptic Curve Signatures..............................11
6. Performance Considerations.............................13
7. Security Considerations................................13
8. IANA Considerations....................................13
Copyright and Additional IPR Provisions...................14
Informational References..................................15
Normative Refrences.......................................15
Author's Addresses........................................16
Expiration and File Name..................................16
Disclaimer................................................16
R. Schroeppel, et al [Page 2]
INTERNET-DRAFT ECC in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. [RFC1034] [RFC1035] The DNS stores data in
resource records and has been extended to include digital signatures
and cryptographic keys in some of these resource records.
This document describes how to format elliptic curve cryptographic
(ECC) key and signature data in the DNS so they can be used for a
variety of purposes. The signatures use the SHA-1 eigest algorithm
[RFC3174]. Familiarity with ECC cryptography is assumed [Menezes].
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. Elliptic Curve Keys in Resource Records
Elliptic curve public keys are stored, using the structure described
below, in the DNS within the RDATA portions of key RRs, such as RRKEY
[RFC4034] and IPSECKEY [RFC4025] RRs.
The research world continues to work on the issue of which is the
best elliptic curve system, which finite field to use, and how to
best represent elements in the field. So, representations are
defined for every type of finite field, and every type of elliptic
curve. The reader should be aware that there is a unique finite
field with a particular number of elements, but many possible
representations of that field and its elements. If two different
representations of a field are given, they are interconvertible with
a tedious but practical precomputation, followed by a fast
computation for each field element to be converted. It is perfectly
reasonable for an algorithm to work internally with one field
representation, and convert to and from a different external
representation.
R. Schroeppel, et al [Page 3]
INTERNET-DRAFT ECC in the DNS
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S M -FMT- A B Z|
+-+-+-+-+-+-+-+-+
| LP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P (length determined from LP) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F (length determined from LF) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGJ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRDV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H (length determined from LH) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K (length determined from LK) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (length determined from LA) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ALTA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B (length determined from LB) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C (length determined from LC) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LG |
R. Schroeppel, et al [Page 4]
INTERNET-DRAFT ECC in the DNS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G (length determined from LG) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Y (length determined from LY) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SMFMTABZ is a flags octet as follows:
S = 1 indicates that the remaining 7 bits of the octet selects
one of 128 predefined choices of finite field, element
representation, elliptic curve, and signature parameters.
MFMTABZ are omitted, as are all parameters from LP through G.
LY and Y are retained.
If S = 0, the remaining parameters are as in the picture and
described below.
M determines the type of field underlying the elliptic curve.
M = 0 if the field is a GF[2^N] field;
M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
FMT is a three bit field describing the format of the field
representation.
FMT = 0 for a (mod P) field.
> 0 for an extension field, either GF[2^D] or GF[P^D].
The degree D of the extension, and the field polynomial
must be specified. The field polynomial is always monic
(leading coefficient 1.)
FMT = 1 The field polynomial is given explicitly; D is implied.
If FMT >=2, the degree D is given explicitly.
= 2 The field polynomial is implicit.
= 3 The field polynomial is a binomial. P>2.
= 4 The field polynomial is a trinomial.
= 5 The field polynomial is the quotient of a trinomial by a
short polynomial. P=2.
= 6 The field polynomial is a pentanomial. P=2.
Flags A and B apply to the elliptic curve parameters.
R. Schroeppel, et al [Page 5]
INTERNET-DRAFT ECC in the DNS
A = 1 When P>=5, the curve parameter A is negated. If P=2, then
A=1 indicates that the A parameter is special. See the
ALTA parameter below, following A. The combination A=1,
P=3 is forbidden.
B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3,
then B=1 indicates an alternate elliptic curve equation is
used. When P=2 and B=1, an additional curve parameter C
is present.
The Z bit SHOULD be set to zero on creation of an RR and MUST be
ignored when processing an RR (when S=0).
Most of the remaining parameters are present in some formats and
absent in others. The presence or absence of a parameter is
determined entirely by the flags. When a parameter occurs, it is in
the order defined by the picture.
Of the remaining parameters, PFHKQABCGY are variable length. When
present, each is preceded by a one-octet length field as shown in the
diagram above. The length field does not include itself. The length
field may have values from 0 through 110. The parameter length in
octets is determined by a conditional formula: If LL<=64, the
parameter length is LL. If LL>64, the parameter length is 16 times
(LL-60). In some cases, a parameter value of 0 is sensible, and MAY
be represented by an LL value of 0, with the data field omitted. A
length value of 0 represents a parameter value of 0, not an absent
parameter. (The data portion occupies 0 space.) There is no
requirement that a parameter be represented in the minimum number of
octets; high-order 0 octets are allowed at the front end. Parameters
are always right adjusted, in a field of length defined by LL. The
octet-order is always most-significant first, least-significant last.
The parameters H and K may have an optional sign bit stored in the
unused high-order bit of their length fields.
LP defines the length of the prime P. P must be an odd prime. The
parameters LP,P are present if and only if the flag M=1. If M=0, the
prime is 2.
LF,F define an explicit field polynomial. This parameter pair is
present only when FMT = 1. The length of a polynomial coefficient is
ceiling(log2 P) bits. Coefficients are in the numerical range
[0,P-1]. The coefficients are packed into fixed-width fields, from
higher order to lower order. All coefficients must be present,
including any 0s and also the leading coefficient (which is required
to be 1). The coefficients are right justified into the octet string
of length specified by LF, with the low-order "constant" coefficient
at the right end. As a concession to storage efficiency, the higher
order bits of the leading coefficient may be elided, discarding high-
order 0 octets and reducing LF. The degree is calculated by
R. Schroeppel, et al [Page 6]
INTERNET-DRAFT ECC in the DNS
determining the bit position of the left most 1-bit in the F data
(counting the right most bit as position 0), and dividing by
ceiling(log2 P). The division must be exact, with no remainder. In
this format, all of the other degree and field parameters are
omitted. The next parameters will be LQ,Q.
If FMT>=2, the degree of the field extension is specified explicitly,
usually along with other parameters to define the field polynomial.
DEG is a two octet field that defines the degree of the field
extension. The finite field will have P^DEG elements. DEG is
present when FMT>=2.
When FMT=2, the field polynomial is specified implicitly. No other
parameters are required to define the field; the next parameters
present will be the LQ,Q pair. The implicit field poynomial is the
lexicographically smallest irreducible (mod P) polynomial of the
correct degree. The ordering of polynomials is by highest-degree
coefficients first -- the leading coefficient 1 is most important,
and the constant term is least important. Coefficients are ordered
by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of
degree D is X^D (which is not irreducible). The next is X^D+1, which
is sometimes irreducible, followed by X^D-1, which isn$t. Assuming
odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
X, X^D + X + 1, X^D + X - 1, etc.
When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
odd. The polynomial is determined by the degree and the low order
term K. Of all the field parameters, only the LK,K parameters are
present. The high-order bit of the LK octet stores on optional sign
for K; if the sign bit is present, the field polynomial is X^DEG - K.
When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
K. When P=2, the H and K parameters are implicitly 1, and are
omitted from the representation. Only DEG and DEGH are present; the
next parameters are LQ,Q. When P>2, then LH,H and LK,K are
specified. Either or both of LH, LK may contain a sign bit for its
parameter.
When FMT=5, then P=2 (only). The field polynomial is the exact
quotient of a trinomial divided by a small polynomial, the trinomial
divisor. The small polynomial is right-adjusted in the two octet
field TRDV. DEG specifies the degree of the field. The degree of
TRDV is calculated from the position of the high-order 1 bit. The
trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If
DEGH is 0, the middle term is omitted from the trinomial. The
quotient must be exact, with no remainder.
When FMT=6, then P=2 (only). The field polynomial is a pentanomial,
with the degrees of the middle terms given by the three 2-octet
R. Schroeppel, et al [Page 7]
INTERNET-DRAFT ECC in the DNS
values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI
> DEGJ > 0.
DEGH, DEGI, DEGJ are two-octet fields that define the degree of
a term in a field polynomial. DEGH is present when FMT = 4,
5, or 6. DEGI and DEGJ are present only when FMT = 6.
TRDV is a two-octet right-adjusted binary polynomial of degree <
16. It is present only for FMT=5.
LH and H define the H parameter, present only when FMT=4 and P
is odd. The high bit of LH is an optional sign bit for H.
LK and K define the K parameter, present when FMT = 3 or 4, and
P is odd. The high bit of LK is an optional sign bit for K.
The remaining parameters are concerned with the elliptic curve and
the signature algorithm.
LQ defines the length of the prime Q. Q is a prime > 2^159.
In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
member of the pair is an element from the finite field defined
earlier. The length field defines a long octet string. Field
elements are represented as (mod P) polynomials of degree < DEG, with
DEG or fewer coefficients. The coefficients are stored from left to
right, higher degree to lower, with the constant term last. The
coefficients are represented as integers in the range [0,P-1]. Each
coefficient is allocated an area of ceiling(log2 P) bits. The field
representation is right-justified; the "constant term" of the field
element ends at the right most bit. The coefficients are fitted
adjacently without regard for octet boundaries. (Example: if P=5,
three bits are used for each coefficient. If the field is GF[5^75],
then 225 bits are required for the coefficients, and as many as 29
octets may be needed in the data area. Fewer octets may be used if
some high-order coefficients are 0.) If a flag requires a field
element to be negated, each non-zero coefficient K is replaced with
P-K. To save space, 0 bits may be removed from the left end of the
element representation, and the length field reduced appropriately.
This would normally only happen with A,B,C, because the designer
chose curve parameters with some high-order 0 coefficients or bits.
If the finite field is simply (mod P), then the field elements are
simply numbers (mod P), in the usual right-justified notation. If
the finite field is GF[2^D], the field elements are the usual right-
justified polynomial basis representation.
R. Schroeppel, et al [Page 8]
INTERNET-DRAFT ECC in the DNS
LA,A is the first parameter of the elliptic curve equation.
When P>=5, the flag A = 1 indicates A should be negated (mod
P). When P=2 (indicated by the flag M=0), the flag A = 1
indicates that the parameter pair LA,A is replaced by the two
octet parameter ALTA. In this case, the parameter A in the
curve equation is x^ALTA, where x is the field generator.
Parameter A often has the value 0, which may be indicated by
LA=0 (with no A data field), and sometimes A is 1, which may
be represented with LA=1 and a data field of 1, or by setting
the A flag and using an ALTA value of 0.
LB,B is the second parameter of the elliptic curve equation.
When P>=5, the flag B = 1 indicates B should be negated (mod
P). When P=2 or 3, the flag B selects an alternate curve
equation.
LC,C is the third parameter of the elliptic curve equation,
present only when P=2 (indicated by flag M=0) and flag B=1.
LG,G defines a point on the curve, of order Q. The W-coordinate
of the curve point is given explicitly; the Z-coordinate is
implicit.
LY,Y is the user$s public signing key, another curve point of
order Q. The W-coordinate is given explicitly; the Z-
coordinate is implicit. The LY,Y parameter pair is always
present.
3. The Elliptic Curve Equation
(The coordinates of an elliptic curve point are named W,Z instead of
the more usual X,Y to avoid confusion with the Y parameter of the
signing key.)
The elliptic curve equation is determined by the flag octet, together
with information about the prime P. The primes 2 and 3 are special;
all other primes are treated identically.
If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
+ A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
If A and/or B is negative (i.e., in the range from P/2 to P), and
P>=5, space may be saved by putting the sign bit(s) in the A and B
bits of the flags octet, and the magnitude(s) in the parameter
fields.
If M=1 and P=3, the B flag has a different meaning: it specifies an
alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of
the right-hand-side is different. When P=3, this equation is more
R. Schroeppel, et al [Page 9]
INTERNET-DRAFT ECC in the DNS
commonly used.
If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
parameter can often be 0 or 1, or be chosen as a single-1-bit value.
The flag B is used to select an alternate curve equation, Z^2 + C*Z =
W^3 + A*W + B. This is the only time that the C parameter is used.
4. How do I Compute Q, G, and Y?
The number of points on the curve is the number of solutions to the
curve equation, + 1 (for the "point at infinity"). The prime Q must
divide the number of points. Usually the curve is chosen first, then
the number of points is determined with Schoof$s algorithm. This
number is factored, and if it has a large prime divisor, that number
is taken as Q.
G must be a point of order Q on the curve, satisfying the equation
Q * G = the point at infinity (on the elliptic curve)
G may be chosen by selecting a random [RFC4086] curve point, and
multiplying it by (number-of-points-on-curve/Q). G must not itself
be the "point at infinity"; in this astronomically unlikely event, a
new random curve point is recalculated.
G is specified by giving its W-coordinate. The Z-coordinate is
calculated from the curve equation. In general, there will be two
possible Z values. The rule is to choose the "positive" value.
In the (mod P) case, the two possible Z values sum to P. The smaller
value is less than P/2; it is used in subsequent calculations. In
GF[P^D] fields, the highest-degree non-zero coefficient of the field
element Z is used; it is chosen to be less than P/2.
In the GF[2^N] case, the two possible Z values xor to W (or to the
parameter C with the alternate curve equation). The numerically
smaller Z value (the one which does not contain the highest-order 1
bit of W (or C)) is used in subsequent calculations.
Y is specified by giving the W-coordinate of the user$s public
signature key. The Z-coordinate value is determined from the curve
equation. As with G, there are two possible Z values; the same rule
is followed for choosing which Z to use.
R. Schroeppel, et al [Page 10]
INTERNET-DRAFT ECC in the DNS
During the key generation process, a random [RFC4086] 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 = X * G (as points on the elliptic curve)
If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
in the (mod P) case, or the high-order non-zero coefficient of Z >
P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
GF[2^N] case), then X must be replaced with Q-X. This will
correspond to the correct Z-coordinate.
5. Elliptic Curve Signatures
The signature portion of an RR RDATA area when using the ECC
algorithm, for example in the SIG and RRSIG [RFC4034] RRs is shown
below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R, (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S, (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R and S are integers (mod Q). Their length is specified by the LQ
field of the corresponding KEY RR and can also be calculated from the
SIG RR$s RDLENGTH. They are right justified, high-order-octet first.
The same conditional formula for calculating the length from LQ is
used as for all the other length fields above.
The data signed is determined as specified in [RFC4034]. Then the
following steps are taken where Q, P, G, and Y are as specified in
the public key [Schneier]. For further information on SHA-1, see
[RFC3174].
hash = SHA-1 ( data )
Generate random [RFC4086] K such that 0 < K < Q. (Never sign
two different messages with the same K. K should be chosen
from a very large space: If an opponent learns a K value
for a single signature, the user$s signing key is
compromised, and a forger can sign arbitrary messages.
There is no harm in signing the same message multiple times
with the same key or different keys.)
R. Schroeppel, et al [Page 11]
INTERNET-DRAFT ECC in the DNS
R = (the W-coordinate of ( K*G on the elliptic curve ))
interpreted as an integer, and reduced (mod Q). (R must
not be 0. In this astronomically unlikely event, generate
a new random K and recalculate R.)
S = ( K^(-1) * (hash + X*R) ) mod Q.
S must not be 0. In this astronomically unlikely event,
generate a new random K and recalculate R and S.
If S > Q/2, set S = Q - S.
The pair (R,S) is the signature.
Another party verifies the signature as follows. For further
information on SHA-1, see [RFC3174].
Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a
valid EC sigature.
hash = SHA-1 ( data )
Sinv = S^(-1) mod Q.
U1 = (hash * Sinv) mod Q.
U2 = (R * Sinv) mod Q.
(U1 * G + U2 * Y) is computed on the elliptic curve.
V = (the W-coordinate of this point) interpreted as an integer
and reduced (mod Q).
The signature is valid if V = R.
The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
(R,Q-S) would be valid signatures for the same data. Note that a
signature that is valid for hash(data) is also valid for hash(data)+Q
or hash(data)-Q, if these happen to fall in the range [0,2^160-1].
It$s believed to be computationally infeasible to find data that
hashes to an assigned value, so this is only a cosmetic blemish. The
blemish can be eliminated by using Q > 2^160, at the cost of having
slightly longer signatures, 42 octets instead of 40.
We must specify how a field-element E ("the W-coordinate") is to be
interpreted as an integer. The field-element E is regarded as a
radix-P integer, with the digits being the coefficients in the
polynomial basis representation of E. The digits are in the ragne
[0,P-1]. In the two most common cases, this reduces to "the obvious
thing". In the (mod P) case, E is simply a residue mod P, and is
R. Schroeppel, et al [Page 12]
INTERNET-DRAFT ECC in the DNS
taken as an integer in the range [0,P-1]. In the GF[2^D] case, E is
in the D-bit polynomial basis representation, and is simply taken as
an integer in the range [0,(2^D)-1]. For other fields GF[P^D], it$s
necessary to do some radix conversion arithmetic.
6. Performance Considerations
Elliptic curve signatures use smaller moduli or field sizes than RSA
and DSA. Creation of a curve is slow, but not done very often. Key
generation is faster than RSA or DSA.
DNS implementations have been optimized for small transfers,
typically less than 512 octets including DNS overhead. Larger
transfers will perform correctly and and extensions have been
standardized to make larger transfers more efficient [RFC2671].
However, it is still advisable at this time to make reasonable
efforts to minimize the size of RR sets stored within the DNS
consistent with adequate security.
7. Security Considerations
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. [RFC4033] [RFC4034] [RFC4035] As with all
cryptographic algorithms, evaluating the necessary strength of the
key is essential and dependent on local policy.
Some specific key generation considerations are given in the body of
this document.
8. IANA Considerations
Assignment of meaning to the remaining ECC data flag bits or to
values of ECC fields outside the ranges for which meaning in defined
in this document requires an IETF consensus as defined in [RFC2434].
R. Schroeppel, et al [Page 13]
INTERNET-DRAFT ECC in the DNS
Copyright and Additional IPR Provisions
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Copyright (C) The IETF Trust (2007)
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
R. Schroeppel, et al [Page 14]
INTERNET-DRAFT ECC in the DNS
Informational References
[RFC1034] - P. Mockapetris, "Domain names - concepts and facilities",
11/01/1987.
[RFC1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August
1999.
[RFC4025] - M. Richardson, "A Method for Storing IPsec Keying
Material in DNS", February 2005.
[RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
2005.
[RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
4035, March 2005.
[RFC4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
[Menezes] - Alfred Menezes, "Elliptic Curve Public Key
Cryptosystems", 1993 Kluwer.
[Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves",
1986, Springer Graduate Texts in mathematics #106.
Normative Refrences
[RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", October 1998.
[RFC3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
1 (SHA1)", RFC 3174, September 2001.
[RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
R. Schroeppel, et al [Page 15]
INTERNET-DRAFT ECC in the DNS
Author's Addresses
Rich Schroeppel
500 S. Maple Drive
Woodland Hills, UT 84653 USA
Telephone: +1-505-844-9079(w)
Email: rschroe@sandia.gov
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in September 2007.
Its file name is draft-ietf-dnsext-ecc-key-10.txt.
Disclaimer
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
R. Schroeppel, et al [Page 16]

334
doc/draft/draft-ietf-dnsext-interop3597-02.txt
View File

@@ -1,334 +0,0 @@
DNS Extensions Working Group J. Schlyter
Internet-Draft May 19, 2005
Expires: November 20, 2005
RFC 3597 Interoperability Report
draft-ietf-dnsext-interop3597-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on November 20, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo documents the result from the RFC 3597 (Handling of Unknown
DNS Resource Record Types) interoperability testing.
Schlyter Expires November 20, 2005 [Page 1]
Internet-Draft RFC 3597 Interoperability Report May 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3
3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Authoritative Primary Name Server . . . . . . . . . . . . 3
3.2 Authoritative Secondary Name Server . . . . . . . . . . . 3
3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . 4
3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . 4
3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . 4
4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5
Intellectual Property and Copyright Statements . . . . . . . . 6
Schlyter Expires November 20, 2005 [Page 2]
Internet-Draft RFC 3597 Interoperability Report May 2005
1. Introduction
This memo documents the result from the RFC 3597 (Handling of Unknown
DNS Resource Record Types) interoperability testing. The test was
performed during June and July 2004 by request of the IETF DNS
Extensions Working Group.
2. Implementations
The following is a list, in alphabetic order, of implementations
tested for compliance with RFC 3597:
DNSJava 1.6.4
ISC BIND 8.4.5
ISC BIND 9.3.0
NSD 2.1.1
Net::DNS 0.47 patchlevel 1
Nominum ANS 2.2.1.0.d
These implementations covers the following functions (number of
implementations tested for each function in paranthesis):
Authoritative Name Servers (4)
Full Recursive Resolver (2)
Stub Resolver (4)
DNSSEC Zone Signers (2)
All listed implementations are genetically different.
3. Tests
The following tests was been performed to validate compliance with
RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression")
and 5 ("Text Representation").
3.1 Authoritative Primary Name Server
The test zone data (Appendix A) was loaded into the name server
implementation and the server was queried for the loaded information.
3.2 Authoritative Secondary Name Server
The test zone data (Appendix A) was transferred using AXFR from
another name server implementation and the server was queried for the
transferred information.
Schlyter Expires November 20, 2005 [Page 3]
Internet-Draft RFC 3597 Interoperability Report May 2005
3.3 Full Recursive Resolver
A recursive resolver was queried for resource records from a domain
with the test zone data (Appendix A).
3.4 Stub Resolver
A stub resolver was used to query resource records from a domain with
the test zone data (Appendix A).
3.5 DNSSEC Signer
A DNSSEC signer was used to sign a zone with test zone data
(Appendix A).
4. Problems found
Two implementations had problems with text presentation of zero
length RDATA.
One implementation had problems with text presentation of RR type
code and classes >= 4096.
Bug reports were filed for problems found.
5. Summary
Unknown type codes works in the tested authoritative servers,
recursive resolvers and stub clients.
No changes are needed to advance RFC 3597 to draft standard.
6. Normative References
[1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
Types", RFC 3597, September 2003.
Author's Address
Jakob Schlyter
Email: jakob@rfc.se
Schlyter Expires November 20, 2005 [Page 4]
Internet-Draft RFC 3597 Interoperability Report May 2005
Appendix A. Test zone data
; A-record encoded as TYPE1
a TYPE1 \# 4 7f000001
a TYPE1 192.0.2.1
a A \# 4 7f000002
; draft-ietf-secsh-dns-05.txt
sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
; bogus test record (from RFC 3597)
type731 TYPE731 \# 6 abcd (
ef 01 23 45 )
; zero length RDATA (from RFC 3597)
type62347 TYPE62347 \# 0
Schlyter Expires November 20, 2005 [Page 5]
Internet-Draft RFC 3597 Interoperability Report May 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schlyter Expires November 20, 2005 [Page 6]

451
doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt
View File

@@ -1,451 +0,0 @@
INTERNET-DRAFT A. Gustafsson
Araneus Information Systems Oy
February 24, 2010
Intended status: Draft Standard
Obsoletes: RFC3597
Handling of Unknown DNS Resource Record (RR) Types
draft-ietf-dnsext-rfc3597-bis-02.txt
Abstract
Extending the Domain Name System (DNS) with new Resource Record (RR)
types should not requires changes to name server software. This
document specifies how new RR types are transparently handled by DNS
software.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Expires August 2010 Standards Track [Page 1]
draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
The DNS [RFC1034] is designed to be extensible to support new
services through the introduction of new resource record (RR) types.
Nevertheless, DNS implementations have historically required software
changes to support new RR types, not only at the authoritative DNS
server providing the new information and the client making use of it,
but also at all slave servers for the zone containing it, and in some
cases also at caching name servers and forwarders used by the client.
Because the deployment of new DNS software is slow and expensive,
this has been a significant impediment to supporting new services in
the DNS.
[RFC3597] defined DNS implementation behavior and procedures for
defining new RR types aimed at simplifying the deployment of new RR
types by allowing them to be treated transparently by existing
implementations. Thanks to the widespread adoption of that
specification, much of the DNS is now capable of handling new record
types without software changes. Another development that has
simplified the introduction of new DNS RR types is the adoption of a
simpler IANA allocation procedure for RR types [RFC5395].
This document is a self-contained revised specification supplanting
and obsoleting RFC 3597, with the aim of allowing the specification
to advance on the Standards Track.
2. Definitions
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].
An "RR of unknown type" is an RR whose RDATA format is not known to
the DNS implementation at hand, and whose type is not an assigned
QTYPE or Meta-TYPE as specified in [RFC5395] (section 3.1) nor within
the range reserved in that section for assignment only to QTYPEs and
Meta-TYPEs. Such an RR cannot be converted to a type-specific text
format, compressed, or otherwise handled in a type-specific way.
In the case of a type whose RDATA format is known to be class
specific, an RR is considered to be of unknown type when the RDATA
format for that combination of type and class is not known.
3. Transparency
Expires August 2010 Standards Track [Page 2]
draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
To enable new RR types to be deployed without server changes, name
servers and resolvers MUST handle RRs of unknown type transparently.
The RDATA section of RRs of unknown type must be treated as
unstructured binary data, and must be stored and transmitted without
change ([RFC1123], section 6.1.3.5).
To ensure the correct operation of equality comparison (section 6)
and of the DNSSEC canonical form (section 7) when an RR type is known
to some but not all of the servers involved, servers MUST also
exactly preserve the RDATA of RRs of known type, except for changes
due to compression or decompression where allowed by section 4 of
this document. In particular, the character case of domain names
that are not subject to compression MUST be preserved.
4. Domain Name Compression
RRs containing compression pointers in the RDATA part cannot be
treated transparently, as the compression pointers are only
meaningful within the context of a DNS message. Transparently
copying the RDATA into a new DNS message would cause the compression
pointers to point at the corresponding location in the new message,
which now contains unrelated data. This would cause the compressed
name to be corrupted.
To avoid such corruption, servers MUST NOT compress domain names
embedded in the RDATA of types that are class-specific or not well-
known. This requirement was stated in [RFC1123] without defining the
term "well-known"; it is hereby specified that only the RR types
defined in [RFC1035] are to be considered "well-known".
Receiving servers MUST decompress domain names in RRs of well-known
type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
NXT, SRV, and NAPTR to ensure interoperability with implementations
predating [RFC3597].
Specifications for new RR types that contain domain names within
their RDATA MUST NOT allow the use of name compression for those
names, and SHOULD explicitly state that the embedded domain names
MUST NOT be compressed.
As noted in [RFC1123], the owner name of an RR is always eligible for
compression.
5. Text Representation
In the "type" field of a master file line, an unknown RR type is
represented by the word "TYPE" immediately followed by the decimal RR
type number, with no intervening whitespace. In the "class" field,
Expires August 2010 Standards Track [Page 3]
draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
an unknown class is similarly represented as the word "CLASS"
immediately followed by the decimal class number.
This convention allows types and classes to be distinguished from
each other and from TTL values, allowing the "[<TTL>] [<class>]
<type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
[RFC1035] section 5.1 to both be unambiguously parsed.
The RDATA section of an RR of unknown type is represented as a
sequence of items separated by any combination of tabs and spaces, as
follows:
- The special token \# (a backslash immediately followed by a hash
sign), which identifies the RDATA as having the generic encoding
defined herein rather than a traditional type-specific encoding.
- An unsigned decimal integer specifying the RDATA length in
octets.
- Zero or more items of hexadecimal data encoding the actual RDATA
field, each item containing an even number of hexadecimal digits.
If the RDATA is of zero length, the text representation contains only
the \# token and the single zero representing the length.
An implementation MAY also choose to represent some RRs of known type
using the above generic representations for the type, class and/or
RDATA, which carries the benefit of making the resulting master file
portable to servers where these types are unknown. Using the generic
representation for the RDATA of an RR of known type can also be
useful in the case of an RR type where the text format varies
depending on a version, protocol, or similar field (or several)
embedded in the RDATA when such a field has a value for which no text
format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
0.
Even though an RR of known type represented in the \# format is
effectively treated as an unknown type for the purpose of parsing the
RDATA text representation, all further processing by the server MUST
treat it as a known type and take into account any applicable type-
specific rules regarding compression, canonicalization, etc.
The following are examples of RRs represented in this manner,
illustrating various combinations of generic and type-specific
encodings for the different fields of the master file format:
a.example. CLASS32 TYPE731 \# 6 abcd (
ef 01 23 45 )
Expires August 2010 Standards Track [Page 4]
draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
b.example. HS TYPE62347 \# 0
e.example. IN A \# 4 C0000201
e.example. CLASS1 TYPE1 192.0.2.1
6. Equality Comparison
Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
to be compared for equality. Two RRs of the same unknown type are
considered equal when their RDATA is bitwise equal. To ensure that
the outcome of the comparison is identical whether the RR is known to
the server or not, specifications for new RR types MUST NOT specify
type-specific comparison rules.
This implies that embedded domain names, being included in the
overall bitwise comparison, are compared in a case-sensitive manner.
As a result, when a new RR type contains one or more embedded domain
names, it is possible to have multiple RRs owned by the same name
that differ only in the character case of the embedded domain
name(s). This is similar to the existing possibility of multiple TXT
records differing only in character case, and not expected to cause
any problems in practice.
7. DNSSEC Considerations
The rules for the DNSSEC canonical form and ordering were updated to
support transparent treatment of unknown types in [RFC3597]. Those
updates have subsequently been integrated into the base DNSSEC
specification, such that the DNSSEC canonical form and ordering are
now specified in [RFC4034] or its successors rather than in this
document.
8. Additional Section Processing
Unknown RR types cause no additional section processing. Future RR
type specifications MAY specify type-specific additional section
processing rules, but any such processing MUST be optional as it can
only be performed by servers for which the RR type in case is known.
9. IANA Considerations
This document does not require any IANA actions.
10. Security Considerations
This specification is not believed to cause any new security
problems, nor to solve any existing ones.
Expires August 2010 Standards Track [Page 5]
draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
11. Normative References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5395] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 5395, November 2008.
12. Informative References
[RFC1876] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
Means for Expressing Location Information in the Domain
Name System", RFC 1876, January 1996.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
14. Author's Address
Andreas Gustafsson
Araneus Information Systems Oy
PL 110
02321 Espoo
Finland
Phone: +358 40 547 2099
EMail: gson@araneus.fi
Appendix A. Summary of Changes Since RFC3597
This section summarizes the major changes between RFC3597 and this
Expires August 2010 Standards Track [Page 6]
draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
document. In addition to the changes listed below, there has also
been a number of editorial changes, such as updates to the text in
the Abstract and Introduction to better reflect the current state of
implementation, updates to boilerplate text, and minor
clarifications.
The reference to the DNS IANA Considerations BCP (BCP42) has been
changed from RFC2929 to the current version, RFC5395.
Downward references have been eliminated; specifically, the document
no longer refers to RFC2163 or RFC2535.
IP addresses in examples have been changed to use the 192.0.2.0/24
range per RFC3330.
The document no longer specifies changes to the DNSSEC canonical form
and ordering, as those changes have now been incorporated into the
base DNSSEC specification.
Appendix B. Detailed Change Log
[NOTE TO RFC EDITOR: PLEASE REMOVE THIS APPENDIX ON PUBLICATION.]
B.1. Changes between RFC3597 and -00
The reference to the DNS IANA Considerations BCP (BCP42) has been
changed from RFC2929 to the current version, RFC5395.
Downward references have been eliminated; specifically, the document
no longer refers to RFC2163 or RFC2535.
IP addresses in examples have been changed to use the 192.0.2.0/24
range per RFC3330.
The document no longer specifies changes to the DNSSEC canonical form
and ordering, as those changes have now been incorporated into the
base DNSSEC specification.
There has also been a number of editorial changes, such as updates to
the text in the Abstract and Introduction to better reflect the
current state of implementation.
B.2. Changes between -00 and -01
Moved the Abstract to immediately following the document title.
Updated boilerplate to the current version.
Expires August 2010 Standards Track [Page 7]
draft-ietf-dnsext-rfc3597-bis-02.txt February 2010
In the Introduction, the text "Another development that has
simplified the introduction of new DNS RR types is the adoption of a
simpler IANA allocation procedure for RR types" and a reference to
[RFC5395] were added.
In the Introduction, the text "with the aim of allowing the
specification to advance on the Standards Track" was added to explain
the motivation for the draft.
In section 2, the text "is class specific" was replaced by "is known
to be class specific".
In section 3, the words "That is" were removed so as not to imply
that the transparent treatment of RRs of unknown type is only a
matter of how the RDATA field is handled. The remainder of the
sentence was rephrased.
In section 4, the entries for SRV and NAPTR in the list of RR types
to decompress were swapped to make the list consistently ordered by
ascending numerical RR type.
References to RFC 1035 and RFC 1123 now include the specific section
numbers being referenced.
A Change History was added as Appendix A.
B.3. Changes between -01 and -02
In section 5, the term "white space" was replaced by "any combination
of tabs and spaces", and the term "word" was replaced by "item", for
consistency with RFC1035 terminology.
In section 5, hyphens were added to mark the beginning of each item
in the the list of items comprising the RDATA text representation.
The Change History was split into a Summary of Changes Since RFC3597
(Appendix A) intended to remain in the document when published as an
RFC, and a Detailed Change Log (Appendix B) to be deleted on
publication.
Expires August 2010 Standards Track [Page 8]

336
doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt
View File

@@ -1,336 +0,0 @@
DNSext Working Group F. Dupont
Internet-Draft ISC
Updates: 2845,2930,4635 May 8, 2009
(if approved)
Intended status: Standards Track
Expires: November 9, 2009
Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records
draft-ietf-dnsext-tsig-md5-deprecated-03.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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.
This Internet-Draft will expire on November 9, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Dupont Expires November 9, 2009 [Page 1]
Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The main purpose of this document is to deprecate the use of HMAC-MD5
as an algorithm for the TSIG (secret key transaction authentication)
resource record in the DNS (domain name system), and the use of MD5
in TKEY (secret key establishment for DNS).
1. Introduction
The secret key transaction authentication for DNS (TSIG, [RFC2845])
was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm.
When the MD5 [RFC1321] security came to be considered lower than
expected, [RFC4635] standardized new TSIG algorithms based on SHA
[RFC3174][RFC3874][RFC4634] digests.
But [RFC4635] did not deprecate the HMAC-MD5 algorithm. This
document is targeted to complete the process, in detail:
1. Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm
name registry managed by the IANA under the IETF Review Policy
[RFC5226]
2. Make HMAC-MD5.SIG-ALG.REG.INT support "not Mandatory" for
implementations
3. Provide a keying material derivation for the secret key
establishment for DNS (TKEY, [RFC2930]) using a Diffie-Hellman
exchange with SHA256 [RFC4634] in place of MD5 [RFC1321]
4. Finally recommend the use of HMAC-SHA256.
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. Implementation Requirements
The table of section 3 of [RFC4635] is replaced by:
Dupont Expires November 9, 2009 [Page 2]
Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
+-------------------+--------------------------+
| Requirement Level | Algorithm Name |
+-------------------+--------------------------+
| Optional | HMAC-MD5.SIG-ALG.REG.INT |
| Optional | gss-tsig |
| Mandatory | hmac-sha1 |
| Optional | hmac-sha224 |
| Mandatory | hmac-sha256 |
| Optional | hmac-sha384 |
| Optional | hmac-sha512 |
+-------------------+--------------------------+
Implementations that support TSIG MUST also implement HMAC-SHA1 and
HMAC-SHA256 (i.e., algorithms at the "Mandatory" requirement level)
and MAY implement GSS-TSIG and the other algorithms listed above
(i.e., algorithms at a "not Mandatory" requirement level).
3. TKEY keying material derivation
When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying
material is derived from the shared secret and TKEY resource record
data using MD5 [RFC1321] at the end of section 4.1 page 9.
This is amended into:
keying material =
XOR ( DH value, SHA256 ( query data | DH value ) |
SHA256 ( server data | DH value ) )
using the same conventions.
4. IANA Consideration
This document extends the "TSIG Algorithm Names - per [] and
[RFC2845]" located at
http://www.iana.org/assignments/tsig-algorithm-names by adding a new
column to the registry "Compliance Requirement".
The registry should contain the following:
Dupont Expires November 9, 2009 [Page 3]
Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
+--------------------------+------------------------+-------------+
| Algorithm Name | Compliance Requirement | Reference |
+--------------------------+------------------------+-------------+
| gss-tsig | Optional | [RFC3645] |
| HMAC-MD5.SIG-ALG.REG.INT | Optional | [][RFC2845] |
| hmac-sha1 | Mandatory | [RFC4635] |
| hmac-sha224 | Optional | [RFC4635] |
| hmac-sha256 | Mandatory | [RFC4635] |
| hmac-sha384 | Optional | [RFC4635] |
| hmac-sha512 | Optional | [RFC4635] |
+--------------------------+------------------------+-------------+
where [] is this document.
5. Availability Considerations
MD5 is no longer universally available and its use may lead to
increasing operation issues. SHA1 is likely to suffer from the same
kind of problem. In summary MD5 has reached end-of-life and SHA1
will likely follow in the near term.
According to [RFC4635], implementations which support TSIG are
REQUIRED to implement HMAC-SHA256.
6. Security Considerations
This document does not assume anything about the cryptographic
security of different hash algorithms. Its purpose is a better
availability of some security mechanisms in a predictable time frame.
Requirement levels are adjusted for TSIG and related specifications
(i.e., TKEY):
The support of HMAC-MD5 is changed from mandatory to optional.
The use of MD5 and HMAC-MD5 is NOT RECOMMENDED.
The use of HMAC-SHA256 is RECOMMENDED.
7. Acknowledgments
Olafur Gudmundsson kindly helped in the procedure to deprecate the
MD5 use in TSIG, i.e., the procedure which led to this memo. Alfred
Hoenes, Peter Koch, Paul Hoffman and Edward Lewis proposed some
improvements.
8. References
Dupont Expires November 9, 2009 [Page 4]
Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC4635] Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers",
RFC 4635, August 2006.
8.2. Informative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
and R. Hall, "Generic Security Service Algorithm for
Secret Key Transaction Authentication for DNS (GSS-TSIG)",
RFC 3645, October 2003.
[RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224",
RFC 3874, September 2004.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, BCP 26,
May 2008.
Dupont Expires November 9, 2009 [Page 5]
Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
Author's Address
Francis Dupont
ISC
Email: Francis.Dupont@fdupont.fr
Dupont Expires November 9, 2009 [Page 6]

1848
doc/draft/draft-ietf-dnsop-dnssec-key-timing-03.txt
View File

File diff suppressed because it is too large Load Diff

616
doc/draft/draft-ietf-dnsop-dnssec-trust-history-02.txt
View File

@@ -1,616 +0,0 @@
Domain Name System Operations W. Wijngaards
Internet-Draft O. Kolkman
Intended status: Standards Track NLnet Labs
Expires: December 31, 2010 June 29, 2010
DNSSEC Trust Anchor History Service
draft-ietf-dnsop-dnssec-trust-history-02
Abstract
When DNS validators have trusted keys, but have been offline for a
longer period, key rollover will fail and they are stuck with stale
trust anchors. History service allows validators to query for older
DNSKEY RRsets and pick up the rollover trail where they left off.
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 31, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Wijngaards & Kolkman Expires December 31, 2010 [Page 1]
Internet-Draft Trust History Service June 2010
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
This memo defines a trust history service for DNS validators -- the
component in a resolver that performs DNSSEC [RFC4034] validation,
validator for short.
A validator that has been offline or missed an (emergency) rollover
can use this service to reconfigure themselves with the current
trust-anchor. Using a newly defined resource record (RR) that links
old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY
RRsets and checks they form a chain to the latest key (see
Section 3). The lists of old DNSKEYS, linked with the TALINK RRs, do
not necessarily need to be published in the zone for which the DNSKEY
history is being maintained but can be published in any DNS domain.
We will call the entity that offers the trust history the History
Provider. The choice of the History Provider is made by the
maintainer of the validator, possibly based on a hint provided, using
the TALINK, by the zone owner.
Section 2 provides background on the mechanism and usage. It looks
at the viewpoints of publishers and consumers of trust anchors, the
use of keys with revocation flags, and SEP flags.
The algorithm that the validator uses to construct a history and
reconfigure a new key is detailed in Section 4, it uses the TALINK RR
type defined in Section 3. The algorithms for how providers of trust
history can fetch the DNSKEY data as published by the zone they track
and publish that are explained in Section 5.
2. Motivation and Description
Validators provide a service in DNSSEC that can be seen from two
ways. Seen from the publisher's point of view, they provide
assurance that the data as received is as it was when it left the
publisher's hands. In this way of looking at things, validators
provide a publication integrity service. The publisher can be
confident that nobody can alter the published data (if it is
validated), because any alteration will be detected. So it protects
a publisher from being seen to send someone to the wrong place.
From the consumer's point of view, validators provide a reason to
trust the data from the network. In this view, the validator is
Wijngaards & Kolkman Expires December 31, 2010 [Page 2]
Internet-Draft Trust History Service June 2010
making a claim about whether the data ought to be accepted or not.
This is subtly different from the publisher's point of view, because
the question for the consumer is not whether the data is safe while
the consumer is not looking, but whether the data is safe for the
consumer at the moment of consumption. Validation protects a
consumer from going to the wrong place.
These two slightly different ways of looking at the situation result
in slightly different operational goals. Whereas publishers want to
make assertions about their data, by controlling the roll over of
keys, consumers want to get the best assurance that they can get that
the data they are consuming is correct.
If a validator has been offline during a key rollover event for one
of its trust anchors, then the validator will be unable to validate
answers that need that trust anchor. For the publisher, this state
of affairs is acceptable: the publisher is confident that no
validator ever consumes the wrong data. For the consumer, however,
this state of affairs represents an outage.
Since publishers of trust anchors already use a chained series of
keys to perform rollovers under some circumstances (see [RFC5011]),
it is possible to use the history of that chain to allow a validator
to resume service for the consumer without needing to use an out-of-
band mechanism to obtain a new trust anchor. This improves the
experience for consumers of validated data, and increases the chances
that DNSSEC is useful for consumers of DNS data.
The mechanism to do this is a double-linked list that recounts a
portion of the history of DNSKEY Resource Records. The list is used
by a validator to catch up with the changes that the validator
somehow missed. This approach may be thought of as replaying the
[RFC5011] rollover history, only at a later time.
2.1. Considerations for Using a Revoked Key
The keys that the publisher rolled are marked REVOKED by the RFC5011
protocol. At this point the publisher considers the keys revoked,
but the validators have not yet seen this or marked the keys as
revoked. In the RFC5011 protocol, the validators probe regularly and
can then see if keys are revoked. If unable to probe, they will be
unable to see if keys are revoked. Hence when using a history to
recount rollovers, the consumer's validator has also missed a number
of revocations. The goal is to pick up the right keys and also the
new revocations along the way.
Although the keys have been marked by the publisher as REVOKED a long
time ago, for the consumer these REVOKED keys are new information.
Wijngaards & Kolkman Expires December 31, 2010 [Page 3]
Internet-Draft Trust History Service June 2010
Their storage in the history list makes it possible for consumers to
pick up key revocations if they missed the revocation announcement
because they could not probe.
This is the allowed usage of REVOKED keys. The publisher is
announcing their presence. And the validators mark them as REVOKED
after verification. The initial part of this verification is the
reverse walk through the history list, which is to avoid exposing
which key is trusted. This means that older signatures with keys
that have in the meantime been revoked are used to construct and
verify the history list by the validator.
A consequence is that once a publisher marks keys as REVOKED, there
will still be consumers who are using such keys, because they have
not seen the revocation. From the publishers point of view they are
revoked and the revocation is filed in the historical key list. From
the consumers point of view, it has not seen a revocation yet, and a
historical key list lookup algorithm is a state change where a new
trusted key is obtained while the old key is observed to be revoked.
2.2. Motivation for Requiring the SEP Bit
The SEP bit is used to differentiate Key Signing Keys from other
keys. It is defined in [RFC3757], it is used to designate trust
anchors in [RFC5011]. The protocol herein specified requires that
DNSKEYs that are subject to use for the trust history service have
the SEP bit set. The reason for this is to keep the set of keys that
need to be stored in history small.
3. The TALINK Resource Record
The DNS Resource Record type TALINK (decimal 58) ties the elements of
a linked list of DNSKEY RRs together.
The rdata consists of two domain names. The first name is the start,
or previous name, and the other name the end or next name in the
list. The empty label '.' is used at the endpoints of the list.
The presentation format is the two domain names. The wire encoding
is the two domain names, with no compression so the type can be
treated according to [RFC3597]. The list is a double linked list,
because this empowers low memory hosts to perform consistency checks.
The TALINK used at the zone apex holds the endpoints of the list.
The TALINKs that form the lists hold previous and next entries.
These TALINKs are distinguished by their usage (entrypoint or list
connection). The double linked list is not circular, because lookups
must stop when they reach the oldest entry.
Wijngaards & Kolkman Expires December 31, 2010 [Page 4]
Internet-Draft Trust History Service June 2010
4. Trust History Lookup
This is the algorithm that a validator uses to detect and resolve the
situation in which a trust-anchor is out of sync with the DNSKEYs
published by a zone owner. The algorithm uses the TALINK RR type
which is used to link various old DNSKEYs as published by the History
Provider, to arrive from the outdated configured Trust Anchor to one
that matches the current DNSKEY. The TALINK RR type is defined in
Section 3.
When the algorithm below results in failure the trust history cannot
be built and a new trust anchor will need to be re-configured using
another mechanism.
Step 1: The validator performs a DNSKEY lookup to the target zone,
which looks like any other initial DNSKEY lookup that the
validator needs to match a trust anchor to the currently used
DNSKEY RR set. If the keyset verifies with the trust anchor
currently held, the trust-anchor is not out of sync. Otherwise,
store the DNSKEY RR set as result. The algorithm will
successfully build a linked list to this DNSKEY RR, or delete the
trust point, or fail.
All nameservers (the ones authoritative for the zone or the
upstream resolver caches when the validator is not full resolver)
SHOULD be checked to make sure the DNSKEY RR sets are the same.
The results can differ if a key-rollover is in progress and not
all nameservers are in sync yet. This case can be detected by
checking that the older keyset signs the newer and take the newer
as result keyset. If both of the keysets sign each other, the
result keyset has the newest rrsig that validates it using the
other keyset. Use the the average over the middle of the
inception and expiration dates of the signatures that are
validated (and for serial arithmetic assume all dates on these
signatures lie within 2^(SERIAL_BITS-1) distance). If the keysets
do not sign each other then this is not a secure change in the
keyset and the history lookup fails.
Step 2: Fetch the trust history list end points. Perform a query of
QTYPE TALINK and QNAME the domain name that is configured to be
the History Provider for the particular domain you are trying to
update the trust-anchor for.
Step 3: Go backwards through the trust history list as provided by
the TALINK linked list. Verify that the keyset validly signs the
next keyset. This is [RFC4034] validation, but the RRSIG
expiration date is ignored. Replace the owner domain name with
the target zone name for verification. One of the keys that signs
Wijngaards & Kolkman Expires December 31, 2010 [Page 5]
Internet-Draft Trust History Service June 2010
the next keyset MUST have the SEP bit set. The middle of
inception and expiration date from the valid signature MUST be
older than that of the signature that validates the next keys in
the list. Take the average if multiple signatures validate (and
for serial arithmetic assume all dates on these signatures lie
within 2^(SERIAL_BITS-1) distance). Query type TALINK to get
previous and next locations.
If all SEP keys have the REVOKE flag set at this step, and the
keyset is signed by all SEP keys, then continue but store that the
end result is that the trust point is deleted, see Section 5
[RFC5011].
If all SEP keys are of an unknown algorithm at this step, continue
and at the next step, when you verify if the keyset signs validly:
if false, continue with result a failure, if true, continue with
the end result that the trust point is deleted. Thus, the keysets
with unknown algorithms are stepped over with an end result of
failure because the validator cannot determine if unknown
algorithm signatures are valid, until the oldest keyset with
unknown algorithms is signed by a known algorithm and the result
is set to deletion and step 3 continues to a known key.
Step 4: When the trust anchor currently held by the validator
verifies the keyset, the algorithm is done. The validator SHOULD
store the result on stable storage. Use the new trust anchor for
validation (if using [RFC5011], put it in state VALID).
5. Trust History Tracker
External trackers can poll the target zone DNSKEY RRset regularly.
Ignore date changes in the RRSIG. Ignore changes to keys with no SEP
flag. Copy the newly polled DNSKEY RRset and RRSIGs, change the
owner name to a new name at the history location. Publish the new
RRset and TALINK records to make it the last element in the list.
Update the TALINK that advertises the first and last name.
Integrated into the rollover, the keys are stored in the history and
the TALINK is updated when a new key is used in the rollover process.
This gives the TALINK and new historical key time to propagate.
The signer can support trust history. Trust history key sets need
only contain SEP keys. To use older signers, move historical RRSIGs
to another file. Sign the zone, including the TALINK and DNSKEY
records. Append the historical RRSIGs to the result. Signing the
zone like this obviates the need for changes to signer and server
software.
Wijngaards & Kolkman Expires December 31, 2010 [Page 6]
Internet-Draft Trust History Service June 2010
6. Example
In this example the trust history for the 'example.net' zone is
published in the 'example.com' namespace. The DNSKEY rdata and RRSIG
rdata is omitted for brevity, it is a copy and paste of the data from
example.net.
$ORIGIN example.com.
example.com. TALINK h0.example.com. h2.example.com.
h0 TALINK . h1.example.com.
h0 DNSKEY ...
h0 RRSIG ...
h1 TALINK h0.example.com. h2.example.com.
h1 DNSKEY ...
h1 RRSIG ...
h2 TALINK h1.example.com. .
h2 DNSKEY ...
h2 RRSIG ...
The example.net zone can advertise the example.com History Provider
by providing the TALINK shown here at example.com at the apex of the
example.net zone. The TALINK at example.com is then not needed.
7. Deployment
The trust history is advertised with TALINK RRs at the zone apex.
These represent alternative history sources, that can be searched in
turn. The TALINK at the zone apex contains the first and last name
of the list of historical keys.
The historical list of keys grows perpetually. Since most validators
have recent keys, their processing time remains similar as the list
grows. If validators no longer have trust in the keys then they need
no longer be published. The oldest key entries can be omitted from
the list to shorten it.
The validator decides how long it trusts a key. A recommendation
from the zone owner can be configured for keys of that zone, or
recommendations per algorithm and key size can be used (e.g. see
[NIST800-57]). If a key is older than that, trust history lookup
fails with it and the trust point can be considered deleted. This
assumes the validator has decided on a security policy and also can
take actions when the update of the trust anchor fails. Without such
policy, or if the alternative is no DNSSEC, the approach below can be
used.
Wijngaards & Kolkman Expires December 31, 2010 [Page 7]
Internet-Draft Trust History Service June 2010
In general, the decision can be that any key - no matter how old or
how small - is better than no security. The validator then never
considers a key too old, and the lookup algorithm becomes an
unsecured update mechanism at the time where the key can be trivially
broken. The history provider SHOULD provide these broken keys to
facilitate clients performing the unsecured update. If a key can not
be trivially broken then it provides a non-trivial amount of security
that the history lookup algorithm uses to get the current keys.
Conceivably after the update the result is stored on stable storage
and the client is thereafter safe - it performs a leap of faith. The
validator operator can opt for this set up after considering the
trade-off between loss of DNSSEC, loss of connectivity, and the
argument that perceived security is worse than no security.
The history lookup can be used on its own. Then, the trust history
is used whenever the key rolls over and no polling is performed. The
results of trust history lookup SHOULD be stored on stable storage,
so that the trust history lookup does not need to be performed if the
last results are okay and for use as trusted anchor in the next
history lookup.
If a validator is also using [RFC5011] for the target zone, then the
trust history algorithm SHOULD only be invoked if the [RFC5011]
algorithm failed due to the inability to perform probes. This is the
case when the last [RFC5011] successful probe was more than 30 days
ago. If a new key has been announced, invoke the history if no 2
probes succeeded during the add hold-down time and there was no
successful probe after the add hold-down time passed. Therefore the
time of the last successful probe MUST be stored on stable storage.
For testing the potentially very infrequently used lookup, the
following SHOULD be implemented. For the test the lookup is
triggered manually by allowing the system to be given a particular
keyset with a last successful lookup date in the past and a test
History Provider. The test History Provider provides access to a
generated back-dated test history.
8. Security Considerations
The History Provider only provides copies of old data. If that
historic data is altered or withheld the lookup algorithm fails
because of validation errors in Step 3 of the algorithm. If the
History provider or a Man in the Middle Adversary (MIMA) has access
to the original private keys (through theft, cryptanalisis, or
otherwise), history can be altered without failure of the algorithm.
Below we only consider MIMAs and assume the History Provider is a
trusted party.
Wijngaards & Kolkman Expires December 31, 2010 [Page 8]
Internet-Draft Trust History Service June 2010
Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of
TALINK and DNSKEY data, can present some alternate history. However
the DNSKEY RR set trusted that the history should arrive at is
already fixed by step 1. If an attempt is made to subvert the
algorithm at step 2 or 3, then the result keyset can not be replaced
by another keyset unnoticed.
To change the keyset trusted as the outcome, the step 1 data has to
be spoofed and the key held by the validator (or a newer historic
key) has to be compromised. Unless such spoof is targeted to a
specific victim, a spoof of the step 1 result has a high visibility.
Since most of the validators that receive the spoof have an up-to-
date trust anchor most validators that would receive this spoof
return validation failure for data from the zone that contains the
DNSKEYs. An adversary will therefore have to target the attack to
validators that are in the process of an update. Since validators do
not announce that they use trust history lookup until step 2
adversaries will not be able to select the validators.
A spoof of data in steps 2 and 3, together with a compromised (old)
key, can result in a downgrade. At steps 2 and 3 a faked trust point
deletion or algorithm rollover can be inserted in a fake history.
This avoids the high visibility of spoofing the current key (see
previous paragraph) and downgrades to insecure.
Finally there is the case that one of the keys published by the
History Providers has been compromised. Since someone spoofing at
step 1 of the lookup algorithm and presenting some fake history to a
compromised key, of course does not include key revocations and does
extend the history to contain the compromised key, it therefore is
not really useful for a History Provider to remove the key from the
published history. That only makes lookups fail for those validators
who are not under attack. Useful action could be to update
validators using some other means.
Rollover with [RFC5011] revokes keys after use. If a History
Provider is used, then such revoked keys SHOULD be used to perform
history tracking and history lookup. The trust anchor keys that the
validator has in its own storage and final current keys that it
stores MUST NOT be trusted if they are revoked.
If the validator operator chooses to operate trust history without
also using [RFC5011] the trust anchor does not get hold-down timer
protection. This has associated risks, in that the immediate
rollover without timeout that it provides could be abused (if private
keys are compromised). Such abuse could result in the stored lookup
results to become compromised. The key changes can be logged, to
inform operators and keep an audit trail.
Wijngaards & Kolkman Expires December 31, 2010 [Page 9]
Internet-Draft Trust History Service June 2010
The SEP bit is checked to make sure that control over the KSK is
necessary to change the keyset for the target zone.
The algorithm can be used to get the inception and expiration times
of signatures on the current keyset, a clock. A MIMA can attempt to
shorten history and put back that clock, but the algorithm attempts
to make this difficult to target and highly visible to others.
If the clock of the validator can be influenced, then setting it
forward is unlikely to give advantage, but setting it backward
enables a replay attack of old DNSSEC data and signatures. This
vulnerability exists also in plain DNSSEC.
9. IANA Considerations
Resource record type TALINK has been defined using RFC5395 expert
review, it has RR type number 58 (decimal).
10. Acknowledgments
Thanks to the people who provided review and suggestions, Peter Koch,
Andrew Sullivan, Joe Abley, George Barwood, Edward Lewis, Michael
StJohns, Bert Hubert, Mark Andrews, Ted Lemon, Steve Crocker, Bill
Manning, Eric Osterweil, Wolfgang Nagele, Alfred Hoenes, Olafur
Gudmundsson, Roy Arends and Matthijs Mekking.
11. References
11.1. Informative References
[NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M.
Smid, "Recommendations for Key Management", NIST
SP 800-57, March 2007.
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
System KEY (DNSKEY) Resource Record (RR) Secure Entry
Point (SEP) Flag", RFC 3757, April 2004.
[RFC5011] StJohns, M., "Automated Updates of DNS Security
(DNSSEC) Trust Anchors", RFC 5011, September 2007.
11.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
Record (RR) Types", RFC 3597, September 2003.
Wijngaards & Kolkman Expires December 31, 2010 [Page 10]
Internet-Draft Trust History Service June 2010
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security
Extensions", RFC 4034, March 2005.
Authors' Addresses
Wouter Wijngaards
NLnet Labs
Science Park 140
Amsterdam 1098 XG
The Netherlands
EMail: wouter@nlnetlabs.nl
Olaf Kolkman
NLnet Labs
Science Park 140
Amsterdam 1098 XG
The Netherlands
EMail: olaf@nlnetlabs.nl
Wijngaards & Kolkman Expires December 31, 2010 [Page 11]

396
doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
View File

@@ -1,396 +0,0 @@
INTERNET-DRAFT D. Senie
Category: BCP Amaranth Networks Inc.
Expires in six months July 2005
Encouraging the use of DNS IN-ADDR Mapping
draft-ietf-dnsop-inaddr-required-07.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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
Mapping of addresses to names has been a feature of DNS. Many sites,
implement it, many others don't. Some applications attempt to use it
as a part of a security strategy. The goal of this document is to
encourage proper deployment of address to name mappings, and provide
guidance for their use.
Copyright Notice
Copyright (C) The Internet Society. (2005)
1. Introduction
The Domain Name Service has provision for providing mapping of IP
addresses to host names. It is common practice to ensure both name to
address, and address to name mappings are provided for networks. This
practice, while documented, has never been required, though it is
generally encouraged. This document both encourages the presence of
Senie [Page 1]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
these mappings and discourages reliance on such mappings for security
checks.
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 [RFC2119].
2. Discussion
From the early days of the Domain Name Service [RFC883] a special
domain has been set aside for resolving mappings of IP addresses to
domain names. This was refined in [RFC1035], describing the .IN-
ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA
was added [RFC3152]. This document uses IPv4 CIDR block sizes and
allocation strategy where there are differences and uses IPv4
terminology. Aside from these differences, this document can and
should be applied to both address spaces.
The assignment of blocks of IP address space was delegated to three
regional registries. Guidelines for the registries are specified in
[RFC2050], which requires regional registries to maintain IN-ADDR
records on the large blocks of space issued to ISPs and others.
ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
allocations. For smaller allocations, ARIN can provide IN-ADDR for
/24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to
update IN-ADDR, however the present version of its policy document
for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
copies of this document. As of this writing, it appears APNIC has no
actual policy on IN-ADDR. RIPE appears to have the strongest policy
in this area [RIPE302] indicating Local Internet Registries should
provide IN-ADDR services, and delegate those as appropriate when
address blocks are delegated.
As we can see, the regional registries have their own policies for
recommendations and/or requirements for IN-ADDR maintenance. It
should be noted, however, that many address blocks were allocated
before the creation of the regional registries, and thus it is
unclear whether any of the policies of the registries are binding on
those who hold blocks from that era.
Registries allocate address blocks on CIDR [RFC1519] boundaries.
Unfortunately the IN-ADDR zones are based on classful allocations.
Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
exist, but are not always implemented.
3. Examples of impact of missing IN-ADDR
Senie [Page 2]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
These are some examples of problems that may be introduced by
reliance on IN-ADDR.
Some applications use DNS lookups for security checks. To ensure
validity of claimed names, some applications will look up IN-ADDR
records to get names, and then look up the resultant name to see if
it maps back to the address originally known. Failure to resolve
matching names is seen as a potential security concern.
Some FTP sites will flat-out reject users, even for anonymous FTP, if
the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
itself resolved, does not match. Some Telnet servers also implement
this check.
Web sites are in some cases using IN-ADDR checks to verify whether
the client is located within a certain geopolitical entity. This
approach has been employed for downloads of crypto software, for
example, where export of that software is prohibited to some locales.
Credit card anti-fraud systems also use these methods for geographic
placement purposes.
The popular TCP Wrappers program found on most Unix and Linux systems
has options to enforce IN-ADDR checks and to reject any client that
does not resolve. This program also has a way to check to see that
the name given by a PTR record then resolves back to the same IP
address. This method provdes more comfort but no appreciable
additional security.
Some anti-spam (anti junk email) systems use IN-ADDR to verify the
presence of a PTR record, or validate the PTR value points back to
the same address.
Many web servers look up the IN-ADDR of visitors to be used in log
analysis. This adds to the server load, but in the case of IN-ADDR
unavailability, it can lead to delayed responses for users.
Traceroutes with descriptive IN-ADDR naming proves useful when
debugging problems spanning large areas. When this information is
missing, the traceroutes take longer, and it takes additional steps
to determine that network is the cause of problems.
Wider-scale implementation of IN-ADDR on dialup, wireless access and
other such client-oriented portions of the Internet would result in
lower latency for queries (due to lack of negative caching), and
lower name server load and DNS traffic.
4. Recommendations
Senie [Page 3]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
4.1 Delegation Recommendations
Regional Registries and any Local Registries to whom they delegate
should establish and convey a policy to those to whom they delegate
blocks that IN-ADDR mappings are recommended. Policies should
recommend those receiving delegations to provide IN-ADDR service
and/or delegate to downstream customers.
Network operators should define and implement policies and procedures
which delegate IN-ADDR to their clients who wish to run their own IN-
ADDR DNS services, and provide IN-ADDR services for those who do not
have the resources to do it themselves. Delegation mechanisms should
permit the downstream customer to implement and comply with IETF
recommendations application of IN-ADDR to CIDR [RFC2317].
All IP address space assigned and in use should be resolved by IN-
ADDR records. All PTR records must use canonical names.
All IP addresses in use within a block should have an IN-ADDR
mapping. Those addresses not in use, and those that are not valid for
use (zeros or ones broadcast addresses within a CIDR block) need not
have mappings.
It should be noted that due to CIDR, many addresses that appear to be
otherwise valid host addresses may actually be zeroes or ones
broadcast addresses. As such, attempting to audit a site's degree of
compliance may only be done with knowledge of the internal subnet
architecture of the site. It can be assumed, however, any host that
originates an IP packet necessarily will have a valid host address,
and must therefore have an IN-ADDR mapping.
4.2 Application Recommendations
Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
of IN-ADDR, sometimes in conjunction with a lookup of the name
resulting from the PTR record provides no real security, can lead to
erroneous results and generally just increases load on DNS servers.
Further, in cases where address block holders fail to properly
configure IN-ADDR, users of those blocks are penalized.
5. Security Considerations
This document has no negative impact on security. While it could be
argued that lack of PTR record capabilities provides a degree of
anonymity, this is really not valid. Trace routes, whois lookups and
other sources will still provide methods for discovering identity.
Senie [Page 4]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
By recommending applications avoid using IN-ADDR as a security
mechanism this document points out that this practice, despite its
use by many applications, is an ineffective form of security.
Applications should use better mechanisms of authentication.
6. IANA Considerations
There are no IANA considerations for this document.
7. References
7.1 Normative References
[RFC883] P.V. Mockapetris, "Domain names: Implementation
specification," RFC883, November 1983.
[RFC1035] P.V. Mockapetris, "Domain Names: Implementation
Specification," RFC 1035, November 1987.
[RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
an Address Assignment and Aggregation Strategy," RFC 1519, September
1993.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, BCP 9, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
Guidelines", RFC2050, BCP 12, Novebmer 1996.
[RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
RFC 2317, March 1998.
[RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
2001.
7.2 Informative References
[ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
unknown, http://www.arin.net/regserv/initial-isp.html
[APNIC] "Policies For IPv4 Address Space Management in the Asia
Pacific Region," APNIC-086, 13 January 2003.
[RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
Senie [Page 5]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
2004. http://www.ripe.net//ripe/docs/rev-del.html
8. Acknowledgements
Thanks to Peter Koch and Gary Miller for their input, and to many
people who encouraged me to write this document.
9. Author's Address
Daniel Senie
Amaranth Networks Inc.
324 Still River Road
Bolton, MA 01740
Phone: (978) 779-5100
EMail: dts@senie.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Senie [Page 6]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Senie [Page 7]

784
doc/draft/draft-ietf-dnsop-respsize-14.txt
View File

@@ -1,784 +0,0 @@
Internet Engineering Task Force P. Vixie
Internet-Draft Internet Systems Consortium
Intended status: Informational A. Kato
Expires: November 11, 2012 Keio University/WIDE Project
May 10, 2012
DNS Referral Response Size Issues
draft-ietf-dnsop-respsize-14
Abstract
With a mandated default minimum maximum UDP message size of 512
octets, the DNS protocol presents some special problems for zones
wishing to expose a moderate or high number of authority servers (NS
RRs). This document explains the operational issues caused by, or
related to this response size limit, and suggests ways to optimize
the use of this limited space. Guidance is offered to DNS server
implementors and to DNS zone operators.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 11, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Vixie & Kato Expires November 11, 2012 [Page 1]
Internet-Draft DNS Referral Response Size May 2012
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
1. Introduction and Overview
The original DNS standard limited the UDP message size to 512 octets
(see Section 4.2.1 of [RFC1035]). Even though this limitation was
due to the required minimum IP reassembly limit for IPv4, it became a
hard DNS protocol limit and is not implicitly relaxed by changes in a
network layer protocol, for example to IPv6.
The EDNS (Extension Mechanisms for DNS) protocol extension starting
with version 0 permits larger responses by mutual agreement of the
requester and responder (see Section 4.3 and Section 6.2 of
[RFC2671bis]), and it is recommended to support EDNS. The 512 octets
UDP message size limit will remain in practical effect until
virtually all DNS servers and resolvers support EDNS.
Since DNS responses include a copy of the request, the space
available for response data is somewhat less than the full 512
octets. Negative responses are quite small, but for positive and
referral responses, every octet must be carefully and sparingly
allocated. While the response size of positive responses is also a
concern in [RFC3226], this document specifically addresses referral
response size.
While more than twelve years passed since the publication of the
original EDNS0 document [RFC2671], approximately 65% of the clients
support it as observed at a root name server and this fraction has
not changed in recent few years. The long tail of EDNS deployment
may eventually be measured in decades.
Even if EDNS deployment reached 100% of all DNS initiators and
responders there will still be cases when path MTU limitations or IP
Vixie & Kato Expires November 11, 2012 [Page 2]
Internet-Draft DNS Referral Response Size May 2012
fragmentation/reassembly problems in firewalls and other middleboxes
will cause EDNS failures which leads to non-extended DNS retries. A
smaller referral response will always be better than a larger one if
the same end result can be achieved either way. See [RFC5625],
[SSAC035], and Section 6.2.6 of [RFC2671bis] for details.
2. Delegation Details
2.1. Relevant Protocol Elements
A positive delegation response will include the following elements:
Header Section: fixed length (12 octets)
Question Section: original query (name, class, type)
Answer Section: empty, or a CNAME/DNAME chain
Authority Section: NS RRset (nameserver names)
Additional Section: A and AAAA RRsets (nameserver addresses)
Note: CNAME defines a canonical name ([RFC1034]) while DNAME maps an
entire subtree to another domain ([RFC2672]).
If the total size of the UDP response exceeds 512 octets or the size
advertised in EDNS, and if the data that does not fit was "required",
then the TC bit will be set (indicating truncation). This will
usually cause the requester to retry using TCP, depending on what
information was desired and what information was omitted. For
example, truncation in the authority section is of no interest to a
stub resolver who only plans to consume the answer section. If a
retry using TCP is needed, the total cost of the transaction is much
higher. See Section 6.1.3.2 of [RFC1123] for details on the
requirement that UDP be attempted before falling back to TCP.
RRsets (Resource Record Set, see [RFC2136]) are never sent partially
unless the TC bit is set to indicate truncation. When the TC bit is
set, the final apparent RRset in the final non-empty section must be
considered "possibly damaged" (see Section 6.2 of [RFC1035] and
Section 9 of [RFC2181]).
With or without truncation, the glue present in the additional data
section should be considered "possibly incomplete", and requesters
should be prepared to re-query for any damaged or missing RRsets.
Note that truncation of the additional data section might not be
signaled via the TC bit since additional data is often optional (see
discussion in Appendix B of [RFC4472]).
DNS label compression allows the component labels of a domain name to
be instantiated exactly once per DNS message, and then referenced
with a two-octet "pointer" from other locations in that same DNS
Vixie & Kato Expires November 11, 2012 [Page 3]
Internet-Draft DNS Referral Response Size May 2012
message (see Section 4.1.4 of [RFC1035]). If all nameserver names in
a message share a common parent (for example, all of them are in
"ROOT-SERVERS.NET." zone), then more space will be available for
incompressible data (such as nameserver addresses).
The query name can be as long as 255 octets of network data. In this
worst case scenario, the question section will be 259 octets in size,
which would leave only 240 octets for the authority and additional
sections (after deducting 12 octets for the fixed length header) in a
referral.
2.2. Advice to Zone Owners
Average and maximum question section sizes can be predicted by the
zone owner, since they will know what names actually exist and can
measure which ones are queried for most often. Note that if the zone
contains any wildcards, it is possible for maximum length queries to
require positive responses, but that it is reasonable to expect
truncation and TCP retry in that case. For cost and performance
reasons, the majority of requests should be satisfied without
truncation or TCP retry.
Some queries to non-existing names can be large, but this is not a
problem because negative responses need not contain any answer,
authority or additional records. See Section 2.1 of [RFC2308] for
more information about the format of negative responses.
The minimum useful number of name servers is two, for redundancy (see
Section 4.1 of [RFC1034]). A zone's name servers should be reachable
by all IP protocols versions (e.g., IPv4 and IPv6) in common use. As
long as the servers are well managed, the server serving IPv6 might
be different from the server serving IPv4 sharing the same server
name.
The best case is no truncation at all. This is because many
requesters will retry using TCP immediately, or will automatically
requery for RRsets that are possibly truncated, without considering
whether the omitted data was actually necessary.
Anycasting [RFC3258] is a useful tool for performance and reliability
without increasing the size of referral responses.
While it is irrelevant to the response size issue, all zones have to
be served via IPv4 as well to avoid name space fragmentation
[RFC3901].
Vixie & Kato Expires November 11, 2012 [Page 4]
Internet-Draft DNS Referral Response Size May 2012
2.3. Advice to Server Implementors
Each NS RR for a zone will add 12 fixed octets (name, type, class,
ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
Each A RR will require 16 octets, and each AAAA RR will require 28
octets.
While DNS distinguishes between necessary and optional resource
records, this distinction is according to protocol elements necessary
to signify facts, and takes no official notice of protocol content
necessary to ensure correct operation. For example, a nameserver
name that is in or below the zone cut being described by a delegation
is "necessary content", since there is no way to reach that zone
unless the parent zone's delegation includes "glue records"
describing that name server's addresses.
Recall that the TC bit is only set when a required RRset can not be
included in its entirety (see Section 9 of [RFC2181]). Even when
some of the RRsets to be included in the additional section don't fit
in the response size, the TC bit isn't set. These RRsets may be
important for a referral. Some DNS implementations try to resolve
these missing glue records separately which will introduce extra
queries and extra time to resolve a given name.
A delegation response should prioritize glue records as follows.
first:
All glue RRsets for one name server whose name is in or below the
zone being delegated, or which has multiple address RRsets
(currently A and AAAA), or preferably both;
second:
Alternate between adding all glue RRsets for any name servers
whose names are in or below the zone being delegated, and all
glue RRsets for any name servers who have multiple address RRsets
(currently A and AAAA);
thence:
All other glue RRsets, in any order.
Whenever there are multiple candidates for a position in this
priority scheme, one should be chosen on a round-robin or fully
random basis. The goal of this priority scheme is to offer
"necessary" glue first to fill into the response if possible.
If any "necessary" content cannot be fit in the response, then it is
advisable that the TC bit be set in order to force a TCP retry,
rather than have the zone be unreachable. Note that a parent
server's proper response to a query for in-child glue or below-child
glue is a referral rather than an answer, and that this referral must
Vixie & Kato Expires November 11, 2012 [Page 5]
Internet-Draft DNS Referral Response Size May 2012
be able to contain the in-child or below-child glue, and that in
outlying cases, only EDNS or TCP will be large enough to contain that
data.
The glue record order should be independent of the version of IP used
in the query because the DNS server might just see a query from an
intermediate server rather than the query from the original client.
3. Analysis
An instrumented protocol trace of a best case delegation response is
shown in Figure 1. Note that 13 servers are named, and 13 addresses
are given. This query was artificially designed to exactly reach the
512 octets limit.
Vixie & Kato Expires November 11, 2012 [Page 6]
Internet-Draft DNS Referral Response Size May 2012
;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
;; QUERY SECTION:
;; [23456789.123456789.123456789.\
123456789.123456789.123456789.com A IN] ;; @80
;; AUTHORITY SECTION:
com. 172800 NS E.GTLD-SERVERS.NET. ;; @112
com. 172800 NS F.GTLD-SERVERS.NET. ;; @128
com. 172800 NS G.GTLD-SERVERS.NET. ;; @144
com. 172800 NS H.GTLD-SERVERS.NET. ;; @160
com. 172800 NS I.GTLD-SERVERS.NET. ;; @176
com. 172800 NS J.GTLD-SERVERS.NET. ;; @192
com. 172800 NS K.GTLD-SERVERS.NET. ;; @208
com. 172800 NS L.GTLD-SERVERS.NET. ;; @224
com. 172800 NS M.GTLD-SERVERS.NET. ;; @240
com. 172800 NS A.GTLD-SERVERS.NET. ;; @256
com. 172800 NS B.GTLD-SERVERS.NET. ;; @272
com. 172800 NS C.GTLD-SERVERS.NET. ;; @288
com. 172800 NS D.GTLD-SERVERS.NET. ;; @304
;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET. 172800 A 192.5.6.30 ;; @320
B.GTLD-SERVERS.NET. 172800 A 192.33.14.30 ;; @336
C.GTLD-SERVERS.NET. 172800 A 192.26.92.30 ;; @352
D.GTLD-SERVERS.NET. 172800 A 192.31.80.30 ;; @368
E.GTLD-SERVERS.NET. 172800 A 192.12.94.30 ;; @384
F.GTLD-SERVERS.NET. 172800 A 192.35.51.30 ;; @400
G.GTLD-SERVERS.NET. 172800 A 192.42.93.30 ;; @416
H.GTLD-SERVERS.NET. 172800 A 192.54.112.30 ;; @432
I.GTLD-SERVERS.NET. 172800 A 192.43.172.30 ;; @448
J.GTLD-SERVERS.NET. 172800 A 192.48.79.30 ;; @464
K.GTLD-SERVERS.NET. 172800 A 192.52.178.30 ;; @480
L.GTLD-SERVERS.NET. 172800 A 192.41.162.30 ;; @496
M.GTLD-SERVERS.NET. 172800 A 192.55.83.30 ;; @512
;; MSG SIZE sent: 80 rcvd: 512
Figure 1
For longer query names, the number of address records supplied will
be lower. Furthermore, it is only by using a common parent name
(which is "GTLD-SERVERS.NET." in this example) that all 13 addresses
are able to fit, due to the use of DNS compression pointers in the
last 12 occurrences of the parent domain name. The outputs from the
response simulator in Appendix A (written in perl [PERL]) shown in
Figure 2 and Figure 3 demonstrate these properties.
Vixie & Kato Expires November 11, 2012 [Page 7]
Internet-Draft DNS Referral Response Size May 2012
% perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
a.dns.br requires 10 bytes
b.dns.br requires 4 bytes
c.dns.br requires 4 bytes
d.dns.br requires 4 bytes
# of NS: 4
For maximum size query (255 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 3 (yellow)
preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
For average size query (64 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 4 (green)
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
Figure 2
% perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
ns-ext.isc.org requires 16 bytes
ns.psg.com requires 12 bytes
ns.ripe.net requires 13 bytes
ns.eu.int requires 11 bytes
# of NS: 4
For maximum size query (255 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 3 (yellow)
preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
For average size query (64 byte):
only A is considered: # of A is 4 (green)
A and AAAA are considered: # of A+AAAA is 4 (green)
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
Figure 3
Here we use the term "green" if all address records could fit, or
"yellow" if two or more could fit, or "orange" if only one could fit,
or "red" if no address record could fit. It's clear that without a
common parent for nameserver names, much space would be lost. For
these examples we use an average/common name size of 15 octets,
befitting our assumption of "GTLD-SERVERS.NET." as our common parent
name.
We're assuming a medium query name size of 64 since that is the
typical size seen in trace data at the time of this writing. If
Internationalized Domain Name (IDN) or any other technology that
results in larger query names be deployed significantly in advance of
Vixie & Kato Expires November 11, 2012 [Page 8]
Internet-Draft DNS Referral Response Size May 2012
EDNS, then new measurements and new estimates will have to be made.
4. Conclusions
The current practice of giving all nameserver names a common parent
(such as "GTLD-SERVERS.NET." or "ROOT-SERVERS.NET.") saves space in
DNS responses and allows for more nameservers to be enumerated than
would otherwise be possible, since the common parent domain name only
appears once in a DNS message and is referred to via "compression
pointers" thereafter.
If all nameserver names for a zone share a common parent, then it is
operationally advisable to make all servers for the zone thus served
also be authoritative for the zone of that common parent. For
example, the root name servers (?.ROOT-SERVERS.NET.) can answer
authoritatively for the ROOT-SERVERS.NET. zone. This is to ensure
that the zone's servers always have the zone's nameservers' glue
available when delegating, and will be able to respond with answers
rather than referrals if a requester who wants that glue comes back
asking for it. In this case the name server will likely be a
"stealth server" -- authoritative but unadvertised in the glue zone's
NS RRset. See Section 2 of [RFC1996] for more information about
stealth servers.
Thirteen (13) is the effective maximum number of nameserver names
usable with traditional (non-extended) DNS, assuming a common parent
domain name, and given that implicit referral response truncation is
undesirable in the average case.
More than one address record in a protocol family per server is
inadvisable since the necessary glue RRsets (A or AAAA) are
atomically indivisible, and will be larger than a single resource
record. Larger RRsets are more likely to lead to or encounter
truncation.
More than one address record across protocol families is less likely
to lead to or encounter truncation, partly because multiprotocol
clients, which are required to handle larger RRsets such as AAAA RRs,
are more likely to speak EDNS, which can use a larger UDP response
size limit, and partly because the resource records (A and AAAA) are
in different RRsets and are therefore divisible from each other.
Name server names that are at or below the zone they serve are more
sensitive to referral response truncation, and glue records for them
should be considered "more important" than other glue records, in the
assembly of referral responses.
Vixie & Kato Expires November 11, 2012 [Page 9]
Internet-Draft DNS Referral Response Size May 2012
5. Security Considerations
The recommendations contained in this document have no known security
implications.
6. IANA Considerations
This document does not call for changes or additions to any IANA
registry.
7. Acknowledgement
The authors thank Peter Koch, Rob Austein, Joe Abley, Mark Andrews,
Kenji Rikitake, Stephane Bortzmeyer, Olafur Gudmundsson, Alfred
Hoenes, Alexander Mayrhofer, and Ray Bellis for their valuable
comments and suggestions.
This work was supported by the US National Science Foundation
(research grant SCI-0427144) and DNS-OARC.
8. References
8.1. Normative 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.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
8.2. Informative References
[PERL] Wall, L., Christiansen, T., and J. Orwant, "Programming
Perl, 3rd ed.", ISBN 0-596-00027-8, July 2000.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
Vixie & Kato Expires November 11, 2012 [Page 10]
Internet-Draft DNS Referral Response Size May 2012
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2671bis]
Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS0)", draft-ietf-dnsext-rfc2671bis-edns0-08 ,
February 2012.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999.
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001.
[RFC3258] Hardie, T., "Distributing Authoritative Name Servers via
Shared Unicast Addresses", RFC 3258, April 2002.
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
Guidelines", BCP 91, RFC 3901, September 2004.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472,
April 2006.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, August 2009.
[SSAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
Broadband Routers and Firewalls", SSAC 035,
September 2008.
Appendix A. The response simulator program
#!/usr/bin/perl
#
# SYNOPSIS
# respsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
# if all queries are assumed to have a same zone suffix,
# such as "jp" in JP TLD servers, specify it in -z option
#
Vixie & Kato Expires November 11, 2012 [Page 11]
Internet-Draft DNS Referral Response Size May 2012
use strict;
use Getopt::Std;
my ($sz_msg) = (512);
my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
my (%namedb, $name, $nssect, %opts, $optz);
my $n_ns = 0;
getopt('z', %opts);
if (defined($opts{'z'})) {
server_name_len($opts{'z'}); # just register it
}
foreach $name (@ARGV) {
my $len;
$n_ns++;
$len = server_name_len($name);
print "$name requires $len bytes\n";
$nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl
+ $sz_rdlen + $len;
}
print "# of NS: $n_ns\n";
arsect(255, $nssect, $n_ns, "maximum");
arsect(64, $nssect, $n_ns, "average");
sub server_name_len {
my ($name) = @_;
my (@labels, $len, $n, $suffix);
$name =~ tr/A-Z/a-z/;
@labels = split(/\./, $name);
$len = length(join('.', @labels)) + 2;
for ($n = 0; $#labels >= 0; $n++, shift @labels) {
$suffix = join('.', @labels);
return length($name) - length($suffix) + $sz_ptr
if (defined($namedb{$suffix}));
$namedb{$suffix} = 1;
}
return $len;
}
sub arsect {
my ($sz_query, $nssect, $n_ns, $cond) = @_;
my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
$ansect = $sz_query + $sz_type + $sz_class;
$space = $sz_msg - $sz_header - $ansect - $nssect;
$n_a = atmost(int($space / $sz_rr_a), $n_ns);
Vixie & Kato Expires November 11, 2012 [Page 12]
Internet-Draft DNS Referral Response Size May 2012
$n_a_aaaa = atmost(int($space
/ ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
$n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
/ $sz_rr_aaaa), $n_ns);
printf "For %s size query (%d byte):\n", $cond, $sz_query;
printf " only A is considered: ";
printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
printf " A and AAAA are considered: ";
printf "# of A+AAAA is %d (%s)\n",
$n_a_aaaa, &judge($n_a_aaaa, $n_ns);
printf " preferred-glue A is assumed: ";
printf "# of A is %d, # of AAAA is %d (%s)\n",
$n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
}
sub judge {
my ($n, $n_ns) = @_;
return "green" if ($n >= $n_ns);
return "yellow" if ($n >= 2);
return "orange" if ($n == 1);
return "red";
}
sub atmost {
my ($a, $b) = @_;
return 0 if ($a < 0);
return $b if ($a > $b);
return $a;
}
Authors' Addresses
Paul Vixie
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
US
Phone: +1 650 423 1300
Email: vixie@isc.org
Vixie & Kato Expires November 11, 2012 [Page 13]
Internet-Draft DNS Referral Response Size May 2012
Akira Kato
Keio University/WIDE Project
Graduate School of Media Design, 4-1-1 Hiyoshi
Kohoku, Yokohama 223-8526
JP
Phone: +81 45 564 2490
Email: kato@wide.ad.jp
Vixie & Kato Expires November 11, 2012 [Page 14]

295
doc/draft/draft-kato-dnsop-local-zones-00.txt
View File

@@ -1,295 +0,0 @@
Internet Engineering Task Force Akira Kato, WIDE
INTERNET-DRAFT Paul Vixie, ISC
Expires: August 24, 2003 February 24, 2003
Operational Guidelines for "local" zones in the DNS
draft-kato-dnsop-local-zones-00.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.
Distribution of this memo is unlimited.
The internet-draft will expire in 6 months. The date of expiration will
be August 24, 2003.
Abstract
A large number of DNS queries regarding to the "local" zones are sent
over the Internet in every second. This memo describes operational
guidelines to reduce the unnecessary DNS traffic as well as the load of
the Root DNS Servers.
1. Introduction
While it has yet been described in a RFC, .local is used to provide a
local subspace of the DNS tree. Formal delegation process has not been
completed for this TLD. In spite of this informal status, .local has
been used in many installations regardless of the awareness of the
users. Usually, the local DNS servers are not authoritative to the
.local domain, they end up to send queries to the Root DNS Servers.
There are several other DNS zones which describe the "local"
information. .localhost has been used to describe the localhost for
more than a couple of decades and virtually all of the DNS servers are
configured authoritative for .localhost and its reverse zone .127.in-
KATO Expires: August 24, 2003 [Page 1]
DRAFT DNS local zones February 2003
addr.arpa. However, there are other "local" zones currently used in the
Internet or Intranets connected to the Internet through NATs or similar
devices.
At a DNS server of an university in Japan, half of the DNS queries sent
to one of the 13 Root DNS Servers were regarding to the .local. At
another DNS Server running in one of the Major ISPs in Japan, the 1/4
were .local. If those "local" queries are able to direct other DNS
servers than Root, or they can be resolved locally, it contributes the
reduction of the Root DNS Servers.
2. Rationale
Any DNS queries regarding to "local" names should not be sent to the DNS
servers on the Internet.
3. Operational Guidelines
Those queries should be processed at the DNS servers internal to each
site so that the severs respond with NXDOMAIN rather than sending
queries to the DNS servers outside.
The "local" names have common DNS suffixes which are listed below:
3.1. Local host related zones:
Following two zones are described in [Barr, 1996] and .localhost is also
defined in [Eastlake, 1999] .
o .localhost
o .127.in-addr.arpa
Following two zones are for the loopback address in IPv6 [Hinden, 1998]
. While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush,
2001] , the old TLD .int has been used for this purpose for years
[Thomson, 1995] and many implementations still use .int. So it is
suggested that both zones should be provided for each IPv6 reverse
lookup zone for a while.
o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int
o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
3.2. Locally created name space
While the use of .local has been proposed in several Internet-Drafts, it
has not been described in any Internet documents with formal status.
However, the amount of the queries for .local is much larger than
others, it is suggested to resolve the following zone locally:
KATO Expires: August 24, 2003 [Page 2]
DRAFT DNS local zones February 2003
o .local
3.3. Private or site-local addresses
The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site-
local addresses [Hinden, 1998] should be resolved locally:
o 10.in-addr.arpa
o 16.172.in-addr.arpa
o 17.172.in-addr.arpa
o 18.172.in-addr.arpa
o 19.172.in-addr.arpa
o 20.172.in-addr.arpa
o 21.172.in-addr.arpa
o 22.172.in-addr.arpa
o 23.172.in-addr.arpa
o 24.172.in-addr.arpa
o 25.172.in-addr.arpa
o 26.172.in-addr.arpa
o 27.172.in-addr.arpa
o 28.172.in-addr.arpa
o 29.172.in-addr.arpa
o 30.172.in-addr.arpa
o 31.172.in-addr.arpa
o 168.192.in-addr.arpa
o c.e.f.ip6.int
o d.e.f.ip6.int
o e.e.f.ip6.int
o f.e.f.ip6.int
o c.e.f.ip6.arpa
o d.e.f.ip6.arpa
o e.e.f.ip6.arpa
o f.e.f.ip6.arpa
3.4. Link-local addresses
The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden,
1998] should be resolved locally:
o 254.169.in-addr.arpa
o 8.e.f.ip6.int
o 9.e.f.ip6.int
o a.e.f.ip6.int
o b.e.f.ip6.int
o 8.e.f.ip6.arpa
o 9.e.f.ip6.arpa
o a.e.f.ip6.arpa
o b.e.f.ip6.arpa
KATO Expires: August 24, 2003 [Page 3]
DRAFT DNS local zones February 2003
4. Suggestions to developers
4.1. Suggestions to DNS software implementors
In order to avoid unnecessary traffic, it is suggested that DNS software
implementors provide configuration templates or default configurations
so that the names described in the previous section are resolved locally
rather than sent to other DNS servers in the Internet.
4.2. Suggestions to developers of NATs or similar devices
There are many NAT or similar devices available in the market.
Regardless of the availability of DNS Servers in those devices, it is
suggested that those devices are able to filter the DNS traffic or
respond to the DNS traffic related to "local" zones by configuration
regardless of its ability of DNS service. It is suggested that this
functionality is activated by default.
5. IANA Consideration
While .local TLD has yet defined officially, there are substantial
queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the
traffic sent to the Root DNS Servers are related to the .local zone.
Therefore, while it is not formally defined, it is suggested that IANA
delegates .local TLD to an organization.
The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918
address and the link-local address. It has several DNS server instances
around the world by using BGP Anycast [Hardie, 2002] . So the AS112
Project is one of the candidates to host the .local TLD.
Authors' addresses
Akira Kato
The University of Tokyo, Information Technology Center
2-11-16 Yayoi Bunkyo
Tokyo 113-8658, JAPAN
Tel: +81 3-5841-2750
Email: kato@wide.ad.jp
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063, USA
Tel: +1 650-779-7001
Email: vixie@isc.org
KATO Expires: August 24, 2003 [Page 4]
DRAFT DNS local zones February 2003
References
To be filled
References
Barr, 1996.
D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912
(February 1996).
Eastlake, 1999.
D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999).
Hinden, 1998.
R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
RFC2373 (July 1998).
Bush, 2001.
R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001).
Thomson, 1995.
S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
RFC1886 (December 1995).
Rekhter, 1996.
Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear,
"Address Allocation for Private Internets" in RFC1918 (February 1996).
IANA, 2002.
IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002).
Vixie, .
P. Vixie, "AS112 Project" in AS112. http://www.as112.net/.
Hardie, 2002.
T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast
Addresses" in RFC3258 (April 2002).
KATO Expires: August 24, 2003 [Page 5]

336
doc/draft/draft-kerr-ixfr-only-01.txt
View File

@@ -1,336 +0,0 @@
DNSext Working Group O. Sury
Internet-Draft CZ.NIC
Updates: 1995 (if approved) S. Kerr, Ed.
Intended status: Standards Track ISC
Expires: August 30, 2010 February 26, 2010
IXFR-ONLY to Prevent IXFR Fallback to AXFR
draft-kerr-ixfr-only-01
Abstract
This documents proposes a new QTYPE (Query pseudo RRtype) for the
Domain Name System (DNS). IXFR-ONLY is a variant of IXFR (RFC 1995)
that allows an authoritative server to incrementally update zone
content from another (primary) server without falling back from IXFR
to AXFR. This way, alternate peers can be contacted more quickly and
convergence of zone content may be achieved much faster in important,
resilient operational scenarios.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on August 30, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sury & Kerr Expires August 30, 2010 [Page 1]
Internet-Draft IXFR-ONLY February 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. IXFR Server Side . . . . . . . . . . . . . . . . . . . . . . . 4
3. IXFR Client Side . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability of IXFR-ONLY . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Sury & Kerr Expires August 30, 2010 [Page 2]
Internet-Draft IXFR-ONLY February 2010
1. Introduction
For large DNS zones, RFC 1995 [RFC1995] defines Incremental Zone
Transfer (IXFR), which allows only to transfer the changed portion(s)
of a zone.
In the document, an IXFR client and an IXFR server is defined as in
RFC 1995 [RFC1995], 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.
IXFR is an efficient way to transfer changes in zones from IXFR
servers to IXFR clients. However, when an IXFR client has multiple
IXFR servers for a single zone, it is possible that not all IXFR
servers have the zone with same serial number for that zone. In this
case, if an IXFR client attempts an IXFR from an IXFR server which
does not have zone with the serial number used by the IXFR client,
the IXFR server will fall back to a full zone transfer (AXFR) when it
has a version of the zone with serial number greater than the serial
requested by the IXFR client.
For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for
a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the
same zone. An IXFR client that has the zone with serial number 2
which sends an IXFR request to IXFR server NS2 will get a full zone
transfer (AXFR) of the zone at serial number 3. This is because NS2
does not know the zone with serial number 2, and therefore does not
know what the differences are between zone with serial number 2 and
3.
If the IXFR client in this example had known to send the query to
IXFR server NS1, then it could have gotten an incremental transfer
(IXFR). But IXFR clients can only know what the latest version of
the zone is at a IXFR server (this information is available via an
SOA query).
The IXFR-ONLY query type provides a way for the IXFR client to ask
each IXFR server to return an error instead of sending the current
version of the zone via full zone transfer (AXFR). By using this, a
IXFR client can check each IXFR server until it finds one able to
provide IXFR.
1.1. Requirements Language
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 [RFC2119].
Sury & Kerr Expires August 30, 2010 [Page 3]
Internet-Draft IXFR-ONLY February 2010
2. IXFR Server Side
A IXFR server receiving a DNS message requesting IXFR-ONLY will reply
as described in RFC 1995 [RFC1995] if it is able to produce an IXFR
for the serial number requested.
If the IXFR server is is not able to reply with an IXFR it MUST NOT
reply with an AXFR unless AXFR result is smaller than IXFR result.
Instead, it MUST reply with RCODE CannotIXFR. (!FIXME)
If the IXFR result is larger than an AXFR, then an IXFR server MAY
reply with an AXFR result instead. This is an optimization, and IXFR
servers MAY only reply with AXFR if they are certain that the reply
using AXFR is smaller than an equivalent IXFR reply.
3. IXFR Client Side
An IXFR client who wishes to use IXFR-ONLY will send a message to one
of the IXFR servers. The format is exactly the same as for IXFR,
except the IXFR-ONLY QTYPE code is used instead of the IXFR QTYPE
code.
If the IXFR server replies with IXFR, then the IXFR client is done.
If the IXFR server replies with an RCODE of CannotIXFR, then the IXFR
client proceeds on to a different IXFR server. In this case the IXFR
server implements IXFR-ONLY, but does not have information about zone
with the serial number requested.
If the IXFR server replies with any RCODE other than CannotIXFR or
NoError, then the IXFR client proceeds on to a different IXFR server.
In this case the IXFR server does not implement IXFR-ONLY.
If the IXFR client attempts IXFR-ONLY to each IXFR server and none of
them reply with an incremental transfer (IXFR), then it should
attempt an IXFR as described in RFC 1995 [RFC1995] to each of the
IXFR servers which replied with an RCODE other than CannotIXFR or
NoError.
The method described above allows IXFR clients to operate normally in
situatians where some of the IXFR servers do support IXFR-ONLY, and
some who do not. IXFR clients MAY remember which IXFR servers
support IXFR-ONLY and query those IXFR servers first. However since
IXFR servers may change software or even run a mix of software, IXFR
clients MUST attempt to query each IXFR server periodically when they
attempt to get new versions of a zone.
Sury & Kerr Expires August 30, 2010 [Page 4]
Internet-Draft IXFR-ONLY February 2010
Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
given IXFR server, if this is known in advance. These IXFR servers
are treated as if they replied with an RCODE other than CannotIXFR or
NoError, although no query with IXFR-ONLY is actually sent.
4. Applicability of IXFR-ONLY
Implementations SHOULD allow IXFR clients to disable IXFR-ONLY
completely.
Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
specific zone. This may be useful for small zones, where fallback to
AXFR is cheap, or in other cases where IXFR-ONLY is causing problems.
Usage of IXFR-ONLY may cause IXFR clients to prefer particular IXFR
servers, by shifting load to ones that support IXFR-ONLY. If this a
problem, then administrators can disable IXFR-ONLY in implementations
that allow it.
If a IXFR client has a single IXFR server for a zone, it SHOULD use
IXFR rather than IXFR-ONLY.
5. IANA Considerations
IANA allocates the new IXFR-ONLY QTYPE, which means "incremental
transfer only". IANA allocates the CannotIXFR RCODE, which means
"Server cannot provide IXFR for zone".
6. Security Considerations
IXFR-ONLY may be used by someone to get information about the state
of IXFR servers by providing a quick and efficient way to check which
versions of a zone each IXFR server supports. Zones should be
secured via TSIG [RFC2845] to prevent unauthorized information
exposure. However, even administrators of IXFR servers may not want
this information given to IXFR clients, in which case they will need
to disable IXFR-ONLY.
7. Normative References
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Sury & Kerr Expires August 30, 2010 [Page 5]
Internet-Draft IXFR-ONLY February 2010
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
Authors' Addresses
Ondrej Sury
CZ.NIC
Americka 23
120 00 Praha 2
CZ
Phone: +420 222 745 110
Email: ondrej.sury@nic.cz
Shane Kerr (editor)
ISC
Bennebrokestraat 17-I
1015 PE Amsterdam
NL
Phone: +31 64 6336297
Email: shane@isc.org
Sury & Kerr Expires August 30, 2010 [Page 6]

392
doc/draft/draft-mekking-dnsop-auto-cpsync-01.txt
View File

@@ -1,392 +0,0 @@
Domain Name System Operations W. Mekking
Internet-Draft NLnet Labs
Intended status: Standards Track December 21, 2010
Expires: June 24, 2011
Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE
draft-mekking-dnsop-auto-cpsync-01
Abstract
This document proposes a way to synchronise existing trust anchors
automatically between a child zone and its parent. The protocol can
be used for other Resource Records that are required to delegate from
a parent to a child such as NS and glue records. The synchronization
allows for a third party to be involved, thus the protocol is
suitable for both cases, whether you have to communicate to the
registry or to the registrar.
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 24, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Mekking Expires June 24, 2011 [Page 1]
Internet-Draft Child Parent Synchronization December 2010
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
This memo defines a way to synchronise existing trust anchors
automatically between a child zone and its parent. The protocol can
be used for other Resource Records that are required to delegate from
a parent to a child such as NS and glue records. The synchronization
allows for a third party to be involved, thus the protocol is
suitable for both cases, whether you have to communicate to the
registry or to the registrar.
To create a DNSSEC RFC 4035 [RFC4035] chain of trust, child zones
must submit their DNSKEYs, or hashes of their DNSKEYs, to their
parent zone. The parent zone publishes the hashes of the DNSKEYs in
the form of a DS record. The DNSKEY RRset at the child may change
over time. In order to keep the chain of trust intact, the DS
records at the parent zone also needs to be updated. The rolling of
the keys with the SEP bit on is one of the few tasks in DNSSEC that
yet has to be fully automated.
The DNS UPDATE mechanism RFC 2136 [RFC2136] can be used to push zone
changes to the parent.
To bootstrap the communication channel, information must be exchanged
in order to detect service location and granting update privileges.
A new or existing child zone is in need of a communication channel
with the parent. This can be a direct channel or a channel through a
third party:
If the parent allows for direct communication channel with child
zones, the parent can share the required data to set up the
channel to the child zone. Once the child has the required
credentials, it can use the direct communication channel with the
parent to request zone changes related to its delegation.
If a third party is involved, the third party acts on behalf of
the parent. In this case, the third party will give out the
required credentials to set up the communication channel.
Allowing for a third party in the communication channel ensures
Mekking Expires June 24, 2011 [Page 2]
Internet-Draft Child Parent Synchronization December 2010
flexibility of the service location.
Please note that the document only describes the front end of the
synchronization service. The first reason for that is that it is not
necessary to write down how the DNS UPDATE is processed after it is
accepted. It is merely a goal to provide a way for the child zone to
automatically update the records at the zone cut. The second reason
is that flexibility is needed in order to fit the protocol into the
multifarious policies that exist among the great number of
registrars.
Thus, it is not required that the DNS UPDATE immediately updates the
name server. Thus, it would still be possible to monitor the
incoming updates with the tools of your choice. It is not a
replacement of your RR provisioning system. The records in the DNS
UPDATE can be converted into any kind of format.
2. Service Discovery
The service location is handed out during bootstrap. If this
information is missing or incorrect, the normal guidelines for
sending DNS UPDATE messages SHOULD be followed.
3. Access and Update Control
The DNS UPDATE normally is used for granting update permissions to a
machine that is within the boundary of the same organization. This
document proposes to grant child zones the same permissions.
However, it MUST NOT be possible that a child zone updates
information in the parent zone that falls outside the administrative
domain of the corresponding delegation. For example, it MUST NOT be
possible for a child zone to update the data that the parent is
authoritative for, or update a delegation that is pointed to a
different child zone. It MUST only be able to update records that
match one of the following:
Or: The owner name is equal the child zone name and RRtype is
delegation specific. Currently those are records with RRtype NS
or DS.
Or: The owner name exists in the right side of the NS RRset
belonging to the child zone and RRtype is is glue specific.
Currently those are records with RRtype A or AAAA.
We can make a distinction here between narrow and wide glue records.
Narrow glue records are said to be glue specific records with an
owner name that is a subdomain of the child zone. Wide glue records
are glue specific records with an owner name that is outside of the
Mekking Expires June 24, 2011 [Page 3]
Internet-Draft Child Parent Synchronization December 2010
delegated child domain.
These updates MAY be refused if it conflicts with the local policy.
This list may be expanded, if there is need for more delegation
related zone content.
In case of adding or deleting delegation specific records, the DNSSEC
related RRs in the parent zone might need to be updated.
4. Update Mechanism
4.1. Update Request
Updating the NS RRset or corresponding glue at the parent, an update
can be sent at any time. Updating the DS RRset is part of key
rollover, as described in RFC 4641 [RFC4641]. When performing a key
rollover that involves updating the RRset at the parent, the child
introduces a new DNSKEY in its zone that represents the security
entry point for determining the chain of trust. After a while, it
will revoke and/or remove the previous security entry point. The
timings when to update the DS RRset at the parent are described in
draft-dnsop-morris-dnssec-key-timing [keytiming]. When updating the
DS RRset at the parent automatically, these timing specifications
SHOULD be followed. To determine the propagation delays described in
this document, the child should poll the parent zone for a short
time, until the DS is visible at all parent name servers.
[Author's note] To discuss: A child zone might be unable to reach all
parent name servers.
The child notifies the parent of the requested changes by sending a
DNS UPDATE message. If it receives a NOERROR reply in return, the
update is acknowledged by the parent zone. Otherwise, the child MAY
retry transmitting the update. In order to prevent duplicate
updates, it SHOULD follow the guidelines described in RFC 2136
[RFC2136].
4.2. Processing the Update
An incoming DNS UPDATE message is processed as follows:
Step 1: Check the TSIG/SIG0 credentials. In case of TSIG, the
parent should follow the TSIG processing described in section 3.2
of RFC 2845. In case of SIG0, the parent should follow the SIG0
processing described in section 3.2 of RFC 2931.
Mekking Expires June 24, 2011 [Page 4]
Internet-Draft Child Parent Synchronization December 2010
Step 2: Verify that the updates matches the update policy for child
zones.
Step 3: If verified, send back DNS UPDATE OK. Otherwise, send back
DNS UPDATE REFUSED.
Step 4: If verified, apply changes. How that is done is a matter of
policy.
5. Examples
5.1. Example BIND9 Configuration
This is how a parent zone can configure a policy to enable a child
zone synchronize delegation specific records. The first rule of the
update policy grants children to update their DS and NS records in
the parent zone, in this case example.com. The second rule of the
update policy grants children to update the corresponding glue
records.
key cs.example.com. {
algorithm HMAC-MD5;
secret "secretforcs";
}
key math.example.com. {
algorithm HMAC-MD5;
secret "secretformath";
}
...
zone "example.com" {
type master;
file "example.com";
update-policy { grant *.example.com. self *.example.com. DS NS; };
update-policy { grant *.example.com. selfsub *.example.com. A AAAA;
};
};
6. Security Considerations
Automating the synchronization of (DNSSEC) records between the parent
and child creates a new communication channel. It is up to the
policy of the parent, or the third party acting on behalf of the
parent, who is allowed such privileges. A policy would usually
include a form of access control. It is recommended that it involves
transaction authentication, for example TSIG [RFC2845] or SIG0
Mekking Expires June 24, 2011 [Page 5]
Internet-Draft Child Parent Synchronization December 2010
[RFC2931].
In the jungle of the DNS, many stakeholders exist. The registrant of
a zone might not be the one that maintains the zone. That can
possibly mean that many stakeholders need to possess the security
credentials in order to use this synchronization channel. However,
this problem exist with any kind of transaction authentication.
The disadvantage of adding a new communication channel is that you
create a new attack window onto your DNS and DNSSEC records. When
using this synchronization method for your DNSSEC records, a
cryptographically equally strong, or stronger private key SHOULD be
used, compared to the strength of your DNSSEC keys.
The advantage is that if somehow your DNSSEC keys are compromised,
you can still use this channel to perform an emergency key rollover.
7. IANA Considerations
None.
8. Acknowledgments
Mark Andrews, Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards.
9. Changelog
01:
- Make it clear that the solution is flexible and it can fit into
many and diverse environments of registrars.
- Short section about service discovery.
- Add text about narrow glue records.
- Add text about transaction authentication concerns with respect
to many stakeholders involved.
00:
- Initial document
10. References
Mekking Expires June 24, 2011 [Page 6]
Internet-Draft Child Parent Synchronization December 2010
10.1. Informative References
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS
UPDATE)", RFC 2136, April 1997.
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational
Practices", RFC 4641, September 2006.
[keytiming] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
Timing Considerations", March 2010.
10.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, May 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
Author's Address
Matthijs Mekking
NLnet Labs
Science Park 140
Amsterdam 1098 XG
The Netherlands
EMail: matthijs@nlnetlabs.nl
Mekking Expires June 24, 2011 [Page 7]

728
doc/draft/draft-pechanec-pkcs11uri-13.txt
View File

@@ -1,728 +0,0 @@
Network Working Group J. Pechanec
Internet-Draft D. Moffat
Intended status: Standards Track Oracle Corporation
Expires: April 03, 2014 September 30, 2013
The PKCS#11 URI Scheme
draft-pechanec-pkcs11uri-13
Abstract
This memo specifies a PKCS#11 Uniform Resource Identifier (URI)
Scheme for identifying PKCS#11 objects stored in PKCS#11 tokens, for
identifying PKCS#11 tokens themselves, or for identifying PKCS#11
libraries. The URI is based on how PKCS#11 objects, tokens, and
libraries are identified in the PKCS#11 Cryptographic Token Interface
Standard.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 03, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Pechanec & Moffat Expires April 03, 2014 [Page 1]
Internet-Draft The PKCS#11 URI Scheme September 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3
3. PKCS#11 URI Scheme Definition . . . . . . . . . . . . . . . . 3
3.1. PKCS#11 URI Scheme Name . . . . . . . . . . . . . . . . . 4
3.2. PKCS#11 URI Scheme Status . . . . . . . . . . . . . . . . 4
3.3. PKCS#11 URI Scheme Syntax . . . . . . . . . . . . . . . . 4
3.4. PKCS#11 URI Matching Guidelines . . . . . . . . . . . . . 7
3.5. PKCS#11 URI Comparison . . . . . . . . . . . . . . . . . 8
4. Examples of PKCS#11 URIs . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The PKCS #11: Cryptographic Token Interface Standard [pkcs11_spec]
specifies an API, called Cryptoki, for devices which hold
cryptographic information and perform cryptographic functions.
Cryptoki, pronounced crypto-key and short for cryptographic token
interface, follows a simple object-based approach, addressing the
goals of technology independence (any kind of device may be used) and
resource sharing (multiple applications may access multiple devices),
presenting applications with a common, logical view of the device - a
cryptographic token.
It is desirable for applications or libraries that work with PKCS#11
tokens to accept a common identifier that consumers could use to
identify an existing PKCS#11 storage object in a PKCS#11 token, an
existing token itself, or an existing Cryptoki library (also called a
producer, module, or provider). The set of storage object types that
can be stored in a PKCS#11 token includes a certificate, a public,
private or secret key, and a data object. These objects can be
uniquely identifiable via the PKCS#11 URI scheme defined in this
Pechanec & Moffat Expires April 03, 2014 [Page 2]
Internet-Draft The PKCS#11 URI Scheme September 2013
document. The set of attributes describing a storage object can
contain an object label, its type, and its ID. The set of attributes
that identifies a PKCS#11 token can contain a token label, a
manufacturer name, a serial number, and a token model. Attributes
that can identify a Cryptoki library are a library manufacturer, a
library description, and a library version. Library attributes may
be necessary to use if more than one Cryptoki library provides a
token and/or PKCS#11 objects of the same name(s).
The PKCS#11 URI cannot identify other objects aside from storage
objects, for example a hardware feature or mechanism. Note that a
Cryptoki library does not have to provide for storage objects at all.
The URI can still be used to identify a specific PKCS#11 token or an
API producer in such a case.
A subset of existing PKCS#11 structure members and object attributes
was chosen believed to be sufficient in uniquely identifying a
PKCS#11 token, storage object, or library in a configuration file, on
a command line, or in a configuration property of something else.
Should there be a need for a more complex information exchange on
PKCS#11 entities a different means of data marshalling should be
chosen accordingly.
A PKCS#11 URI is not intended to be used to create new PKCS#11
objects in tokens, or to create PKCS#11 tokens. It is solely to be
used to identify and work with existing storage objects and tokens
through the PKCS#11 API, or identify Cryptoki libraries themselves.
The URI scheme defined in this document is designed specifically with
a mapping to the PKCS#11 API in mind. The URI uses the scheme, path
and query components defined in the Uniform Resource Identifier
(URI): Generic Syntax [RFC3986] document. The URI does not use the
hierarchical element for a naming authority in the path since the
authority part could not be mapped to PKCS#11 API elements. The URI
does not use the fragment component.
If an application has no access to a producer or producers of the
PKCS#11 API it is left to its implementation to provide adequate user
interface to locate and load such producer(s).
2. Contributors
Stef Walter, Nikos Mavrogiannopoulos, Nico Williams, Dan Winship, and
Jaroslav Imrich contributed to the development of this document.
3. PKCS#11 URI Scheme Definition
Pechanec & Moffat Expires April 03, 2014 [Page 3]
Internet-Draft The PKCS#11 URI Scheme September 2013
In accordance with [RFC4395], this section provides the information
required to register the PKCS#11 URI scheme.
3.1. PKCS#11 URI Scheme Name
pkcs11
3.2. PKCS#11 URI Scheme Status
Permanent.
3.3. PKCS#11 URI Scheme Syntax
The PKCS#11 URI is a sequence of attribute value pairs separated by a
semicolon that form a one level path component, optionally followed
by a query. In accordance with Section 2.5 of [RFC3986], the data
should first be encoded as octets according to the UTF-8 character
encoding [RFC3629]; then only those octets that do not correspond to
characters in the unreserved set or to permitted characters from the
reserved set should be percent-encoded. This specification suggests
one allowable exception to that rule for the "id" attribute, as
stated later in this section. Grammar rules "unreserved" and "pct-
encoded" in the PKCS#11 URI specification below are imported from
[RFC3986]. As a special case, note that according to Appendix A of
[RFC3986], a space must be percent-encoded.
PKCS#11 specification imposes various limitations on the value of
attributes, be it a more restrictive character set for the "serial"
attribute or fixed sized buffers for almost all the others, including
"token", "manufacturer", and "model" attributes. However, the
PKCS#11 URI notation does not impose such limitations aside from
removing generic and PKCS#11 URI delimiters from a permitted
character set. We believe that being too restrictive on the
attribute values could limit the PKCS#11 URI's usefulness. What is
more, possible future changes to the PKCS#11 specification should not
affect existing attributes.
A PKCS#11 URI takes the form (for explanation of Augmented BNF, see
[RFC5234]):
Pechanec & Moffat Expires April 03, 2014 [Page 4]
Internet-Draft The PKCS#11 URI Scheme September 2013
pk11-URI = "pkcs11" ":" pk11-path *1("?" pk11-query)
; Path component and its attributes. Path may be empty.
pk11-path = *1(pk11-pattr *(";" pk11-pattr))
pk11-pattr = pk11-token / pk11-manuf / pk11-serial /
pk11-model / pk11-lib-manuf /
pk11-lib-ver / pk11-lib-desc /
pk11-object / pk11-type / pk11-id /
pk11-x-pattr
; Query component and its attributes. Query may be empty.
pk11-qattr = pk11-pin-source / pk11-x-qattr
pk11-query = *1(pk11-qattr *("&" pk11-qattr))
; RFC 3986 section 2.2 mandates all potentially reserved characters
; that do not conflict with actual delimiters of the URI do not have
; to be percent-encoded.
pk11-res-avail = ":" / "[" / "]" / "@" / "!" / "$" /
"'" / "(" / ")" / "*" / "+" / "," / "="
pk11-path-res-avail = pk11-res-avail / "&"
; We allow "/" and "?" in the query to be unencoded but "&" must
; be encoded since it may be used as a delimiter in the component.
pk11-query-res-avail = pk11-res-avail / "/" / "?"
pk11-pchar = unreserved / pk11-path-res-avail / pct-encoded
pk11-qchar = unreserved / pk11-query-res-avail / pct-encoded
pk11-token = "token" "=" *pk11-pchar
pk11-manuf = "manufacturer" "=" *pk11-pchar
pk11-serial = "serial" "=" *pk11-pchar
pk11-model = "model" "=" *pk11-pchar
pk11-lib-manuf = "library-manufacturer" "=" *pk11-pchar
pk11-lib-desc = "library-description" "=" *pk11-pchar
pk11-lib-ver = "library-version" "=" 1*DIGIT *1("." 1*DIGIT)
pk11-object = "object" "=" *pk11-pchar
pk11-type = "type" "=" *1("public" / "private" / "cert" /
"secret-key" / "data")
pk11-id = "id" "=" *pk11-pchar
pk11-pin-source = "pin-source" "=" *pk11-qchar
pk11-x-attr-nm-char = ALPHA / DIGIT / "-" / "_"
; Permitted value of a vendor specific attribute is based on
; whether the attribute is used in the path or in the query.
pk11-x-pattr = "x-" 1*pk11-x-attr-nm-char "=" *pk11-pchar
pk11-x-qattr = "x-" 1*pk11-x-attr-nm-char "=" *pk11-qchar
Pechanec & Moffat Expires April 03, 2014 [Page 5]
Internet-Draft The PKCS#11 URI Scheme September 2013
The URI path component contains attributes that identify a resource
in a one level hierarchy provided by Cryptoki producers. The query
component may contain a PIN source attribute that may be needed to
retrieve the resource identified by the URI path. Both path and
query components may contain vendor specific attributes. Such
attribute names must start with an "x-" prefix. Attributes in the
path component are delimited by ';' character, attributes in the
query component use '&' as a delimiter.
The general '/' delimiter was removed from available characters that
do not have to be percent-encoded in the path component so that
generic URI parsers never split the path component into multiple
segments. The '/' delimiter can be used unencoded in the query
component. Delimiter '?' was removed since the PKCS#11 URI uses a
query component. Delimiter '#' was removed so that generic URI
parsers are not confused by unencoded hash characters. All other
generic delimiters are allowed to be used unencoded (':', '[', ']',
and '@') in the PKCS#11 URI.
The attribute "token" represents a token label and corresponds to the
"label" member of the CK_TOKEN_INFO structure, the attribute
"manufacturer" corresponds to the "manufacturerID" member of
CK_TOKEN_INFO, the attribute "serial" corresponds to the
"serialNumber" member of CK_TOKEN_INFO, the attribute "model"
corresponds to the "model" member of CK_TOKEN_INFO, the attribute
"library-manufacturer" represents the Cryptoki library manufacturer
and corresponds to the "manufacturerID" member of the CK_INFO
structure, the attribute "library-description" corresponds to the
"libraryDescription" member of CK_INFO, the attribute "library-
version" corresponds to the "libraryVersion" member of CK_INFO, the
attribute "object" represents a PKCS#11 object label and corresponds
to the "CKA_LABEL" object attribute, the attribute "type" represents
the type of the object and corresponds to the "CKA_CLASS" object
attribute, the attribute "id" represents the object ID and
corresponds to the "CKA_ID" object attribute, and the attribute "pin-
source" specifies where the application or library should find the
token PIN, if needed.
The PKCS#11 URI must not contain duplicate attributes of the same
name in the URI path component. It means that each attribute may be
present at most once in the PKCS#11 URI path. Aside from the "pin-
source" attribute, duplicate attributes may be present in the URI
query component and it is up to the URI consumer to decide on how to
deal with such duplicates.
The "pin-source" attribute may represent a filename that contains a
token PIN but an application may overload this attribute. For
example, "pin-source=%7Cprog-name" could mean to read a PIN from an
Pechanec & Moffat Expires April 03, 2014 [Page 6]
Internet-Draft The PKCS#11 URI Scheme September 2013
external application (%7C denotes a pipe '|' character). Note that
an application may always ask for a PIN and/or interpret the "pin-
source" attribute by any means it decides to. However, as discussed
in Section 6, the attribute should never contain the PIN itself.
It is recommended to percent-encode the whole value of the "id"
attribute which is supposed to be handled as arbitrary binary data.
Value "M" of the "library-version" attribute should be interpreted as
"M" for the major and "0" for the minor version of the library. Note
that if the "library-version" attribute is present, the major version
number is mandatory.
An empty PKCS#11 URI path attribute that does allow for an empty
value matches a corresponding structure member or an object attribute
with an empty value. Note that according to the PKCS#11
specification [pkcs11_spec], empty character values in a PKCS#11 API
producer must be padded with spaces and should not be NULL
terminated.
3.4. PKCS#11 URI Matching Guidelines
The PKCS#11 URI can identify PKCS#11 storage objects, tokens, or
Cryptoki libraries. The following guidelines should help a PKCS#11
URI consumer (eg. an application accepting PKCS#11 URIs) to match the
URI with the desired resource.
o the consumer must know whether the URI is to identify PKCS#11
storage object(s), token(s), or Cryptoki producer(s).
o an unrecognized attribute in the URI path component, including a
vendor specific attribute, should result in an empty set of
matched resources. The consumer should consider whether an error
message presented to the user is appropriate in such a case.
o an unrecognized attribute in the URI query should be ignored. The
consumer should consider whether a warning message presented to
the user is appropriate in such a case.
o an attribute not present in the URI path but known to a consumer
matches everything. Each additional attribute present in the URI
path further restricts the selection.
o a logical extension of the above is that an empty URI path matches
everything. For example, if used to identify storage objects, it
matches all accessible objects in all tokens provided by all
PKCS#11 API producers found in the system.
Pechanec & Moffat Expires April 03, 2014 [Page 7]
Internet-Draft The PKCS#11 URI Scheme September 2013
o use of the PIN attribute may change the set of storage objects
visible to the consumer.
o in addition to the PIN attribute, query string attributes may
contain further information about how to perform the selection or
other related information.
3.5. PKCS#11 URI Comparison
Comparison of two URIs is a way of determining whether the URIs are
equivalent without comparing the actual resource the URIs point to.
The comparison of URIs aims to minimize false negatives while
strictly avoiding false positives.
Two PKCS#11 URIs are said to be equal if URIs as character strings
are identical as specified in Section 6.2.1 of [RFC3986], or if both
following rules are fulfilled:
o set of attributes present in the URI is equal. Note that the
ordering of attributes in the URI string is not significant for
the mechanism of comparison.
o values of respective attributes are equal based on rules specified
below
The rules for comparing values of respective attributes are:
o values of attributes "library-description", "library-
manufacturer", "manufacturer", "model", "object", "serial",
"token", and "type" must be compared using a simple string
comparison as specified in Section 6.2.1 of [RFC3986] after the
case and the percent-encoding normalization are both applied as
specified in Section 6.2.2 of [RFC3986]
o value of attribute "id" must be compared using the simple string
comparison after all bytes are percent-encoded using uppercase
letters for digits A-F
o value for attribute "pin-source", if deemed containing the
filename with the PIN value, must be compared using the simple
string comparison after the full syntax based normalization as
specified in Section 6.2.2 of [RFC3986] is applied. If value of
the "pin-source" attribute is believed to be overloaded it is
recommended to perform case and percent-encoding normalization
before the values are compared but the exact mechanism of
comparison is left to the application.
Pechanec & Moffat Expires April 03, 2014 [Page 8]
Internet-Draft The PKCS#11 URI Scheme September 2013
o value of attribute "library-version" must be processed as a
specific scheme-based normalization permitted by Section 6.2.3 of
[RFC3986]. The value must be split into a major and minor version
with character '.' (dot) serving as a delimiter. Library version
"M" must be treated as "M" for the major version and "0" for the
minor version. Resulting minor and major version numbers must be
then separately compared numerically.
o when comparing vendor specific attributes it is recommended to
perform case and percent-encoding normalization before the values
are compared but the exact mechanism of comparison is left to the
application.
4. Examples of PKCS#11 URIs
This section contains some examples of how PKCS#11 token objects,
PKCS#11 tokens, and PKCS#11 libraries can be identified using the
PKCS#11 URI scheme. Note that in some of the following examples,
newlines and spaces were inserted for better readability. As
specified in Appendix C of [RFC3986], whitespace should be ignored
when extracting the URI. Also note that all spaces as part of the
URI are percent-encoded, as specified in Appendix A of [RFC3986].
An empty PKCS#11 URI might be useful to PKCS#11 consumers:
pkcs11:
One of the simplest and most useful forms might be a PKCS#11 URI that
specifies only an object label and its type. The default token is
used so the URI does not specify it. Note that when specifying
public objects, a token PIN might not be required.
pkcs11:object=my-pubkey;type=public
When a private key is specified either the "pin-source" attribute or
an application specific method would be usually used. Note that '/'
is not percent-encoded in the "pin-source" attribute value since this
attribute is part of the query component, not the path, and thus is
separated by '?' from the rest of the URI.
pkcs11:object=my-key;type=private?pin-source=/etc/token
The following example identifies a certificate in the software token.
Note an empty value for the attribute "serial". Also note that the
"id" attribute value is entirely percent-encoded, as recommended.
Pechanec & Moffat Expires April 03, 2014 [Page 9]
Internet-Draft The PKCS#11 URI Scheme September 2013
While ',' is in the reserved set it does not have to be percent-
encoded since it does not conflict with any sub-delimiters used. The
'#' character as in "The Software PKCS#11 Softtoken" must be percent-
encoded.
pkcs11:token=The%20Software%20PKCS%2311%20Softtoken;
manufacturer=Snake%20Oil,%20Inc.;
model=1.0;
object=my-certificate;
type=cert;
id=%69%95%3E%5C%F4%BD%EC%91;
serial=
?pin-source=/etc/token_pin
The token alone can be identified without specifying any PKCS#11
objects. A PIN may still be needed to list all objects, for example.
pkcs11:token=Software%20PKCS%2311%20softtoken;
manufacturer=Snake%20Oil,%20Inc.
?pin-source=/etc/token_pin
The Cryptoki library alone can be also identified without specifying
a PKCS#11 token or object.
pkcs11:library-manufacturer=Snake%20Oil,%20Inc.;
library-description=Soft%20Token%20Library;
library-version=1.23
The following example shows that the attribute value can contain a
semicolon. In such case, it is percent-encoded. The token attribute
value must be read as "My token; created by Joe". Lower case letters
can also be used in percent-encoding as shown below in the "id"
attribute value but note that Sections 2.1 and 6.2.2.1 of [RFC3986]
read that all percent-encoded characters should use the uppercase
hexadecimal digits. More specifically, if the URI string was to be
compared, the algorithm defined in Section 3.5 explicitly requires
percent-encoding to use the uppercase digits A-F in the "id"
attribute values. And as explained in Section 3.3, library version
"3" should be interpreted as "3" for the major and "0" for the minor
version of the library.
pkcs11:token=My%20token%25%20created%20by%20Joe;
library-version=3;
id=%01%02%03%Ba%dd%Ca%fe%04%05%06
Pechanec & Moffat Expires April 03, 2014 [Page 10]
Internet-Draft The PKCS#11 URI Scheme September 2013
If there is any need to include literal "%;" substring, for example,
both characters must be escaped. The token value must be read as "A
name with a substring %;".
pkcs11:token=A%20name%20with%20a%20substring%20%25%3B;
object=my-certificate;
type=cert
?pin-source=/etc/token_pin
The next example includes a small A with acute in the token name. It
must be encoded in octets according to the UTF-8 character encoding
and then percent-encoded. Given that a small A with acute is U+225
unicode code point, the UTF-8 encoding is 195 161 in decimal, and
that is "%C3%A1" in percent-encoding.
pkcs11:token=Name%20with%20a%20small%20A%20with%20acute:%20%C3%A1;
object=my-certificate;
type=cert
Both the path and query components may contain vendor specific
attributes. Attributes in the query component may be delimited by
either ';' or '&'. We use '&' in the example that follows.
pkcs11:token=my-token;
object=my-certificate;
type=cert;
x-vend-aaa=value-a
?pin-source=/etc/token_pin&
x-vend-bbb=value-b
5. IANA Considerations
This document moves the "pkcs11" URI scheme from the provisional to
the permanent URI scheme registry. The registration template for the
URI scheme is accessible on http://www.iana.org/assignments/uri-
schemes.
6. Security Considerations
There are general security considerations for URI schemes discussed
in Section 7 of [RFC3986].
From those security considerations, Section 7.1 of [RFC3986] applies
since there is no guarantee that the same PKCS#11 URI will always
identify the same object, token, or a library in the future.
Pechanec & Moffat Expires April 03, 2014 [Page 11]
Internet-Draft The PKCS#11 URI Scheme September 2013
Section 7.5 of [RFC3986] applies since the PKCS#11 URI may be used in
command line arguments to run applications, and those arguments can
be world readable on some systems. For that reasons, the URI
intentionally does not allow for specifying the PKCS#11 token PIN as
a URI attribute.
7. References
7.1. Normative References
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, STD 63, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986, STD
66, January 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, STD 68, January 2008.
7.2. Informative References
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", RFC 4395,
February 2006.
[pkcs11_spec]
RSA Laboratories, "PKCS #11: Cryptographic Token Interface
Standard v2.20", June 2004.
Authors' Addresses
Jan Pechanec
Oracle Corporation
4180 Network Circle
Santa Clara CA 95054
USA
Email: Jan.Pechanec@Oracle.COM
URI: http://www.oracle.com
Pechanec & Moffat Expires April 03, 2014 [Page 12]
Internet-Draft The PKCS#11 URI Scheme September 2013
Darren J. Moffat
Oracle Corporation
Oracle Parkway
Thames Valley Park
Reading RG6 1RA
UK
Email: Darren.Moffat@Oracle.COM
URI: http://www.oracle.com
Pechanec & Moffat Expires April 03, 2014 [Page 13]

841
doc/draft/draft-yao-dnsext-bname-05.txt
View File

@@ -1,841 +0,0 @@
Network Working Group J. Yao
Internet-Draft X. Lee
Intended status: Standards Track CNNIC
Expires: February 20, 2011 P. Vixie
Internet Software Consortium
August 19, 2010
Bundled DNS Name Redirection
draft-yao-dnsext-bname-05.txt
Abstract
This document defines a new DNS Resource Record called "BNAME", which
provides the capability to map itself and its subtree of the DNS name
space to another domain. It differs from the CNAME record which only
maps a single node of the DNS name space, from the DNAME which only
maps the subtree of the DNS name space to another domain.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 20, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Yao, et al. Expires February 20, 2011 [Page 1]
Internet-Draft bname August 2010
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The BNAME Resource Record . . . . . . . . . . . . . . . . . . 4
3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. The BNAME Substitution . . . . . . . . . . . . . . . . . . 4
3.3. The BNAME Rules . . . . . . . . . . . . . . . . . . . . . 4
3.4. BNAME Examples . . . . . . . . . . . . . . . . . . . . . . 4
4. Query Processing . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Processing by Servers . . . . . . . . . . . . . . . . . . 5
4.2. Processing by Resolvers . . . . . . . . . . . . . . . . . 8
5. BNAME in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. BNAME validating . . . . . . . . . . . . . . . . . . . . . 9
5.2. BNAME alias algorithm identifiers . . . . . . . . . . . . 10
5.3. Signaling of BNAME . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. draft-yao-dnsext-bname: Version 00 . . . . . . . . . . . . 12
9.2. draft-yao-dnsext-bname: Version 01 . . . . . . . . . . . . 12
9.3. draft-yao-dnsext-bname: Version 02 . . . . . . . . . . . . 12
9.4. draft-yao-dnsext-bname: Version 03 . . . . . . . . . . . . 12
9.5. draft-yao-dnsext-bname: Version 04 . . . . . . . . . . . . 13
9.6. draft-yao-dnsext-bname: Version 05 . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Yao, et al. Expires February 20, 2011 [Page 2]
Internet-Draft bname August 2010
1. Introduction
More and more internationalized domain name labels [RFC3490] appear
in the DNS trees. Some labels [RFC3743] are equivalent in some
languages. The internet users want them to be identical in the DNS
resolution. For example, color.exmaple.com==colour.example.com. The
BNAME represents for bundle names. This document defines a new DNS
Resource Record called "BNAME", which provides the capability to map
an entire tree of the DNS name space to another domain. It means
that the BNAME redirects both itself and its descendants to its
owner. The DNAME [RFC2672] and [RFC2672bis] do not redirect itself,
only the descendants. The domain name that owns a DNAME record is
allowed to have other resource record types at that domain name. The
domain name that owns a BNAME record is not allowed to have other
resource record types at that domain name unless they are the DNSSEC
related resource record types defined in [RFC4033], [RFC4034],
[RFC4035] and [RFC5155]. A server MAY refuse to load a zone that has
data at a sub-domain of a domain name owning a BNAME RR or that has
other data except the DNSSEC related resource record types and BNAME
at that name. BNAME is a singleton type, meaning only one BNAME is
allowed per name except the DNSSEC related resource record types.
Resolvers, servers and zone content administrators should be cautious
that usage of BNAME or its combination with CNAME or DNAME may lead
to form loops. The loops should be avoided.
1.1. Terminology
All the basic terms used in this specification are defined in the
documents [RFC1034], [RFC1035] and [RFC2672].
2. Motivation
In some languages, some characters have the variants, which look
differently or very similar but are identical in the meaning. For
example, Chinese character U+56FD and its variant U+570B look
differently, but are identical in the meaning. If Internationalized
Domain Label" or "IDL" [RFC3743] are composed of variant characters,
we regard this kind of IDL as the IDL variant. If these IDL variants
are put into the DNS for resolution, they are expected to be
identical in the DNS resolution. More comprehensible example is that
we expect color.exmaple.com to be equivalent with the
colour.exmaple.com in the DNS resolution. The BNAME Resource Record
and its processing rules are conceived as a solution to this
equivalence problem. Without the BNAME mechanism, current mechanisms
such as DNAME or CNAME are not enough capable to solve all the
problems with the emergence of internationalized domain names. The
internationalized domain names may have alias or equivalence of the
Yao, et al. Expires February 20, 2011 [Page 3]
Internet-Draft bname August 2010
original one. The BNAME solution provides the solution to both ASCII
alias names and internationalized domain alias names.
3. The BNAME Resource Record
3.1. Format
The BNAME RR has mnemonic BNAME and type code xx (decimal). It is
not class-sensitive. Its RDATA is comprised of a single field,
<target>, which contains a fully qualified domain name that must be
sent in uncompressed form [RFC1035], [RFC3597]. The <target> field
MUST be present. The presentation format of <target> is that of a
domain name [RFC1035]. The wildcards in the BNAME RR SHOULD NOT be
used.
<owner> <ttl> <class> BNAME <target>
The effect of the BNAME RR is the substitution of the record's
<target> for its owner name, as a suffix of a domain name. This
substitution has to be applied for every BNAME RR found in the
resolution process, which allows fairly lengthy valid chains of BNAME
RRs.
3.2. The BNAME Substitution
A BNAME substitution is performed by replacing the suffix labels of
the name being sought matching the owner name of the BNAME resource
record with the string of labels in the RDATA field. The matching
labels end with the root label in all cases. Only whole labels are
replaced.
3.3. The BNAME Rules
There are two rules which governs the use of BNAMEs in a zone file.
The first one is that there SHOULD be no descendants under the owner
of the BNAME. The second one is that no resource records can co-
exist with the BNAME for the same name except the DNSSEC related
resource record types. It means that if a BNAME RR is present at a
node N, there MUST be no other data except the DNSSEC related
resource record types at N and no data at any descendant of N. This
restriction applies only to records of the same class as the BNAME
record.
3.4. BNAME Examples
The table below shows some examples of the BNAME usage.
Yao, et al. Expires February 20, 2011 [Page 4]
Internet-Draft bname August 2010
QNAME owner BNAME target result
---------------- -------------- -------------- -----------------
com. example.com. example.net. <no match>
com. com. net. net.
example.com. example.com. example.net. example.net.
a.example.com. example.com. example.net. a.example.net.
a.b.example.com. example.com. example.net. a.b.example.net.
ab.example.com. b.example.com. example.net. <no match>
bar.example.com. example.com. example.net. bar.example.net.
a.b.example.com. b.example.com. example.net. a.example.net.
a.example.com. example.com. b.example.net. a.b.example.net.
Table 1. BNAME Usage Examples.
If the owner name of the CNAME RR is regarded as the target of the MX
RR, it may cause some problems. Some mail servers may directly
connect the owner name of the CNAME instead of the name pointed by
CNAME for mail delivery and cause the undelivery of the mails. BNAME
has the similar problems with CNAME. This document specifies that
the owner name of the BNAME should not be the targets of some RRs
such as MX, SRV and PTR. In case that the owner name of the BNAME RR
is the target of some RRs, it should be cautious.
4. Query Processing
To exploit the BNAME mechanism the name resolution algorithms
[RFC1034] must be modified slightly for both servers and resolvers.
Both modified algorithms incorporate the operation of making a
substitution on a name (either QNAME or SNAME) under control of a
BNAME record. This operation will be referred to as "the BNAME
substitution".
4.1. Processing by Servers
For a server performing non-recursive service steps 3.a, 3.c and 4 of
section 4.3.2 [RFC1034] are changed to check for a BNAME record, and
to return certain BNAME records from zone data and the cache.
If the owner name of the bname is the suffix of the name queryed but
different, when preparing a response, a server performing a BNAME
substitution will in all cases include the relevant BNAME RR in the
answer section. A CNAME RR is synthesized and included in the answer
section. This will help the client to reach the correct DNS data.
If the owner name of the bname is same with the name queryed, when
preparing a response, a server performing a BNAME substitution will
Yao, et al. Expires February 20, 2011 [Page 5]
Internet-Draft bname August 2010
not include the relevant BNAME RR in the answer section unless the
type queryed is BNAME. A CNAME RR will be synthesized and included
in the answer section unless the type queryed is BNAME.
The provided synthesized CNAME RR if there has one, MUST have
The same CLASS as the QCLASS of the query,
TTL equal to the corresponding BNAME RR,
An <owner> equal to the QNAME in effect at the moment the BNAME RR
was encountered, and
An RDATA field containing the new QNAME formed by the action of
the BNAME substitution.
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.
3. Start matching down, label by label, in the zone. The matching
process can terminate several ways:
Yao, et al. Expires February 20, 2011 [Page 6]
Internet-Draft bname August 2010
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.
If the data at the node is a BNAME, and QTYPE doesn't
match BNAME, copy the BNAME RR and also a corresponding,
synthesized CNAME RR into the answer section of the
response, change QNAME to the name carried as RDATA in
the BNAME 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 BNAME record.
If a BNAME 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 [RFC2136] and exit; otherwise
perform the substitution and continue. The server SHOULD
synthesize a corresponding CNAME record as described above and
include it in the answer section. Go back to step 1.
If there was no BNAME 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.
Yao, et al. Expires February 20, 2011 [Page 7]
Internet-Draft bname August 2010
If the "*" label does exist, match RRs at that node against
QTYPE. If any match, copy them into the answer section, but
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 BNAME record is
present at QNAME, copy that BNAME 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 BNAMEs, 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 BNAME 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 BNAME record is encountered.
4.2. Processing by Resolvers
A resolver or a server providing recursive service must be modified
to treat a BNAME as somewhat analogous to a CNAME. The resolver
algorithm of [RFC1034] section 5.3.3 is modified to renumber step 4.d
as 4.e and insert a new 4.d. The complete algorithm becomes:
Yao, et al. Expires February 20, 2011 [Page 8]
Internet-Draft bname August 2010
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.
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 BNAME and that is not the answer
itself, cache the BNAME. If substitution of the BNAME'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 BNAME 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 BNAME record in the response.
5. BNAME in DNSSEC
5.1. BNAME validating
With the deployment of DNSSEC, more and more servers and resolvers
will support DNSSEC. In order to make BNAME valid in DNSSEC
verification, the DNSSEC enabled resolvers and servers MUST support
BNAME. The synthesized CNAME in the answer section for the BNAME
will never be signed if there has one.
If the owner name of the bname is the suffix of the name queryed but
Yao, et al. Expires February 20, 2011 [Page 9]
Internet-Draft bname August 2010
different, DNSSEC validators MUST understand BNAME, verify the BNAME
and then checking that the CNAME was properly synthesized in order to
verify the synthesized CNAME.
If the owner name of the bname is same with the name queryed, DNSSEC
validators MUST understand BNAME and verify the BNAME. The BNAME
enabled resolver (validator) should do somewhat analogous to a CNAME
for further query.
In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
map SHOULD be checked to see that there was no BNAME that could have
been applied. If the BNAME bit in the type bit map is set and the
query type is not BNAME, then BNAME substitution should have been
done.
5.2. BNAME alias algorithm identifiers
In order to prevent BNAME-unaware resolvers from attempting to
validate responses from BNAME-signed zones, this specification
allocates two new DNSKEY algorithm identifiers. Algorithm Y, DSA-
BNAME-SHA1 is an alias for algorithm 3, DSA. Algorithm Z, RSASHA1-
BNAME-SHA1 is an alias for algorithm 5, RSASHA1. These are not new
algorithms, they are additional identifiers for the existing
algorithms. Zones signed according to this specification MUST only
use these algorithm identifiers for their DNSKEY RRs. The BNAME-
unaware resolvers will not know these new identifiers and treat
responses from the BNAME signed zone as insecure, otherwise the bname
RR will be regarded as bogus if there is no such a mechanism. These
algorithm identifiers are used with the BNAME hash algorithm SHA1.
Using other BNAME hash algorithms requires allocation of a new alias.
Validating resolvers which follow the BNAME specification MUST
recognize the new alias algorithm identifier. The future new DNSSEC
algorithms are suggested to indicate the support of BNAME.
5.3. Signaling of BNAME
A new UB (Understand BNAME) bit in the EDNS flags field [RFC2671]can
be used to signal that the resolvers can understand BNAME in DNSSEC.
BNAME aware resolvers can set the Understand-BNAME (UB bit) to
receive a response without the synthesized CNAMEs. The UB bit is
part of the EDNS extended RCODE and Flags field[RFC2671]. Resolvers
should set this in a query to request omission of the synthesized
CNAMEs.
If the query is a DNSSEC query, the BNAME enabled resolvers MUST set
the UB bit in the query. The server receiving the UB bit MUST not
issue synthesized CNAMEs. Servers copy the UB bit to the response,
and should delete the synthesized CNAMEs from the answer if there has
Yao, et al. Expires February 20, 2011 [Page 10]
Internet-Draft bname August 2010
one.
If the query is the DNSSEC query but the UB bit is not set, the
server should follow the rules below:
o If the owner name of the bname is the suffix of the name queryed
but different, when preparing a response, a server performing a
BNAME substitution will in all cases include the relevant BNAME RR
in the answer section. An unsigned CNAME RR is synthesized and
included in the answer section. This will help the client to
reach the correct DNS data.
o If the owner name of the bname is same with the name queryed, when
preparing a response, a DNSSEC enabled server performing a BNAME
substitution will not include the relevant BNAME RR and its RRSIG
RR in the answer section unless the type queryed is BNAME. An
unsigned CNAME RR will be synthesized and included in the answer
section unless the type queryed is BNAME.
o Since the BNAME-unaware DNSSEC resolvers do not know the alias
algorithm defined in secton 5.2 of this document, any response
from these zones signed with these alias algorithms unknown to
them will be regarded as the insecure one according to section 5.2
of [RFC4035].
Below are Updated EDNS extended RCODE and Flags fields [RFC2671]:
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|UB| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6. IANA Considerations
IANA is requested to assign the number to XX. This document updates
the IANA registry "DNS SECURITY ALGORITHM NUMBERS". IANA is
requested to assign the number to Y and Z.
[[anchor15: Note in draft: before this document goes to WG Last call,
it is better that we list all DNSSEC algorithms that need to be
aliased to reflect compatibility with this extension.]]
Yao, et al. Expires February 20, 2011 [Page 11]
Internet-Draft bname August 2010
7. Security Considerations
Both ASCII domain name labels and non-ASCII ones have some aliases.
We can bundle the domain name labels and their aliases through BNAME
in the DNS resolutions. The name labels and their aliases in the
particular languages are only known by those who know these
languages. Those labels may be regarded as different ones by those
who don't know those languages. Those who do not know the aliases
should only use the familar ones. The applications will not know the
aliases unless they are properly configured.
8. Acknowledgements
Because the BNAME is very similar to DNAME, the authors learn a lot
from [RFC2672]. Many ideas are from the discussion in the DNSOP and
DNSEXT mailling list. Thanks a lot to all in the list. Many
important comments and suggestions are contributed by many members of
the DNSEXT and DNSOP WGs. The authors especially thanks the
following ones:Niall O'Reilly, Glen Zorn, Mark Andrews, George
Barwood,Olafur Gudmundsson, Sun Guonian and Hanfeng for improving
this document.
9. Change History
[[anchor18: RFC Editor: Please remove this section.]]
9.1. draft-yao-dnsext-bname: Version 00
o Bundle DNS Name Redirection
9.2. draft-yao-dnsext-bname: Version 01
o Improve the algorithm
o Improve the text
9.3. draft-yao-dnsext-bname: Version 02
o Add the DNSSEC discussion
o Improve the text
9.4. draft-yao-dnsext-bname: Version 03
o Update the DNSSEC discussion
o Update the IANA consideration
Yao, et al. Expires February 20, 2011 [Page 12]
Internet-Draft bname August 2010
9.5. draft-yao-dnsext-bname: Version 04
o Improve the text
9.6. draft-yao-dnsext-bname: Version 05
o add section: bname examples
o add section: Signaling of BNAME
10. References
10.1. Normative References
[ASCII] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, 1968.
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
Yao, et al. Expires February 20, 2011 [Page 13]
Internet-Draft bname August 2010
10646", RFC 3629, November 2003.
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
Engineering Team (JET) Guidelines for Internationalized
Domain Names (IDN) Registration and Administration for
Chinese, Japanese, and Korean", RFC 3743, April 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
10.2. Informative References
[RFC2672bis]
Rose, S. and W. Wijngaards, "Update to DNAME Redirection
in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname-
17.txt, 6 2009.
Authors' Addresses
Jiankang YAO
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813007
Email: yaojk@cnnic.cn
Yao, et al. Expires February 20, 2011 [Page 14]
Internet-Draft bname August 2010
Xiaodong LEE
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813020
Email: lee@cnnic.cn
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA
Phone: +1 650 779 7001
Email: vixie@isc.org
Yao, et al. Expires February 20, 2011 [Page 15]

68
doc/draft/update
View File

@@ -1,68 +0,0 @@
#!/bin/sh
commit=
if type fetch >/dev/null 2>&1
then
fetch=fetch
elif type curl >/dev/null 2>&1
then
fetch="curl -L -O"
else
exit 1
fi
for i
do
z=
case $i in
http://tools.ietf.org/html/*|http://www.ietf.org/internet-drafts/*|http://www.ietf.org/id/*)
z=`expr "$i" : 'http://.*/.*/\(.*\)'`
;;
*://*/*)
echo -n "unknown uri $i"
continue;
esac
if test -n "$z"
then
case $z in
*-[0-9][0-9]) z="$z.txt"''
esac
i="$z"
fi
if test -f "$i"
then
continue
fi
pat=`echo "$i" | sed 's/...txt/??.txt/'`
old=`echo $pat 2> /dev/null`
if test "X$old" != "X$pat"
then
newer=0
for j in $old
do
if test $j ">" $i
then
newer=1
fi
done
if test $newer = 1
then
continue;
fi
fi
if $fetch "http://www.ietf.org/id/$i"
then
git add "$i"
if test "X$old" != "X$pat"
then
rm $old
git rm $old
commit="$commit $old"
fi
commit="$commit $i"
fi
done
if test -n "$commit"
then
git commit -m "new draft"
git push
fi

905
doc/expired/draft-duerst-dns-i18n-02.txt
View File

@@ -1,905 +0,0 @@
Internet Draft M. Duerst
<draft-duerst-dns-i18n-02.txt> Keio University
Expires in six months July 1998
Internationalization of Domain Names
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing 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 ftp.ietf.org (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this document is unlimited. Please send comments to
the author at <mduerst@w3.org>.
Abstract
Internet domain names are currently limited to a very restricted
character set. This document proposes the introduction of a new
"zero-level" domain (ZLD) to allow the use of arbitrary characters
from the Universal Character Set (ISO 10646/Unicode) in domain names.
The proposal is fully backwards compatible and does not need any
changes to DNS. Version 02 is reissued without changes just to
keep this draft available.
Table of contents
0. Change History ................................................. 2
0.8 Changes Made from Version 01 to Version 02 .................. 2
0.9 Changes Made from Version 00 to Version 01 .................. 2
1. Introduction ................................................... 3
1.1 Motivation .................................................. 3
Expires End of January 1998 [Page 1]
Internet Draft Internationalization of Domain Names July 1997
1.2 Notational Conventions ...................................... 4
2. The Hidden Zero Level Domain ................................... 4
3. Encoding International Characters .............................. 5
3.1 Encoding Requirements ....................................... 5
3.2 Encoding Definition ......................................... 5
3.3 Encoding Example ............................................ 7
3.4 Length Considerations ....................................... 8
4. Usage Considerations ........................................... 8
4.1 General Usage ............................................... 8
4.2 Usage Restrictions .......................................... 9
4.3 Domain Name Creation ....................................... 10
4.4 Usage in URLs .............................................. 12
5. Alternate Proposals ........................................... 13
5.1 The Dillon Proposal ........................................ 13
5.2 Using a Separate Lookup Service ............................ 13
6. Generic Considerations ........................................ 14
5.1 Security Considerations .................................... 14
5.2 Internationalization Considerations ........................ 14
Acknowledgements ................................................. 14
Bibliography ..................................................... 15
Author's Address .................................................=
16
0. Change History
0.8 Changes Made from Version 01 to Version 02
No significant changes; reissued to make it available officially.
Changed author's address.
Changes deferred to future versions (if ever):
- Decide on ZLD name (.i or .i18n.int or something else)
- Decide on casing solution
- Decide on exact syntax
- Proposals for experimental setup
0.9 Changes Made from Version 00 to Version 01
Expires End of January 1998 [Page 2]
Internet Draft Internationalization of Domain Names July 1997
- Minor rewrites and clarifications
- Added the following references: [RFC1730], [Kle96], [ISO3166],
[iNORM]
- Slightly expanded discussion about casing
- Added some variant proposals for syntax
- Added some explanations about different kinds of name parallelism
- Added some explanation about independent addition of internation-
alized names in subdomains without bothering higher-level domains
- Added some explanations about tools needed for support, and the
MX/CNAME problem
- Change to RFC1123 (numbers allowed at beginning of labels)
1. Introduction
1.1 Motivation
The lower layers of the Internet do not discriminate any language or
script. On the application level, however, the historical dominance
of the US and the ASCII character set [ASCII] as a lowest common
denominator have led to limitations. The process of removing these
limitations is called internationalization (abbreviated i18n). One
example of the abovementioned limitations are domain names [RFC1034,
RFC1035], where only the letters of the basic Latin alphabet (case-
insensitive), the decimal digits, and the hyphen are allowed.
While such restrictions are convenient if a domain name is intended
to be used by arbitrary people around the globe, there may be very
good reasons for using aliases that are more easy to remember or type
in a local context. This is similar to traditional mail addresses,
where both local scripts and conventions and the Latin script can be
used.
There are many good reasons for domain name i18n, and some arguments
that are brought forward against such an extension. This document,
however, does not discuss the pros and cons of domain name i18n. It
proposes and discusses a solution and therefore eliminates one of the
Expires End of January 1998 [Page 3]
Internet Draft Internationalization of Domain Names July 1997
most often heard arguments agains, namely "it cannot be done".
The solution proposed in this document consists of the introduction
of a new "zero-level" domain building the root of a new domain
branch, and an encoding of the Universal Character Set (UCS)
[ISO10646] into the limited character set of domain names.
1.2 Notational Conventions
In the domain name examples in this document, characters of the basic
Latin alphabet (expressible in ASCII) are denoted with lower case
letters. Upper case letters are used to represent characters outside
ASCII, such as accented characters of the Latin alphabet, characters
of other alphabets and syllabaries, ideographic characters, and vari-
ous signs.
2. The Hidden Zero Level Domain
The domain name system uses the domain "in-addr.arpa" to convert
internet addresses back to domain names. One way to view this is to
say that in-addr.arpa forms the root of a separate hierarchy. This
hierarchy has been made part of the main domain name hierarchy just
for implementation convenience. While syntactically, in-addr.arpa is
a second level domain (SLD), functionally it is a zero level domain
(ZLD) in the same way as "." is a ZLD. A similar example of a ZLD is
the domain tpc.int, which provides a hierarchy of the global phone
numbering system [RFC1530] for services such as paging and printing
to fax machines.
For domain name i18n to work inside the tight restrictions of domain
name syntax, one has to define an encoding that maps strings of UCS
characters to strings of characters allowable in domain names, and a
means to distinguish domain names that are the result of such an
encoding from ordinary domain names.
This document proposes to create a new ZLD to distinguish encoded
i18n domain names from traditional domain names. This domain would
be hidden from the user in the same way as a user does not see in-
addr.arpa. This domain could be called "i18n.arpa" (although the use
of arpa in this context is definitely not appropriate), simply
"i18n", or even just "i". Below, we are using "i" for shortness,
while we leave the decision on the actual name to further=
discussion.
Expires End of January 1998 [Page 4]
Internet Draft Internationalization of Domain Names July=
1997
3. Encoding International Characters
3.1 Encoding Requirements
Until quite recently, the thought of going beyond ASCII for something
such as domain names failed because of the lack of a single encom-
passing character set for the scripts and languages of the world.
Tagging techniques such as those used in MIME headers [RFC1522] would
be much too clumsy for domain names.
The definition of ISO 10646 [ISO10646], codepoint by codepoint iden-
tical with Unicode [Unicode], provides a single Universal Character
Set (UCS). A recent report [RFCIAB] clearly recommends to base the
i18n of the Internet on these standards.
An encoding for i18n domain names therefore has to take the charac-
ters of ISO 10646/Unicode as a starting point. The full four-byte
(31 bit) form of UCS, called UCS4, should be used. A limitation to
the two-byte form (UCS2), which allows only for the encoding of the
Base Multilingual Plane, is too restricting.
For the mapping between UCS4 and the strongly limited character set
of domain names, the following constraints have to be considered:
- The structure of domain names, and therefore the "dot", have to be
conserved. Encoding is done for individual labels.
- Individual labels in domain names allow the basic Latin alphabet
(monocase, 26 letters), decimal digits, and the "-" inside the
label. The capacity per octet is therefore limited to somewhat
above 5 bits.
- There is no need nor possibility to preserve any characters.
- Frequent characters (i.e. ASCII, alphabetic, UCS2, in that order)
should be encoded relatively compactly. A variable-length encoding
(similar to UTF-8) seems desirable.
3.2 Encoding Definition
Several encodings for UCS, so called UCS Transform Formats, exist
Expires End of January 1998 [Page 5]
Internet Draft Internationalization of Domain Names July 1997
already, namely UTF-8 [RFC2044], UTF-7 [RFC1642], and UTF-16 [Uni-
code]. Unfortunately, none of them is suitable for our purposes. We
therefore use the following encoding:
- To accommodate the slanted probability distribution of characters
in UCS4, a variable-length encoding is used.
- Each target letter encodes 5 bits of information. Four bits of
information encode character data, the fifth bit is used to indi-
cate continuation of the variable-length encoding.
- Continuation is indicated by distinguishing the initial letter
from the subsequent letter.
- Leading four-bit groups of binary value 0000 of UCS4 characters
are discarded, except for the last TWO groups (i.e. the last
octet). This means that ASCII and Latin-1 characters need two
target letters, the main alphabets up to and including Tibetan
need three target letters, the rest of the characters in the BMP
need four target letters, all except the last (private) plane in
the UTF-16/Surrogates area [Unicode] need five target letters, and
so on.
- The letters representing the various bit groups in the various
positions are chosen according to the following table:
Nibble Value Initial Subsequent
Hex Binary
0 0000 G 0
1 0001 H 1
2 0010 I 2
3 0011 J 3
4 0100 K 4
5 0101 L 5
6 0110 M 6
7 0111 N 7
8 1000 O 8
9 1001 P 9
A 1010 Q A
B 1011 R B
C 1100 S C
D 1101 T D
E 1110 U E
F 1111 V F
[Should we try to eliminate "I" and "O" from initial? "I" might be
Expires End of January 1998 [Page 6]
Internet Draft Internationalization of Domain Names July 1997
eliminated because then an algorithm can more easily detect ".i". "O"
could lead to some confusion with "0". What other protocols are
there that might be able to use a similar solution, but that might
have other restrictions for the initial letters? Proposal to run ini-
tial range from H to X. Extracting the initial bits then becomes ^
'H'. Proposal to have a special convention for all-ASCII labels
(start label with one of the letters not used above).]
Please note that this solution has the following interesting proper-
ties:
- For subsequent positions, there is an equivalence between the hex-
adecimal value of the character code and the target letter used.
This assures easy conversion and checking.
- The absence of digits from the "initial" column, and the fact that
the hyphen is not used, assures that the resulting string conforms
to domain name syntax.
- Raw sorting of encoded and unencoded domain names is equivalent.
- The boundaries of characters can always be detected easily.
(While this is important for representations that are used inter-
nally for text editing, it is actually not very important here,
because tools for editing can be assumed to use a more straight-
forward representation internally.)
- Unless control characters are allowed, the target string will
never actually contain a G.
3.3 Encoding Example
As an example, the current domain
is.s.u-tokyo.ac.jp
with the components standing for information science, science, the
University of Tokyo, academic, and Japan, might in future be repre-
sented by
JOUHOU.RI.TOUDAI.GAKU.NIHON
(a transliteration of the kanji that might probably be chosen to rep-
resent the same domain). Writing each character in U+HHHH notation as
in [Unicode], this results in the following (given for reference
Expires End of January 1998 [Page 7]
Internet Draft Internationalization of Domain Names July 1997
only, not the actual encoding or something being typed in by the
user):
U+60c5U+5831.U+7406.U+6771U+5927.U+5b66.U+65e5U+672c
The software handling internationalized domain names will translate
this, according to the above specifications, before submitting it to
the DNS resolver, to:
M0C5L831.N406.M771L927.LB66.M5E5M72C.i
3.4 Length Considerations
DNS allows for a maximum of 63 positions in each part, and for 255
positions for the overall domain name including dots. This allows up
to 15 ideographs, or up to 21 letters e.g. from the Hebrew or Arabic
alphabet, in a label. While this does not allow for the same margin
as in the case of ASCII domain names, it should still be quite suffi-
cient. [Problems could only surface for languages that use very long
words or terms and don't know any kind of abbreviations or similar
shortening devices. Do these exist? Islandic expert asserted
Islandic is not a problem.] DNS contains a compression scheme that
avoids sending the same trailing portion of a domain name twice in
the same transmission. Long domain names are therefore not that much
of a concern.
4. Usage Considerations
4.1 General Usage
To implement this proposal, neither DNS servers nor resolvers need
changes. These programs will only deal with the encoded form of the
domain name with the .i suffix. Software that wants to offer an
internationalized user interface (for example a web browser) is
responsible for the necessary conversions. It will analyze the domain
name, call the resolver directly if the domain name conforms to the
domain name syntax restrictions, and otherwise encode the name
according to the specifications of Section 3.2 and append the .i suf-
fix before calling the resolver. New implementations of resolvers
will of course offer a companion function to gethostbyname accepting
a ISO10646/Unicode string as input.
Expires End of January 1998 [Page 8]
Internet Draft Internationalization of Domain Names July 1997
For domain name administrators, them main tool that will be needed is
a program to compile files configuring zones from an UTF-8 notation
(or any other suitable encoding) to the encoding described in Section
3.3. Utility tools will include a corresponding decompiler, checkers
for various kinds of internationalization-related errors, and tools
for managing syntactic parallelism (see Section 4.3).
4.2 Usage Restrictions
While this proposal in theory allows to have control characters such
as BEL or NUL or symbols such as arrows and smilies in domain names,
such characters should clearly be excluded from domain names. Whether
this has to be explicitly specified or whether the difficulty to type
these characters on any keyboard of the world will limit their use
has to be discussed. One approach is to start with a very restricted
subset and gradually relax it; the other is to allow almost anything
and to rely on common sense. Anyway, such specifications should go
into a separate document to allow easy updates.
A related point is the question of equivalence. For historical rea-
sons, ISO 10646/Unicode contain considerable number of compatibility
characters and allow more than one representation for characters with
diacritics. To guarantee smooth interoperability in these and related
cases, additional restrictions or the definition of some form of nor-
malization seem necessary. However, this is a general problem
affecting all areas where ISO 10646/Unicode is used in identifiers,
and should therefore be addressed in a generic way. See [iNORM] for
an initial proposal.
Equally related is the problem of case equivalence. Users can very
well distinguish between upper case and lower case. Also, casing in
an i18n context is not as straightforward as for ASCII, so that case
equivalence is best avoided. Problems therefore result not from the
fact that case is distinguished for i18n domain names, but from the
fact that existing domain names do not distinguish case. Where it is
impossible to distinguish between next.com and NeXT.com, the same two
subdomains would easily be distinguishable if subordinate to a i18n
domain. There are several possible solutions. One is to try to grad-
ually migrate from a case-insensitive solution to a case-sensitive
solution even for ASCII. Another is to allow case-sensitivity only
beyond ASCII. Another is to restrict anything beyond ASCII to lower-
case only (lowercase distinguishes better than uppercase, and is also
generally used for ASCII domain names).
A problem that also has to be discussed and solved is bidirectional-
ity. Arabic and Hebrew characters are written right-to-left, and the
Expires End of January 1998 [Page 9]
Internet Draft Internationalization of Domain Names July 1997
mixture with other characters results in a divergence between logical
and graphical sequence. See [HTML-I18N] for more explanations. The
proposal of [Yer96] for dealing with bidirectionality in URLs could
probably be applied to domain names. Anyway, there should be a gen-
eral solution for identifiers, not a DNS-specific solution.
4.3 Domain Name Creation
The ".i" ZLD should be created as such to allow the internationaliza-
tion of domain names. Rules for creating subdomains inside ".i"
should follow the established rules for the creation of functionally
equivalent domains in the existing domain hierarchy, and should
evolve in parallel.
For the actual domain hierarchy, the amount of parallelism between
the current ASCII-oriented hierarchy and some internationalized hier-
archy depends on various factors. In some cases, two fully parallel
hierarchies may emerge. In other cases, if more than one script or
language is used locally, more than two parallel hierarchies may
emerge. Some nodes, e.g. in intranets, may only appear in an i18n
hierarchy, whereas others may only appear in the current hierarchy.
In some cases, the pecularities of scripts, languages, cultures, and
the local marketplace may lead to completely different hierarchies.
Also, one has to be aware that there may be several kinds of paral-
lelisms. The first one is called syntactic parallelism. If there is
a domain XXXX.yy.zz and a domain vvvv.yy.zz, then the domain yy.zz
will have to exist both in the traditional DNS hierarchy as well as
within the hierarchy starting at the .i ZLD, with appropriate encod-
ing.
The second type of parallelism is called transcription parallelism.
It results by transcribing or transliterating relations between ASCII
domain names and domain names in other scripts.
The third type of parallelism is called semantic parallelism. It
results from translating elements of a domain name from one language
to another, possibly also changing the script or set of used charac-
ters.
On the host level, parallelism means that there are two names for the
same host. Conventions should exist to decide whether the parallel
names should have separate IP addresses or not (A record or CNAME
record). With separate IP addresses, address to name lookup is easy,
otherwise it needs special precautions to be able to find all names
corresponding to a given host address. Another detail entering this
Expires End of January 1998 [Page 10]
Internet Draft Internationalization of Domain Names July 1997
consideration is that MX records only work for hostnames/domains,
not for CNAME aliases. This at least has the consequence that alias
resolution for internationalized mail addresses has to occur before
MX record lookup.
When discussing and applying the rules for creating domain names,
some peculiarities of i18n domain names should be carefully consid-
ered:
- Depending on the script, reasonable lengths for domain name parts
may differ greatly. For ideographic scripts, a part may often be
only a one-letter code. Established rules for lengths may need
adaptation. For example, a rule for country TLDs could read: one
ideographic character or two other characters.
- If the number of generic TLDs (.com, .edu, .org, .net) is kept
low, then it may be feasible to restrict i18n TLDs to country
TLDs.
- There are no ISO 3166 [ISO3166] two-letter codes in scripts other
than Latin. I18n domain names for countries will have to be
designed from scratch.
- The names of some countries or regions may pose greater political
problems when expressed in the native script than when expressed
in 2-letter ISO 3166 codes.
- I18n country domain names should in principle only be created in
those scripts that are used locally. There is probably little use
in creating an Arabic domain name for China, for example.
- In those cases where domain names are open to a wide range of
applicants, a special procedure for accepting applications should
be used so that a reasonable-quality fit between ASCII domain
names and i18n domain names results where desired. This would
probably be done by establishing a period of about a month for
applications inside a i18n domain newly created as a parallel for
an existing domain, and resolving the detected conflicts. For
syntactically parallel domain names, the owners should always be
the same. Administration may be split in some cases to account for
the necessary linguistic knowledge. For domain names with tran-
scription parallelism and semantic parallelism, the question of
owner identity should depend on the real-life situation (trade-
marks,...).
- It will be desirable to have internationalized subdomains in non-
internationalized TLDs. As an example, many companies in France
may want to register an accented version of their company name,
Expires End of January 1998 [Page 11]
Internet Draft Internationalization of Domain Names July 1997
while remaining under the .fr TLD. For this, .fr would have to be
reregistered as .M6N2.i. Accented and other internationalized sub-
domains would go below .M6N2.i, whereas unaccented ones would go
below .fr in its plain form.
- To generalize the above case, one may need to create a requirement
that any domain name registry would have to register and manage
syntactically parallel domain names below the .i ZLD upon request
to allow registration of i18n domain names in arbitrary subdo-
mains. An alternative to this is to organize domain name search
so that e.g. in a search for XXXXXX.fr, if M6N2.i is not found in
.i, the name server for .fr is queried for XXXXXX.M6N2.i (with
XXXXXX appropriately encoded). This convention would allow lower-
level domains to introduce internationalized subdomains without
depending on higher-level domains.
4.4 Usage in URLs
According to current definitions, URLs encode sequences of octets
into a sequence of characters from a character set that is almost as
limited as the character set of domain names [RFC1738]. This is
clearly not satisfying for i18n.
Internationalizing URLs, i.e. assigning character semantics to the
encoded octets, can either be done separately for each part and/or
scheme, or in an uniform way. Doing it separately has the serious
disadvantage that software providing user interfaces for URLs in gen-
eral would have to know about all the different i18n solutions of the
different parts and schemes. Many of these solutions may not even be
known yet.
It is therefore definitely more advantageous to decide on a single
and consistent solution for URL internationalization. The most valu-
able candidate [Yer96], for many reasons, is UTF-8 [RFC2044], an
ASCII-compatible encoding of UCS4.
Therefore, an URL containing the domain name of the example of Sec-
tion 3.3 should not be written as:
ftp://M0C5L831.N406.M771L927.LB66.M5E5M72C.i
(although this will also work) but rather
ftp://%e6%83%85%e5%a0%b1.%e7%90%86.%e6%9d%b1%e5%a4%a7.
%e5%ad%a6.%e6%97%a5%e6%9c%ac
Expires End of January 1998 [Page 12]
Internet Draft Internationalization of Domain Names July 1997
In this canonical form, the trailing .i is absent, and the octets can
be reconstructed from the %HH-encoding and interpreted as UTF-8 by
generic URL software. The software part dealing with domain names
will carry out the conversion to the .i form.
5. Alternate Proposals
5.1 The Dillon Proposal
The proposal of Michael Dillon [Dillon96] is also based on encoding
Unicode into the limited character set of domain names. Distinction
is done for each part, using the hyphen in initial position. Because
this does not fully conform to the syntax of existing domain names,
it is questionable whether it is backwards-compatible. On the other
hand, this has the advantage that local i18n domain names can be
installed easily without cooperation by the manager of the superdo-
main.
A variable-length scheme with base 36 is used that can encode up to
1610 characters, absolutely insufficient for Chinese or Japanese.
Characters assumed not to be used in i18n domain names are excluded,
i.e. only one case is allowed for basic Latin characters. This means
that large tables have to be worked out carefully to convert between
ISO 10646/Unicode and the actual number that is encoded with base=
36.
5.2 Using a Separate Lookup Service
Instead of using a special encoding and burdening DNS with i18n, one
could build and use a separate lookup service for i18n domain names.
Instead of converting to UCS4 and encoding according to Section 3.2,
and then calling the DNS resolver, a program would contact this new
service when seeing a domain name with characters outside the allowed
range.
Such solutions have various problems. There are many directory ser-
vices and proposals for how to use them in a way similar to DNS. For
an overview and a specific proposal, see [Kle96]. However, while
there are many proposals, a real service containing the necessary
data and providing the wide installed base and distributed updating
is in DNS does not exist.
Most directory service proposals also do not offer uniqueness.
Defining unique names again for a separate service will duplicate
much of the work done for DNS. If uniqueness is not guaranteed, the
Expires End of January 1998 [Page 13]
Internet Draft Internationalization of Domain Names July 1997
user is bundened with additional selection steps.
Using a separate lookup service for the internationalization of
domain names also results in more complex implementations than the
proposal made in this draft. Contrary to what some people might
expect, the use of a separate lookup service also does not solve a
capacity problem with DNS, because there is no such problem, nor will
one be created with the introduction of i18n domain names.
6. Generic Considerations
6.1 Security Considerations
This proposal is believed not to raise any other security considera-
tions than the current use of the domain name system.
6.2 Internationalization Considerations
This proposal addresses internationalization as such. The main addi-
tional consideration with respect to internationalization may be the
indication of language. However, for concise identifiers such as
domain names, language tagging would be too much of a burden and
would create complex dependencies with semantics.
NOTE -- This section is introduced based on a recommenda-
tion in [RFCIAB]. A similar section addressing internation-
alization should be included in all application level
internet drafts and RFCs.
Acknowledgements
I am grateful in particular to the following persons for their advice
or criticism: Bert Bos, Lori Brownell, Michael Dillon, Donald E.
Eastlake 3rd, David Goldsmith, Larry Masinter, Ryan Moats, Keith
Moore, Thorvardur Kari Olafson, Erik van der Poel, Jurgen Schwertl,
Paul A. Vixie, Francois Yergeau, and others.
Expires End of January 1998 [Page 14]
Internet Draft Internationalization of Domain Names July=
1997
Bibliography
[ASCII] Coded Character Set -- 7-Bit American Standard Code
for Information Interchange, ANSI X3.4-1986.
[Dillon96] M. Dillon, "Multilingual Domain Names", Memra Software
Inc., November 1996 (circulated Dec. 6, 1996 on iahc-
discuss@iahc.org).
[HTML-I18N] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Inter-
nationalization of the Hypertext Markup Language",
Work in progress (draft-ietf-html-i18n-05.txt), August
1996.
[iNORM] M. Duerst, "Normalization of Internationalized Identi-
fiers", draft-duerst-i18n-norm-00.txt, July 1997.
[ISO3166] ISO 3166, "Code for the representation of names of
countries", ISO 3166:1993.
[ISO10646] ISO/IEC 10646-1:1993. International standard -- Infor-
mation technology -- Universal multiple-octet coded
character Set (UCS) -- Part 1: Architecture and basic
multilingual plane.
[Kle96] J. Klensin and T. Wolf, Jr., "Domain Names and Company
Name Retrieval", Work in progress (draft-klensin-tld-
whois-01.txt), November 1996.
[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facili-
ties", ISI, Nov. 1987.
[RFC1035] P. Mockapetris, "Domain Names - Implementation and
Specification", ISI, Nov. 1987.
[RFC1522] K. Moore, "MIME (Multipurpose Internet Mail Exten-
sions) Part Two: Message Header Extensions for Non-
ASCII Text", University of Tennessee, September 1993.
[RFC1642] D. Goldsmith, M. Davis, "UTF-7: A Mail-safe Transfor-
mation Format of Unicode", Taligent Inc., July 1994.
[RFC1730] C. Malamud and M. Rose, "Principles of Operation for
the TPC.INT Subdomain: General Principles and Policy",
Internet Multicasting Service, October 1993.
[RFC1738] T. Berners-Lee, L. Masinter, and M. McCahill,
"Uniform Resource Locators (URL)", CERN, Dec. 1994.
Expires End of January 1998 [Page 15]
Internet Draft Internationalization of Domain Names July 1997
[RFC2044] F. Yergeau, "UTF-8, A Transformation Format of Unicode
and ISO 10646", Alis Technologies, October 1996.
[RFCIAB] C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R.
Atkinson, M. Crispin, P. Svanberg, "Report from the
IAB Character Set Workshop", October 1996 (currently
available as draft-weider-iab-char-wrkshop-00.txt).
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
2.0", Addison-Wesley, Reading, MA, 1996.
[Yer96] F. Yergeau, "Internationalization of URLs", Alis Tech-
nologies,
=
<http://www.alis.com:8085/~yergeau/url-00.html>.
Author's Address
Martin J. Duerst
World Wide Web Consortium
Keio Research Institute at SFC
Keio University
5322 Endo
Fujisawa
252-8520 Japan
Tel: +81 466 49 11 70
E-mail: mduerst@w3.org
NOTE -- Please write the author's name with u-Umlaut wherever
possible, e.g. in HTML as D&uuml;rst.
Expires End of January 1998 [Page 16]

336
doc/expired/draft-dunlap-dns-duxfr-00.txt
View File

@@ -1,336 +0,0 @@
DNSIND Working Group K. Dunlap
INTERNET-DRAFT Check Point Software
<draft-dunlap-dns-duxfr-00.txt> P. Vixie
ISC
September 1999
Dynamic Update Zone Transfer
Copyright (C) The Internet Society (1999). All Rights Reserved.
Status of This Memo
This draft, file name draft-dunlap-dns-duxfr-00.txt, is intended to
become a Proposed Standard RFC. Distribution of this document is unlim-
ited. Comments should be sent to <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 docu-
ments 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 not appropriate 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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document proposes an alternative extension to the DNS protocol for
Incremental zone transfer (IXFR) [RFC1995]. This extension uses the
mechanisms for adding and deleting Resource Records specified in
[RFC2136] to transmit the changes between authoritative servers of a
zone.
Expires March 2000 [Page 1]
INTERNET-DRAFT DNS DUXFR September 1999
1 - Introduction
For rapid propagation of changes to a DNS database [STD13], it is neces-
sary to reduce latency by actively notifying servers of the change.
This is accomplished by the DNS NOTIFY Mechanism [RFC1996].
The simple method described for Incremental transfer (IXFR), in
[RFC1995], does not adequately address the complexity of the problem.
Dynamic Update Zone Transfer (DUXFR), as proposed, is a mechanism to
transmit the complexity of changes in the zone and still have the effi-
ciency of IXFR means to propagate changed portions of a zone.
In this document, a slave name server which requests DUXFR is called a
DUXFR client and a master or slave name server which responds to the
request is called a DUXFR server.
2 - Brief Description of the Protocol
If a DUXFR client, which likely has an older version of a zone, thinks
it needs a newer version of the zone (typically through SOA refresh
timeout or the NOTIFY mechanism), it sends a DUXFR message containing
the SOA serial number of its (presumably outdated) copy of the zone.
A DUXFR server should keep record of the newest version of the zone and
the differences between that copy and several older versions. When a
DUXFR request with an older version number is received, the DUXFR server
needs to send only the differences required to make that version
current. These differences are sent using the DNS UPDATE format packets
for deletes and add specified in [RFC2136 2.5].
When a zone has been updated, it should be saved in stable storage
before the new version is used to respond to DUXFR (or AXFR) queries.
Otherwise, if the server crashes, data which is no longer available may
have been distributed to slave servers, which can cause persistent data-
base inconsistencies.
If a DUXFR 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 IXFR.
The Transport protocol for DUXFR queries is TCP/IP.
Expires March 2000 [Page 2]
INTERNET-DRAFT DNS DUXFR September 1999
3 - Query Format
The DUXFR Query format is based on the standard DNS UPDATE Message For-
mat. In the DNS Packet Header the Opcode is set to UPDATE and the Zone
Type (ZTYPE) being set to AXFR. The Additional section containing the
SOA record of the client's version of the zone.
4 - Response Format
The response packets to the DUXFR query are in the standard DNS UPDATE
Message Format. The records in the Update Section are formatted using
the four sets of semantics for adding and deleting Resource Records
specified in the ``Update Section'' in [RFC2136 2.5]. The client will
process these changes using the prerequisite for the transaction as the
existence of the SOA serial number specified in the Additional section
of the DUXFR query.
The response to a DUXFR query, when the server no longer has all the
previous history from the version the client requests, will be a
Response code (RCODE) of "Refused". It is recommended that the client
retry with an AXFR query described in [RFC1034 4.3.5].
It is recommended that the Prerequisite sections of the DNS message be
empty on transmission and ignored on reception. The Additional section
may contain necessary data such as signatures as specified by other
extensions to [RFC 2136].
5 - Version Overhead
A DUXFR 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 DUXFR.
Information about older versions should be purged if the total length of
a DUXFR response would be longer than that of an AXFR response. Given
that the purpose of DUXFR 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.
Information older than the SOA expire period may also be purged.
6 - IANA Considerations
No IANA services are required by this document.
Expires March 2000 [Page 3]
INTERNET-DRAFT DNS DUXFR September 1999
7 - Security Considerations
DNS is related to several security problems, no attempt is made to fix
them in this document.
The authors believe that this document does not introduce any additional
security problems to the current DNS protocol.
8 - Examples
Given the following three generations of data with the current serial
number of 3.
Example.Com. IN SOA NS.Example.Com. admin.Example.Com.
(
1 600 600 3600000 604800 )
IN NS NS.Example.Com.
NS.Example.Com. IN A 192.168.1.5
Vangogh.Example.Com. IN A 192.168.1.21
Vangogh.Example.Com. is removed and Monet.Example.Com. is added.
Example.Com. IN SOA NS.Example.Com. admin.Example.Com. (
2 600 600 3600000 604800 )
IN NS NS.Example.Com.
NS.Example.Com. IN A 192.168.1.5
Monet.Example.Com. IN A 192.168.6.27
IN A 192.168.3.128
One of the IP address of Monet.Example.Com. is changed.
Example.Com. IN SOA NS.Example.Com. admin.Example.Com. (
3 600 600 3600000 604800 )
IN NS NS.Example.Com.
NS.Example.Com. IN A 192.168.1.5
Monet.Example.Com. IN A 192.168.6.42
IN A 192.168.3.128
Expires March 2000 [Page 4]
INTERNET-DRAFT DNS DUXFR September 1999
The following DUXFR query:
+--------------------------------------------------+
Header | OPCODE=QUERY, QR=Request |
+--------------------------------------------------+
Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR |
+--------------------------------------------------+
Prerequisite | <empty> |
+--------------------------------------------------+
Update | <empty> |
+--------------------------------------------------+
Additional | Example.Com. IN SOA serial=1 |
+--------------------------------------------------+
The reply could be with the following DUXFR response with Update packets
in the Answer Section:
+--------------------------------------------------+
Header | OPCODE=QUERY, QR=Response |
+--------------------------------------------------+
Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR |
+--------------------------------------------------+
Prerequisite | Example.Com. IN SOA serial=1 |
+--------------------------------------------------+
Update | Vangogh.Example.Com. 0 ANY A 192.168.1.21 |
| Monet.Example.Com. IN A 192.168.6.42 |
| Monet.Example.Com. IN A 192.168.3.128 |
| Example.Com. 0 IN SOA serial=1 |
| Example.Com. IN SOA serial=2 |
| Monet.Example.Com. 0 ANY A 192.168.6.42 |
| Example.Com. 0 ANY SOA serial=2 |
| Example.Com. IN SOA serial=3 |
+--------------------------------------------------+
Additional | <empty> |
+--------------------------------------------------+
or with the following Compressed DUXFR response with Update packets in
the Answer Section:
Expires March 2000 [Page 5]
INTERNET-DRAFT DNS DUXFR September 1999
+--------------------------------------------------+
Header | OPCODE=QUERY, QR=Response |
+--------------------------------------------------+
Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR |
+--------------------------------------------------+
Prerequisite | Example.Com. IN SOA serial=1 |
+--------------------------------------------------+
Update | Vangogh.Example.Com. 0 ANY A 192.168.1.21 |
| Monet.Example.Com. IN A 192.168.6.42 |
| Monet.Example.Com. IN A 192.168.3.128 |
| Example.Com. 0 ANY SOA serial=1 |
| Example.Com. IN SOA serial=3 |
+--------------------------------------------------+
Additional | <empty> |
+--------------------------------------------------+
References
[RFC1034]]
P. Mockapetris, ``Domain Names - Concepts and Facilities'' STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[RFC1035]
P. Mockapetris, ``Domain Names - Implementation and Specifica-
tion'' RFC 1035, USC/Information Sciences Institute, November
1987.
[RFC1996]
P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes
(DNS Notify)'' RFC 1996, August 1996
[RFC1995]
M. Ohta, ``Incremental Zone Transfer in DNS'' RFC 1995, August
1996.
[RFC2026]
S. Bradner, ``the Internet Standards Process -- Revision 3'' RFC
2026, Harvard University, October 1996.
[RFC2136]
P. Vixie, S. Thomson, Y. Rekhter and J. Bound, ``Dynamic
Updates in the Domain Name System (DNS UPDATE)'' RFC 2136,
April 1997
Expires March 2000 [Page 6]
INTERNET-DRAFT DNS DUXFR September 1999
Author's Address
Kevin J. Dunlap
Check Point Software Technologies, Inc.
The Meta IP Group
119 South Main Street, Suite 200
Seattle, WA 98033
+1 206 674 3700
<kevind@MetaIP.CheckPoint.Com>
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
<vixie@isc.org>
Expires March 2000 [Page 7]
INTERNET-DRAFT DNS DUXFR September 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.
Expires March 2000 [Page 8]

696
doc/expired/draft-ietf-dnsext-iana-dns-00.txt
View File

@@ -1,696 +0,0 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
Eric Brunner
Bill Manning
Expires: June 2000 February 2000
Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ---- --------------
Status of This Document
Distribution of this draft <draft-ietf-dnsext-iana-dns-00.txt>, which
is intended to become a Best Current Practice, is unlimited. Comments
should be sent to the DNS Working Group 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.''
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
Internet Assigned Number Authority (IANA) parameter assignment
considerations are given for the allocation of Domain Name System
(DNS) classes, RR types, operation codes, error codes, etc.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 1]
INTERNET-DRAFT DNS IANA Considerations February 2000
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. DNS Query/Response Headers..............................3
2.1 One Spare Bit?.........................................4
2.2 Opcode Assignment......................................4
2.3 RCODE Assignment.......................................5
3. DNS Resource Records....................................5
3.1 RR TYPE IANA Considerations............................7
3.1.1 Special Note on the OPT RR...........................8
3.2 RR CLASS IANA Considerations...........................8
3.3 RR NAME Considerations.................................9
4. Designated Expert......................................10
5. Security Considerations................................10
References................................................10
Authors Addresses.........................................12
Expiration and File Name..................................12
D. Eastlake 3rd, E. Brunner, B. Manning [Page 2]
INTERNET-DRAFT DNS IANA Considerations February 2000
1. Introduction
The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases which hierarchically store "resource records"
(RRs) under domain names.
This data is structured into CLASSes and zones which can be
independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535]
familiarity with which is assumed.
This document covers, either directly or by reference, general IANA
parameter assignment considerations applying across DNS query and
response headers and all RRs. There may be additional IANA
considerations that apply to only a particular RR type or
query/response opcode. See the specific RFC defining that RR type or
query/response opcode for such considerations if they have been
defined.
IANA currently maintains a web page of DNS parameters at
<http://www.isi.edu/in-notes/iana/assignments/dns-parameters>.
"IETF Standards Action", "IETF Consensus", "Specification Required",
and "Private Use" are as defined in [RFC 2434].
2. DNS Query/Response Headers
The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC 2136, 2535]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so
they can be matched.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 3]
INTERNET-DRAFT DNS IANA Considerations February 2000
The QR bit indicates whether the header is for a query or a response.
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value
of the response header without clearing bits. Thus any attempt to
use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous given existing
implementation. Such meanings may only be assigned by an IETF
Standards Action.
The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
authority count (NSCOUNT), and additional information count (ARCOUNT)
express the number of records in each section for all opcodes except
Update. These fields have the same structure and data type for
Update but are instead the counts for the zone (ZOCOUNT),
prerequisite (PRCOUNT), update (UPCOUNT), and additional information
(ARCOUNT) sections.
2.1 One Spare Bit?
There have been ancient DNS implementations for which the Z bit being
on in a query meant that only a response from the primary server for
a zone is acceptable. It is believed that current DNS
implementations ignore this bit.
Assigning a meaning to the Z bit requires an IETF Standards Action.
2.2 Opcode Assignment
New OpCode assignments require an IETF Standards Action.
Currently DNS OpCodes are assigned as follows:
OpCode Name Reference
0 Query [RFC 1035]
1 IQuery (Inverse Query) [RFC 1035]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
D. Eastlake 3rd, E. Brunner, B. Manning [Page 4]
INTERNET-DRAFT DNS IANA Considerations February 2000
2.3 RCODE Assignment
It would appear from the DNS header above that only four bits of
RCODE, or response/error code are available. However, RCODEs can
appear not only at the top level of a DNS response but also inside
TSIG RRs [RFC XXX3] and OPT RRs [RFC 2671]. The OPT RR provides an
eight bit extension resulting in a 12 bit RCODE field and the TSIG RR
has a 16 bit RCODE field.
RCODE Name Description Reference
Decimal
Hexadecimal
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11-15 available for assignment
16 BADVERS Bad OPT Version [RFC 2671]
16 BADSIG TSIG Signature Failure [RFC XXX3]
17 BADKEY Key not recognized [RFC XXX3]
18 BADTIME Signature out of time window [RFC XXX3]
19-3840 available for assignment
0x0013-0x0F00
3841-4095 Private Use
0x0F01-0x0FFF
4096-65535 available for assignment
0x1000-0xFFFF
Since it is important that RCODEs be understood for interoperability,
assignment of new RCODE listed above as "available for assignment"
requires an IETF Consensus.
3. DNS Resource Records
All RRs have the same top level format shown in the figure below
taken from [RFC 1035]:
D. Eastlake 3rd, E. Brunner, B. Manning [Page 5]
INTERNET-DRAFT DNS IANA Considerations February 2000
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this
resource record pertains. NAMEs are specific to a CLASS as described
in section 3.2. NAMEs consist of an ordered sequence of one or more
labels each of which has a label type [RFC 1035, 2671].
TYPE is a two octet unsigned integer containing one of the RR TYPE
codes. See section 3.1.
CLASS is a two octet unsigned integer containing one of the RR CLASS
codes. See section 3.2.
TTL is a four octet (32 bit) bit unsigned integer that specifies the
number of seconds that the resource record may be cached before the
source of the information should again be consulted. Zero is
interpreted to mean that the RR can only be used for the transaction
in progress.
RDLENGTH is an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
RDATA is a variable length string of octets that constitutes the
resource. The format of this information varies according to the
TYPE and in some cases the CLASS of the resource record.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 6]
INTERNET-DRAFT DNS IANA Considerations February 2000
3.1 RR TYPE IANA Considerations
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
and MetaTYPEs.
Data TYPEs are the primary means of storing data. QTYPES can only be
used in queries. Meta-TYPEs designate transient data associated with
an particular DNS message and in some cases can also be used in
queries. Thus far, data TYPEs have been assigned from 1 upwards plus
the block from 100 through 103 while Q and Meta Types have been
assigned from 255 downwards (except for the OPT Meta-RR which is
assigned TYPE 41). There have been DNS implementations which made
caching decisions based on the top bit of the bottom byte of the RR
TYPE.
There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
[RFC XXX3], and TKEY [work in progress].
There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
AXFR, and IXFR.
Considerations for the allocation of new RR TYPEs are as follows:
Decimal
Hexadecimal
0
0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
2535] and in other circumstances and must never be allocated
for ordinary use.
1 - 127
0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
TYPEs by IETF Consensus.
128 - 255
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
Meta TYPEs by IETF Consensus.
256 - 32767
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
Consensus.
32768 - 65279
0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
65280 - 65535
0xFF00 - 0xFFFF - Private Use.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 7]
INTERNET-DRAFT DNS IANA Considerations February 2000
3.1.1 Special Note on the OPT RR
The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
primary purpose is to extend the effective field size of various DNS
fields including RCODE, label type, OpCode, flag bits, and RDATA
size. In particular, for resolvers and servers that recognize it, it
extends the RCODE field from 4 to 12 bits.
3.2 RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary
relationship between the name space or root servers for one CLASS and
those for another CLASS. The same name can have completely different
meanings in different CLASSes although the label types are the same
and the null label is usable only as root in every CLASS. However,
as global networking and DNS have evolved, the IN, or Internet, CLASS
has dominated DNS use.
There are two subcategories of DNS CLASSes: normal data containing
classes and QCLASSes that are only meaningful in queries or updates.
The current CLASS assignments and considerations for future
assignments are as follows:
Decimal
Hexadecimal
0
0x0000 - assignment requires an IETF Standards Action.
1
0x0001 - Internet (IN).
2
0x0002 - available for assignment by IETF Consensus as a data CLASS.
3
0x0003 - Chaos (CH) [Moon 81].
4
0x0004 - Hesiod (HS) [Dyer 87].
5 - 127
0x0005 - 0x007F - available for assignment by IETF Consensus as data
CLASSes only.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 8]
INTERNET-DRAFT DNS IANA Considerations February 2000
128 - 253
0x0080 - 0x00FD - available for assignment by IETF Consensus as
QCLASSes only.
254
0x00FE - QCLASS None [RFC 2136].
255
0x00FF - QCLASS Any [RFC 1035].
256 - 32767
0x0100 - 0x7FFF - assigned by IETF Consensus.
32768 - 65280
0x8000 - 0xFEFF - assigned based on Specification Required as defined
in [RFC 2434].
65280 - 65534
0xFF00 - 0xFFFE - Private Use.
65535
0xFFFF - can only be assigned by an IETF Standards Action.
3.3 RR NAME Considerations
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
NAME is "ROOT" which is the zero length label. By definition, the
null or ROOT label can not be used for any other NAME purpose.
At the present time, there are two categories of label types, data
labels and compression labels. Compression labels are pointers to
data labels elsewhere within an RR or DNS message and are intended to
shorten the wire encoding of NAMEs. The two existing data label
types are frequently referred to as ASCII and Binary. ASCII labels
can, in fact, include any octet value including zero octets but most
current uses involve only [US-ASCII] For retrieval ASCII labels are
defined to treat upper and lower case letters the same. Binary
labels are bit sequences [RFC 2673].
IANA considerations for label types are given in [RFC 2671].
NAMEs are local to a CLASS. The Hesiod [Dyer 87] and Chaos [Moon 81]
CLASSes are essentially for local use. The IN or Internet CLASS is
thus the only DNS CLASS in global use on the Internet at this time.
A somewhat dated description of name allocation in the IN Class is
given in [RFC 1591]. Some information on reserved top level domain
names is in Best Current Practice 32 [RFC 2606].
D. Eastlake 3rd, E. Brunner, B. Manning [Page 9]
INTERNET-DRAFT DNS IANA Considerations February 2000
4. Designated Expert
To provide additional support to IANA in the DNS area, the IESG MAY
appoint a designed expert.
5. Security Considerations
This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 2535] for secure DNS
considerations.
References
[Dyer 87] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
Plan - Name Service, April 1987,
[Moon 81] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence Laboratory, June
1981.
[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", March 1994.
[RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", August 1996.
[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
[RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS
Specification", July 1997.
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
in RFCs", T. Narten, H. Alvestrand, October 1998.
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 10]
INTERNET-DRAFT DNS IANA Considerations February 2000
[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
1999.
[RFC 2672] - M. Crawford, " Non-Terminal DNS Name Redirection",
August 1999.
[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
August 1999.
[RFC XXX3] - P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
"Secret Key Transaction Signatures for DNS (TSIG)", xxx 2000 (draft-
ietf-dnsind-tsig-*.txt).
[US-ASCII] - ANSI, "USA Standard Code for Information
Interchange", X3.4, American National Standards Institute: New York,
1968.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 11]
INTERNET-DRAFT DNS IANA Considerations February 2000
Authors Addresses
Donald E. Eastlake 3rd
Motorola
65 Shindegan Hill Road
Carmel, NY 10512 USA
Telephone: +1-914-276-2668 (h)
+1-508-261-5434 (w)
email: dee3@torque.pothole.com
Eric Brunner
1415 Forest Avenue
Portland, ME 04103 USA
Telephone: +1 207-797-0525
email: brunner@world.std.com
Bill Manning
USC/ISI
4676 Admiralty Way, #1001
Marina del Rey, CA 90292 USA
Telephone: +1 310 822 1511
email: bmanning@isi.edu
Expiration and File Name
This draft expires August 2000.
Its file name is draft-ietf-dnsext-iana-dns-00.txt.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 12]

337
doc/expired/draft-ietf-dnsind-binary-labels-05.txt
View File

@@ -1,337 +0,0 @@
DNSIND Working Group Matt Crawford
Internet Draft Fermilab
May 5, 1999
Binary Labels in the Domain Name System
<draft-ietf-dnsind-binary-labels-05.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.
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 November 10, 1999 Crawford [Page 1]
Internet Draft Binary DNS Labels May 5, 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 November 10, 1999 Crawford [Page 2]
Internet Draft Binary DNS Labels May 5, 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 November 10, 1999 Crawford [Page 3]
Internet Draft Binary DNS Labels May 5, 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 November 10, 1999 Crawford [Page 4]
Internet Draft Binary DNS Labels May 5, 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. he canonicalization and
sorting rules of section 3.3 allow these to be addressed by DNS
Security [DNSSEC].
Expires November 10, 1999 Crawford [Page 5]
Internet Draft Binary DNS Labels May 5, 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 November 10, 1999 Crawford [Page 6]

334
doc/expired/draft-ietf-dnsind-dddd-01.txt
View File

@@ -1,334 +0,0 @@
DNSIND Working Group Brian Wellington (TISLabs)
INTERNET-DRAFT Olafur Gudmundsson (TISLabs)
April 1999
<draft-ietf-dnsind-dddd-01.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 October 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. In many cases, 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 October 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 exectuted 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.
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 silently ignore (*)
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. If multiple deferred deletes are sent in the same DNS message
with the same TTL value, they MUST be processed atomically if processed
as planned (that is, none of the deferred deletes are updated or
cancelled).
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 October 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 SHOULD purge
any matching deferred delete 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. If no deferred delete matches, this request will be silently
ignored.
3.5 - Processing of adds
When data is added through a dynamic update which matches a deferred
delete, there is no additional processing done.
4 - TTL handling
Any record that may be deleted SHOULD have a short TTL compared to its
lease time, to prevent deleted data from being cached past its
expiration.
When the time until an RR is deleted becomes low enough, the server MAY
modify the TTL of the RRset. 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]. As these operations can potentially be
expensive (more so if DNSSEC [RFC2535] signatures must be regenerated),
the specific limits and effects are left to the implementation.
If the TTL is modified by the server, it is not reset if the lease is
renewed. Therefore, the original RR SHOULD be sent with the lease
renewal if the client expects that the server has modified the TTL.
Expires October 1999 [Page 4]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
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 may be sent independently, although the add should be sent again.
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 - Protocol robustness
This protocol has no inherent protection against replayed messages,
which can either originate from an attack or faulty hardware. To
prevent this problem, prerequisites should be used in the update
message, such as a test for the existence of a TXT record describing the
lease, which would be added along with the other records (see [RFC2136],
section 5).
7 - 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
[RFC2535] 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.
8 - IANA Considerations
None.
9 - 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.
Expires October 1999 [Page 5]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
2137, CyberCash, April 1997.
[RFC2535] D. Eastlake ``Domain Name System Security Extensions,'' RFC
2535, IBM, March 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.
[simple-update]
B. Wellington ``Simple Secure Domain Name System (DNS)
Dynamic Update,'' draft-ietf-dnssec-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
<bwelling@tislabs.com> <ogud@tislabs.com>
Expires October 1999 [Page 6]

167
doc/expired/draft-ietf-dnsind-dhcp-rr-00.txt
View File

@@ -1,167 +0,0 @@
INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsind-dhcp-rr-00.txt Internet Engines, Inc.
October 1999
A DNS RR for encoding DHCP information
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 describes a DNS RR for use by DHCP servers that need to
store state information in the DNS.
Introduction
A set of procedures to allow DHCP servers [RFC2131] to automatically
update the DNS [RFC1034, RFC1035] is proposed in [DHCPDNS].
A situation can arise where multiple DHCP clients request the same
DNS name from their (possibly distinct) DHCP servers. To resolve
such conflicts, [DHCPDNS] proposes storing client identifiers in the
DNS to unambiguously associate domain names with the DHCP clients
"owning" them. Early versions of [DHCPDNS] proposed using TXT
records for encoding this information; the current version specifies
the use of KEY records.
In the interest of clarity, it would be preferable for this DHCP
Expires April 2000 [Page 1]
draft-ietf-dnsind-dhcp-rr-00.txt October 1999
information to use a distinct RR type rather than the existing KEY
type. A separate RR type can also improve efficiency by avoiding the
unnecessary transmission of unrelated KEY records.
This memo defines a distinct RR type for use by DHCP servers, the
"DHCP" RR.
The DHCP RR
The DHCP RR is defined with mnemonic DHCP and type code <TBD>.
DHCP RDATA format
The RDATA section of a DHCP RR in transmission contains RDLENGTH
bytes of binary data. The format of this data and its interpretation
by DHCP servers and clients, including the interpretation of multiple
DHCP RRs at the same domain name, are TBD. [This part of the
specification should be driven by the needs of, and written in
cooperation with, the DHCP Working Group and the authors of
[DHCPDNS]].
DNS software should consider the RDATA section to be opaque. In DNS
master files, the RDATA is represented as a hexadecimal string with
an optional "0x" or "0X" prefix. Periods (".") may be inserted
anywhere after the "0x" for readability. This format is identical to
that of the NSAP RR [RFC1706]. The number of hexadecimal digits MUST
be even.
Example
A DHCP server allocating the IPv4 address 10.0.0.1 to a client
"client.org.nil" might associate eight bytes of housekeeping
information with the client as follows:
client.org.nil. A 10.0.0.1
client.org.nil. DHCP 01.23.45.67.89.ab.cd.ef
Security Considerations
The DHCP record as such does not introduce any new security problems
into the DNS. However, care should be taken not to store sensitive
information in DHCP records, since they are published along with
other DNS data. Note that even the hardware addresses of DHCP
clients may be considered sensitive information.
IANA Considerations
The IANA is requested to allocate an RR type number for the DHCP
Expires April 2000 [Page 2]
draft-ietf-dnsind-dhcp-rr-00.txt October 1999
record type from the regular RR type number range.
References
[RFC1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987.
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987.
[RFC1706] - DNS NSAP Resource Records, B. Manning, R. Colella,
October 1994.
[RFC2131] - Dynamic Host Configuration Protocol, R. Droms, March
1997.
[DHCPDNS] - draft-ietf-dhc-dhcp-dns-*.txt
Author's Address
Andreas Gustafsson
Internet Engines, Inc.
950 Charter Street
Redwood City, CA 94063
USA
Phone: +1 650 779 6004
Email: gson@iengines.net
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 implmentation 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.
Expires April 2000 [Page 3]
draft-ietf-dnsind-dhcp-rr-00.txt October 1999
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."
Expires April 2000 [Page 4]

502
doc/expired/draft-ietf-dnsind-dname-03.txt
View File

@@ -1,502 +0,0 @@
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/expired/draft-ietf-dnsind-edns0-01.txt
View File

@@ -1,319 +0,0 @@
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]

249
doc/expired/draft-ietf-dnsind-edns1-03.txt
View File

@@ -1,249 +0,0 @@
DNSIND Working Group Paul Vixie
INTERNET-DRAFT ISC
<draft-ietf-dnsind-edns1-03.txt> June, 1999
Extensions to DNS (EDNS1)
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 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 December 1999 [Page 1]
INTERNET-DRAFT EDNS1 June 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 December 1999 [Page 2]
INTERNET-DRAFT EDNS1 June 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. Each
section in a multipart message must appear in normal
message order, and each section must be complete before
later sections are added. All segments of a message
must be transmitted contiguously, without interleaving
of other messages.
FM ``First match'' flag. Notable only when multiple
questions are present. If set in a request, questions
will be processed in wire order and the first question
whose answer would have NOERROR AND ANCOUNT>0 is treated
Expires December 1999 [Page 3]
INTERNET-DRAFT EDNS1 June 1999
as if it were the only question in the query message.
Otherwise, questions can be processed in any order and
all possible answer records will be included in the
response. Response FM should be ignored by requestors.
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.
Expires December 1999 [Page 4]
INTERNET-DRAFT EDNS1 June 1999
5 - Multiple Questions for QUERY
5.1. If QDCOUNT>1, multiple questions are present. All questions must
be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It
is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY.
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, Michael Patton,
and Michael Graff 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.
Expires December 1999 [Page 5]
INTERNET-DRAFT EDNS1 June 1999
IETF DNSIND, March 1998.
8 - Author's Address
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
<vixie@isc.org>
Expires December 1999 [Page 6]

470
doc/expired/draft-ietf-dnsind-indirect-key-00.txt
View File

@@ -1,470 +0,0 @@
DNSIND Working Group D. Eastlake
INTERNET-DRAFT IBM
Expires October 1999
April 1999
draft-ietf-dnsind-indirect-key-00.txt
Indirect KEY RRs in the Domain Name System (DNS)
-------- --- --- -- --- ------ ---- ------ -----
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsind-indirect-key-00.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 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.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
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
[RFC 2535] defines a means for storing cryptographic public keys in
the Domain Name System. An additional code point is defined for the
algorithm field of the KEY resource record (RR) to indicate that the
key 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.
[This draft is moved from the DNSSEC WG as part of that WG's merger
into me DNSIND WG. It would have been draft-ietf-dnssec-indirect-
key-02.txt in the DNSSEC WG.]
D. 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...........................3
2.1 The Target Type Field..................................4
2.2 The Target Algorithm Field.............................5
2.3 The Hash Fields........................................5
3. Performance Considerations..............................6
4. IANA Considerations.....................................6
5. Security Considerations.................................6
References.................................................7
Author's Address...........................................7
Expiration and File Name...................................8
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT Indirect KEY RRs
1. Introduction
The Domain Name System (DNS) security extensions [RFC 2535] 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, it will sometimes 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 [RFC 2538] 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, i.e., the
value of the "protocol" field of an indirect KEY RR MUST NOT be 3.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD",
"RECOMMENDED", and "MAY" in this document are to be interpreted as
described in [RFC 2119].
2. The Indirect KEY RR Algorithm
Domain Name System (DNS) KEY Resource Record (RR) [RFC 2535]
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 the 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 (variable size) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT Indirect KEY RRs
2.1 The Target Type Field
Target type specifies the type of the key containing data being
pointed at.
Target type
-----------
0 - reserved, see section 4
1 - indicates that the pointer is a domain name from which KEY RRs
[RFC 2535] should be retrieved. Name compression in the pointer
field is prohibited.
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 schemes may be
defined which return multiple keys.)
3 - indicates that the pointer is a domain name from which CERT RRs
[RFC 2538] should be retrieved. Name compression in the pointer
field is prohibited.
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 the same as
the entire RDATA portion of a CERT RR [RFC 2538]. (New URL
schemes may be defined which return multiple such data blocks.)
5 - 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 [RFC
2437] format key. (New URL schemes may be defined which return
multiple keys.)
6 through 255 - available for assignment, see section 4.
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
[RFC 2538] 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
schemes may be defined which return multiple such certificates.)
512 through 65534 - available for assignment, see section 4.
65535 reserved, see section 4.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT Indirect KEY RRs
2.2 The Target Algorithm Field
The algorithm field is as defined in [RFC 2535]. 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 RRset [RFC 2181, 2535] 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 RRset including any direct keys. This may or
may not be true of any indirect key pointed to. If an indirect 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 including a hash in a secure indirecting RR,
this secure hash can be checked against the hash of the actual keying
material
Type Hash Algorithm
---- --------------
0 indicates no hash present
1 MD5 [RFC 1321]
2 SHA-1
3 RIPEMD
4-252 available, see section 4
253 private, domain name (see below)
254 private, OID (see below)
255 reserved
Codes 253 and 254 indicate that a private, proprietary, local, or
experimental hash algorithm is used. For code 253, the hash field
begins with a wire encoded domain name (with compression prohibited)
that indicates the algorithm to use. For code 254, the hash field
begins with a one byte unsigned OID length followed by a BER encoded
OID which indicates the algorithm to use.
The hash size field is an unsigned octet count of the hash field size
less the length of any code 253 or 254 prefix. 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
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT Indirect KEY RRs
hash algorithm field 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 and any code 253 or 254 prefix.
3. Performance Considerations
With current public key technology, an indirect key will sometimes be
shorter than the keying material it points at. In addition, there
can be cases where a single indirect KEY RR points to multiple keys
elsewhere. This may improve DNS performance in the retrieval of the
initial KEY RR. However, an additional retrieval step then needs to
be done to get the actually keying material which must be added to
the overall time to get the public key.
4. IANA Considerations
IETF consensus, standards action, and similar terms in this section
are as define in [RFC 2434].
KEY RR algorithm number 252 was already reserved for indirect keys in
RFC 2535.
An IETF standards action is required to allocate target type codes
hex x0000, x0006 through x00FF, x0200 through x0FFF, and xFFFF.
Codes in the range x1000 through x7FFF can be allocated by an IETF
consensus. Codes x8000 through xFEFF are available on a first come
first serve basis. Codes xFF00 through xFFFE are available for
experimentation or private local use without allocation. Use of
codes in this block may result in conflicts outside such experiment
or locality.
An IETF consensus is required to allocate an indirect KEY RR hash
algorithm code in the range 4-252 and a standards action is required
to allocate hash algorithm code 255. Codes 253 and 254 should cover
requirements for local, private, or proprietary algorithms.
5. 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,
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT Indirect KEY RRs
point to a key which can not be securely retrieved and is not
validateted by a secure hash in the indirect key RR, you have no
security.
References
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 2119 - "Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner. March 1997.
RFC 2181 - R. Elz, R. Bush, "Clarifications to the DNS
Specification", July 1997.
RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", October 1998.
RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", October 1998.
RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
RFC 2538 - D. Eastlake, O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", March 1999.
Author's Address
Donald E. Eastlake 3rd
IBM
65 shindegan Hill Road, RR #1
Carmel, NY 10512 USA
Telephone: +1-914-784-7913 (w)
+1-914-276-2668 (h)
FAX: +1-914-784-3833 (w)
EMail: dee3@us.ibm.com
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT Indirect KEY RRs
Expiration and File Name
This draft expires October 1999.
Its file name is draft-ietf-dnsind-indirect-key-00.txt.
D. Eastlake 3rd [Page 8]

440
doc/expired/draft-ietf-dnsind-keyreferral-00.txt
View File

@@ -1,440 +0,0 @@
DNSIND WG Edward Lewis
INTERNET DRAFT TIS Labs
May Update: RFC 2535 Jerry Scharf
Catagory: I-D ISC
April 1, 1999
The Zone Key Referral
<draft-ietf-dnsind-keyreferral-00.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 authors or the DNSIND WG mailing list
<namedroppers@internic.net>.
This draft expires on October 1, 1999
Copyright Notice
Copyright (C) The Internet Society (1999). All rights
reserved.
Notes on this document
This section will only appear in the -00.txt edition of this draft.
This document originated in the DNSSEC working group in June 1998. The
discussion of the issues in this draft were tabled until the publication
of the then current DNSSEC drafts as RFCs.
The first version of this document lists a third author, John Gilmore.
He is listed as an author because he was one of the initiators of what is
proposed. In this and following versions he is only listed in the
Acknowledgements (as opposed to being an author) as he has not been
involved in the writing/editing of the draft. This has been done to
avoid assigning his name to a document he may not have a chance to read,
this is not intended as a slight on his efforts.
When commenting on this draft, please be aware that some terms used here
are up for negotiation before progressing - such as "thief" and "road
block" appearing later in the draft. Comments which are left justified
were added during the re-issuing of the draft, they add context that
may have been lost over time.
Abstract
A new type of key is defined to address the problems of
performance in large delegeted zones and issues of liability of
registrars with regards to the storing of public keys belonging
to zone cuts. This new key type also brings DNSSEC more in line
with the DNS treatment of zone cuts and speeds recovery in
handling privatekey exposure.
The new type of key is a referral record that is stored, signed,
at the parent zone's place for the delegation point. A resolver
receiving this record is being informed that there are genuine
public keys at the child's authoritative name servers. The
parent no longer needs to store the child's public keys locally.
1 Introduction
There are a number of different reasons for the proposal of this
new key type. Reasons include:
o the performance impact that RFC 2535 has on name servers
o the problem of updating a widely delegated parent zone on demand
o statements in RFC 2181 on authoritative data at delegations
o perceived liability of the operator of a name server or registry
To address these issues, which are expanded upon below, a new
key type is proposed - a "zone key referral" - to join the user
key, host key, and zone key types defined in RFC 2535.
1.1 Performance Issues
A sample zone will be used to illustrate the problem. The
example will part from reality mostly in the length of zone
names, which changes the size of the owner and resource record
data fields.
# $ORIGIN test.
# @ IN SOA <SOA data>
# IN SIG SOA <by test.>
# IN KEY <1024 bit zone key>
# IN SIG KEY <by test.>
# IN SIG KEY <by .>
# IN NS ns.test.
# IN SIG NS <by test.>
# IN NXT my-org.test. NS SOA SIG KEY NXT
# IN SIG NXT <by test.>
#
# my-org IN KEY <1024 bit zone key>
# IN KEY <1024 bit zone key>
# IN SIG KEY <by test.>
# IN NS ns1.my-org.test.
# IN NS ns2.my-org.test.
# IN NXT them.test. NS SIG KEY NXT
# IN SIG NXT <by test.>
#
# them IN KEY 0xC100 3 1
# IN SIG KEY <by test.>
# IN NS ns1.them.test.
# IN NS ns2.them.test.
# IN NXT test. NS SIG KEY NXT
# IN SIG NXT <by test.>
In this zone file fragment, "my-org" is a delegation point of
interest with two registered public keys. Presumably, one key
is for signatures generated currently and the other is for still
living and valid but older signatures. "them" is another
delegation point, with a NULL key. This signifies that this zone
is unsecured.
To analyze the performance impact of the storing of keys, the
number of bytes used to represent the RRs in the procotol format
is used. The actual number of bytes stored will likely be
higher, accounting for data structure overhead and alignment.
The actual number of bytes transferred will be lower due to DNS
name compression.
The number of bytes for my-org's two 1024-bit keys, two NS
records, NXT and the associated signatures is 526. The bytes
needed for them (with the NULL key) is 346. Currently, there
are close to 2 million entries in com., so if we take my-org as
a typical domain, over 1GB on memory will be needed for com.
The zone keys used in the example are set to 1024 bits. This
number may range from as low as 512 bits upwards to over 3000
bits. To scale the above numbers to a different key size,
multiply the difference in key sizes by 4 for my-org and by 2
for them, and adjust the numbers accordingly.
The increased size of the data held for the zone cuts will have
two impacts at the transport and below layers. Bandwidth beyond
that currently needed will be used to carry the KEY records.
The inclusion of all of the child's keys will also push DNS over
the UDP size limit and start using TCP - which could cause
critical problems for current heavily used name servers, like
the roots.
Another impact, not illustrated by the example, is the frequency
of updates. If each time a public key for my-org is added or
deleted, the SOA serial number will have to increase, and the
SOA signed again. If an average zone changes its keys(s) once
per month, there will be on average 45 updates per minute in a
zone of 2 million delegations.
(The multiple algorithms issue is an extension of multiple keys. The
example should be updated to show at least a DSS key as well as an RSA
key.)
1.2 Security Incident Recovery (w/ respect to keys only)
Once a zone administrator is alerted that any key's private
counterpart has been discovered (exposed), the first action to
be taken is to stop advertising the public key in DNS. This
doesn't end the availability of the key - it will be residing in
caches - but is the closest action resembling revokation
available in DNS.
Stopping the advertisement in the zone's name servers is as
quick as altering the master file and restarting the name
server. Having to do this in two places will will only delay
the time until the recovery is complete.
For example, a registrar of a top level domain has decided to
update its zone only on Mondays and Fridays due to the size of
the zone. A customer/delegatee is the victim of a break in, in
which one of the items taken is the file of private keys used to
sign DNS data. If this occurs on a Tuesday, the thief has until
Friday to use the keys before they disappear from the DNS, even
if the child stops publishing them immediately.
If the public key set is in the parent zone, and the parent zone
is not able to make the change quickly, the public key cannot be
revoked quickly. If the parent only refers to there being a key
at the child zone, then the child has the agility to change the
keys - even issue a NULL key, which will force all signatures in
the zone to become suspect.
1.3 DNS Clarifications
RFC 2181, section 6, clarifies the status of data appearing at a
zone cut. Data at a zone cut is served authoritatively from the
servers listed in the NS set present at the zone cut. The data
is not (necessarily) served authoritatively from the parent.
(The exception is in servers handling both the parent and child
zone.)
Section 6 also mentions that there are two exceptions created by
DNSSEC, the NXT single record set and the KEY set. This
proposal addresses the exception relating to the KEY set,
limiting its severity (but falling short of removing it
altogether). By limiting the exception, we will be simplifying
DNS.
1.4 Liability
Liability is a legal concept, so it is not wise to attempt an
engineering solution to it. However, the perceived liability
incurred in using DNSSEC by registrars may prevent the adoption
of DNSSEC. Hence DNSSEC should be engineered in such a away to
address the concern.
One source of liability is the notion that by advertising a
public key for a child zone, a parent zone is providing a
service of security. With that comes responsibility. By having
the parent merely indicate that a child has a key (or has no
key), the parent is providing less in the way of security. If
the parent is wrong, the potential loss is less. Instead of
falsely authenticated data, configuration errors will be
apparent to the resolving client.
2 The Proposal
The proposal is to introduce a new key type which indicates
whether the delegated zone is running secured or not. Running
secured is either a zone signed with at least one key, an
experimental zone, or a zone with only NULL keys published.
The Zone Referral Key will resemble the NULL key in syntax.
There will be a flags field, an algorithm field, and a protocol
field, but no public key material. The Referral Key is signed
by the parent zone, as was the public key set in RFC 2065.
There is only one Referral Key RR present.
The Referral Key flags field will have the following values:
Field Bit(s) Value Meaning
A/C 0- 1 0b01 indicates a key will be found
0b11 indicates a key will not be found
0b?0 error (referral cannot encrypt)
XT 2 0 no extended flags are needed
Z 4- 5 0 must be zero for all keys
NAMTYP 6- 7 0b11 this is a referral to a zone key
Z 8-11 0 must be zero for all keys
SIG 12-15 0 must be zero for a referral key
The legal values of the flags field are (in summary):
Hex Value Indicates
0x4300 The delegation has a key record set
0xC300 The delegation has no key record
Other values are not valid for Referral Keys (but may be valid
for other keys).
The Protocol field must be set to 3, the DNSSEC protocol value.
The Algorithm field must be 0.
The algorithm is not important at this point. So long as the searcher
knows to expect a key set at the delegated zone's apex, a secure chain
is possible. One the key set is retrieved and verified, then the
algorithms used in the delegated zone are known. (The issue is that a
zone may be signed in algorithm 1 and not 3, 3 and not 1, both, etc.,
and a secure resolver must know this in order to set signature arrival
expectations.
2.1 Example
The Referral key for my-org.test. and them.test. would appear as
the following in the zone master file:
my-org.test. IN KEY 0x4300 3 0
them.test. IN KEY 0xC300 3 0
In the example introduced earlier, the master file would change
to the following.
# $ORIGIN test.
# @ IN SOA <SOA data>
# IN SIG SOA <by test.>
# IN KEY <1024 bit zone key>
# IN SIG KEY <by test.>
# IN SIG KEY <by .>
# IN NS ns.test.
# IN SIG NS <by test.>
# IN NXT my-org.test. NS SOA SIG KEY NXT
# IN SIG NXT <by test.>
#
# my-org IN KEY 0x4300 3 0
# IN SIG KEY <by test.>
# IN NS ns1.my-org.test.
# IN NS ns2.my-org.test.
# IN NXT them.test. NS SIG KEY NXT
# IN SIG NXT <by test.>
#
# them IN KEY 0xC300 3 1
# IN SIG KEY <by test.>
# IN NS ns1.them.test.
# IN NS ns2.them.test.
# IN NXT test. NS SIG KEY NXT
# IN SIG NXT <by test.>
3 Analysis
By removing the public keys from the parent's master file, the
parent is no longer a road block during an emergency removal of
keys. A parent zone is unchanged as a zone changes from NULL
keys to experimental keys to fully signed. The parent is also
not providing a security service, other than to authentically
claim the existence of a KEY record set - akin to the "hints" of
the name servers.
The change also improves the prospect for performance. The need
for multiple KEY RR's, each one on the order of 100 bytes, is
removed and replaced by a single KEY RR of the order of 25
bytes. Saving bytes reduces the need to use TCP to avoid
truncated responses. Also, the need for updating the zone drops
- no longer will there be updates for each key change.
As far as the statements by RFC 2181 conerning authority levels,
the Referral Key is not authortative and would be superseeded by
a verified set of the real zone keys. The only caveat is that
once the verified set of keys expire (assuming the parent has to
learn the keys from another server), the Referal Key must
reappear. This is an example of what has been labelled "mount-
like semantics."
[No reference for mount-like semantics has yet been found.]
The last point is important. This requires the "mount-like
semantics" that have been discussed for the BIND name servers.
Once hints are overridden by learned, authorititative and
verified data, the hints are not discarded. Hints in this state
are stored and become visible when the learned data expires.
4 IANA Considerations
Other than using a new value in the flags field of the KEY RR,
no new number assignments are needed. The flags field is not
under the control of IANA as of yet. There are no requirements
placed on IANA by this draft.
5 Security Considerations
There has been some debate about whether the Referral key should
be treated as a hint - just like the NS records. If so, then
there is no need to sign the Referral Key, and an unsigned
(hence non-authenticated) security record is of little value.
So, is the Referral Key even needed?
Authentication in DNSSEC is done from the data "back" towards a
trusted point - e.g., "up" to the root. Since the
authentication is done by going repeatedly from child to parent,
why bother having the parent indicate the status of the child?
The answer is in the scenario in which a resolver somewhere has
obtained data which fails the verification process. Perhaps the
signature is wrong, a key in the chain of trust is unavailable,
the set should have had a signature, but none is found (or vice
versa), or the trail of signed-by names is not acceptable. In
this case, the resolver needs to find the authoritative zone,
its status and its name server set.
If a zone is being attacked by a masquerader, and parents do not
make any statements about the security of child zones, then an
easy and successfull attack may occur. An attacker only needs
to supply either fake name server records or glue records to
redirect queries.
While this attack will not be stopped as far as denial of
service, the masquerader can be stopped from being accepted as
an authoritative source if the parent of the zone claims the
child is secure and signs the public keys of the true child and
not the masquerader.
The masquerader cannot successfully claim that the zone is
unsigned, because it must have a zone key signed by the parent.
NULL or not, the key would not be trusted by the resolver,
assuming the parent has not also been duped. The resolver,
sensing this, should report an error or security incident, and
not accept data.
6 Acknowledgements
John Gilmore originally raised the issues that have led to this
document.
7 Author's addresses
Edward Lewis Jerry Scharf
<lewis@tislabs.com> <scharf@vix.com>
3060 Washinton Rd (Rte 97)
Glenwood, MD 21738
+1(443)259-2352
8 References
RFC 2181 "Clarifications to the DNS Specification", Elz and Bush
RFC 2535 "Domain Name System Security Extensions", Eastlake
9 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 implmentation 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."
This draft expires on October 1, 1999

697
doc/expired/draft-ietf-dnsind-kitchen-sink-02.txt
View File

@@ -1,697 +0,0 @@
INTERNET-DRAFT Donald E. Eastlake, 3rd
IBM
Expires March 2000 September 1999
draft-ietf-dnsind-kitchen-sink-02.txt
The Kitchen Sink DNS Resource Record
--- ------- ---- --- -------- ------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsind-kitchen-sink-02.txt, is
intended to be become an Experimental RFC. Distribution of this
document is unlimited. Comments should be sent to
<namedroppers@internic.net> or to the author.
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.''
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.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved
Abstract
Periodically people desire to put proprietary, complex, and/or
obscure data into the Domain Name System (DNS). This draft defines a
kitchen sink Resource Record that will satisfy this desire for the
storage of miscellaneous structured information.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT The Kitchen Sink Resource Record
Acknowledgements
The suggestions or information provided by the following persons have
improved this document and they are gratefully acknowledged:
Rob Austein
Matt Crawford
Johnny Eriksson
Phillip H. Griffin
Michael A. Patton
David Singer
Table of Contents
Status of This Document....................................1
Copyright Notice...........................................1
Abstract...................................................1
Acknowledgements...........................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Kitchen Sink Resource Record............................3
2.1 The Meaning Octet......................................4
2.2 The Coding and Subcoding Octets........................5
2.2.1 ASN.1 Subcodings.....................................7
2.2.2 MIME Subcodings......................................7
2.2.3 Text Subcodings......................................8
3. Master File Representation..............................8
4. Performance Considerations..............................9
5. Security Considerations.................................9
6. IANA Considerations.....................................9
7. Full Copyright Statement................................9
References................................................11
Author's Address..........................................12
Expiration and File Name..................................12
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT The Kitchen Sink Resource Record
1. Introduction
The Domain Name System (DNS) provides a replicated distributed secure
hierarchical database which stores "resource records" (RRs) under
hierarchical domain names. This data is structured into zones which
are independently maintained. [RFC 1034, 1035, 2535]
Numerous types of RRs have been defined. These support such critical
functions as host name to address translation (A, AAAA, etc. RRs),
automatic mail routing (MX etc. RRs), and other functions. In
addition, there are RRs defined related to the zone structure and
administration of the DNS (SOA, NS, and RP RRs), security (SIG, KEY,
and NXT RRs), etc. There is a TXT RR for the inclusion of general
human readable text.
New RRs that are reasonably simple and designed via the open IETF
standards process are periodically added as new needs become
apparent. But there are people who want to put some proprietary,
complex and/or non-standard structured data in the DNS. In the past
they have frequently come up with some way of reinterpreting the TXT
RR, since that is one of the least constrained RRs. This is likely a
bad idea since all previous ways to reinterpreting the TXT RR have
sunk without a trace. (Well, if they actually got an RFC out, it's
still there, but, practically speaking, almost nobody actually uses
it.)
If a new type of data is needed for a global interoperable use in the
DNS, the best course is to design a new RR that meets the need
through the IETF standards process. This draft defines an extremely
general and flexible RR which can be used for other data, such as
proprietary data, where global interoperability is not a
consideration. It includes representations of OSI ASN.1, MIME, XML,
and, recursively, DNS RRs.
2. Kitchen Sink Resource Record
The symbol for the kitchen sink resource record is SINK. Its type
number is 40. This type is defined across all DNS classes.
The RDATA portion of the SINK RR is structured as follows:
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT The Kitchen Sink Resource Record
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| meaning | coding |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| subcoding | /
+--+--+--+--+--+--+--+--+ /
/ data /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The "meaning", "coding", and "subcoding" octets are always present.
The "data" portion is variable length and could be null in some
cases. The size of the "data" portion can always be determined by
subtracting 3 from the SINK resource record RDLENGTH. The coding
octet gives the general structure of the data. The subcoding octet
provides additional information depending on the value of the coding
nibble.
All references to "domain name" in this document mean a domain name
in the DNS CLASS of the SINK RR.
2.1 The Meaning Octet
The meaning octet indicates whether any semantic tagging appears at
the beginning of the data field and the format of such semantic
tagging. This contrasts with the coding and subcoding octets which
merely indicate format. The inclusion of such semantic tagging is
encouraged and it is expected to be the primary means by which
applications determine if a SINK RR is of the variety in which they
have interest.
It is noted that multiple popular uses of SINK could develop that are
not distinguished by using different parts of the DNS name space or
different DNS classes. If this occurs, retrievals may fetch large
sets of SINK RR to be sorted through at the application level.
Should this occur, such popular uses of SINK should obtain and
migrate to their own RR number using normal RR number allocation
procedures. In addition, it would be possible to define an extended
query operation that selects from among SINK RRs based on the
semantic tag.
The types of tags available are chosen to be globally unique and
under the control of some "owner". The owner designates the meaning
associated with the tags they control. Where the tag is a URI, it is
recommended that a retrieval from the URI fetch material that would
be helpful in determining this meaning. No a priori method is
defined for determining the meaning of other tags beside an out of
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT The Kitchen Sink Resource Record
band question to the owner.
INITIAL ASSIGNED MEANING VALUES
0 - reserved.
1 - none.
2 - OID.
3 - domain name.
4 - URI.
5-254 - available for assignment, see section 6.
255 - reserved.
A meaning octet value of 1 indicates that there is no semantic
tagging at the beginning of the data area. The information, whatever
it is, starts at the beginning of the data field and is coded
according to the coding and subcoding octets.
Meaning octet values of 2, 3, or 4, indicate, on the other hand, that
a semantic tag is present. A value of two indicates that a BER
[X.690] encoded OID appears prefixed by a single unsigned octet of
OID length count. A value of three indicates that a DNS domain name
appears in wire format with name compression prohibited. And a value
of four indicates that a null (zero) octet terminated URI appears.
2.2 The Coding and Subcoding Octets
The coding octet gives the major method by which the data in the data
field is encoded. It should always have a meaningful value. The
subcoding octet is intended to give additional coding details.
Although the subcoding octet is always present, it must be
interpreted in the context of the coding octet. For any coding octet
value which does not specify subcoding octet value meanings, the
subcoding octet MUST be ignored and SHOULD be zero.
While not explicitly mentioned below, the data field will actually
start with a semantic tag if indicated by the meaning octet. If such
a semantic tag is present, any data prefix required by the coding or
subcoding octet is placed after the semantic tag and before the data.
CODING OCTET VALUES
0 - reserved.
1 - DNS RRs. The data portion consists of DNS resource records
as they would be transmitted in a DNS response section. The
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT The Kitchen Sink Resource Record
subcoding octet is the number of RRs in the data area as an
unsigned integer. Domain names may be compressed via pointers
as in DNS replies. The origin for the pointers is the beginning
of the RDATA section of the SINK RR. Thus the SINK RR is safe
to cache since only code that knows how to parse the data
portion of a SINK RR need know of and can expand these
compressions.
2 - MIME structured data [RFC 2045, 2046]. The data portion is
a MIME structured message. The "MIME-Version:" header line may
be omitted unless the version is other than "1.0". The top
level Content-Transfer-Encoding may be encoded into the
subcoding octet (see section 2.2.2). Note that, to some extent,
the size limitations of DNS RRs may be overcome in the MIME case
by using the "Content-Type: message/external-body" mechanism.
3 - Text tagged data. The data potion consists of text formated
as specified in the TXT RR except that the first and every
subsequent odd numbered text item is considered to be a tag
labeling the immediately following text item. If there are an
odd number of text items overall, then the last is considered to
label a null text item. Syntax of the tags is as specified in
RFC 2396 for the "Authority Component" without the two leading
slashes ("//") or trailing slash using the DNS for authority.
Thus any organization with a domain name can assign tags without
fear of conflict. The subcodings octet specifies the encoding
of the labeled text items as specified in section 2.2.3.
4 - HTML. The subcoding octet indicates the version of HTML
with the major version number in the upper nibble and the minor
version number in the lower nibble. Thus, for example, HTML 3.2
would be indicated by a 0x32 octet.
5 - XML. The subcoding octet is the version of XML, currently
1.
6 - ASN.1 [X.680, etc.]. See section 2.2.1.
7-251 - Available for assignment, see section 6.
252 - Private coding format indicated by an OID. The format of
the data portion is indicated by an initial BER encoded OID
which is prefixed by a one octet unsigned length count for the
OID. The subcoding octet is available for whatever use the
private formating wishes to make of it.
253 - Private coding format indicated by a domain name. The
format of the data portion is indicated by an initial wire
format domain name with compression prohibited. (Such names are
self delimiting.) The subcoding octet is available for whatever
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT The Kitchen Sink Resource Record
use the private formating wishes to make of it.
254 - Private coding format indicated by a URI. The format of
the data portion is indicated by an initial URI [RFC 2396] which
is terminated by a zero (null) valued octet followed by the data
with that format. The subcoding octet is available for whatever
use the private formating wishes to make of it. The manner in
which the URI specifies the format is not defined but presumably
the retriever will recognize the URI by some pattern match.
255 - reserved.
NOTE: the existence of a DNS RR coding and the infinite possibilities
of ASN.1, XML, and MIME permit one to SINK to even greater depths by
nesting.
2.2.1 ASN.1 Subcodings
For ASN.1 [X.680, etc.] data, a specific concrete encoding must be
chosen as indicated by the subcoding octet.
ASN.* SUBCODINGS
0 - reserved.
1 - BER ( Basic Encoding Rules [X.690] ).
2 - DER ( Distinguished Encoding Rules [X.690] ).
3 - PER ( Packed Encoding Rules ) Aligned [X.691].
4 - PER Unaligned [X.691].
5 - CER ( Canonical Encoding Rules [X.690] ).
6-253 - available for assignment, see section 6.
254 - private. This subcoding will never be assigned to a standard
set of encoding rules. An OID preceded by a one octet unsigned
length of OID appears at the beginning of the data area after
the ASN coding OID.
255 - reserved.
2.2.2 MIME Subcodings
If the coding octet indicates the data is MIME structured, the
precise encoding is given by the subcoding octets as listed below.
MIME SUBCODINGS
0 - reserved, see section 6.
1 - 7bit.
2 - 8bit.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT The Kitchen Sink Resource Record
3 - binary.
4 - quoted-printable.
5 - base64.
6 - 253 - available for assignment, see section 6.
254 - private. The data portion must start with an "x-" or "X-"
token denoting the private content-transfer-encoding immediately
followed by one null (zero) octet followed by the remainder of
the MIME object.
255 - reserved, see section 6.
2.2.3 Text Subcodings
If the coding octet indicates the data is text, the exact encoding of
the text items is indicated by the subcoding octet as follows:
TEXT SUBCODINGS
0 - reserved, see section 6.
1 - ASCII.
2 - UTF-7 [RFC 1642].
3 - UTF-8 [RFC 2044].
4 - ASCII with MIME header escapes [RFC 2047].
5 - 253 - available for assignment, see section 6.
254 - private. Each text item must start with a domain name [RFC
1034] in wire format without compression denoting the private
text encoding immediately followed by the remainder of the text
item.
255 - reserved, see section 6.
3. Master File Representation
SINK resource records may appear as lines in zone master files. The
meaning, coding, and subcoding appear as unsigned decimal integers.
The data portion can be quite long. It is represented in base 64
[RFC 2045] 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 data. These substrings can span
lines using the standard parenthesis notation. (This type of base64
master file data is also required to support the DNS KEY and SIG
security RRs [RFC 2535].)
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT The Kitchen Sink Resource Record
4. Performance Considerations
Currently DNS is optimized for small data transfers, generally not
exceeding 512 octets including overhead. Larger transfers are less
efficient but do work correctly and efforts are underway to make them
more efficient.
It is easy to create very large RRs or RR sets using SINK. DNS
administrators should think about this and may wish to discourage
large RRs or RR sets. Consideration should also be given to putting
zones from which large RRs or RR sets will be commonly retrieved on
separate hosts which can be tuned for the load this will represent.
5. Security Considerations
Since the SINK resource record can be used to store arbitrary data in
the DNS, this data could have security consequences, particularly if
it is control, executable, macro, or interpretable information or
very large and might cause buffer overflow. Due care should be
taken.
[RFC 2535] covers data original authentication of the data in the
domain name system including SINK RRs.
6. IANA Considerations
Assignment of specific meaning to the values listed herein as
"reserved" requires an IETF standards action.
All other assignments of available meaning, coding, or subcoding
octet values are by IETF consensus.
The many provisions for private indicita specified by separately
allocated OIDs, domain names, or URIs should cover most requirements
for private or proprietary values.
7. 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
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT The Kitchen Sink Resource Record
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.
D. Eastlake 3rd [Page 10]
INTERNET-DRAFT The Kitchen Sink Resource Record
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 1642] - D. Goldsmith, M. Davis, "UTF-7 - A Mail-Safe
Transformation Format of Unicode", 07/13/1994.
[RFC 2044] - F. Yergeau, "UTF-8, a transformation format of Unicode
and ISO 10646", 10/30/1996.
[RFC 2045] - N. Freed, N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
12/02/1996.
[RFC 2046] - N. Freed, N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", 12/02/1996.
[RFC 2047] - K. Moore, "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
12/02/1996.
[RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", August 1998.
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
[X.680] - ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998,
Information Technology - Abstract Syntax Notation One (ASN.1):
Specification of Basic Notation
[X.681] - ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998,
Information Technology - Abstract Syntax Notation One (ASN.1):
Information Object Specification
[X.682] - ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998,
Information Technology - Abstract Syntax Notation One (ASN.1):
Constraint Specification
[X.683] - ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998,
Information Technology - Abstract Syntax Notation One (ASN.1):
Parameterization of ASN.1 Specifications
[X.690] - ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
Information Technology - ASN.1 Encoding Rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
D. Eastlake 3rd [Page 11]
INTERNET-DRAFT The Kitchen Sink Resource Record
Distinguished Encoding Rules (DER)
[X.691] - ITU-T Recommendation X.691 (1997) | ISO/IEC 8825-2:1998,
Information Technology - ASN.1 Encoding Rules: Specification of
Packed Encoding Rules (PER)
Author's Address
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road
Carmel, 10512 USA
Telephone: +1 914-276-2668 (h)
+1 914-784-7913 (w)
FAX: +1 914-784-3833 (w)
EMail: dee3@us.ibm.com
Expiration and File Name
This draft expires March 2000.
Its file name is draft-ietf-dnsind-kitchen-sink-02.txt.
D. Eastlake 3rd [Page 12]

420
doc/expired/draft-ietf-dnsind-local-compression-05.txt
View File

@@ -1,420 +0,0 @@
INTERNET-DRAFT Peter Koch
Expires: December 1999 Universitaet Bielefeld
Updates: 1035, 1183, 2163, 2168, 2535 June 1999
A New Scheme for the Compression of Domain Names
draft-ietf-dnsind-local-compression-05.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 December 1999 [Page 1]
INTERNET-DRAFT DNS Compression June 1999
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Domain names herein are for explanatory purposes only and should not
be expected to lead to useful information in real life [RFC2606].
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 December 1999 [Page 2]
INTERNET-DRAFT DNS Compression June 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 December 1999 [Page 3]
INTERNET-DRAFT DNS Compression June 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 a.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 December 1999 [Page 4]
INTERNET-DRAFT DNS Compression June 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 [RFC2535] mandate that domain names in
RDATA be signed only in expanded, lower case format. For RR types
using local compression the specification is changed as follows:
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 December 1999 [Page 5]
INTERNET-DRAFT DNS Compression June 1999
the RDATA section are treated as arbitrary data and can be cached and
verified by resolvers not aware of the particular RR type. Old RR
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.
Currently slave servers store zones in text format and re-encode the
data into wire format, e.g. after a restart. This encoding must be
unique to ensure signature validity. To achieve this, local
compression MUST be applied optimally, i.e. every domain name must be
compressed as far as possible and each local compression pointer must
point to the earliest available target (including the owner).
6. Interaction with Binary Labels
When constructing local compression pointers into the owner name,
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 [RFC2535], section 4.1.3.
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 [RFC2535], PX [RFC2163], NXT [RFC2535],
Koch Expires December 1999 [Page 6]
INTERNET-DRAFT DNS Compression June 1999
SRV [RFC2052], NAPTR [RFC2168], KX [RFC2230]. Some specifications do
not mention DNS compression at all, others explicitly suggest it and
only in part identify interoperability issues. Only the KX and SRV
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
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
Koch Expires December 1999 [Page 7]
INTERNET-DRAFT DNS Compression June 1999
[RFC1035] Mockapetris,P., "Domain Names - Implementation and
Specification", RFC 1035, STD 13, November 1987
[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
[RFC2052] Gulbrandsen,A., Vixie,P. "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996
[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
[RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC
2535, March 1999
[RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
RFC 2606, BCP 32, June 1999
[EDNS0] Vixie,P., "Extension mechanisms for DNS (EDNS0)", draft-
ietf-dnsind-edns0-XX.txt, work in progress
[BINLABELS] Crawford,M., "Binary Labels in the Domain Name System",
draft-ietf-dnsind-binary-labels-XX.txt, work in progress
11. Author's Address
Peter Koch
Universitaet Bielefeld
Technische Fakultaet
Postfach 10 01 31
D-33501 Bielefeld
Germany
Koch Expires December 1999 [Page 8]
INTERNET-DRAFT DNS Compression June 1999
+49 521 106 2902
<pk@TechFak.Uni-Bielefeld.DE>
Koch Expires December 1999 [Page 9]

662
doc/expired/draft-ietf-dnsind-local-names-07.txt
View File

@@ -1,662 +0,0 @@
DNS Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT IBM
Expires December 1999 June 1999
draft-ietf-dnsind-local-names-07.txt
Local Domain Name System (DNS) Names
----- ------ ---- ------ ----- -----
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsind-local-names-07.txt.
Distribution of this document is unlimited. Comments should be sent
to the DNS mailing list <namedroppers@internic.net> or to the author.
This document is an Internet-Draft 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.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
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
It is increasingly common for their to be "local" domain names which
are not intended to be seen from the global Internet. In some cases
this if for policy reasons, in other cases because they map to IP
addresses or other data which is only locally meaningful [RFC 1918,
2373].
A new top level domain (TLD) name (.local) is reserved and a name
structure suggested below this TLD such that local private DNS zones
can safely be created without fear of conflict if these names should
leak out of a private enclave. It addition, a method of providing
DNS service for these names is suggested such that they are
maintained privately, similar to the reserved private IP addresses,
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT Local DNS Names
yet locally appear to be part of the global DNS name tree and are
reachable by a local resolver with no special knowledge. Additional
second level domain names are assigned under this TLD for IPv6 link
and site local addresses and loopback functions.
Acknowledgments
The valuable contributions of the following persons are gratefully
acknowledged:
Dan Harrington
Michael A. Patton
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT Local DNS Names
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Acknowledgments............................................2
Table of Contents..........................................3
1. Introduction............................................4
2. Local Names Via The .local Top Level Domain.............5
2.1 Local DNS Server Specifics.............................7
2.2 Local in-addr.arpa Zones...............................8
2.3 Name Conflicts.........................................8
2.4 Nested Enclaves........................................9
3. Other Names in .local...................................9
4. Security Considerations.................................9
4.1 Strength of Privacy Offered............................9
4.2 Interaction with DNSSEC...............................10
References................................................11
Author's Address..........................................11
Expiration and File Name..................................11
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT Local DNS Names
1. Introduction
The global Internet Domain Name System (DNS) is documented in [RFC
1034, 1035, 1591, 2606] and numerous additional Requests for Comment.
It defines a tree of names starting with root, ".", immediately below
which are top level domain names such as .com and .us. Below top
level domain names there are normally additional levels of names.
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 for the resource.
In the realm of IP addresses, this has been accomplished by reserving
three blocks of IPv4 addresses as documented in [RFC 1918] and by
allocating parts of the IPv6 address space for link and site local
addresses [RFC 2373]. Familiarity with the contents of these RFCs is
assumed. Addresses in these blocks are not to be globally routed.
In the DNS area, local private names have generally been achieved in
the past by "splitting" DNS at the enclave boundary, giving different
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 concept.
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. By
implication, the same would be true of IPv6 local addresses. This
RFC provides the recommended way to accomplish such private IP
address hiding and carves out a limited exception thereto for the
addresses of the servers for some zones which are children of the
.local top level domain name.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT Local DNS Names
2. Local Names Via The .local Top Level Domain
The fundamental idea, as described in more detail below, is to define
second level domains under .local which are served by DNS name
servers that have private IP addresses. These server's addresses
would only be routed within the domain to which the names are local.
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
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT Local DNS Names
Starting at the bottom, pubhost6 is intended to illustrate an
ordinary host connected to the Internet with domain name
pubhost6.example.com. Though not indicated in the above diagram,
every DNS zone is in fact served by at least two hosts (and some but
substantially more). The addresses of the servers for the root (.),
.com, and example.com zones would all be in the public portion of the
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
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT Local DNS Names
having the host answer to both a public IP address stored under the
public name and a private IP address stored under the private name.
In the later case you could even also store the public address along
with the private address under the private name.
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.
D. Eastlake 3rd [Page 7]
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 and ip6.int zones. Because
of the fixed naming within this zone, different names with different
numbers of servers or different addresses can not be provided. As
with the forward .local entries, the actual NS RRs in the servers
serving the private portions of the inverse in-addr.arpa will
dominate. When one of these is queried by a resolver, it can provide
information on additional servers for that particular subzone in the
private IP address portion of the in-addr.arpa tree.
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.example
as a globally accessible host and
host2.company.example.b3.local
as a host for internal use only. The global name could normally be
resolvable anywhere on the Internet while the local name could not be
resolved anywhere except within the company enclave.
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.example and host4.school.ac.example.b3.local existed,
then a local reference to "host4" would be ambiguous and could lead
to either machine depending on the order of qualifications tried.
This order could even be different in different pieces of local
software or on different local hosts, resulting in substantial
confusion. For this reason, it is strongly recommended that disjoint
name sets be used for global and local entity unqualified domain
names and that fully qualified domain names be used wherever
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT Local DNS Names
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 and interactions with DNS security.
4.1 Strength of Privacy Offered
Local names, as proposed herein, are not intended to be a strong
security mechanism.
The privacy of the DNS information protected by storing it in servers
with private IP addresses is weak. It is completely dependent on the
integrity of enclave perimeter routing to make these servers
inaccessible. And it may occasionally leak out in any case due to
inclusion in email address fields, web pages, and the like, although
such leakage should be no worse than current split DNS
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT Local DNS Names
implementations of DNS data hiding.
Software should not depend on local names being accessible only
within a particular enclave as someone could deliberately create the
same names within a different enclave. This is true even if, as
recommended herein, the names incorporate the domain name of the
original enclave in an attempt to avoid such conflicts.
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 [RFC 2535] within the enclave. The enclave owner should
generate their own keys and sign their subzone of .local. However, a
signed copy of their public key can not be included in the .local
zone as it is different for every enclave. Thus, to authenticate the
.local subzone contents, it will be necessary to sign the KEY RR at
the apex of the local subzone of .local with the .local zone key or
another key that is trusted by local resolvers or staticly configure
the public key for the .local subzone in local resolvers.
D. Eastlake 3rd [Page 10]
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.
RFC 2373 - R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", July 1998
RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
RFC 2606 - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
Author's Address
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 10512 USA
Telephone: +1 914-276-2668 (h)
+1 914-784-7913 (w)
FAX: +1 914-784-3833 (w)
EMail: dee3@us.ibm.com
Expiration and File Name
This draft expires December 1999.
Its file name is draft-ietf-dnsind-local-names-07.txt.
D. Eastlake 3rd [Page 11]
D. Eastlake 3rd [Page 12]

560
doc/expired/draft-ietf-dnsind-rfc2052bis-02.txt
View File

@@ -1,560 +0,0 @@
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]

648
doc/expired/draft-ietf-dnsind-rollover-00.txt
View File

@@ -1,648 +0,0 @@
INTERNET-DRAFT DNSIND Key Rollover
UPDATES RFC 1996 April 1999
Expires October 1999
draft-ietf-dnsind-rollover-00.txt
Domain Name System (DNS) Security Key Rollover
------ ---- ------ ----- -------- --- --------
Donald E. Eastlake 3rd, Mark Andrews
Status of This Document
This draft, file name draft-ietf-dnsind-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 working group
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.''
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
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 will be necessary for
this to be practical and is specified herein.
[Note: this draft has been moved to dnsind from dnssec as part of the
ongoing combination of these working groups. It would have been
draft-ietf-dnssec-rollover-01.txt otherwise.]
D. Eastlake 3rd, M. Andrews [Page 1]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. Key Rollover Scenario...................................3
3. Rollover Operation......................................5
3.1 Rollover to Parent.....................................5
3.2 Rollover to Children...................................6
4. Secure Zone Cuts and Joinders...........................7
5. Security Considerations.................................8
6. IANA Considerations.....................................9
References................................................10
Authors Address...........................................10
Expiration and File Name..................................11
D. Eastlake 3rd, M. Andrews [Page 2]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
1. Introduction
The Domain Name System (DNS) [RFC 1034, 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 [RFC 2535].
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
[RFC 2541].
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 hundred of thousands of new signatures on
the existing child public keys to the child zones.
It will be impractical to handle such update volumes manually on a
case by case basis. The bulk of such key rollover updates must be
automated.
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC 2119].
2. Key Rollover Scenario
Although DNSSEC provides for the storage of other keys in the DNS for
other 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. Similarly, old parent
SIGs should be retained for a short time after a parent KEY(s) roll
over and new parent SIGs have been installed.
D. Eastlake 3rd, M. Andrews [Page 3]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
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/SIG RRsets due to
simultaneous expiration of SIGs everywhere in the DNS. But these
assumptions do not hold. 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 generally be left due to
clock skew, RR retention by applications, and the like. Retaining
old KEYs for a while after rolling over to new KEYs will be necessary
in practical cases.
Assume a middle zone with a secure parent and a secure child 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 middle zone. (These RRs may also
exist at the leaf node for this zone in its parent if the parent
chooses to store them there.) The contents of the middle zone and the
zone KEY RRs of its secure child will have SIGs under the old key.
The middle 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. The signature on both is needed so the
old KEY can be retain for the period it might be needed to
authenticate old SIGs. The middle zone 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 its zone. Finally, it
needs to give new SIG RRs to its child that cover its KEY RRs so it
must signal its children to ask for such SIG RRs.
BEFORE ROLLOVER SHORTLY AFTER AFTER ROLLOVER
p.x KEY P1 p.x KEY P1 p.x KEY P1
p.x SIG(KEY) P1 p.x SIG(KEY) P1 p.x SIG(KEY) P1
p.x SIG(KEY) GP p.x SIG(KEY) GP p.x SIG(KEY) GP
m.p.x KEY M1 m.p.x KEY M2 m.p.x KEY M2
m.p.x SIG(KEY) P1 m.p.x KEY M1 m.p.x SIG(KEY) P1
m.p.x SIG(KEY) M1 m.p.x SIG(KEY) P1 m.p.x SIG(KEY) M2
m.p.x SIG(KEY) M2
c.m.p.x KEY C1 c.m.p.x KEY C1 c.m.p.x KEY C1
c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) M2 c.m.p.x SIG(KEY) M2
c.m.p.x SIG(KEY) C1 c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) C1
c.m.p.x SIG(KEY) C1
p = parent, m = middle, c = child, GP = grandparent key
P* = parent key, M* = middle zone key, C* = child key
D. Eastlake 3rd, M. Andrews [Page 4]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
3. Rollover Operation
Rollover operations use a DNS request syntactically identical to the
UPDATE request [RFC 2136] (except that the operation code is ROLLOVER
which is equal to (TBD)) and use a new form of NOTIFY [RFC 1996].
Considerations for such requests to the parent and children of a zone
are givens below.
All rollover operations involve significant amounts of cryptographic
calculations. Appropriate rate limiting SHOULD be applied to avoid
denial of service attacks.
[This draft does not consider cross-certification key rollover.]
3.1 Rollover to Parent
A zone rolling over its KEY RRset sends an upward ROLLOVER request to
its parent. Actually, it will normally do two upward ROLLOVERs, one
for a combined KEY RRset of its old and new KEYs and one for just its
new KEY RRset, as discussed above.
The server selection algorithm in [RFC 2136] section 4 should be
used. A child needs to be configured with or determine the name of
its parent but SHOULD NOT remember the location of its parent other
than via normal DNS caching of address RRs so that rollover will
continue to work if its parent servers are moved.
The ROLLOVER request Zone should be specified as the parent zone.
The request Update section has the new 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 child SIG or SIGs are the
requested inception and expiration times for the new parent SIG(s).
The "prerequisites" section has the old child KEY RRset with the
parent SIG (see next paragraph).
An upward ROLLOVER request MUST be signed and if not signed a BADAUTH
response generated. The signature MUST be under the previous zone
KEY, so the parent can validate it, or under a valid TSIG key
[draft-ietf-dnsind-tsig-*.txt] arranged with the parent. Including
the "prerequisite" section as specified above enables a parent that
keeps no record of its children's KEYs to still authenticate a
child's ROLLOVER request based on the old child KEY because the
parent is presented with its own SIG on the old KEY.
If the ROLLOVER command is erroneous or violates parental policy, an
Error response is returned. If a parent retains copies of its
children's KEYs, it may use that knowledge to validate ROLLOVER
D. Eastlake 3rd, M. Andrews [Page 5]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
request SIGs and ignore the "prerequisites" section.
If the ROLLOVER command is OK and the parent can sign online, its
response MAY include the new parent SIG(s) in the response Update
section. 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.
ROLLOVER response messages MUST always include the actual parent's
SOA signed with a key the child should recognize in the Additional
Information section (see section 4 below).
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). There
are several reasons for sending the ROLLOVER response regardless of
whether the new SIG RR(s) were sent in the original response. One is
to provide an indication to the operators of the zone in the event
someone is trying to hijack the zone. Another is that this maximizes
the probability of the response getting through.
Although the parent zone need not hold or serve the child's key, if
it does the ROLLOVER command REQUEST SHOULD NOT automatically 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 of future
authoritative existence to the controller of the child private key
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 secure 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). The
parent simply notifIES the child via a rollover NOTIFY [RFC 1996]
D. Eastlake 3rd, M. Andrews [Page 6]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
that the parent KEY(s) have changed. The child then proceeds to do
an upward ROLLOVER request, as described in 3.1 above to obtain the
new parental SIG(s).
A rollover NOTIFY is a NOTIFY request [RFC 1996] that has a QTYPE of
SIG and the owner name of the child zone. The answer section has the
current parent SOA signed by a key the child will know (see section
4).
A rollover NOTIFY MUST be signed and if not signed a BADAUTH response
generated. The signature MUST be under the previous parental zone
KEY, so the child can validate it, or under a valid TSIG key [draft-
ietf-dnsind-tsig-*.txt] negotiated between parent and child.
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 same 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
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. As with all rollover operations, care
should be taken to rate limit these messages so prevent them being
used to facilitate a denial of service attack.
Once the message has been sent (or suppressed if so configured) to
the child zone's administrator the master server for the child zone
is free to respond to the rollover NOTIFY request.
4. Secure Zone Cuts and Joinders
There are two other events that have some similarity to key rollover.
The first is when a secure zone the is more than one level deep has a
zone cut introduced inside it. For example, assume zone example.com
has a.b.c.example.com, d.b.c.example.com and e.example.com in it. A
zone cut could be introduced such that b.c.example.com became a
separate child zone of example.com. A real world exampe would be a
company that structures its DNS as host.branch.company.example. It
might start out will all of these names in one zone but later decide
to delegate all or some of the branches to branch zone file
maintainers.
D. Eastlake 3rd, M. Andrews [Page 7]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
The second is when a secure zone absorbs a child zone eliminating a
zone cut. This is simply the inverse of the previous paragraph.
From the point of view of the parent zone above the splitting zone or
above the upper of the two combining zones, there is no change.
When a zone is split by introducing a cut, the newly created child
must be properly configured.
However, from the point of view of a child of the splitting zone
which becomes a grandchild or a grandchild that becomes a child due
to joinder, there is a change in parent name. Therefore, in general,
there is a change in parent KEY(s). Unless the entity that handles
rollovers for the zone whose parent name has changed is appropriately
updated, future automated rollover will fail because it will be sent
to the old parent.
For this reason and so that other consistency checks can be made, the
parent SOA and SIG(SOA) are always included in the Answer section of
rollover NOTIFY requests and in ROLLOVER responsess. For automated
rollover to the new cut or joined state to work, these SOAs must be
signed with old KEY(s) of the former parent so the signatures can be
validated by the zone whose parent name is changing. In the case of
a joinder, if the private key of the pinched out middle zone is not
available, then manual update of the former grandchild, now child,
will be necessary. In the case of introducing a cut, operational
coordination with the former parent, now grandparent, signing the
initial updates to the former child, now grandchild, will be needed
to automate the reconfiguration of the zones.
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 authenticated by request SIG(s)under the
old zone KEY(s) of the requestor [RFC 2535]. 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-dnsind-tsig-*.txt]. (TSIG
security could be used to rollover a zone to unsecured and to
D. Eastlake 3rd, M. Andrews [Page 8]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
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.
6. IANA Considerations
The DNS operation code (TBD) is assigned to ROLLOVER. There are no
other IANA considerations in this document.
D. Eastlake 3rd, M. Andrews [Page 9]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
References
[RFC 1034] - "Domain names - concepts and facilities", P.
Mockapetris, 11/01/1987.
[RFC 1035] - "Domain names - implementation and specification", P.
Mockapetris, 11/01/1987.
[RFC 1996] - "A Mechanism for Prompt Notification of Zone Changes
(DNS NOTIFY)", P. Vixie, August 1996.
[RFC 2119] - "Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner. March 1997.
[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]
[RFC 2535] - "Domain Name System Security Extensions", D. Eastlake.
March 1999.
[RFC 2541] - "DNS Security Operational Considerations", D. Eastlake.
March 1999.
Authors Address
Donald E. Eastlake 3rd
IBM
65 Sindegan Hill Road, RR #1
Carmel, NY 10512
Telephone: +1 914-276-2668 (h)
+1 914-784-7913 (w)
FAX: +1 914-784-3833 (w)
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 10]
INTERNET-DRAFT April 1999 DNSSEC Key Rollover
Expiration and File Name
This draft expires in October 1999.
Its file name is draft-ietf-dnsind-rollover-00.txt.
D. Eastlake 3rd, M. Andrews [Page 11]

663
doc/expired/draft-ietf-dnsind-sec-rr-00.txt
View File

@@ -1,663 +0,0 @@
DNSIND WG Edward Lewis
INTERNET DRAFT NAI Labs
Category: I-D Jerry Scharf
ISC
Olafur Gudmundsson
NAI Labs
June 25, 1999
The SEC Resource Record
<draft-ietf-dnsind-sec-rr-00.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 authors or the DNSIND WG mailing list
namedroppers@internic.net.
This draft expires on December 25, 1999.
Copyright Notice
Copyright (C) The Internet Society (1999). All rights reserved.
Abstract
A new DNS reseource record, the SECurity RR, is defined to address
concerns about the parent zone's holding of the child zone's KEY RR
set. These concerns are addressed in a manner that retains the
information needed by a secure resolver when asking a parent zone
about the child zone. This proposal updates RFC 2535 and RFC 2181.
1. Introduction
DNS security extensions require a signed zone to hold KEY RR sets for
each of its delegations. This requirement has four negative
implications for the top level domains, which, for the most part,
consist of delegation points. (These issues also impact other
delegating zones, these problems are not unique to the TLDs.)
Addressing these concerns by removing the requirement for the KEY RR
in the parent has an adverse effect on secure resolution of DNS
Expires December 25, 1999 [Page 1]
Internet Draft June 25, 1999
signatures. A new DNS reseource record, the SECurity RR, is defined
to address these concerns.
The Zone Key Referral, described in another draft by the same authors,
is one proposed response to the concerns about parent's holding child
keys. However, that proposal has two drawbacks. One, it results in
two KEY RR sets at a delegation, one in the parent and one in the
child, which differ. It also does not address the expression of
security parameters, such as whether or not the child zone uses the
NXT record (which is currently mandatory).
This document will begin by repeating the arguments against the
holding of keys at the parent as presented in the Zone Key Referral.
The document will then present the need for information about the
child to be held in parent. Following this, the SEC RR will be
defined, its master file representation discussed, and implications on
name servers.
(Editorial note. Sections 1.1 through 1.5 are copied nearly verbatim
from the Zone Key Referral so that retirement of that draft will not
cause a problem.)
1.1 Reasons for removing the KEY data from the parent
There are a number of different reasons for the removal of the KEY RR
from the parent. Reasons include:
o the performance impact that holding keys has on name servers
o the problem of updating a widely delegated parent zone on demand
o statements in RFC 2181 on authoritative data at delegations
o perceived liability of the operator of a name server or registry
1.2 Performance Issues
A sample zone will be used to illustrate the problem. The example
will part from reality mostly in the length of zone names, which
changes the size of the owner and resource record data fields.
Expires December 25, 1999 [Page 2]
Internet Draft June 25, 1999
# $ORIGIN test.
# @ IN SOA <SOA data>
# IN SIG SOA <by test.>
# IN KEY <1024 bit zone key>
# IN SIG KEY <by test.>
# IN SIG KEY <by .>
# IN NS ns.test.
# IN SIG NS <by test.>
# IN NXT my-org.test. NS SOA SIG KEY NXT
# IN SIG NXT <by test.>
#
# my-org IN KEY <1024 bit zone key>
# IN KEY <1024 bit zone key>
# IN SIG KEY <by test.>
# IN NS ns1.my-org.test.
# IN NS ns2.my-org.test.
# IN NXT that-org.test. NS SIG KEY NXT
# IN SIG NXT <by test.>
#
# that-org IN KEY 0xC100 3 255
# IN SIG KEY <by test.>
# IN NS ns1.that-org.test.
# IN NS ns2.that-org.test.
# IN NXT test. NS SIG KEY NXT
# IN SIG NXT <by test.>
In this zone file, "my-org" is a delegation point of interest with two
registered public keys. Presumably, one key is for signatures
generated currently and the other is for still living and valid but
older signatures. "that-org" is another delegation point, with a NULL
key. This signifies that this zone is unsecured.
To analyze the performance impact of the storing of keys, the number
of bytes used to represent the RRs in the procotol format is used.
The actual number of bytes stored will likely be higher, accounting
for data structure overhead and alignment. The actual number of bytes
transferred will be lower due to DNS name compression.
The number of bytes for my-org's two 1024-bit keys, two NS records,
NXT and the associated signatures is 526. (1024 bit RSA/MD5 keys were
used for the calculation.) The bytes needed for that-org (with the
NULL key) is 346. Currently, there are close to 2 million entries in
com., so if we take my-org as a typical domain, over 1GB on memory
will be needed for com. The zone keys used in the example are set to
1024 bits. This number may range from as low as 512 bits upwards to
over 3000 bits.
The increased size of the data held for the zone cuts will have two
impacts at the transport and below layers. Bandwidth beyond that
currently needed will be used to carry the KEY records. The inclusion
of all of the child's keys will also push DNS over the UDP size limit
and start using TCP - which could cause critical problems for current
Expires December 25, 1999 [Page 3]
Internet Draft June 25, 1999
heavily used name servers, like the root and TLD name servers. EDNS0
[RFC-to-be] addresses expansion of UDP message size, which alleviates
this problem.
Another impact, not illustrated by the example, is the frequency of
updates. If each time a public key for my-org is added or deleted,
the SOA serial number will have to increase, and the SOA signed again.
If an average zone changes the contents of its key RR set once per
month, there will be on average 45 updates per minute in a zone of 2
million delegations. (This estimate does not address the fact that
signatures also expire, requiring a new signing of the zone
periodically.)
1.3 Security Incident Recovery (w/ respect to keys only)
Once a zone administrator is alerted that any key's private
counterpart has been discovered (exposed), the first action to be
taken is to stop advertising the public key in DNS. This doesn't end
the availability of the key - it will be residing in caches and given
in answers from those caches - but is the closest action resembling
revokation available in DNS.
Stopping the advertisement in the zone's name servers is as quick as
altering the master file and restarting the name server. Having to do
this in two places will will only delay the time until the recovery is
complete.
For example, a registrar of a top level domain has decided to update
its zone only on Mondays and Fridays due to the size of the zone. A
customer/delegatee is the victim of a break in, in which one of the
items taken is the file of private keys used to sign DNS data. If this
occurs on a Tuesday, the thief has until Friday to use the keys before
they disappear from the DNS, even if the child stops publishing them
immediately.
If the public key set is in the parent zone, and the parent zone is
not able to make the change quickly, the public key cannot be revoked
quickly. If the parent only refers to there being a key at the child
zone, then the child has the agility to change the keys - even issue a
NULL key, which will force all signatures in the zone to become
suspect.
1.4 DNS Clarifications
RFC 2181, section 6, clarifies the status of data appearing at a zone
cut. Data at a zone cut is served authoritatively from the servers
listed in the NS set present at the zone cut. The data is not
(necessarily) served authoritatively from the parent. (The exception
is in servers handling both the parent and child zone.)
Section 6 also mentions that there are two exceptions created by
DNSSEC, the NXT single record set and the KEY set. This proposal
addresses the exception relating to the KEY set, by removing the set
Expires December 25, 1999 [Page 4]
Internet Draft June 25, 1999
from the parent. The SEC RR is introduced and belongs in the parent
zone, there is no counterpart in the child (at the apex).
1.5 Liability
Liability is a legal concept, so it is not wise to attempt an
engineering solution to it. However, the perceived liability incurred
in using DNSSEC by registrars may prevent the adoption of DNSSEC.
Hence DNSSEC should be engineered in such a way to address the
concern.
One source of liability is the notion that by advertising a public key
for a child zone, a parent zone is providing a service of security.
With that comes responsibility. By having the parent merely indicate
that a child has a key (or has no key), the parent is providing less
in the way of security. If the parent is wrong, the potential loss is
less. Instead of falsely authenticated data, configuration errors
will be apparent to the resolving client.
Whether or not the KEY RR remains advertised in the parent zone or the
SEC RR is in place, the parent zone administrators still have to
adhere to proper key handling practices, which are being documented in
DNSOP draft. In particular, the parent has to be sure that the keys
it is signing for a child have been submitted by the true
administrator of the the child zone, and not submitted by an imposter.
1.6 The needs of the resolver
Now that the reasons for removing the child's keys from the parent
zone have been presented, reasons why something must take their place
are presented. A "secure" resolver is a DNS resolver that receives an
answer and, if a signature arrives, verifies the signature. Most
often, this operation will happen in resolvers that are part of name
servers, as opposed to general purpose hosts.
The first step in authenticating a DNS response is to see if the data
is accompanied by a signature. There are five possible outcomes.
Three results are not desirable, a signature may arrive but shouldn't,
no signature arrives but should, or a signature arrives but uses the
wrong cryptographic algorthm Two outcomes can be considered
successful, a signature arriving with the correct algorithm or no
signature arrives and shouldn't. (There is one other case - a
signature generated with an inappropriate key - which is a matter
beyond the scope of this draft.)
Since the resolver can not instantly know whether a signature is
expected, the resolver must start a discovery process. This process
can be done by the resolver querying zones between the root and the
desired domain for information about the next successive zones.
(Optimizing this search is not presented here.) For this search to be
successful, the parent must hold something that indicates the status
of the child's security, so the resolver may search with certainty.
While refraining from using the word "policy" to describe the data,
the phrase "security parameters" is used.
Expires December 25, 1999 [Page 5]
Internet Draft June 25, 1999
The security parameters of a zone are not entirely defined yet, and
will remain open until a critical mass of operations experience is
gained. Initially, the following information is known to be needed.
The set of algorithms in use by the zone.
KEY RRs and SIG RRs have protocol fields indicating how the key is
made. For now, two are in distribution, a value of 1 for RSA/MD5 and
3 for DSA. Unfortunately, the value are numeric in 8 bits, so a
bitmap representation cannot be used.
The mechanism for negative answers.
Currently, the NXT is mandatory, liked by some administrators and
disliked by other administrators. NXTs cannot be made optional, doing
so makes them obsolete. (An attacker can make the responses look like
a zone doesn't use NXTs, even if the zone does.) If the choice of NXT
or no NXT can be securely indicated, then this is solved. There have
been discussions on alternatives to the NXT record. By allowing a
zone to indicate the style of negative answer in use, alternatives can
be installed in experimental zones.
Signature policy.
This is an untested issue. Expressing a policy, such as whether
multiple algorithms are used, whether verification of one signature
needed or all signatures, etc., has not been fully studied.
2. The SEC RR
The SEC RR is a record that describes the DNS security parameters of
the owner. The owner MUST also have an NS RR set, i.e., the owner
MUST be a cut point. A signed zone MUST have a SEC RR set for each
delegation point.
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Negative Answer Bitmap | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ Security Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RDATA of the SEC RR
The SEC RR RDATA contains two data fields. One is a 16-bit field
acting as a bitmap to indicate the means used to signify a negative
answer. The other field is an unbounded field of option-value pairs
indicating other salient settings for the zone. The latter field is
not padded to any particular byte boundary.
The SEC RR is answered authoritatively from the parent zone, and is
signed by the parent. A properly configured delegation point in the
parent would have just an SEC RR, records used for negative answering,
and a glue NS set. The corresponding point in the child (the zone's
apex) would have the SOA, KEY set, NS records, negative answer
Expires December 25, 1999 [Page 6]
Internet Draft June 25, 1999
records, and other desired and legal RR sets. SIG RR's appear in both
the parent and child side of the delegation.
There is no other special processing of the SEC RR set. It is used in
a reply as an answer when it is the subject of a direct query (QTYPE
IS SEC) or when a QTYPE=ANY reaches the delegating zone. If a name
server is authoritative for both the parent and child, the SEC is
included in the ANY reply for the delegation point.
(Editorial note: this region is in particular need of careful review.)
The SEC RR for a name SHOULD be supplied optionally in the additional
data section if the CD bit is not set whenever a zone's NS or KEY set
is requested. If a request for a KEY set is sent to a parent-only
server and the server is not recursive, the server should add the SEC
record to the additional section of the referral message.
If a name server authoritative for a child zone is asked for its SEC
RR and the server has never learned the SEC RR (whether through
caching the record or by also loading the parent zone), the server MAY
answer with a negative answer. The resolver seeking a SEC RR SHOULD
know to ask for this from a parent-serving name server.
2.1 Negative Answer Bitmap
The Negative Answer Bitmap indicates the mechanism for use in denying
the existance of data. The bitmap is 16 bits, the most significant
bit called 0, least significant is 15.
Bit 0 = The parent doesn't know what the child uses (1=Yes)
Bit 1 = The child signs its negative answers (1=Yes)
Bit 2 = The child follows traditional DNS rules (1=yes)
Bit 3 = The child uses the NXT record (1=yes)
Bit 14 = The child uses a locally defined mechanism (1=yes)
Bit 15 = The length of the bit field has been extended (1=yes)
Bits 4 through 14 are currently unassigned, and are under the purview
of IANA. Bit 15 MUST BE zero. (This specification must be
superceeded to define an extension mechanism.)
A zone may use multiple mechanisms to indicate a negative answer. A
zone SHOULD expect that a resolver finding any one of the mechanisms
used in a reply indicates a negative answer, i.e. the mechanisms are
OR'd together.
The only illegal values for this bit field are:
Bit 0 = 1 and any other bit turned on
Bit 0 = 0, Bit 1 = 1, and no other bit turned on
Bit 15 = 1
2.1.1 Bit 0 (Better titles will be attached later)
The situation in which this bit is on should not arise, but it is
defined to be safe. The philosophy behind this is that security
Expires December 25, 1999 [Page 7]
Internet Draft June 25, 1999
parameters should always be made explicit, including when a sitation
is unclear.
2.1.2 Bit 1
This bit indicates that the child attachs SIG records to the resource
records used in the negative answer. For example, this may indicate
that the reslover should expect to see a SIG (NXT) when an NXT is
returned.
2.1.3 Bit 2
The child will answer with an SOA or any of the other means used in
the past to indicate a negative answer. (I think a reference to the
negative answer/cache document should go here.)
2.1.4. Bit 3
The child uses the NXT as defined in RFC 2535. This document declares
that the use of the NXT is optional, a deviation from RFC 2535.
2.1.5 Bit 14
The child is using a mechanism that is not globally defined. A zone
should be in such a state for only experimental reasons and realize
that in this state, the negative answers it gives may not be useful to
the general population of resolvers.
2.1.6 Bit 15
As of this specification, this bit must be 0 (zero).
2.1.7 Unallocated bits
The remainder of the bits must also be zero. A procedure will be
defined for allocating them.
2.2 Security Parameters
The Security parameters is a sequence of options and values. An
option is a numeric indicatior of the parameter. The value is usually
either a yes or no, or a enumerated value. In rare instances, an
option may require variable length data, in this case a triplet of
option-length-value is used. The presence of the length field is
indicated by the most significant bit in the option field being 1.
Due to the nature of the SEC RR, the length field is not commonly
used.
The option field is 8 bits. The most significant bit of the options
field is turned on if there is a length field. The value field is
also 8 bits. If the option-length-value is needed, the length is 8
bits and contains the number of octets comprising the value. No
padding is used.
Expires December 25, 1999 [Page 8]
Internet Draft June 25, 1999
An option may appear multiple times in the Security Parameters. The
sequencing of the options is not significant. If two options
contradict each other, this is an error, and is noted by the resolver.
A self-contradictory SEC RR is a security error and data from the zone
covered by it SHOULD be considered at risk.
Option Values are
0 Reserved
1 Zone is unsigned
2 Key Algorithm in use
3 Signing policy
0x70-0x7F Locally defined (no length field)
0xF0-0xFF Locally defined (uses length field)
All unassigned option values are under the control of IANA. Values 0
to 127 do not use the length field, values 128 to 255 do use the
length field. The option value is to be treated as unsigned.
2.2.1 Option 0
This option is reserved for future definition.
2.2.2 Option 1
The parent has not signed a KEY RR for the child, therefore the child
zone has no DNSSEC approved signing keys. If this option is not
present, then the resolver SHOULD assume that there are zone keys in
the child zone.
If the value of this is non-zero, this assertion is true. If the
value is zero, this assertion is false. If the parent has signed keys
for the child, the value is zero, however, in this case, the parent
SHOULD NOT include this option in the security parameters.
It is tempting to exclude an unsigned zone option from this list,
relying on the absence of any in use key algorithms (option 2) to
imply that the zone is unsigned. The unsigned option is included to
make this information explicit, so that when analyzing a running zone,
it is obvious to an administrator that a zone is unsigned.
2.2.3 Option 2
The parent has signed a key for the child which claims a particular
algorithm. This value field is equal to that of the algorithm field
of the triggering KEY RR.
Option 2 can be repeated for different algorithms. It is not
necessary to have multiple Option 2 entries with the same key
algorithm value.
If Option 1 and Option 2 appear in the same SEC RR, this is a
self-contradictory record. If neither Option 1 nor Option 2 appear,
this also constitues a self-contradictory record.
Expires December 25, 1999 [Page 9]
Internet Draft June 25, 1999
2.2.4 Option 3
The child has the option to require that all material signatures
(those generated by DNSSEC-approved signing keys) must be validated
(within any temporal constraints) for the data to be considered valid.
The child may instead require that just one of the signatures be
validated. This may be a reflection of the manner in which a zone's
administration is shared amongst organizations.
If Option 3 is not present (and Option 2 is), the resolver SHOULD
assume that ALL (temporally valid) signatures are required. If the
parent includes at least one Option 2, it SHOULD specify an Option 3,
with a value indicated by the child.
Values for Option 3 are
0 Reserved
1 All signatures are required
2 One signature is required
256 Locally defined
All remaining values are under the control of IANA.
(Editorial note: whether the assumption that all signatures are
necessary or just one is sufficient in the absence of this option is
open to WG debate.)
2.2.5 Options 0x70-0x7F
This option is reserved for an organization to use locally, in an
experimental fashion. This option does not use the length field.
Global interpretation of this option is undefined.
2.2.6 Options 0xF0-0xFF
This option is reserved for an organization to use locally, in an
experimental fashion. This option uses the length field. Global
interpretation of this option is undefined.
3. Master File Representation
The SEC RR fields are to be represented as hexidecimal fields, with a
preceeding '0x', or in decimal format. Hexidecimal SHOULD be used.
For example, the SEC RR representing a zone that use signed NXT
records, and has one or more DSA keys, one or more RSA keys, and
requires that just one signature be verified would be:
myzone.test. 3500 IN SEC 0x5000 0x0201 0203 0302
(0x020102030302 is one field, hence one 0x prefix.)
Hex values for the security parameters MAY BE separated by
whitespace, as shown. DNS data display routines SHOULD substitute
Expires December 25, 1999 [Page 10]
Internet Draft June 25, 1999
mnemonics for these values, but MUST write the numeric form in master
files.
4. Signature Policy
The SEC RR must be signed by one or more zone keys of the parent
(delgating) zone, and the signatures must adhere to the parent's
policy.
The SEC RR for the root zone is the lone exception, it appears at the
apex of the root zone, and must be signed sufficiently by the root's
zone key or keys.
5. Cache Considerations
When a SEC RR set for a name is held in a cache, it will have a
credibility rating indicating that the data came from the parent
(unless the parent and child share servers). When data about the same
name arrives from the child, with a higher credibility, the newly
arrived data MUST NOT cause the cache to remove the SEC RR.
6. IANA Considerations
IANA is requested to assign this RR an type parameter for DNS, and to
assign the indicated option numbers and values when requests are
approved. The procedure for requesting new options and values will be
defined in future versions of this specfication.
7. Security Considerations
This record is designed to address the concerns of securing delegation
points and resolving the security of DNS answers. This record is
important to the security because it supplies needed information and
eases the burden of security on the DNS.
The SEC RR does require one piece of additional information not
addressed to date to be communicated from the parent to the child.
This is the signature policy. This will be needed in the operations
documents.
Editorial Note: This document would benefit by a companion document
describing the process of evaluating the signatures in DNS. Such a
document would provide clearer input to the security parameters field.
8. Editorial Considerations
Although somewhat detailed in this current description, this record is
still in the formative state. The -00 document has been quickly
written to test the waters for interest.
9. References
RFC 2535 is the prime DNSSEC definition. RFC 2181 is the Clarify
document. EDNS0 reference needed...
Expires December 25, 1999 [Page 11]
Internet Draft June 25, 1999
10. Acknowledgements
This record is a successor to the Zone Key Referral, originally
promoted by John Gilmore and Jerry Scharf. A DNSSEC workshop
sponsored by the NIC-SE in May 1999 provided the enlightenment that
expanded the Zone Key Referral into the SEC RR proposal.
11. Author's Addresses
Edward Lewis Jerry Scharf Olafur Gudmundsson
NAI Labs Internet Software Consortium NAI Labs
3060 Washington Road 950 Charter St 3060 Washington Rd
Glenwood, MD 21738 Redwood City, CA 94063 Glenwood, MD 21738
+1 443 259 2352 +1 650 779 7060 +1 443 259 2389
<lewis@tislabs.com> <scharf@vix.com> <ogud@tislabs.com>
12. 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 implmentation 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."
Expires December 25, 1999 [Page 12]

164
doc/expired/draft-ietf-dnsind-sigalgopt-00.txt
View File

@@ -1,164 +0,0 @@
Network Working Group R. Austein
draft-ietf-dnsind-sigalgopt-00.txt On Sabbatical
P. Vixie
Internet Software Consortium
October 1999
DNS SIGALGOPT
Status of this document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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>
Distribution of this document is unlimited. Please send comments to
the namedroppers@internic.net mailing list.
Abstract
This document describes a mechanism for conserving packet space in a
DNS response message in the presence of multiple DNSSEC signature
algorithms.
Motivation and Scope
DNSSEC [DNSSEC] specifies a general framework for attaching
cryptographic signatures to DNS resource records. The framework
includes provisions for multiple signature protocols, possibly even
on a per-name basis. While this open-ended framework is good and
useful, it poses a problem when multiple signature protocols are in
use and DNS message sizes are limited by the underlying UDP transport
packet size. EDNS0 [EDNS0] provides a way to specify a larger
Austein & Vixie Expires 18 April 2000 [Page 1]
draft-ietf-dnsind-sigalgopt-00.txt October 1999
payload size, but this still does not entirely solve the problem for
large RRsets. Worse, in cases where multiple signature algorithms
generate a response packet so large that it must be truncated, the
signatures that fit into the truncated response will be useless if
the resolver doesn't know how to verify signatures generated with
that algorithm.
This note proposes a way for a resolver to indicate which signature
algorithms it understands to a name server in the form of an ordered
list. When this mechanism is in use, the name server can conserve
packet space by (a) not sending signatures with algorithms that the
resolver will not understand, and (b) not sending multiple signatures
for the same resource records.
Mechanism
[DNSSEC] SIG RRs include a one-octet code indicating the algorithm
associated with a particular signature. The SIGALGOPT option defined
below allows the resolver to specify an ordered list of signature
algorithms using the same one-octet codes that DNSSEC uses.
SIGALGOPT is encoded n the variable RDATA part of the OPT pseudo-RR
in the DNS request (see [EDNS0]).
The OPTION-CODE for SIGALGOPT is [TBD].
The OPTION-DATA for SIGALGOPT is an ordered list of the one-octet
codes used by DNSSEC.
If the SIGALGOPT option in a query specifies multiple signature
algorithms and signatures using more than one of those algorithms are
available in the zone, the server must respond with the signatures
corresponding to the first algorithm on the SIGALGOPT list that
matches, omitting any signatures corresponding to the remaining
algorithms.
We have deliberately not provided a mechanism to return all the
matching signatures, because the purpose of the SIGALGOPT mechanism
is to minimize packet size. If the resolver wants to see all
available signatures, it should just leave off the SIGALGOPT option
entirely.
Security Considerations
Good question. What horrible things could a bad guy do by
creating/altering/deleting SIGALGOPT? Are any of the possible
attacks more interesting than denial of service?
Austein & Vixie Expires 18 April 2000 [Page 2]
draft-ietf-dnsind-sigalgopt-00.txt October 1999
IANA Considerations
SIGALGOPT will need an option code.
The signature algorithm codes themselves are borrowed from DNSSEC and
do not create any new issues for IANA.
References
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and
facilities", RFC 1034, November 1987.
[DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation
and specification", RFC 1035, November 1987.
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.
Author's addresses:
Rob Austein
On Sabbatical
sra@hactrn.net
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
vixie@isc.org
Austein & Vixie Expires 18 April 2000 [Page 3]

290
doc/expired/draft-ietf-dnsind-test-tlds-13.txt
View File

@@ -1,290 +0,0 @@
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]

158
doc/expired/draft-ietf-dnsind-verify-00.txt
View File

@@ -1,158 +0,0 @@
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/expired/draft-ietf-dnssec-ar-00.txt
View File

@@ -1,618 +0,0 @@
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/expired/draft-ietf-dnssec-as-map-05.txt
View File

@@ -1,522 +0,0 @@
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/expired/draft-ietf-dnssec-indirect-key-01.txt
View File

@@ -1,464 +0,0 @@
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/expired/draft-ietf-dnssec-key-handling-00.txt
View File

@@ -1,473 +0,0 @@
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/expired/draft-ietf-dnssec-rollover-00.txt
View File

@@ -1,521 +0,0 @@
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/expired/draft-ietf-dnssec-secfail-00.txt
View File

@@ -1,291 +0,0 @@
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/expired/draft-ietf-dnssec-simple-update-01.txt
View File

@@ -1,278 +0,0 @@
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/expired/draft-ietf-dnssec-tkey-01.txt
View File

File diff suppressed because it is too large Load Diff

871
doc/expired/draft-ietf-dnssec-update2-00.txt
View File

@@ -1,871 +0,0 @@
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]

3531
doc/expired/draft-ietf-ipngwg-2292bis-00.txt
View File

File diff suppressed because it is too large Load Diff

2176
doc/expired/draft-ietf-ipngwg-bsd-api-new-06.txt
View File

File diff suppressed because it is too large Load Diff

4044
doc/expired/draft-ietf-ipngwg-rfc2292bis-01.txt
View File

File diff suppressed because it is too large Load Diff

869
doc/expired/draft-schroeppel-dnsind-ecc-00.txt
View File

@@ -1,869 +0,0 @@
INTERNET-DRAFT ECC in the DNS
Expires April 2000 October 1999
draft-schroeppel-dnsind-ecc-00.txt
Elliptic Curve KEYs and SIGs in the DNS
-------- ----- ---- --- ---- -- --- ---
Richard C. Schroeppel
Donald Eastlake 3rd
Status of This Document
This draft, file name draft-schroeppel-dnsind-ecc-00.txt, is intended
to be become a Proposed Standard RFC. Distribution of this document
is unlimited. Comments should be sent to the DNS mailing list
<namedroppers@internic.com> or to the authors.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
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
A standard method for storing elliptic curve cryptographic keys and
signatures in the Domain Name System is described which utilizes DNS
KEY and SIG resource records.
R. Schroeppel, et al [Page 1]
INTERNET-DRAFT ECC in the DNS
Acknowledgement
The assistance of Hilarie K. Orman in the production of this document
is greatfully acknowledged.
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Acknowledgement............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Elliptic Curve KEY Resource Records.....................3
3. The Elliptic Curve Equation.............................9
4. How do I Compute Q, G, and Y?..........................10
5. Elliptic Curve SIG Resource Records....................11
6. Performance Considerations.............................13
7. Security Considerations................................13
8. IANA Considerations....................................13
References................................................14
Authors' Addresses........................................15
Expiration and File Name..................................15
R. Schroeppel, et al [Page 2]
INTERNET-DRAFT ECC in the DNS
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.
Elliptic curve keys can be used for signatures, as shown herein, and
also for key agreement and encryption. This document describes how to
store elliptic curve cryptographic (ECC) keys and signatures in the
DNS. Familiarity with ECC cryptography is assumed [Menezes].
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. Elliptic Curve KEY Resource Records
Elliptic curve public keys are stored in the DNS as KEY RRs using
algorithm number 4 (see [RFC 2535]). 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.
The remainder 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 and class.
The research world continues to churn on the issue of which is the
best elliptic curve system, which finite field to use, and how to
best represent elements in the field.
We have defined representations for every type of finite field, and
every type of elliptic curve. The reader should be aware that there
is a unique finite field with a particular number of elements, but
many possible representations of that field and its elements. If two
different representations of a field are given, they are
interconvertible with a tedious but practical precomputation,
followed by a fast computation for each field element to be
converted. It is perfectly reasonable for an algorithm to work
internally with one field representation, and convert to and from a
different external representation.
R. Schroeppel, et al [Page 3]
INTERNET-DRAFT ECC in the DNS
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=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S M -FMT- A B Z|
+-+-+-+-+-+-+-+-+
| LP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P (length determined from LP) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F (length determined from LF) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGJ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRDV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H (length determined from LH) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K (length determined from LK) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (length determined from LA) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ALTA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B (length determined from LB) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C (length determined from LC) .../
R. Schroeppel, et al [Page 4]
INTERNET-DRAFT ECC in the DNS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G (length determined from LG) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Y (length determined from LY) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SMFMTABZ is a flags octet as follows:
S = 1 indicates that the remaining 7 bits of the octet selects
one of 128 predefined choices of finite field, element
representation, elliptic curve, and signature parameters.
MFMTABZ are omitted, as are all parameters from LP through G.
LY and Y are retained.
If S = 0, the remaining parameters are as in the picture and
described below.
M determines the type of field underlying the elliptic curve.
M = 0 if the field is a GF[2^N] field;
M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
FMT is a three bit field describing the format of the field
representation.
FMT = 0 for a (mod P) field.
> 0 for an extension field, either GF[2^D] or GF[P^D].
The degree D of the extension, and the field polynomial
must be specified. The field polynomial is always monic
(leading coefficient 1.)
FMT = 1 The field polynomial is given explicitly; D is implied.
If FMT >=2, the degree D is given explicitly.
= 2 The field polynomial is implicit.
= 3 The field polynomial is a binomial. P>2.
= 4 The field polynomial is a trinomial.
= 5 The field polynomial is the quotient of a trinomial by a
short polynomial. P=2.
= 6 The field polynomial is a pentanomial. P=2.
Flags A and B apply to the elliptic curve parameters.
R. Schroeppel, et al [Page 5]
INTERNET-DRAFT ECC in the DNS
A = 1 When P>=5, the curve parameter A is negated. If P=2, then
A=1 indicates that the A parameter is special. See the
ALTA parameter below, following A. The combination A=1,
P=3 is forbidden.
B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3,
then B=1 indicates an alternate elliptic curve equation is
used. When P=2 and B=1, an additional curve parameter C
is present.
The Z bit SHOULD be set to zero on creation of KEY RR and MUST
be ignored when processing a KEY RR (when S=0).
Most of the remaining parameters are present in some formats and
absent in others. The presence or absence of a parameter is
determined entirely by the flags. When a parameter occurs, it is in
the order defined by the picture.
Of the remaining parameters, PFHKQABCGY are variable length. When
present, each is preceded by a one-octet length field as shown in the
diagram above. The length field does not include itself. The length
field may have values from 0 through 110. The parameter length in
octets is determined by a conditional formula: If LL<=64, the
parameter length is LL. If LL>64, the parameter length is 16 times
(LL-60). In some cases, a parameter value of 0 is sensible, and MAY
be represented by an LL value of 0, with the data field omitted. A
length value of 0 represents a parameter value of 0, not an absent
parameter. (The data portion occupies 0 space.) There is no
requirement that a parameter be represented in the minimum number of
octets; high-order 0 octets are allowed at the front end. Parameters
are always right adjusted, in a field of length defined by LL. The
octet-order is always most-significant first, least-significant last.
The parameters H and K may have an optional sign bit stored in the
unused high-order bit of their length fields.
LP defines the length of the prime P. P must be an odd prime. The
parameters LP,P are present if and only if the flag M=1. If M=0, the
prime is 2.
LF,F define an explicit field polynomial. This parameter pair is
present only when FMT = 1. The length of a polynomial coefficient is
ceiling(log2 P) bits. Coefficients are in the numerical range [0,P-
1]. The coefficients are packed into fixed-width fields, from higher
order to lower order. All coefficients must be present, including
any 0s and also the leading coefficient (which is required to be 1).
The coefficients are right justified into the octet string of length
specified by LF, with the low-order "constant" coefficient at the
right end. As a concession to storage efficiency, the higher order
bits of the leading coefficient may be elided, discarding high-order
0 octets and reducing LF. The degree is calculated by determining
R. Schroeppel, et al [Page 6]
INTERNET-DRAFT ECC in the DNS
the bit position of the left most 1-bit in the F data (counting the
right most bit as position 0), and dividing by ceiling(log2 P). The
division must be exact, with no remainder. In this format, all of
the other degree and field parameters are omitted. The next
parameters will be LQ,Q.
If FMT>=2, the degree of the field extension is specified explicitly,
usually along with other parameters to define the field polynomial.
DEG is a two octet field that defines the degree of the field
extension. The finite field will have P^DEG elements. DEG is
present when FMT>=2.
When FMT=2, the field polynomial is specified implicitly. No other
parameters are required to define the field; the next parameters
present will be the LQ,Q pair. The implicit field poynomial is the
lexicographically smallest irreducible (mod P) polynomial of the
correct degree. The ordering of polynomials is by highest-degree
coefficients first -- the leading coefficient 1 is most important,
and the constant term is least important. Coefficients are ordered
by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial
of degree D is X^D (which is not irreducible). The next is X^D+1,
which is sometimes irreducible, followed by X^D-1, which isn't.
Assuming odd P, this series continues to X^D - (P-1)/2, and then goes
to X^D + X, X^D + X + 1, X^D + X - 1, etc.
When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
odd. The polynomial is determined by the degree and the low order
term K. Of all the field parameters, only the LK,K parameters are
present. The high-order bit of the LK octet stores on optional sign
for K; if the sign bit is present, the field polynomial is X^DEG - K.
When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
K. When P=2, the H and K parameters are implicitly 1, and are
omitted from the representation. Only DEG and DEGH are present; the
next parameters are LQ,Q. When P>2, then LH,H and LK,K are
specified. Either or both of LH, LK may contain a sign bit for its
parameter.
When FMT=5, then P=2 (only). The field polynomial is the exact
quotient of a trinomial divided by a small polynomial, the trinomial
divisor. The small polynomial is right-adjusted in the two octet
field TRDV. DEG specifies the degree of the field. The degree of
TRDV is calculated from the position of the high-order 1 bit. The
trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If
DEGH is 0, the middle term is omitted from the trinomial. The
quotient must be exact, with no remainder.
When FMT=6, then P=2 (only). The field polynomial is a pentanomial,
with the degrees of the middle terms given by the three 2-octet
R. Schroeppel, et al [Page 7]
INTERNET-DRAFT ECC in the DNS
values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI
> DEGJ > 0.
DEGH, DEGI, DEGJ are two-octet fields that define the degree of
a term in a field polynomial. DEGH is present when FMT = 4,
5, or 6. DEGI and DEGJ are present only when FMT = 6.
TRDV is a two-octet right-adjusted binary polynomial of degree <
16. It is present only for FMT=5.
LH and H define the H parameter, present only when FMT=4 and P
is odd. The high bit of LH is an optional sign bit for H.
LK and K define the K parameter, present when FMT = 3 or 4, and
P is odd. The high bit of LK is an optional sign bit for K.
The remaining parameters are concerned with the elliptic curve and
the signature algorithm.
LQ defines the length of the prime Q. Q is a prime > 2^159.
In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
member of the pair is an element from the finite field defined
earlier. The length field defines a long octet string. Field
elements are represented as (mod P) polynomials of degree < DEG, with
DEG or fewer coefficients. The coefficients are stored from left to
right, higher degree to lower, with the constant term last. The
coefficients are represented as integers in the range [0,P-1]. Each
coefficient is allocated an area of ceiling(log2 P) bits. The field
representation is right-justified; the "constant term" of the field
element ends at the right most bit. The coefficients are fitted
adjacently without regard for octet boundaries. (Example: if P=5,
three bits are used for each coefficient. If the field is GF[5^75],
then 225 bits are required for the coefficients, and as many as 29
octets may be needed in the data area. Fewer octets may be used if
some high-order coefficients are 0.) If a flag requires a field
element to be negated, each non-zero coefficient K is replaced with
P-K. To save space, 0 bits may be removed from the left end of the
element representation, and the length field reduced appropriately.
This would normally only happen with A,B,C, because the designer
chose curve parameters with some high-order 0 coefficients or bits.
If the finite field is simply (mod P), then the field elements are
simply numbers (mod P), in the usual right-justified notation. If
the finite field is GF[2^D], the field elements are the usual right-
justified polynomial basis representation.
R. Schroeppel, et al [Page 8]
INTERNET-DRAFT ECC in the DNS
LA,A is the first parameter of the elliptic curve equation.
When P>=5, the flag A = 1 indicates A should be negated (mod
P). When P=2 (indicated by the flag M=0), the flag A = 1
indicates that the parameter pair LA,A is replaced by the two
octet parameter ALTA. In this case, the parameter A in the
curve equation is x^ALTA, where x is the field generator.
Parameter A often has the value 0, which may be indicated by
LA=0 (with no A data field), and sometimes A is 1, which may
be represented with LA=1 and a data field of 1, or by setting
the A flag and using an ALTA value of 0.
LB,B is the second parameter of the elliptic curve equation.
When P>=5, the flag B = 1 indicates B should be negated (mod
P). When P=2 or 3, the flag B selects an alternate curve
equation.
LC,C is the third parameter of the elliptic curve equation,
present only when P=2 (indicated by flag M=0) and flag B=1.
LG,G defines a point on the curve, of order Q. The W-coordinate
of the curve point is given explicitly; the Z-coordinate is
implicit.
LY,Y is the user's public signing key, another curve point of
order Q. The W-coordinate is given explicitly; the Z-
coordinate is implicit. The LY,Y parameter pair is always
present.
3. The Elliptic Curve Equation
(The coordinates of an elliptic curve point are named W,Z instead of
the more usual X,Y to avoid confusion with the Y parameter of the
signing key.)
The elliptic curve equation is determined by the flag octet, together
with information about the prime P. The primes 2 and 3 are special;
all other primes are treated identically.
If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
+ A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
If A and/or B is negative (i.e., in the range from P/2 to P), and
P>=5, space may be saved by putting the sign bit(s) in the A and B
bits of the flags octet, and the magnitude(s) in the parameter
fields.
If M=1 and P=3, the B flag has a different meaning: it specifies an
alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of
the right-hand-side is different. When P=3, this equation is more
R. Schroeppel, et al [Page 9]
INTERNET-DRAFT ECC in the DNS
commonly used.
If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
parameter can often be 0 or 1, or be chosen as a single-1-bit value.
The flag B is used to select an alternate curve equation, Z^2 + C*Z =
W^3 + A*W + B. This is the only time that the C parameter is used.
4. How do I Compute Q, G, and Y?
The number of points on the curve is the number of solutions to the
curve equation, + 1 (for the "point at infinity"). The prime Q must
divide the number of points. Usually the curve is chosen first, then
the number of points is determined with Schoof's algorithm. This
number is factored, and if it has a large prime divisor, that number
is taken as Q.
G must be a point of order Q on the curve, satisfying the equation
Q * G = the point at infinity (on the elliptic curve)
G may be chosen by selecting a random [RFC 1750] curve point, and
multiplying it by (number-of-points-on-curve/Q). G must not itself
be the "point at infinity"; in this astronomically unlikely event, a
new random curve point is recalculated.
G is specified by giving its W-coordinate. The Z-coordinate is
calculated from the curve equation. In general, there will be two
possible Z values. The rule is to choose the "positive" value.
In the (mod P) case, the two possible Z values sum to P. The smaller
value is less than P/2; it is used in subsequent calculations. In
GF[P^D] fields, the highest-degree non-zero coefficient of the field
element Z is used; it is chosen to be less than P/2.
In the GF[2^N] case, the two possible Z values xor to W (or to the
parameter C with the alternate curve equation). The numerically
smaller Z value (the one which does not contain the highest-order 1
bit of W (or C)) is used in subsequent calculations.
Y is specified by giving the W-coordinate of the user's public
signature key. The Z-coordinate value is determined from the curve
equation. As with G, there are two possible Z values; the same rule
is followed for choosing which Z to use.
R. Schroeppel, et al [Page 10]
INTERNET-DRAFT ECC in the DNS
During the key generation process, a random [RFC 1750] 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 = X * G (as points on the elliptic curve)
If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
in the (mod P) case, or the high-order non-zero coefficient of Z >
P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
GF[2^N] case), then X must be replaced with Q-X. This will
correspond to the correct Z-coordinate.
5. Elliptic Curve SIG Resource Records
The signature portion of the SIG RR RDATA area, when using the EC
algorithm, is shown below. See [RFC 2535] for fields in the SIG RR
RDATA which precede the signature itself.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R, (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S, (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R and S are integers (mod Q). Their length is specified by the LQ
field of the corresponding KEY RR and can also be calculated from the
SIG RR's RDLENGTH. They are right justified, high-order-octet first.
The same conditional formula for calculating the length from LQ is
used as for all the other length fields above.
The data signed is determined as specified in [RFC 2535]. Then the
following steps are taken where Q, P, G, and Y are as specified in
the public key [Schneier]:
hash = SHA-1 ( data )
Generate random [RFC 1750] K such that 0 < K < Q. (Never sign
two different messages with the same K. K should be chosen
from a very large space: If an opponent learns a K value for
a single signature, the user's signing key is compromised,
and a forger can sign arbitrary messages. There is no harm
in signing the same message multiple times with the same key
or different keys.)
R. Schroeppel, et al [Page 11]
INTERNET-DRAFT ECC in the DNS
R = (the W-coordinate of ( K*G on the elliptic curve ))
interpreted as an integer, and reduced (mod Q). (R must not
be 0. In this astronomically unlikely event, generate a new
random K and recalculate R.)
S = ( K^(-1) * (hash + X*R) ) mod Q.
S must not be 0. In this astronomically unlikely event,
generate a new random K and recalculate R and S.
If S > Q/2, set S = Q - S.
The pair (R,S) is the signature.
Another party verifies the signature as follows:
Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a
valid EC sigature.
hash = SHA-1 ( data )
Sinv = S^(-1) mod Q.
U1 = (hash * Sinv) mod Q.
U2 = (R * Sinv) mod Q.
(U1 * G + U2 * Y) is computed on the elliptic curve.
V = (the W-coordinate of this point) interpreted as an integer
and reduced (mod Q).
The signature is valid if V = R.
The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
(R,Q-S) would be valid signatures for the same data. Note that a
signature that is valid for hash(data) is also valid for hash(data)+Q
or hash(data)-Q, if these happen to fall in the range [0,2^160-1].
It's believed to be computationally infeasible to find data that
hashes to an assigned value, so this is only a cosmetic blemish. The
blemish can be eliminated by using Q > 2^160, at the cost of having
slightly longer signatures, 42 octets instead of 40.
We must specify how a field-element E ("the W-coordinate") is to be
interpreted as an integer. The field-element E is regarded as a
radix-P integer, with the digits being the coefficients in the
polynomial basis representation of E. The digits are in the ragne
[0,P-1]. In the two most common cases, this reduces to "the obvious
thing". In the (mod P) case, E is simply a residue mod P, and is
R. Schroeppel, et al [Page 12]
INTERNET-DRAFT ECC in the DNS
taken as an integer in the range [0,P-1]. In the GF[2^D] case, E is
in the D-bit polynomial basis representation, and is simply taken as
an integer in the range [0,(2^D)-1]. For other fields GF[P^D], it's
necessary to do some radix conversion arithmetic.
6. Performance Considerations
Elliptic curve signatures use smaller moduli or field sizes than RSA
and DSA, so signature generation is significantly faster. Creation
of a curve is slow, but not done very often. Key generation is
faster than RSA or DSA. Signature verification is faster than DSA,
but slower than RSA.
Current DNS implementations are optimized for small transfers,
typically less than 512 octets including DNS 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
the DNS consistent with adequate security. Keep in mind that in a
secure zone, an authenticating SIG RR will also be returned.
7. Security Considerations
Many of the general security consideration in [RFC 2535] apply. Some
specific key generation considerations are given above. Of course,
the elliptic curve key stored in the DNS for an entity should not be
trusted unless it has been obtain via a trusted DNS resolver that
vouches for its security or unless the application using the key has
done a similar authentication.
8. IANA Considerations
Assignment of meaning to the remaining ECC KEY flag bit or to values
of fields outside the ranges for which meaning in defined in this
document requires an IETF consensus as defined in [RFC 2434].
R. Schroeppel, et al [Page 13]
INTERNET-DRAFT ECC in the DNS
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 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", 12/29/1994.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", October 1998.
[RFC 2535] - D. Eastlake,"Domain Name System Security Extensions",
March 1999.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
[Menezes] - Alfred Menezes, "Elliptic Curve Public Key
Cryptosystems", 1993 Kluwer.
[Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves",
1986, Springer Graduate Texts in mathematics #106.
R. Schroeppel, et al [Page 14]
INTERNET-DRAFT ECC in the DNS
Authors' Addresses
Rich Schroeppel
500 S. Maple Drive
Woodland Hills, Utah 84653 USA
Telephone: 1-801-423-7998(h)
1-505-844-9079(w)
Email: rcs@cs.arizona.edu
rschroe@sandia.gov
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road
Carmel, NY 10512 USA
Telephone: +1 914-276-2668(h)
+1 914-784-7913(w)
FAX: +1 914-784-3833(w)
EMail: dee3@us.ibm.com
Expiration and File Name
This draft expires in April 2000.
Its file name is draft-schroeppel-dnsind-ecc-00.txt.
R. Schroeppel, et al [Page 15]

6
doc/rfc/fetch
View File

@@ -1,6 +0,0 @@
#!/bin/sh -f
for i in $*
do
i=`echo $i | sed -e 's/^rfc//' -e 's/\.txt$//'`
fetch "http://www.ietf.org/rfc/rfc${i}.txt"
done

170
doc/rfc/index
View File

@@ -1,170 +0,0 @@
952: DOD INTERNET HOST TABLE SPECIFICATION
1032: DOMAIN ADMINISTRATORS GUIDE
1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE
1034: DOMAIN NAMES - CONCEPTS AND FACILITIES
1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
1101: DNS Encoding of Network Names and Other Types
1122: Requirements for Internet Hosts -- Communication Layers
1123: Requirements for Internet Hosts -- Application and Support
1183: New DNS RR Definitions (AFSDB, RP, X25, ISDN and RT)
1348: DNS NSAP RRs
1535: A Security Problem and Proposed Correction
With Widely Deployed DNS Software
1536: Common DNS Implementation Errors and Suggested Fixes
1537: Common DNS Data File Configuration Errors
1591: Domain Name System Structure and Delegation
1611: DNS Server MIB Extensions
1612: DNS Resolver MIB Extensions
1706: DNS NSAP Resource Records
1712: DNS Encoding of Geographical Location
1750: Randomness Recommendations for Security
1876: A Means for Expressing Location Information in the Domain Name System
1886: DNS Extensions to support IP version 6
1912: Common DNS Operational and Configuration Errors
1982: Serial Number Arithmetic
1995: Incremental Zone Transfer in DNS
1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
2052: A DNS RR for specifying the location of services (DNS SRV)
2104: HMAC: Keyed-Hashing for Message Authentication
2119: Key words for use in RFCs to Indicate Requirement Levels
2133: Basic Socket Interface Extensions for IPv6
2136: Dynamic Updates in the Domain Name System (DNS UPDATE)
2137: Secure Domain Name System Dynamic Update
2163: Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping (MCGAM)
2168: Resolution of Uniform Resource Identifiers using the Domain Name System
2181: Clarifications to the DNS Specification
2230: Key Exchange Delegation Record for the DNS
2308: Negative Caching of DNS Queries (DNS NCACHE)
2317: Classless IN-ADDR.ARPA delegation
2373: IP Version 6 Addressing Architecture
2374: An IPv6 Aggregatable Global Unicast Address Format
2375: IPv6 Multicast Address Assignments
2418: IETF Working Group Guidelines and Procedures
2535: Domain Name System Security Extensions
2536: DSA KEYs and SIGs in the Domain Name System (DNS)
2537: RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
2538: Storing Certificates in the Domain Name System (DNS)
2539: Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
2540: Detached Domain Name System (DNS) Information
2541: DNS Security Operational Considerations
2553: Basic Socket Interface Extensions for IPv6
2671: Extension Mechanisms for DNS (EDNS0)
2672: Non-Terminal DNS Name Redirection
2673: Binary Labels in the Domain Name System
2782: A DNS RR for specifying the location of services (DNS SRV)
2825: A Tangled Web: Issues of I18N, Domain Names, and the
Other Internet protocols
2826: IAB Technical Comment on the Unique DNS Root
2845: Secret Key Transaction Authentication for DNS (TSIG)
2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering
2915: The Naming Authority Pointer (NAPTR) DNS Resource Record
2929: Domain Name System (DNS) IANA Considerations
2930: Secret Key Establishment for DNS (TKEY RR)
2931: DNS Request and Transaction Signatures ( SIG(0)s )
3007: Secure Domain Name System (DNS) Dynamic Update
3008: Domain Name System Security (DNSSEC) Signing Authority
3056: Connection of IPv6 Domains via IPv4 Clouds
3071: Reflections on the DNS, RFC 1591, and Categories of Domains
3090: DNS Security Extension Clarification on Zone Status
3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
3123: A DNS RR Type for Lists of Address Prefixes (APL RR)
3152: Delegation of IP6.ARPA
3197: Applicability Statement for DNS MIB Extensions
3225: Indicating Resolver Support of DNSSEC
3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements
3258: Distributing Authoritative Name Servers via Shared Unicast Addresses
3363: Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)
3364: Tradeoffs in Domain Name System (DNS) Support
for Internet Protocol version 6 (IPv6)
3425: Obsoleting IQUERY
3445: Limiting the Scope of the KEY Resource Record (RR)
3467: Role of the Domain Name System (DNS)
3490: Internationalizing Domain Names In Applications (IDNA)
3491: Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)
3492: Punycode:A Bootstring encoding of Unicode for
Internationalized Domain Names in Applications (IDNA)
3493: Basic Socket Interface Extensions for IPv6
3513: Internet Protocol Version 6 (IPv6) Addressing Architecture
3596: DNS Extensions to Support IP Version 6
3597: Handling of Unknown DNS Resource Record (RR) Types
3645: Generic Security Service Algorithm for
Secret Key Transaction Authentication for DNS (GSS-TSIG)
3655: Redefinition of DNS Authenticated Data (AD) bit
3658: Delegation Signer (DS) Resource Record (RR)
3755: Legacy Resolver Compatibility for Delegation Signer (DS)
3757: Domain Name System KEY (DNSKEY) Resource Record (RR)
Secure Entry Point (SEP) Flag
3833: Threat Analysis of the Domain Name System (DNS)
3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
3901: DNS IPv6 Transport Operational Guidelines
4025: A Method for Storing IPsec Keying Material in DNS
4033: DNS Security Introduction and Requirements
4034: Resource Records for the DNS Security Extensions
4035: Protocol Modifications for the DNS Security Extensions
4074: Common Misbehavior Against DNS Queries for IPv6 Addresses
4159: Deprecation of "ip6.int"
4193: Unique Local IPv6 Unicast Addresses
4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
4294: IPv6 Node Requirements
4339: IPv6 Host Configuration of DNS Server Information Approaches
4343: Domain Name System (DNS) Case Insensitivity Clarification
4367: What's in a Name: False Assumptions about DNS Names
4398: Storing Certificates in the Domain Name System (DNS)
4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record
4408: Sender Policy Framework (SPF) for Authorizing Use of Domains
in E-Mail, Version 1
4470: Minimally Covering NSEC Records and DNSSEC On-line Signing
4471: Derivation of DNS Name Predecessor and Successor
4472: Operational Considerations and Issues with IPv6 DNS
4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
4634: US Secure Hash Algorithms (SHA and HMAC-SHA)
4635: HMAC SHA TSIG Algorithm Identifiers
4641: DNSSEC Operational Practices
4648: The Base16, Base32, and Base64 Data Encodings
4697: Observed DNS Resolution Misbehavior
4701: A DNS Resource Record (RR) for Encoding
Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
4892: Requirements for a Mechanism Identifying a Name Server Instance
4955: DNS Security (DNSSEC) Experiments
4956: DNS Security (DNSSEC) Opt-In
5001: DNS Name Server Identifier (NSID) Option
5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors
5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extension
5395: Domain Name System (DNS) IANA Considerations
5452: Measures for Making DNS More Resilient against Forged Answers
5507: Design Choices When Expanding the DNS
5625: DNS Proxy Implementation Guidelines
5702: Use of SHA-2 Algorithms with RSA in
DNSKEY and RRSIG Resource Records for DNSSEC
5933: Use of GOST Signature Algorithms in DNSKEY
and RRSIG Resource Records for DNSSEC
5936: DNS Zone Transfer Protocol (AXFR)
5952: A Recommendation for IPv6 Address Text Representation
5966: DNS Transport over TCP - Implementation Requirements
6052: IPv6 Addressing of IPv4/IPv6 Translators
6147: DNS64: DNS Extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers
6168: Requirements for Management of Name Servers for the DNS
6303: Locally Served DNS Zones
6605: Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
6672: DNAME Redirection in the DNS
6698: The DNS-Based Authentication of Named Entities (DANE)
Transport Layer Security (TLS) Protocol: TLSA
6742: DNS Resource Records for the
Identifier-Locator Network Protocol (ILNP)
6840: Clarifications and Implementation Notes for DNS Security (DNSSEC)
6844: DNS Certification Authority Authorization (CAA) Resource Record
6891: Extension Mechanisms for DNS (EDNS(0))
7043: Resource Records for EUI-48 and EUI-64 Addresses in the DNS
7314: Extension Mechanisms for DNS (EDNS) EXPIRE Option
7534: AS112 Nameserver Operations
7477: Child-to-Parent Synchronization in DNS
7535: AS112 Redirection Using DNAME
7793: Adding 100.64.0.0/10 Prefixes to the
IPv4 Locally-Served DNS Zones Registry
7830: The EDNS(0) Padding Option
7873: Domain Name System (DNS) Cookies
8020: NXDOMAIN: There Really Is Nothing Underneath

781
doc/rfc/rfc1032.txt
View File

@@ -1,781 +0,0 @@
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
View File

File diff suppressed because it is too large Load Diff

3077
doc/rfc/rfc1034.txt
View File

File diff suppressed because it is too large Load Diff

3077
doc/rfc/rfc1035.txt
View File

File diff suppressed because it is too large Load Diff

787
doc/rfc/rfc1101.txt
View File

@@ -1,787 +0,0 @@
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
View File

File diff suppressed because it is too large Load Diff

5782
doc/rfc/rfc1123.txt
View File

File diff suppressed because it is too large Load Diff

619
doc/rfc/rfc1183.txt
View File

@@ -1,619 +0,0 @@
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]

227
doc/rfc/rfc1348.txt
View File

@@ -1,227 +0,0 @@
Network Working Group B. Manning
Request for Comments: 1348 Rice University
Updates: RFCs 1034, 1035 July 1992
DNS NSAP RRs
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Table of Contents
Introduction ..................................................... 1
Background ....................................................... 1
NSAP RR .......................................................... 2
NSAP-PTR RR ...................................................... 2
REFERENCES and BIBLIOGRAPHY ...................................... 3
Security Considerations .......................................... 4
Author's Address ................................................. 4
Introduction
This RFC defines the format of two new Resource Records (RRs) for the
Domain Name System (DNS), and reserves corresponding DNS type
mnemonic and numerical codes. This format may be used with the any
proposal that has variable length addresses, but is targeted for CLNP
use.
This memo assumes that the reader is familiar with the DNS [3,4].
Background
This section describes an experimental representation of NSAP
addresses in the DNS. There are several reasons to take this approch.
First, it provides simple documentation of the correct addresses to
use in static configurations of CLNP compliant hosts and routers.
NSAP support requires that a new DNS resource record entry type
("NSAP") be defined, to store longer Internet (i.e., NSAP) addresses.
This resource record allows mapping from DNS names to NSAP addresses,
and will contain entries for systems which are able to run Internet
applications, over TCP or UDP, over CLNP.
Manning [Page 1]
RFC 1348 DNS NSAP RRs July 1992
The backward translation (from NSAP address to DNS name) is
facilitated by definition of an associated resource record. This
resource record is known as "NSAP-PTR", and is used in a manner
analogous to the existing "in-addr.arpa".
These RRs are intended for use in a proposal [6] by one of the
members of the NOOP WG to address the next-generation internet.
The NSAP RR
The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal).
An NSAP (Network Service Access Protocol) number is a unique string
to OSI transport service.
The numbering plan follows RFC 1237 and associated OSI definitions
for NSAP format.
NSAP has the following format:
<owner> <ttl> <class> NSAP <length> <NSAP-address>
All fields are required.
<length> identifies the number of octets in the <NSAP-address> as
defined by the various national and international authorities.
<NSAP-address> enumerates the actual octet values assigned by the
assigning authority. Its format in master files is a <character-
string> syntactically identical to that used in TXT and HINFO.
The format of NSAP is class insensitive. NSAP RR causes no
additional section processing.
For example:
foo.bar.com. IN NSAP 21 47000580ffff000000321099991111222233334444
host.school.de IN NSAP 17 39276f3100111100002222333344449876
The RR data is the ASCII representation of the digits. It is encoded
as two <character-strings>, i.e., count followed by characters.
The NSAP-PTR RR
The NSAP-PTR RR is defined with mnemonic NSAP-PTR and a type code 23
(decimal).
Its function is analogous to the PTR record used for IP addresses
Manning [Page 2]
RFC 1348 DNS NSAP RRs July 1992
[4,7].
NSAP-PTR has the following format:
<NSAP-suffix> <ttl> <class> NSAP-PTR <owner>
All fields are required.
<NSAP-suffix> enumerates the actual octet values assigned by the
assigning authority for the LOCAL network. Its format in master
files is a <character-string> syntactically identical to that used in
TXT and HINFO.
The format of NSAP-PTR is class insensitive. NSAP-PTR RR causes no
additional section processing.
For example:
In net ff08000574.nsap-in-addr.arpa:
444433332222111199990123000000ff NSAP-PTR foo.bar.com.
Or in net 11110031f67293.nsap-in-addr.arpa:
67894444333322220000 NSAP-PTR host.school.de.
The RR data is the ASCII representation of the digits. It is encoded
as a <character-string>.
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] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI
NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC,
July 1991.
Manning [Page 3]
RFC 1348 DNS NSAP RRs July 1992
[6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA),
A Simple Proposal for Internet Addressing and Routing",
Digital Equipment Corporation, RFC 1347, June 1992.
[7] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
RFC 1101, USC/Information Sciences Institute, April 1989.
[8] ISO/IEC. Information Processing Systems -- Data Communications
-- Network Service Definition Addendum 2: Network Layer Address-
ing. International Standard 8348/Addendum 2, ISO/IEC JTC 1,
Switzerland, 1988.
[9] Bryant, P., "NSAPs", PB660, IPTAG/92/23, SCIENCE AND ENGINEERING
RESEARCH COUNCIL, RUTHERFORD APPLETON LABORATORY May 1992.
Security Considerations
Security issues are not addressed in this memo.
Author's Address
Bill Manning
Rice University - ONCS
PO Box 1892
6100 South Main
Houston, Texas 77251-1892
Phone: +1.713.285.5415
EMail: bmanning@rice.edu
Manning [Page 4]

283
doc/rfc/rfc1535.txt
View File

@@ -1,283 +0,0 @@
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
View File

@@ -1,675 +0,0 @@
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
View File

@@ -1,507 +0,0 @@
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
View File

@@ -1,395 +0,0 @@
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/rfc1611.txt
View File

File diff suppressed because it is too large Load Diff

1795
doc/rfc/rfc1612.txt
View File

File diff suppressed because it is too large Load Diff

563
doc/rfc/rfc1706.txt
View File

@@ -1,563 +0,0 @@
Network Working Group B. Manning
Request for Comments: 1706 ISI
Obsoletes: 1637, 1348 R. Colella
Category: Informational NIST
October 1994
DNS NSAP Resource Records
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
OSI lower layer protocols, comprising the connectionless network
protocol (CLNP) and supporting routing protocols, are deployed in
some parts of the global Internet. Maintenance and debugging of CLNP
connectivity is greatly aided by support in the Domain Name System
(DNS) for mapping between names and NSAP addresses.
This document defines the format of one new Resource Record (RR) for
the DNS for domain name-to-NSAP mapping. The RR may be used with any
NSAP address format.
NSAP-to-name translation is accomplished through use of the PTR RR
(see STD 13, RFC 1035 for a description of the PTR RR). This paper
describes how PTR RRs are used to support this translation.
This document obsoletes RFC 1348 and RFC 1637.
Manning & Colella [Page 1]
RFC 1706 DNS NSAP RRs October 1994
1. Introduction
OSI lower layer protocols, comprising the connectionless network
protocol (CLNP) [5] and supporting routing protocols, are deployed in
some parts of the global Internet. Maintenance and debugging of CLNP
connectivity is greatly aided by support in the Domain Name System
(DNS) [7] [8] for mapping between names and NSAP (network service
access point) addresses [6] [Note: NSAP and NSAP address are used
interchangeably throughout this memo].
This document defines the format of one new Resource Record (RR) for
the DNS for domain name-to-NSAP mapping. The RR may be used with any
NSAP address format.
NSAP-to-name translation is accomplished through use of the PTR RR
(see RFC 1035 for a description of the PTR RR). This paper describes
how PTR RRs are used to support this translation.
This memo assumes that the reader is familiar with the DNS. Some
familiarity with NSAPs is useful; see [1] or Annex A of [6] for
additional information.
2. Background
The reason for defining DNS mappings for NSAPs is to support the
existing CLNP deployment in the Internet. Debugging with CLNP ping
and traceroute has become more difficult with only numeric NSAPs as
the scale of deployment has increased. Current debugging is supported
by maintaining and exchanging a configuration file with name/NSAP
mappings similar in function to hosts.txt. This suffers from the lack
of a central coordinator for this file and also from the perspective
of scaling. The former describes the most serious short-term
problem. Scaling of a hosts.txt-like solution has well-known long-
term scaling difficiencies.
3. Scope
The methods defined in this paper are applicable to all NSAP formats.
As a point of reference, there is a distinction between registration
and publication of addresses. For IP addresses, the IANA is the root
registration authority and the DNS a publication method. For NSAPs,
Annex A of the network service definition, ISO8348 [6], describes the
root registration authority and this memo defines how the DNS is used
as a publication method.
Manning & Colella [Page 2]
RFC 1706 DNS NSAP RRs October 1994
4. Structure of NSAPs
NSAPs are hierarchically structured to allow distributed
administration and efficient routing. Distributed administration
permits subdelegated addressing authorities to, as allowed by the
delegator, further structure the portion of the NSAP space under
their delegated control. Accomodating this distributed authority
requires that there be little or no a priori knowledge of the
structure of NSAPs built into DNS resolvers and servers.
For the purposes of this memo, NSAPs can be thought of as a tree of
identifiers. The root of the tree is ISO8348 [6], and has as its
immediately registered subordinates the one-octet Authority and
Format Identifiers (AFIs) defined there. The size of subsequently-
defined fields depends on which branch of the tree is taken. The
depth of the tree varies according to the authority responsible for
defining subsequent fields.
An example is the authority under which U.S. GOSIP defines NSAPs [2].
Under the AFI of 47, NIST (National Institute of Standards and
Technology) obtained a value of 0005 (the AFI of 47 defines the next
field as being two octets consisting of four BCD digits from the
International Code Designator space [3]). NIST defined the subsequent
fields in [2], as shown in Figure 1. The field immediately following
0005 is a format identifier for the rest of the U.S. GOSIP NSAP
structure, with a hex value of 80. Following this is the three-octet
field, values for which are allocated to network operators; the
registration authority for this field is delegated to GSA (General
Services Administration).
The last octet of the NSAP is the NSelector (NSel). In practice, the
NSAP minus the NSel identifies the CLNP protocol machine on a given
system, and the NSel identifies the CLNP user. Since there can be
more than one CLNP user (meaning multiple NSel values for a given
"base" NSAP), the representation of the NSAP should be CLNP-user
independent. To achieve this, an NSel value of zero shall be used
with all NSAP values stored in the DNS. An NSAP with NSel=0
identifies the network layer itself. It is left to the application
retrieving the NSAP to determine the appropriate value to use in that
instance of communication.
When CLNP is used to support TCP and UDP services, the NSel value
used is the appropriate IP PROTO value as registered with the IANA.
For "standard" OSI, the selection of NSel values is left as a matter
of local administration. Administrators of systems that support the
OSI transport protocol [4] in addition to TCP/UDP must select NSels
for use by OSI Transport that do not conflict with the IP PROTO
values.
Manning & Colella [Page 3]
RFC 1706 DNS NSAP RRs October 1994
|--------------|
| <-- IDP --> |
|--------------|-------------------------------------|
| AFI | IDI | <-- DSP --> |
|-----|--------|-------------------------------------|
| 47 | 0005 | DFI | AA |Rsvd | RD |Area | ID |Sel |
|-----|--------|-----|----|-----|----|-----|----|----|
octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
|-----|--------|-----|----|-----|----|-----|----|----|
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
AA Administrative Authority
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
SEL NSAP Selector
Figure 1: GOSIP Version 2 NSAP structure.
In the NSAP RRs in Master Files and in the printed text in this memo,
NSAPs are often represented as a string of "."-separated hex values.
The values correspond to convenient divisions of the NSAP to make it
more readable. For example, the "."-separated fields might correspond
to the NSAP fields as defined by the appropriate authority (RARE,
U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for
readability. The "."s do not appear in DNS packets and DNS servers
can ignore them when reading Master Files. For example, a printable
representation of the first four fields of a U.S. GOSIP NSAP might
look like
47.0005.80.005a00
and a full U.S. GOSIP NSAP might appear as
47.0005.80.005a00.0000.1000.0020.00800a123456.00.
Other NSAP formats have different lengths and different
administratively defined field widths to accomodate different
requirements. For more information on NSAP formats in use see RFC
1629 [1].
Manning & Colella [Page 4]
RFC 1706 DNS NSAP RRs October 1994
5. The NSAP RR
The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
(decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
mapping in the DNS using the NSAP RR operates analogously to IP
address lookup. A query is generated by the resolver requesting an
NSAP RR for a provided domain name.
NSAP RRs conform to the top level RR format and semantics as defined
in Section 3.2.1 of RFC 1035.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE = NSAP |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS = IN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
* NAME: an owner name, i.e., the name of the node to which this
resource record pertains.
* TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
* CLASS: two octets containing the RR IN CLASS code of 1.
* TTL: a 32 bit signed integer that specifies the time interval in
seconds that the resource record may be cached before the source
of the information should again be consulted. Zero values are
interpreted to mean that the RR can only be used for the
transaction in progress, and should not be cached. For example,
SOA records are always distributed with a zero TTL to prohibit
caching. Zero values can also be used for extremely volatile data.
Manning & Colella [Page 5]
RFC 1706 DNS NSAP RRs October 1994
* RDLENGTH: an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
* RDATA: a variable length string of octets containing the NSAP.
The value is the binary encoding of the NSAP as it would appear in
the CLNP source or destination address field. A typical example of
such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
20 (decimal); "."s have been omitted to emphasize that they don't
appear in the DNS packets.
39840f80005a0000000001e13708002010726e00
NSAP RRs cause no additional section processing.
6. NSAP-to-name Mapping Using the PTR RR
The PTR RR is defined in RFC 1035. This RR is typically used under
the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
Similarly, the PTR RR is used to map from NSAPs to domain names under
the "NSAP.INT" domain. A domain name is generated from the NSAP
according to the rules described below. A query is sent by the
resolver requesting a PTR RR for the provided domain name.
A domain name is generated from an NSAP by reversing the hex nibbles
of the NSAP, treating each nibble as a separate subdomain, and
appending the top-level subdomain name "NSAP.INT" to it. For example,
the domain name used in the reverse lookup for the NSAP
47.0005.80.005a00.0000.0001.e133.ffffff000162.00
would appear as
0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
0.8.5.0.0.0.7.4.NSAP.INT.
[Implementation note: For sanity's sake user interfaces should be
designed to allow users to enter NSAPs using their natural order,
i.e., as they are typically written on paper. Also, arbitrary "."s
should be allowed (and ignored) on input.]
7. Master File Format
The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
conforms to Section 5, "Master Files," of RFC 1035. Below are
examples of the use of these RRs in Master Files to support name-to-
NSAP and NSAP-to-name mapping.
Manning & Colella [Page 6]
RFC 1706 DNS NSAP RRs October 1994
The NSAP RR introduces a new hex string format for the RDATA field.
The format is "0x" (i.e., a zero followed by an 'x' character)
followed by a variable length string of hex characters (0 to 9, a to
f). The hex string is case-insensitive. "."s (i.e., periods) may be
inserted in the hex string anywhere after the "0x" for readability.
The "."s have no significance other than for readability and are not
propagated in the protocol (e.g., queries or zone transfers).
;;;;;;
;;;;;; Master File for domain nsap.nist.gov.
;;;;;;
@ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. (
1994041800 ; Serial - date
1800 ; Refresh - 30 minutes
300 ; Retry - 5 minutes
604800 ; Expire - 7 days
3600 ) ; Minimum - 1 hour
IN NS emu.ncsl.nist.gov.
IN NS tuba.nsap.lanl.gov.
;
;
$ORIGIN nsap.nist.gov.
;
; hosts
;
bsdi1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
IN A 129.6.224.161
IN HINFO PC_486 BSDi1.1
;
bsdi2 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
IN A 129.6.224.162
IN HINFO PC_486 BSDi1.1
;
cursive IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
IN A 129.6.224.171
IN HINFO PC_386 DOS_5.0/NCSA_Telnet(TUBA)
;
infidel IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
IN A 129.6.55.164
IN HINFO PC/486 BSDi1.0(TUBA)
;
; routers
;
cisco1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
IN A 129.6.224.151
Manning & Colella [Page 7]
RFC 1706 DNS NSAP RRs October 1994
IN A 129.6.225.151
IN A 129.6.229.151
;
3com1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
IN A 129.6.224.111
IN A 129.6.225.111
IN A 129.6.228.111
;;;;;;
;;;;;; Master File for reverse mapping of NSAPs under the
;;;;;; NSAP prefix:
;;;;;;
;;;;;; 47.0005.80.005a00.0000.0001.e133
;;;;;;
@ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. (
1994041800 ; Serial - date
1800 ; Refresh - 30 minutes
300 ; Retry - 5 minutes
604800 ; Expire - 7 days
3600 ) ; Minimum - 1 hour
IN NS emu.ncsl.nist.gov.
IN NS tuba.nsap.lanl.gov.
;
;
$ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
;
0.0.1.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi1.nsap.nist.gov.
;
0.0.2.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi2.nsap.nist.gov.
;
0.0.1.7.1.0.0.0.f.f.f.f.f.f IN PTR cursive.nsap.nist.gov.
;
0.0.4.6.1.0.0.0.f.f.f.f.f.f IN PTR infidel.nsap.nist.gov.
;
0.0.1.5.1.0.0.0.a.a.a.a.a.a IN PTR cisco1.nsap.nist.gov.
;
0.0.1.1.1.0.0.0.a.a.a.a.a.a IN PTR 3com1.nsap.nist.gov.
8. Security Considerations
Security issues are not discussed in this memo.
Manning & Colella [Page 8]
RFC 1706 DNS NSAP RRs October 1994
9. Authors' Addresses
Bill Manning
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA. 90292
USA
Phone: +1.310.822.1511
EMail: bmanning@isi.edu
Richard Colella
National Institute of Standards and Technology
Technology/B217
Gaithersburg, MD 20899
USA
Phone: +1 301-975-3627
Fax: +1 301 590-0932
EMail: colella@nist.gov
10. References
[1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
1994.
[2] GOSIP Advanced Requirements Group. Government Open Systems
Interconnection Profile (GOSIP) Version 2. Federal Information
Processing Standard 146-1, U.S. Department of Commerce, National
Institute of Standards and Technology, Gaithersburg, MD, April
1991.
[3] ISO/IEC. Data interchange - structures for the identification of
organization. International Standard 6523, ISO/IEC JTC 1,
Switzerland, 1984.
[4] ISO/IEC. Connection oriented transport protocol specification.
International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
[5] ISO/IEC. Protocol for Providing the Connectionless-mode Network
Service. International Standard 8473, ISO/IEC JTC 1,
Switzerland, 1986.
Manning & Colella [Page 9]
RFC 1706 DNS NSAP RRs October 1994
[6] ISO/IEC. Information Processing Systems -- Data Communications --
Network Service Definition. International Standard 8348, ISO/IEC
JTC 1, Switzerland, 1993.
[7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[8] Mockapetris, P., "Domain Names -- Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
Manning & Colella [Page 10]

395
doc/rfc/rfc1712.txt
View File

@@ -1,395 +0,0 @@
Network Working Group C. Farrell
Request for Comments: 1712 M. Schulze
Category: Experimental S. Pleitner
D. Baldoni
Curtin University of Technology
November 1994
DNS Encoding of Geographical Location
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 defines the format of a new Resource Record (RR) for
the Domain Naming System (DNS), and reserves a corresponding DNS type
mnemonic and numerical code. This definition deals with associating
geographical host location mappings to host names within a domain.
The data shown in this document is fictitious and does not
necessarily reflect the real Internet.
1. Introduction
It has been a long standing problem to relate IP numbers to
geographical locations. The availability of Geographical location
information has immediate applications in network management. Such
information can be used to supplement the data already provided by
utilities such as whois [Har85], traceroute [VJ89], and nslookup
[UCB89]. The usefulness and functionality of these already widely
used tools would be greatly enhanced by the provision of reliable
geographical location information.
The ideal way to manage and maintain a database of information, such
as geographical location of internet hosts, is to delegate
responsibility to local domain administrators. A large distributed
database could be implemented with a simple mechanism for updating
the local information. A query mechanism also has to be available
for checking local entries, as well as inquiring about data from
non-local domains.
Farrell, Schulze, Pleitner & Baldoni [Page 1]
RFC 1712 DNS Encoding of Geographical Location November 1994
2. Background
The Internet continues to grow at an ever increasing rate with IP
numbers allocated on a first-come-first-serve basis. Deciding when
and how to setup a database of geographical information about
internet hosts presented a number of options. The uumap project
[UU85] was the first serious attempt to collect geographical location
data from sites and store it centrally. This project met with
limited success because of the difficulty in maintaining and updating
a large central database. Another problem was the lack of tools for
the checking the data supplied, this problem resulted in some
erroneous data entering the database.
2.1 SNMP:
Using an SNMP get request on the sysLocation MIB (Management
Information Base) variable was also an option, however this would
require the host to be running an appropriate agent with public read
access. It was also felt that MIB data should reflect local
management data (e.g., "this" host is on level 5 room 74) rather than
a hosts geographical position. This view is supported in the
examples given in literature in this area [ROSE91].
2.2 X500:
The X.500 Directory service [X.500.88] defined as part of the ISO
standards also appears as a potential provider of geographical
location data. However due to the limited implementations of this
service it was decided to defer this until this service gains wider
use and acceptance within the Internet community.
2.3 BIND:
The DNS [Mock87a][Mock87b] represents an existing system ideally
suited to the provision of host specific information. The DNS is a
widely used and well-understood mechanism for providing a distributed
database of such information and its extensible nature allows it to
be used to disseminate virtually any information. The most commonly
used DNS implementation is the Berkeley Internet Name Domain server
BIND [UCB89]. The information we wished to make available needed to
be updated locally but available globally; a perfect match with the
services provided by the DNS. Current DNS servers provide a variety
of useful information about hosts in their domain but lack the
ability to report a host's geographical location.
Farrell, Schulze, Pleitner & Baldoni [Page 2]
RFC 1712 DNS Encoding of Geographical Location November 1994
3. RDATA Format
MSB LSB
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ LONGITUDE /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ LATITUDE /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ ALTITUDE /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
LONGITUDE The real number describing the longitude encoded as a
printable string. The precision is limited by 256 charcters
within the range -90..90 degrees. Positive numbers
indicate locations north of the equator.
LATITUDE The real number describing the latitude encoded as a
printable string. The precision is limited by 256 charcters
within the range -180..180 degrees. Positive numbers
indicate locations east of the prime meridian.
ALTITUDE The real number describing the altitude (in meters) from
mean sea-level encoded as a printable string. The precision
is limited by 256 charcters. Positive numbers indicate
locations above mean sea-level.
Latitude/Longitude/Altitude values are encoded as strings as to avoid
the precision limitations imposed by encoding as unsigned integers.
Although this might not be considered optimal, it allows for a very
high degree of precision with an acceptable average encoded record
length.
4. The GPOS RR
The geographical location is defined with the mnemonic GPOS and type
code 27.
GPOS has the following format:
<owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>
A floating point format was chosen to specify geographical locations
for reasons of simplicity. This also guarantees a concise
unambiguous description of a location by enforcing three compulsory
numerical values to be specified.
Farrell, Schulze, Pleitner & Baldoni [Page 3]
RFC 1712 DNS Encoding of Geographical Location November 1994
The owner, ttl, and class fields are optional and default to the last
defined value if omitted. The longitude is a floating point number
ranging from -90 to 90 with positive values indicating locations
north of the equator. For example Perth, Western Australia is
located at 32^ 7` 19" south of the equator which would be specified
as -32.68820. The latitude is a number ranging from -180.0 to 180.0.
For example Perth, Western Australia is located at 116^ 2' 25" east
of the prime meridian which would be specified as 116.86520. Curtin
University, Perth is also 10 meters above sea-level.
The valid GPOS record for a host at Curtin University in Perth
Western Australia would therefore be:
GPOS -32.6882 116.8652 10.0
There is no limit imposed on the number of decimal places, although
the length of the encoded string is limited to 256 characters for
each field. It is also suggested that administrators limit their
entries to the minimum number of necessary characters in each field.
5. Master File Format
Each host requires its own GPOS field in the corresponding DNS RR to
explicitly specify its geographical location and altitude. If the
GPOS field is omitted, a DNS enquiry will return no position
information for that host.
Consider the following example:
; Authoritative data for cs.curtin.edu.au.
;
@ IN SOA marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au.
(
94070503 ; Serial (yymmddnn)
10800 ; Refresh (3 hours)
3600 ; Retry (1 hour)
3600000 ; Expire (1000 hours)
86400 ; Minimum (24 hours)
)
IN NS marsh.cs.curtin.edu.au.
marsh IN A 134.7.1.1
IN MX 0 marsh
IN HINFO SGI-Indigo IRIX-4.0.5F
IN GPOS -32.6882 116.8652 10.0
ftp IN CNAME marsh
Farrell, Schulze, Pleitner & Baldoni [Page 4]
RFC 1712 DNS Encoding of Geographical Location November 1994
lillee IN A 134.7.1.2
IN MX 0 marsh
IN HINFO SGI-Indigo IRIX-4.0.5F
IN GPOS -32.6882 116.8652 10.0
hinault IN A 134.7.1.23
IN MX 0 marsh
IN HINFO SUN-IPC SunOS-4.1.3
IN GPOS -22.6882 116.8652 250.0
merckx IN A 134.7.1.24
IN MX 0 marsh
IN HINFO SUN-IPC SunOS-4.1.1
ambrose IN A 134.7.1.99
IN MX 0 marsh
IN HINFO SGI-CHALLENGE_L IRIX-5.2
IN GPOS -32.6882 116.8652 10.0
The hosts marsh, lillee, and ambrose are all at the same geographical
location, Perth Western Australia (-32.68820 116.86520). The host
hinault is at a different geographical location, 10 degrees north of
Perth in the mountains (-22.6882 116.8652 250.0). For security
reasons we do not wish to give the location of the host merckx.
Although the GPOS clause is not a standard entry within BIND
configuration files, most vendor implementations seem to ignore
whatever is not understood upon startup of the DNS. Usually this
will result in a number of warnings appearing in system log files,
but in no way alters naming information or impedes the DNS from
performing its normal duties.
Farrell, Schulze, Pleitner & Baldoni [Page 5]
RFC 1712 DNS Encoding of Geographical Location November 1994
7. References
[ROSE91] Rose M., "The Simple Book: An Introduction to
Management of TCP/IP-based Internets", Prentice-Hall,
Englewood Cliffs, New Jersey, 1991.
[X.500.88] CCITT: The Directory - Overview of Concepts, Models
and Services", Recommendations X.500 - X.521.
[Har82] Harrenstein K, Stahl M., and E. Feinler,
"NICNAME/WHOIS" RFC 812, SRI NIC, March 1982.
[Mock87a] Mockapetris P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, USC/Information
Sciences Institute, November 1987.
[Mock87b] Mockapetris P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information
Sciences Institute, November 1987.
[FRB93] Ford P., Rekhter Y., and H-W. Braun, "Improving the
Routing and Addressing of IP", IEEE Network
Vol.7, No. 3, pp. 11-15, May 1993.
[VJ89] Jacobsen V., "The Traceroute(8) Manual Page",
Lawrence Berkeley Laboratory, Berkeley,
CA, February 1989.
[UCB89] University of California, "BIND: Berkeley Internet
Name Domain Server", 1989.
[UU85] UUCP Mapping Project, Software available via
anonymous FTP from ftp.uu.net., 1985.
8. Security Considerations
Once information has been entered into the DNS, it is considered
public.
Farrell, Schulze, Pleitner & Baldoni [Page 6]
RFC 1712 DNS Encoding of Geographical Location November 1994
9. Authors' Addresses
Craig Farrell
Department of Computer Science
Curtin University of technology
GPO Box U1987 Perth,
Western Australia
EMail: craig@cs.curtin.edu.au
Mike Schulze
Department of Computer Science
Curtin University of technology
GPO Box U1987 Perth,
Western Australia
EMail: mike@cs.curtin.edu.au
Scott Pleitner
Department of Computer Science
Curtin University of technology
GPO Box U1987 Perth,
Western Australia
EMail: pleitner@cs.curtin.edu.au
Daniel Baldoni
Department of Computer Science
Curtin University of technology
GPO Box U1987 Perth,
Western Australia
EMail: flint@cs.curtin.edu.au
Farrell, Schulze, Pleitner & Baldoni [Page 7]

1683
doc/rfc/rfc1750.txt
View File

File diff suppressed because it is too large Load Diff

1011
doc/rfc/rfc1876.txt
View File

File diff suppressed because it is too large Load Diff

268
doc/rfc/rfc1886.txt
View File

@@ -1,268 +0,0 @@
Network Working Group S. Thomson
Request for Comments: 1886 Bellcore
Category: Standards Track C. Huitema
INRIA
December 1995
DNS Extensions to support IP version 6
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 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,
a new domain to support lookups based on an IPv6 address, and updated
definitions of existing query types that return Internet addresses as
part of additional section processing. The extensions are designed
to be compatible with existing applications and, in particular, DNS
implementations themselves.
Thompson & Huitema Standards Track [Page 1]
RFC 1886 IPv6 DNS Extensions December 1995
1. INTRODUCTION
Current support for the storage of Internet addresses in the Domain
Name System (DNS)[1,2] cannot easily be extended to support IPv6
addresses[3] since applications assume that address queries return
32-bit IPv4 addresses only.
To support the storage of IPv6 addresses we define the following
extensions:
o A new resource record type is defined to map a domain name to an
IPv6 address.
o A new domain is defined to support lookups based on address.
o Existing queries that perform additional section processing to
locate IPv4 addresses are redefined to perform additional
section processing on both IPv4 and IPv6 addresses.
The changes are designed to be compatible with existing software. The
existing support for IPv4 addresses is retained. Transition issues
related to the co-existence of both IPv4 and IPv6 addresses in DNS
are discussed in [4].
2. NEW RESOURCE RECORD DEFINITION AND DOMAIN
A new record type is defined to store a host's IPv6 address. A host
that has more than one IPv6 address must have more than one such
record.
2.1 AAAA record type
The AAAA resource record type is a new record specific to the
Internet class that stores a single IPv6 address.
The value of the type is 28 (decimal).
2.2 AAAA data format
A 128 bit IPv6 address is encoded in the data portion of an AAAA
resource record in network byte order (high-order byte first).
Thompson & Huitema Standards Track [Page 2]
RFC 1886 IPv6 DNS Extensions December 1995
2.3 AAAA query
An AAAA query for a specified domain name in the Internet class
returns all associated AAAA resource records in the answer section of
a response.
A type AAAA query does not perform additional section processing.
2.4 Textual format of AAAA records
The textual representation of the data portion of the AAAA resource
record used in a master database file is the textual representation
of a IPv6 address as defined in [3].
2.5 IP6.INT Domain
A special domain is defined to look up a record given an address. The
intent of this domain is to provide a way of mapping an IPv6 address
to a host name, although it may be used for other purposes as well.
The domain is rooted at IP6.INT.
An IPv6 address is represented as a name in the IP6.INT domain by a
sequence of nibbles separated by dots with the suffix ".IP6.INT". The
sequence of nibbles is encoded in reverse order, i.e. the low-order
nibble is encoded first, followed by the next low-order nibble and so
on. Each nibble is represented by a hexadecimal digit. For example,
the inverse lookup domain name corresponding to the address
4321:0:1:2:3:4:567:89ab
would be
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
3. MODIFICATIONS TO EXISTING QUERY TYPES
All existing query types that perform type A additional section
processing, i.e. name server (NS), mail exchange (MX) and mailbox
(MB) query types, must be redefined to perform both type A and type
AAAA additional section processing. These new definitions mean that a
name server must add any relevant IPv4 addresses and any relevant
Thompson & Huitema Standards Track [Page 3]
RFC 1886 IPv6 DNS Extensions December 1995
IPv6 addresses available locally to the additional section of a
response when processing any one of the above queries.
4. SECURITY CONSIDERATIONS
Security issues are not discussed in this memo.
Thompson & Huitema Standards Track [Page 4]
RFC 1886 IPv6 DNS Extensions December 1995
5. 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 Specifica-
tion", STD 13, RFC 1035, USC/Information Sciences Institute,
November 1987.
[3] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing
Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December
1995.
[4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", Work in Progress.
Authors' Addresses
Susan Thomson
Bellcore
MRE 2P343
445 South Street
Morristown, NJ 07960
U.S.A.
Phone: +1 201-829-4514
EMail: set@thumper.bellcore.com
Christian Huitema
INRIA, Sophia-Antipolis
2004 Route des Lucioles
BP 109
F-06561 Valbonne Cedex
France
Phone: +33 93 65 77 15
EMail: Christian.Huitema@MIRSA.INRIA.FR
Thompson & Huitema Standards Track [Page 5]

899
doc/rfc/rfc1912.txt
View File

@@ -1,899 +0,0 @@
Network Working Group D. Barr
Request for Comments: 1912 The Pennsylvania State University
Obsoletes: 1537 February 1996
Category: Informational
Common DNS Operational and Configuration Errors
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 memo describes errors often found in both the operation of
Domain Name System (DNS) servers, and in the data that these DNS
servers contain. This memo tries to summarize current Internet
requirements as well as common practice in the operation and
configuration of the DNS. This memo also tries to summarize or
expand upon issues raised in [RFC 1537].
1. Introduction
Running a nameserver is not a trivial task. There are many things
that can go wrong, and many decisions have to be made about what data
to put in the DNS and how to set up servers. This memo attempts to
address many of the common mistakes and pitfalls that are made in DNS
data as well as in the operation of nameservers. Discussions are
also made regarding some other relevant issues such as server or
resolver bugs, and a few political issues with respect to the
operation of DNS on the Internet.
2. DNS Data
This section discusses problems people typically have with the DNS
data in their nameserver, as found in the zone data files that the
nameserver loads into memory.
2.1 Inconsistent, Missing, or Bad Data
Every Internet-reachable host should have a name. The consequences
of this are becoming more and more obvious. Many services available
on the Internet will not talk to you if you aren't correctly
registered in the DNS.
Barr Informational [Page 1]
RFC 1912 Common DNS Errors February 1996
Make sure your PTR and A records match. For every IP address, there
should be a matching PTR record in the in-addr.arpa domain. If a
host is multi-homed, (more than one IP address) make sure that all IP
addresses have a corresponding PTR record (not just the first one).
Failure to have matching PTR and A records can cause loss of Internet
services similar to not being registered in the DNS at all. Also,
PTR records must point back to a valid A record, not a alias defined
by a CNAME. It is highly recommended that you use some software
which automates this checking, or generate your DNS data from a
database which automatically creates consistent data.
DNS domain names consist of "labels" separated by single dots. The
DNS is very liberal in its rules for the allowable characters in a
domain name. However, if a domain name is used to name a host, it
should follow rules restricting host names. Further if a name is
used for mail, it must follow the naming rules for names in mail
addresses.
Allowable characters in a label for a host name are only ASCII
letters, digits, and the `-' character. Labels may not be all
numbers, but may have a leading digit (e.g., 3com.com). Labels must
end and begin only with a letter or digit. See [RFC 1035] and [RFC
1123]. (Labels were initially restricted in [RFC 1035] to start with
a letter, and some older hosts still reportedly have problems with
the relaxation in [RFC 1123].) Note there are some Internet
hostnames which violate this rule (411.org, 1776.com). The presence
of underscores in a label is allowed in [RFC 1033], except [RFC 1033]
is informational only and was not defining a standard. There is at
least one popular TCP/IP implementation which currently refuses to
talk to hosts named with underscores in them. It must be noted that
the language in [1035] is such that these rules are voluntary -- they
are there for those who wish to minimize problems. Note that the
rules for Internet host names also apply to hosts and addresses used
in SMTP (See RFC 821).
If a domain name is to be used for mail (not involving SMTP), it must
follow the rules for mail in [RFC 822], which is actually more
liberal than the above rules. Labels for mail can be any ASCII
character except "specials", control characters, and whitespace
characters. "Specials" are specific symbols used in the parsing of
addresses. They are the characters "()<>@,;:\".[]". (The "!"
character wasn't in [RFC 822], however it also shouldn't be used due
to the conflict with UUCP mail as defined in RFC 976) However, since
today almost all names which are used for mail on the Internet are
also names used for hostnames, one rarely sees addresses using these
relaxed standard, but mail software should be made liberal and robust
enough to accept them.
Barr Informational [Page 2]
RFC 1912 Common DNS Errors February 1996
You should also be careful to not have addresses which are valid
alternate syntaxes to the inet_ntoa() library call. For example 0xe
is a valid name, but if you were to type "telnet 0xe", it would try
to connect to IP address 0.0.0.14. It is also rumored that there
exists some broken inet_ntoa() routines that treat an address like
x400 as an IP address.
Certain operating systems have limitations on the length of their own
hostname. While not strictly of issue to the DNS, you should be
aware of your operating system's length limits before choosing the
name of a host.
Remember that many resource records (abbreviated RR) take on more
than one argument. HINFO requires two arguments, as does RP. If you
don't supply enough arguments, servers sometime return garbage for
the missing fields. If you need to include whitespace within any
data, you must put the string in quotes.
2.2 SOA records
In the SOA record of every zone, remember to fill in the e-mail
address that will get to the person who maintains the DNS at your
site (commonly referred to as "hostmaster"). The `@' in the e-mail
must be replaced by a `.' first. Do not try to put an `@' sign in
this address. If the local part of the address already contains a
`.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by
preceding it with `\' character. (e.g., to become
John\.Smith.widget.xx) Alternately (and preferred), you can just use
the generic name `hostmaster', and use a mail alias to redirect it to
the appropriate persons. There exists software which uses this field
to automatically generate the e-mail address for the zone contact.
This software will break if this field is improperly formatted. It
is imperative that this address get to one or more real persons,
because it is often used for everything from reporting bad DNS data
to reporting security incidents.
Even though some BIND versions allow you to use a decimal in a serial
number, don't. A decimal serial number is converted to an unsigned
32-bit integer internally anyway. The formula for a n.m serial
number is n*10^(3+int(0.9+log10(m))) + m which translates to
something rather unexpected. For example it's routinely possible
with a decimal serial number (perhaps automatically generated by
SCCS) to be incremented such that it is numerically larger, but after
the above conversion yield a serial number which is LOWER than
before. Decimal serial numbers have been officially deprecated in
recent BIND versions. The recommended syntax is YYYYMMDDnn
(YYYY=year, MM=month, DD=day, nn=revision number. This won't
overflow until the year 4294.
Barr Informational [Page 3]
RFC 1912 Common DNS Errors February 1996
Choose logical values for the timer values in the SOA record (note
values below must be expressed as seconds in the zone data):
Refresh: How often a secondary will poll the primary server to see
if the serial number for the zone has increased (so it knows
to request a new copy of the data for the zone). Set this to
how long your secondaries can comfortably contain out-of-date
data. You can keep it short (20 mins to 2 hours) if you
aren't worried about a small increase in bandwidth used, or
longer (2-12 hours) if your Internet connection is slow or is
started on demand. Recent BIND versions (4.9.3) have optional
code to automatically notify secondaries that data has
changed, allowing you to set this TTL to a long value (one
day, or more).
Retry: If a secondary was unable to contact the primary at the
last refresh, wait the retry value before trying again. This
value isn't as important as others, unless the secondary is on
a distant network from the primary or the primary is more
prone to outages. It's typically some fraction of the refresh
interval.
Expire: How long a secondary will still treat its copy of the zone
data as valid if it can't contact the primary. This value
should be greater than how long a major outage would typically
last, and must be greater than the minimum and retry
intervals, to avoid having a secondary expire the data before
it gets a chance to get a new copy. After a zone is expired a
secondary will still continue to try to contact the primary,
but it will no longer provide nameservice for the zone. 2-4
weeks are suggested values.
Minimum: The default TTL (time-to-live) for resource records --
how long data will remain in other nameservers' cache. ([RFC
1035] defines this to be the minimum value, but servers seem
to always implement this as the default value) This is by far
the most important timer. Set this as large as is comfortable
given how often you update your nameserver. If you plan to
make major changes, it's a good idea to turn this value down
temporarily beforehand. Then wait the previous minimum value,
make your changes, verify their correctness, and turn this
value back up. 1-5 days are typical values. Remember this
value can be overridden on individual resource records.
Barr Informational [Page 4]
RFC 1912 Common DNS Errors February 1996
As you can see, the typical values above for the timers vary widely.
Popular documentation like [RFC 1033] recommended a day for the
minimum TTL, which is now considered too low except for zones with
data that vary regularly. Once a DNS stabilizes, values on the order
of 3 or more days are recommended. It is also recommended that you
individually override the TTL on certain RRs which are often
referenced and don't often change to have very large values (1-2
weeks). Good examples of this are the MX, A, and PTR records of your
mail host(s), the NS records of your zone, and the A records of your
nameservers.
2.3 Glue A Records
Glue records are A records that are associated with NS records to
provide "bootstrapping" information to the nameserver. For example:
podunk.xx. in ns ns1.podunk.xx.
in ns ns2.podunk.xx.
ns1.podunk.xx. in a 1.2.3.4
ns2.podunk.xx. in a 1.2.3.5
Here, the A records are referred to as "Glue records".
Glue records are required only in forward zone files for nameservers
that are located in the subdomain of the current zone that is being
delegated. You shouldn't have any A records in an in-addr.arpa zone
file (unless you're using RFC 1101-style encoding of subnet masks).
If your nameserver is multi-homed (has more than one IP address), you
must list all of its addresses in the glue to avoid cache
inconsistency due to differing TTL values, causing some lookups to
not find all addresses for your nameserver.
Some people get in the bad habit of putting in a glue record whenever
they add an NS record "just to make sure". Having duplicate glue
records in your zone files just makes it harder when a nameserver
moves to a new IP address, or is removed. You'll spend hours trying
to figure out why random people still see the old IP address for some
host, because someone forgot to change or remove a glue record in
some other file. Newer BIND versions will ignore these extra glue
records in local zone files.
Older BIND versions (4.8.3 and previous) have a problem where it
inserts these extra glue records in the zone transfer data to
secondaries. If one of these glues is wrong, the error can be
propagated to other nameservers. If two nameservers are secondaries
for other zones of each other, it's possible for one to continually
pass old glue records back to the other. The only way to get rid of
Barr Informational [Page 5]
RFC 1912 Common DNS Errors February 1996
the old data is to kill both of them, remove the saved backup files,
and restart them. Combined with that those same versions also tend
to become infected more easily with bogus data found in other non-
secondary nameservers (like the root zone data).
2.4 CNAME records
A CNAME record is not allowed to coexist with any other data. In
other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
can't also have an MX record for suzy.podunk.edu, or an A record, or
even a TXT record. Especially do not try to combine CNAMEs and NS
records like this!:
podunk.xx. IN NS ns1
IN NS ns2
IN CNAME mary
mary IN A 1.2.3.4
This is often attempted by inexperienced administrators as an obvious
way to allow your domain name to also be a host. However, DNS
servers like BIND will see the CNAME and refuse to add any other
resources for that name. Since no other records are allowed to
coexist with a CNAME, the NS entries are ignored. Therefore all the
hosts in the podunk.xx domain are ignored as well!
If you want to have your domain also be a host, do the following:
podunk.xx. IN NS ns1
IN NS ns2
IN A 1.2.3.4
mary IN A 1.2.3.4
Don't go overboard with CNAMEs. Use them when renaming hosts, but
plan to get rid of them (and inform your users). However CNAMEs are
useful (and encouraged) for generalized names for servers -- `ftp'
for your ftp server, `www' for your Web server, `gopher' for your
Gopher server, `news' for your Usenet news server, etc.
Don't forget to delete the CNAMEs associated with a host if you
delete the host it is an alias for. Such "stale CNAMEs" are a waste
of resources.
Barr Informational [Page 6]
RFC 1912 Common DNS Errors February 1996
Don't use CNAMEs in combination with RRs which point to other names
like MX, CNAME, PTR and NS. (PTR is an exception if you want to
implement classless in-addr delegation.) For example, this is
strongly discouraged:
podunk.xx. IN MX mailhost
mailhost IN CNAME mary
mary IN A 1.2.3.4
[RFC 1034] in section 3.6.2 says this should not be done, and [RFC
974] explicitly states that MX records shall not point to an alias
defined by a CNAME. This results in unnecessary indirection in
accessing the data, and DNS resolvers and servers need to work more
to get the answer. If you really want to do this, you can accomplish
the same thing by using a preprocessor such as m4 on your host files.
Also, having chained records such as CNAMEs pointing to CNAMEs may
make administration issues easier, but is known to tickle bugs in
some resolvers that fail to check loops correctly. As a result some
hosts may not be able to resolve such names.
Having NS records pointing to a CNAME is bad and may conflict badly
with current BIND servers. In fact, current BIND implementations
will ignore such records, possibly leading to a lame delegation.
There is a certain amount of security checking done in BIND to
prevent spoofing DNS NS records. Also, older BIND servers reportedly
will get caught in an infinite query loop trying to figure out the
address for the aliased nameserver, causing a continuous stream of
DNS requests to be sent.
2.5 MX records
It is a good idea to give every host an MX record, even if it points
to itself! Some mailers will cache MX records, but will always need
to check for an MX before sending mail. If a site does not have an
MX, then every piece of mail may result in one more resolver query,
since the answer to the MX query often also contains the IP addresses
of the MX hosts. Internet SMTP mailers are required by [RFC 1123] to
support the MX mechanism.
Put MX records even on hosts that aren't intended to send or receive
e-mail. If there is a security problem involving one of these hosts,
some people will mistakenly send mail to postmaster or root at the
site without checking first to see if it is a "real" host or just a
terminal or personal computer that's not set up to accept e-mail. If
you give it an MX record, then the e-mail can be redirected to a real
person. Otherwise mail can just sit in a queue for hours or days
Barr Informational [Page 7]
RFC 1912 Common DNS Errors February 1996
until the mailer gives up trying to send it.
Don't forget that whenever you add an MX record, you need to inform
the target mailer if it is to treat the first host as "local". (The
"Cw" flag in sendmail, for example)
If you add an MX record which points to an external host (e.g., for
the purposes of backup mail routing) be sure to ask permission from
that site first. Otherwise that site could get rather upset and take
action (like throw your mail away, or appeal to higher authorities
like your parent DNS administrator or network provider.)
2.6 Other Resource Records
2.6.1 WKS
WKS records are deprecated in [RFC 1123]. They serve no known useful
function, except internally among LISP machines. Don't use them.
2.6.2 HINFO
On the issue HINFO records, some will argue that these is a security
problem (by broadcasting what vendor hardware and operating system
you so people can run systematic attacks on known vendor security
holes). If you do use them, you should keep up to date with known
vendor security problems. However, they serve a useful purpose.
Don't forget that HINFO requires two arguments, the hardware type,
and the operating system.
HINFO is sometimes abused to provide other information. The record
is meant to provide specific information about the machine itself.
If you need to express other information about the host in the DNS,
use TXT.
2.6.3 TXT
TXT records have no specific definition. You can put most anything
in them. Some use it for a generic description of the host, some put
specific information like its location, primary user, or maybe even a
phone number.
2.6.4 RP
RP records are relatively new. They are used to specify an e-mail
address (see first paragraph of section 2.2) of the "Responsible
Person" of the host, and the name of a TXT record where you can get
more information. See [RFC 1183].
Barr Informational [Page 8]
RFC 1912 Common DNS Errors February 1996
2.7 Wildcard records
Wildcard MXs are useful mostly for non IP-connected sites. A common
mistake is thinking that a wildcard MX for a zone will apply to all
hosts in the zone. A wildcard MX will apply only to names in the
zone which aren't listed in the DNS at all. e.g.,
podunk.xx. IN NS ns1
IN NS ns2
mary IN A 1.2.3.4
*.podunk.xx. IN MX 5 sue
Mail for mary.podunk.xx will be sent to itself for delivery. Only
mail for jane.podunk.xx or any hosts you don't see above will be sent
to the MX. For most Internet sites, wildcard MX records are not
useful. You need to put explicit MX records on every host.
Wildcard MXs can be bad, because they make some operations succeed
when they should fail instead. Consider the case where someone in
the domain "widget.com" tries to send mail to "joe@larry". If the
host "larry" doesn't actually exist, the mail should in fact bounce
immediately. But because of domain searching the address gets
resolved to "larry.widget.com", and because of the wildcard MX this
is a valid address according to DNS. Or perhaps someone simply made
a typo in the hostname portion of the address. The mail message then
gets routed to the mail host, which then rejects the mail with
strange error messages like "I refuse to talk to myself" or "Local
configuration error".
Wildcard MX records are good for when you have a large number of
hosts which are not directly Internet-connected (for example, behind
a firewall) and for administrative or political reasons it is too
difficult to have individual MX records for every host, or to force
all e-mail addresses to be "hidden" behind one or more domain names.
In that case, you must divide your DNS into two parts, an internal
DNS, and an external DNS. The external DNS will have only a few
hosts and explicit MX records, and one or more wildcard MXs for each
internal domain. Internally the DNS will be complete, with all
explicit MX records and no wildcards.
Wildcard As and CNAMEs are possible too, and are really confusing to
users, and a potential nightmare if used without thinking first. It
could result (due again to domain searching) in any telnet/ftp
attempts from within the domain to unknown hosts to be directed to
one address. One such wildcard CNAME (in *.edu.com) caused
Internet-wide loss of services and potential security nightmares due
to unexpected interactions with domain searching. It resulted in
swift fixes, and even an RFC ([RFC 1535]) documenting the problem.
Barr Informational [Page 9]
RFC 1912 Common DNS Errors February 1996
2.8 Authority and Delegation Errors (NS records)
You are required to have at least two nameservers for every domain,
though more is preferred. Have secondaries outside your network. If
the secondary isn't under your control, periodically check up on them
and make sure they're getting current zone data from you. Queries to
their nameserver about your hosts should always result in an
"authoritative" response. If not, this is called a "lame
delegation". A lame delegations exists when a nameserver is
delegated responsibility for providing nameservice for a zone (via NS
records) but is not performing nameservice for that zone (usually
because it is not set up as a primary or secondary for the zone).
The "classic" lame delegation can be illustrated in this example:
podunk.xx. IN NS ns1.podunk.xx.
IN NS ns0.widget.com.
"podunk.xx" is a new domain which has recently been created, and
"ns1.podunk.xx" has been set up to perform nameservice for the zone.
They haven't quite finished everything yet and haven't made sure that
the hostmaster at "ns0.widget.com" has set up to be a proper
secondary, and thus has no information about the podunk.xx domain,
even though the DNS says it is supposed to. Various things can
happen depending on which nameserver is used. At best, extra DNS
traffic will result from a lame delegation. At worst, you can get
unresolved hosts and bounced e-mail.
Also, sometimes a nameserver is moved to another host or removed from
the list of secondaries. Unfortunately due to caching of NS records,
many sites will still think that a host is a secondary after that
host has stopped providing nameservice. In order to prevent lame
delegations while the cache is being aged, continue to provide
nameservice on the old nameserver for the length of the maximum of
the minimum plus refresh times for the zone and the parent zone.
(See section 2.2)
Whenever a primary or secondary is removed or changed, it takes a
fair amount of human coordination among the parties involved. (The
site itself, it's parent, and the site hosting the secondary) When a
primary moves, make sure all secondaries have their named.boot files
updated and their servers reloaded. When a secondary moves, make
sure the address records at both the primary and parent level are
changed.
It's also been reported that some distant sites like to pick popular
nameservers like "ns.uu.net" and just add it to their list of NS
records in hopes that they will magically perform additional
Barr Informational [Page 10]
RFC 1912 Common DNS Errors February 1996
nameservice for them. This is an even worse form of lame delegation,
since this adds traffic to an already busy nameserver. Please
contact the hostmasters of sites which have lame delegations.
Various tools can be used to detect or actively find lame
delegations. See the list of contributed software in the BIND
distribution.
Make sure your parent domain has the same NS records for your zone as
you do. (Don't forget your in-addr.arpa zones too!). Do not list
too many (7 is the recommended maximum), as this just makes things
harder to manage and is only really necessary for very popular top-
level or root zones. You also run the risk of overflowing the 512-
byte limit of a UDP packet in the response to an NS query. If this
happens, resolvers will "fall back" to using TCP requests, resulting
in increased load on your nameserver.
It's important when picking geographic locations for secondary
nameservers to minimize latency as well as increase reliability.
Keep in mind network topologies. For example if your site is on the
other end of a slow local or international link, consider a secondary
on the other side of the link to decrease average latency. Contact
your Internet service provider or parent domain contact for more
information about secondaries which may be available to you.
3. BIND operation
This section discusses common problems people have in the actual
operation of the nameserver (specifically, BIND). Not only must the
data be correct as explained above, but the nameserver must be
operated correctly for the data to be made available.
3.1 Serial numbers
Each zone has a serial number associated with it. Its use is for
keeping track of who has the most current data. If and only if the
primary's serial number of the zone is greater will the secondary ask
the primary for a copy of the new zone data (see special case below).
Don't forget to change the serial number when you change data! If
you don't, your secondaries will not transfer the new zone
information. Automating the incrementing of the serial number with
software is also a good idea.
If you make a mistake and increment the serial number too high, and
you want to reset the serial number to a lower value, use the
following procedure:
Barr Informational [Page 11]
RFC 1912 Common DNS Errors February 1996
Take the `incorrect' serial number and add 2147483647 to it. If
the number exceeds 4294967296, subtract 4294967296. Load the
resulting number. Then wait 2 refresh periods to allow the zone
to propagate to all servers.
Repeat above until the resulting serial number is less than the
target serial number.
Up the serial number to the target serial number.
This procedure won't work if one of your secondaries is running an
old version of BIND (4.8.3 or earlier). In this case you'll have to
contact the hostmaster for that secondary and have them kill the
secondary servers, remove the saved backup file, and restart the
server. Be careful when editing the serial number -- DNS admins
don't like to kill and restart nameservers because you lose all that
cached data.
3.2 Zone file style guide
Here are some useful tips in structuring your zone files. Following
these will help you spot mistakes, and avoid making more.
Be consistent with the style of entries in your DNS files. If your
$ORIGIN is podunk.xx., try not to write entries like:
mary IN A 1.2.3.1
sue.podunk.xx. IN A 1.2.3.2
or:
bobbi IN A 1.2.3.2
IN MX mary.podunk.xx.
Either use all FQDNs (Fully Qualified Domain Names) everywhere or
used unqualified names everywhere. Or have FQDNs all on the right-
hand side but unqualified names on the left. Above all, be
consistent.
Use tabs between fields, and try to keep columns lined up. It makes
it easier to spot missing fields (note some fields such as "IN" are
inherited from the previous record and may be left out in certain
circumstances.)
Barr Informational [Page 12]
RFC 1912 Common DNS Errors February 1996
Remember you don't need to repeat the name of the host when you are
defining multiple records for one host. Be sure also to keep all
records associated with a host together in the file. It will make
things more straightforward when it comes time to remove or rename a
host.
Always remember your $ORIGIN. If you don't put a `.' at the end of
an FQDN, it's not recognized as an FQDN. If it is not an FQDN, then
the nameserver will append $ORIGIN to the name. Double check, triple
check, those trailing dots, especially in in-addr.arpa zone files,
where they are needed the most.
Be careful with the syntax of the SOA and WKS records (the records
which use parentheses). BIND is not very flexible in how it parses
these records. See the documentation for BIND.
3.3 Verifying data
Verify the data you just entered or changed by querying the resolver
with dig (or your favorite DNS tool, many are included in the BIND
distribution) after a change. A few seconds spent double checking
can save hours of trouble, lost mail, and general headaches. Also be
sure to check syslog output when you reload the nameserver. If you
have grievous errors in your DNS data or boot file, named will report
it via syslog.
It is also highly recommended that you automate this checking, either
with software which runs sanity checks on the data files before they
are loaded into the nameserver, or with software which checks the
data already loaded in the nameserver. Some contributed software to
do this is included in the BIND distribution.
4. Miscellaneous Topics
4.1 Boot file setup
Certain zones should always be present in nameserver configurations:
primary localhost localhost
primary 0.0.127.in-addr.arpa 127.0
primary 255.in-addr.arpa 255
primary 0.in-addr.arpa 0
These are set up to either provide nameservice for "special"
addresses, or to help eliminate accidental queries for broadcast or
local address to be sent off to the root nameservers. All of these
files will contain NS and SOA records just like the other zone files
you maintain, the exception being that you can probably make the SOA
Barr Informational [Page 13]
RFC 1912 Common DNS Errors February 1996
timers very long, since this data will never change.
The "localhost" address is a "special" address which always refers to
the local host. It should contain the following line:
localhost. IN A 127.0.0.1
The "127.0" file should contain the line:
1 PTR localhost.
There has been some extensive discussion about whether or not to
append the local domain to it. The conclusion is that "localhost."
would be the best solution. The reasons given include:
"localhost" by itself is used and expected to work in some
systems.
Translating 127.0.0.1 into "localhost.dom.ain" can cause some
software to connect back to the loopback interface when it didn't
want to because "localhost" is not equal to "localhost.dom.ain".
The "255" and "0" files should not contain any additional data beyond
the NS and SOA records.
Note that future BIND versions may include all or some of this data
automatically without additional configuration.
4.2 Other Resolver and Server bugs
Very old versions of the DNS resolver have a bug that cause queries
for names that look like IP addresses to go out, because the user
supplied an IP address and the software didn't realize that it didn't
need to be resolved. This has been fixed but occasionally it still
pops up. It's important because this bug means that these queries
will be sent directly to the root nameservers, adding to an already
heavy DNS load.
While running a secondary nameserver off another secondary nameserver
is possible, it is not recommended unless necessary due to network
topologies. There are known cases where it has led to problems like
bogus TTL values. While this may be caused by older or flawed DNS
implementations, you should not chain secondaries off of one another
since this builds up additional reliability dependencies as well as
adds additional delays in updates of new zone data.
Barr Informational [Page 14]
RFC 1912 Common DNS Errors February 1996
4.3 Server issues
DNS operates primarily via UDP (User Datagram Protocol) messages.
Some UNIX operating systems, in an effort to save CPU cycles, run
with UDP checksums turned off. The relative merits of this have long
been debated. However, with the increase in CPU speeds, the
performance considerations become less and less important. It is
strongly encouraged that you turn on UDP checksumming to avoid
corrupted data not only with DNS but with other services that use UDP
(like NFS). Check with your operating system documentation to verify
that UDP checksumming is enabled.
References
[RFC 974] Partridge, C., "Mail routing and the domain system", STD
14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
[RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC
1033, USC/Information Sciences Institute, November 1987.
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, USC/Information Sciences Institute,
November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[RFC 1123] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, IETF, October
1989.
[RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC
1178, Integrated Systems Group/NIST, August 1990.
[RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart,
"New DNS RR Definitions", RFC 1183, October 1990.
[RFC 1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535, ACES
Research Inc., October 1993.
[RFC 1536] 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.
Barr Informational [Page 15]
RFC 1912 Common DNS Errors February 1996
[RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors",
RFC 1537, CWI, October 1993.
[RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN,
November 1994.
[BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND",
Vixie Enterprises, July 1994.
5. Security Considerations
Security issues are not discussed in this memo.
6. Author's Address
David Barr
The Pennsylvania State University
Department of Mathematics
334 Whitmore Building
University Park, PA 16802
Voice: +1 814 863 7374
Fax: +1 814 863-8311
EMail: barr@math.psu.edu
Barr Informational [Page 16]

394
doc/rfc/rfc1982.txt
View File

@@ -1,394 +0,0 @@
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
View File

@@ -1,451 +0,0 @@
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
View File

@@ -1,395 +0,0 @@
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
View File

@@ -1,563 +0,0 @@
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
View File

@@ -1,620 +0,0 @@
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
View File

@@ -1,171 +0,0 @@
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]

1795
doc/rfc/rfc2133.txt
View File

File diff suppressed because it is too large Load Diff

1460
doc/rfc/rfc2136.txt
View File

File diff suppressed because it is too large Load Diff

619
doc/rfc/rfc2137.txt
View File

@@ -1,619 +0,0 @@
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]

1459
doc/rfc/rfc2163.txt
View File

File diff suppressed because it is too large Load Diff

1123
doc/rfc/rfc2168.txt
View File

File diff suppressed because it is too large Load Diff

842
doc/rfc/rfc2181.txt
View File

@@ -1,842 +0,0 @@
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]

619
doc/rfc/rfc2230.txt
View File

@@ -1,619 +0,0 @@
Network Working Group R. Atkinson
Request for Comments: 2230 NRL
Category: Informational November 1997
Key Exchange Delegation Record for the DNS
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 (1997). All Rights Reserved.
ABSTRACT
This note describes a mechanism whereby authorisation for one node to
act as key exchanger for a second node is delegated and made
available via the Secure DNS. This mechanism is intended to be used
only with the Secure DNS. It can be used with several security
services. For example, a system seeking to use IP Security [RFC-
1825, RFC-1826, RFC-1827] to protect IP packets for a given
destination can use this mechanism to determine the set of authorised
remote key exchanger systems for that destination.
1. INTRODUCTION
The Domain Name System (DNS) is the standard way that Internet nodes
locate information about addresses, mail exchangers, and other data
relating to remote Internet nodes. [RFC-1035, RFC-1034] More
recently, Eastlake and Kaufman have defined standards-track security
extensions to the DNS. [RFC-2065] These security extensions can be
used to authenticate signed DNS data records and can also be used to
store signed public keys in the DNS.
The KX record is useful in providing an authenticatible method of
delegating authorisation for one node to provide key exchange
services on behalf of one or more, possibly different, nodes. This
note specifies the syntax and semantics of the KX record, which is
currently in limited deployment in certain IP-based networks. The
Atkinson Informational [Page 1]
RFC 2230 DNS Key Exchange Delegation Record November 1997
reader is assumed to be familiar with the basics of DNS, including
familiarity with [RFC-1035, RFC-1034]. This document is not on the
IETF standards-track and does not specify any level of standard.
This document merely provides information for the Internet community.
1.1 Identity Terminology
This document relies upon the concept of "identity domination". This
concept might be new to the reader and so is explained in this
section. The subject of endpoint naming for security associations
has historically been somewhat contentious. This document takes no
position on what forms of identity should be used. In a network,
there are several forms of identity that are possible.
For example, IP Security has defined notions of identity that
include: IP Address, IP Address Range, Connection ID, Fully-Qualified
Domain Name (FQDN), and User with Fully Qualified Domain Name (USER
FQDN).
A USER FQDN identity dominates a FQDN identity. A FQDN identity in
turn dominates an IP Address identity. Similarly, a Connection ID
dominates an IP Address identity. An IP Address Range dominates each
IP Address identity for each IP address within that IP address range.
Also, for completeness, an IP Address identity is considered to
dominate itself.
2. APPROACH
This document specifies a new kind of DNS Resource Record (RR), known
as the Key Exchanger (KX) record. A Key Exchanger Record has the
mnemonic "KX" and the type code of 36. Each KX record is associated
with a fully-qualified domain name. The KX record is modeled on the
MX record described in [Part86]. Any given domain, subdomain, or host
entry in the DNS might have a KX record.
2.1 IPsec Examples
In these two examples, let S be the originating node and let D be the
destination node. S2 is another node on the same subnet as S. D2 is
another node on the same subnet as D. R1 and R2 are IPsec-capable
routers. The path from S to D goes via first R1 and later R2. The
return path from D to S goes via first R2 and later R1.
IETF-standard IP Security uses unidirectional Security Associations
[RFC-1825]. Therefore, a typical IP session will use a pair of
related Security Associations, one in each direction. The examples
below talk about how to setup an example Security Association, but in
practice a pair of matched Security Associations will normally be
Atkinson Informational [Page 2]
RFC 2230 DNS Key Exchange Delegation Record November 1997
used.
2.1.1 Subnet-to-Subnet Example
If neither S nor D implements IPsec, security can still be provided
between R1 and R2 by building a secure tunnel. This can use either
AH or ESP.
S ---+ +----D
| |
+- R1 -----[zero or more routers]-------R2-+
| |
S2---+ +----D2
Figure 1: Network Diagram for Subnet-to-Subnet Example
In this example, R1 makes the policy decision to provide the IPsec
service for traffic from R1 destined for R2. Once R1 has decided
that the packet from S to D should be protected, it performs a secure
DNS lookup for the records associated with domain D. If R1 only
knows the IP address for D, then a secure reverse DNS lookup will be
necessary to determine the domain D, before that forward secure DNS
lookup for records associated with domain D. If these DNS records of
domain D include a KX record for the IPsec service, then R1 knows
which set of nodes are authorised key exchanger nodes for the
destination D.
In this example, let there be at least one KX record for D and let
the most preferred KX record for D point at R2. R1 then selects a
key exchanger (in this example, R2) for D from the list obtained from
the secure DNS. Then R1 initiates a key management session with that
key exchanger (in this example, R2) to setup an IPsec Security
Association between R1 and D. In this example, R1 knows (either by
seeing an outbound packet arriving from S destined to D or via other
methods) that S will be sending traffic to D. In this example R1's
policy requires that traffic from S to D should be segregated at
least on a host-to-host basis, so R1 desires an IPsec Security
Association with source identity that dominates S, proxy identity
that dominates R1, and destination identity that dominates R2.
In turn, R2 is able to authenticate the delegation of Key Exchanger
authorisation for target S to R1 by making an authenticated forward
DNS lookup for KX records associated with S and verifying that at
least one such record points to R1. The identity S is typically
given to R2 as part of the key management process between R1 and R2.
Atkinson Informational [Page 3]
RFC 2230 DNS Key Exchange Delegation Record November 1997
If D initially only knows the IP address of S, then it will need to
perform a secure reverse DNS lookup to obtain the fully-qualified
domain name for S prior to that secure forward DNS lookup.
If R2 does not receive an authenticated DNS response indicating that
R1 is an authorised key exchanger for S, then D will not accept the
SA negotiation from R1 on behalf of identity S.
If the proposed IPsec Security Association is acceptable to both R1
and R2, each of which might have separate policies, then they create
that IPsec Security Association via Key Management.
Note that for unicast traffic, Key Management will typically also
setup a separate (but related) IPsec Security Association for the
return traffic. That return IPsec Security Association will have
equivalent identities. In this example, that return IPsec Security
Association will have a source identity that dominates D, a proxy
identity that dominates R2, and a destination identity that dominates
R1.
Once the IPsec Security Association has been created, then R1 uses it
to protect traffic from S destined for D via a secure tunnel that
originates at R1 and terminates at R2. For the case of unicast, R2
will use the return IPsec Security Association to protect traffic
from D destined for S via a secure tunnel that originates at R2 and
terminates at R1.
2.1.2 Subnet-to-Host Example
Consider the case where D and R1 implement IPsec, but S does not
implement IPsec, which is an interesting variation on the previous
example. This example is shown in Figure 2 below.
S ---+
|
+- R1 -----[zero or more routers]-------D
|
S2---+
Figure 2: Network Diagram for Subnet-to-Host Example
In this example, R1 makes the policy decision that IP Security is
needed for the packet travelling from S to D. Then, R1 performs the
secure DNS lookup for D and determines that D is its own key
exchanger, either from the existence of a KX record for D pointing to
D or from an authenticated DNS response indicating that no KX record
exists for D. If R1 does not initially know the domain name of D,
then prior to the above forward secure DNS lookup, R1 performs a
Atkinson Informational [Page 4]
RFC 2230 DNS Key Exchange Delegation Record November 1997
secure reverse DNS lookup on the IP address of D to determine the
fully-qualified domain name for that IP address. R1 then initiates
key management with D to create an IPsec Security Association on
behalf of S.
In turn, D can verify that R1 is authorised to create an IPsec
Security Association on behalf of S by performing a DNS KX record
lookup for target S. R1 usually provides identity S to D via key
management. If D only has the IP address of S, then D will need to
perform a secure reverse lookup on the IP address of S to determine
domain name S prior to the secure forward DNS lookup on S to locate
the KX records for S.
If D does not receive an authenticated DNS response indicating that
R1 is an authorised key exchanger for S, then D will not accept the
SA negotiation from R1 on behalf of identity S.
If the IPsec Security Association is successfully established between
R1 and D, that IPsec Security Association has a source identity that
dominates S's IP address, a proxy identity that dominates R1's IP
address, and a destination identity that dominates D's IP address.
Finally, R1 begins providing the security service for packets from S
that transit R1 destined for D. When D receives such packets, D
examines the SA information during IPsec input processing and sees
that R1's address is listed as valid proxy address for that SA and
that S is the source address for that SA. Hence, D knows at input
processing time that R1 is authorised to provide security on behalf
of S. Therefore packets coming from R1 with valid IP security that
claim to be from S are trusted by D to have really come from S.
2.1.3 Host to Subnet Example
Now consider the above case from D's perspective (i.e. where D is
sending IP packets to S). This variant is sometimes known as the
Mobile Host or "roadwarrier" case. The same basic concepts apply, but
the details are covered here in hope of improved clarity.
S ---+
|
+- R1 -----[zero or more routers]-------D
|
S2---+
Figure 3: Network Diagram for Host-to-Subnet Example
Atkinson Informational [Page 5]
RFC 2230 DNS Key Exchange Delegation Record November 1997
In this example, D makes the policy decision that IP Security is
needed for the packets from D to S. Then D performs the secure DNS
lookup for S and discovers that a KX record for S exists and points
at R1. If D only has the IP address of S, then it performs a secure
reverse DNS lookup on the IP address of S prior to the forward secure
DNS lookup for S.
D then initiates key management with R1, where R1 is acting on behalf
of S, to create an appropriate Security Association. Because D is
acting as its own key exchanger, R1 does not need to perform a secure
DNS lookup for KX records associated with D.
D and R1 then create an appropriate IPsec Security Security
Association. This IPsec Security Association is setup as a secure
tunnel with a source identity that dominates D's IP Address and a
destination identity that dominates R1's IP Address. Because D
performs IPsec for itself, no proxy identity is needed in this IPsec
Security Association. If the proxy identity is non-null in this
situation, then the proxy identity must dominate D's IP Address.
Finally, D sends secured IP packets to R1. R1 receives those
packets, provides IPsec input processing (including appropriate
inner/outer IP address validation), and forwards valid packets along
to S.
2.2 Other Examples
This mechanism can be extended for use with other services as well.
To give some insight into other possible uses, this section discusses
use of KX records in environments using a Key Distribution Center
(KDC), such as Kerberos [KN93], and a possible use of KX records in
conjunction with mobile nodes accessing the network via a dialup
service.
2.2.1 KDC Examples
This example considers the situation of a destination node
implementing IPsec that can only obtain its Security Association
information from a Key Distribution Center (KDC). Let the KDC
implement both the KDC protocol and also a non-KDC key management
protocol (e.g. ISAKMP). In such a case, each client node of the KDC
might have its own KX record pointing at the KDC so that nodes not
implementing the KDC protocol can still create Security Associations
with each of the client nodes of the KDC.
In the event the session initiator were not using the KDC but the
session target was an IPsec node that only used the KDC, the
initiator would find the KX record for the target pointing at the
Atkinson Informational [Page 6]
RFC 2230 DNS Key Exchange Delegation Record November 1997
KDC. Then, the external key management exchange (e.g. ISAKMP) would
be between the initiator and the KDC. Then the KDC would distribute
the IPsec SA to the KDC-only IPsec node using the KDC. The IPsec
traffic itself could travel directly between the initiator and the
destination node.
In the event the initiator node could only use the KDC and the target
were not using the KDC, the initiator would send its request for a
key to the KDC. The KDC would then initiate an external key
management exchange (e.g. ISAKMP) with a node that the target's KX
record(s) pointed to, on behalf of the initiator node.
The target node could verify that the KDC were allowed to proxy for
the initiator node by looking up the KX records for the initiator
node and finding a KX record for the initiator that listed the KDC.
Then the external key exchange would be performed between the KDC and
the target node. Then the KDC would distribute the resulting IPsec
Security Association to the initiator. Again, IPsec traffic itself
could travel directly between the initiator and the destination.
2.2.2 Dial-Up Host Example
This example outlines a possible use of KX records with mobile hosts
that dial into the network via PPP and are dynamically assigned an IP
address and domain-name at dial-in time.
Consider the situation where each mobile node is dynamically assigned
both a domain name and an IP address at the time that node dials into
the network. Let the policy require that each mobile node act as its
own Key Exchanger. In this case, it is important that dial-in nodes
use addresses from one or more well known IP subnets or address pools
dedicated to dial-in access. If that is true, then no KX record or
other action is needed to ensure that each node will act as its own
Key Exchanger because lack of a KX record indicates that the node is
its own Key Exchanger.
Consider the situation where the mobile node's domain name remains
constant but its IP address changes. Let the policy require that
each mobile node act as its own Key Exchanger. In this case, there
might be operational problems when another node attempts to perform a
secure reverse DNS lookup on the IP address to determine the
corresponding domain name. The authenticated DNS binding (in the
form of a PTR record) between the mobile node's currently assigned IP
address and its permanent domain name will need to be securely
updated each time the node is assigned a new IP address. There are
no mechanisms for accomplishing this that are both IETF-standard and
widely deployed as of the time this note was written. Use of Dynamic
Atkinson Informational [Page 7]
RFC 2230 DNS Key Exchange Delegation Record November 1997
DNS Update without authentication is a significant security risk and
hence is not recommended for this situation.
3. SYNTAX OF KX RECORD
A KX record has the DNS TYPE of "KX" and a numeric value of 36. A KX
record is a member of the Internet ("IN") CLASS in the DNS. Each KX
record is associated with a <domain-name> entry in the DNS. A KX
record has the following textual syntax:
<domain-name> IN KX <preference> <domain-name>
For this description, let the <domain-name> item to the left of the
"KX" string be called <domain-name 1> and the <domain-name> item to
the right of the "KX" string be called <domain-name 2>. <preference>
is a non-negative integer.
Internet nodes about to initiate a key exchange with <domain-name 1>
should instead contact <domain-name 2> to initiate the key exchange
for a security service between the initiator and <domain-name 2>. If
more than one KX record exists for <domain-name 1>, then the
<preference> field is used to indicate preference among the systems
delegated to. Lower values are preferred over higher values. The
<domain-name 2> is authorised to provide key exchange services on
behalf of <domain-name 1>. The <domain-name 2> MUST have a CNAME
record, an A record, or an AAAA record associated with it.
3.1 KX RDATA format
The KX DNS record has the following RDATA format:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGER /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PREFERENCE A 16 bit non-negative integer which specifies the
preference given to this RR among other KX records
at the same owner. Lower values are preferred.
EXCHANGER A <domain-name> which specifies a host willing to
act as a mail exchange for the owner name.
Atkinson Informational [Page 8]
RFC 2230 DNS Key Exchange Delegation Record November 1997
KX records MUST cause type A additional section processing for the
host specified by EXCHANGER. In the event that the host processing
the DNS transaction supports IPv6, KX records MUST also cause type
AAAA additional section processing.
The KX RDATA field MUST NOT be compressed.
4. SECURITY CONSIDERATIONS
KX records MUST always be signed using the method(s) defined by the
DNS Security extensions specified in [RFC-2065]. All unsigned KX
records MUST be ignored because of the security vulnerability caused
by assuming that unsigned records are valid. All signed KX records
whose signatures do not correctly validate MUST be ignored because of
the potential security vulnerability in trusting an invalid KX
record.
KX records MUST be ignored by systems not implementing Secure DNS
because such systems have no mechanism to authenticate the KX record.
If a node does not have a permanent DNS entry and some form of
Dynamic DNS Update is in use, then those dynamic DNS updates MUST be
fully authenticated to prevent an adversary from injecting false DNS
records (especially the KX, A, and PTR records) into the Domain Name
System. If false records were inserted into the DNS without being
signed by the Secure DNS mechanisms, then a denial-of-service attack
results. If false records were inserted into the DNS and were
(erroneously) signed by the signing authority, then an active attack
results.
Myriad serious security vulnerabilities can arise if the restrictions
throuhout this document are not strictly adhered to. Implementers
should carefully consider the openly published issues relating to DNS
security [Bell95,Vixie95] as they build their implementations.
Readers should also consider the security considerations discussed in
the DNS Security Extensions document [RFC-2065].
5. REFERENCES
[RFC-1825] Atkinson, R., "IP Authentication Header", RFC 1826,
August 1995.
[RFC-1827] Atkinson, R., "IP Encapsulating Security Payload",
RFC 1827, August 1995.
Atkinson Informational [Page 9]
RFC 2230 DNS Key Exchange Delegation Record November 1997
[Bell95] Bellovin, S., "Using the Domain Name System for System
Break-ins", Proceedings of 5th USENIX UNIX Security
Symposium, USENIX Association, Berkeley, CA, June 1995.
ftp://ftp.research.att.com/dist/smb/dnshack.ps
[RFC-2065] Eastlake, D., and C. Kaufman, "Domain Name System
Security Extensions", RFC 2065, January 1997.
[RFC-1510] Kohl J., and C. Neuman, "The Kerberos Network
Authentication Service", RFC 1510, September 1993.
[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.
[Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of
the 5th USENIX UNIX Security Symposium, USENIX
Association, Berkeley, CA, June 1995.
ftp://ftp.vix.com/pri/vixie/bindsec.psf
ACKNOWLEDGEMENTS
Development of this DNS record was primarily performed during 1993
through 1995. The author's work on this was sponsored jointly by the
Computing Systems Technology Office (CSTO) of the Advanced Research
Projects Agency (ARPA) and by the Information Security Program Office
(PD71E), Space & Naval Warface Systems Command (SPAWAR). In that
era, Dave Mihelcic and others provided detailed review and
constructive feedback. More recently, Bob Moscowitz and Todd Welch
provided detailed review and constructive feedback of a work in
progress version of this document.
AUTHOR'S ADDRESS
Randall Atkinson
Code 5544
Naval Research Laboratory
4555 Overlook Avenue, SW
Washington, DC 20375-5337
Phone: (DSN) 354-8590
EMail: atkinson@itd.nrl.navy.mil
Atkinson Informational [Page 10]
RFC 2230 DNS Key Exchange Delegation Record November 1997
Full Copyright Statement
Copyright (C) The Internet Society (1997). 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 implmentation may be prepared, copied, published
andand 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.
Atkinson Informational [Page 11]

1067
doc/rfc/rfc2308.txt
View File

File diff suppressed because it is too large Load Diff

563
doc/rfc/rfc2317.txt
View File

@@ -1,563 +0,0 @@
Network Working Group H. Eidnes
Request for Comments: 2317 SINTEF RUNIT
BCP: 20 G. de Groot
Category: Best Current Practice Berkeley Software Design, Inc.
P. Vixie
Internet Software Consortium
March 1998
Classless IN-ADDR.ARPA delegation
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.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
2. Introduction
This document describes a way to do IN-ADDR.ARPA delegation on non-
octet boundaries for address spaces covering fewer than 256
addresses. The proposed method should thus remove one of the
objections to subnet on non-octet boundaries but perhaps more
significantly, make it possible to assign IP address space in smaller
chunks than 24-bit prefixes, without losing the ability to delegate
authority for the corresponding IN-ADDR.ARPA mappings. The proposed
method is fully compatible with the original DNS lookup mechanisms
specified in [1], i.e. there is no need to modify the lookup
algorithm used, and there should be no need to modify any software
which does DNS lookups.
The document also discusses some operational considerations to
provide some guidance in implementing this method.
3. Motivation
With the proliferation of classless routing technology, it has become
feasible to assign address space on non-octet boundaries. In case of
a very small organization with only a few hosts, assigning a full
24-bit prefix (what was traditionally referred to as a "class C
network number") often leads to inefficient address space
utilization.
Eidnes, et. al. Best Current Practice [Page 1]
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
One of the problems encountered when assigning a longer prefix (less
address space) is that it seems impossible for such an organization
to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously. By
use of the reverse delegation method described below, the most
important objection to assignment of longer prefixes to unrelated
organizations can be removed.
Let us assume we have assigned the address spaces to three different
parties as follows:
192.0.2.0/25 to organization A
192.0.2.128/26 to organization B
192.0.2.192/26 to organization C
In the classical approach, this would lead to a single zone like
this:
$ORIGIN 2.0.192.in-addr.arpa.
;
1 PTR host1.A.domain.
2 PTR host2.A.domain.
3 PTR host3.A.domain.
;
129 PTR host1.B.domain.
130 PTR host2.B.domain.
131 PTR host3.B.domain.
;
193 PTR host1.C.domain.
194 PTR host2.C.domain.
195 PTR host3.C.domain.
The administration of this zone is problematic. Authority for this
zone can only be delegated once, and this usually translates into
"this zone can only be administered by one organization." The other
organizations with address space that corresponds to entries in this
zone would thus have to depend on another organization for their
address to name translation. With the proposed method, this
potential problem can be avoided.
4. Classless IN-ADDR.ARPA delegation
Since a single zone can only be delegated once, we need more points
to do delegation on to solve the problem above. These extra points
of delegation can be introduced by extending the IN-ADDR.ARPA tree
downwards, e.g. by using the first address or the first address and
the network mask length (as shown below) in the corresponding address
Eidnes, et. al. Best Current Practice [Page 2]
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
space to form the the first component in the name for the zones. The
following four zone files show how the problem in the motivation
section could be solved using this method.
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
;...
; <<0-127>> /25
0/25 NS ns.A.domain.
0/25 NS some.other.name.server.
;
1 CNAME 1.0/25.2.0.192.in-addr.arpa.
2 CNAME 2.0/25.2.0.192.in-addr.arpa.
3 CNAME 3.0/25.2.0.192.in-addr.arpa.
;
; <<128-191>> /26
128/26 NS ns.B.domain.
128/26 NS some.other.name.server.too.
;
129 CNAME 129.128/26.2.0.192.in-addr.arpa.
130 CNAME 130.128/26.2.0.192.in-addr.arpa.
131 CNAME 131.128/26.2.0.192.in-addr.arpa.
;
; <<192-255>> /26
192/26 NS ns.C.domain.
192/26 NS some.other.third.name.server.
;
193 CNAME 193.192/26.2.0.192.in-addr.arpa.
194 CNAME 194.192/26.2.0.192.in-addr.arpa.
195 CNAME 195.192/26.2.0.192.in-addr.arpa.
$ORIGIN 0/25.2.0.192.in-addr.arpa.
@ IN SOA ns.A.domain. hostmaster.A.domain. (...)
@ NS ns.A.domain.
@ NS some.other.name.server.
;
1 PTR host1.A.domain.
2 PTR host2.A.domain.
3 PTR host3.A.domain.
Eidnes, et. al. Best Current Practice [Page 3]
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
$ORIGIN 128/26.2.0.192.in-addr.arpa.
@ IN SOA ns.B.domain. hostmaster.B.domain. (...)
@ NS ns.B.domain.
@ NS some.other.name.server.too.
;
129 PTR host1.B.domain.
130 PTR host2.B.domain.
131 PTR host3.B.domain.
$ORIGIN 192/26.2.0.192.in-addr.arpa.
@ IN SOA ns.C.domain. hostmaster.C.domain. (...)
@ NS ns.C.domain.
@ NS some.other.third.name.server.
;
193 PTR host1.C.domain.
194 PTR host2.C.domain.
195 PTR host3.C.domain.
For each size-256 chunk split up using this method, there is a need
to install close to 256 CNAME records in the parent zone. Some
people might view this as ugly; we will not argue that particular
point. It is however quite easy to automatically generate the CNAME
resource records in the parent zone once and for all, if the way the
address space is partitioned is known.
The advantage of this approach over the other proposed approaches for
dealing with this problem is that there should be no need to modify
any already-deployed software. In particular, the lookup mechanism
in the DNS does not have to be modified to accommodate this splitting
of the responsibility for the IPv4 address to name translation on
"non-dot" boundaries. Furthermore, this technique has been in use
for several years in many installations, apparently with no ill
effects.
As usual, a resource record like
$ORIGIN 2.0.192.in-addr.arpa.
129 CNAME 129.128/26.2.0.192.in-addr.arpa.
can be convienently abbreviated to
$ORIGIN 2.0.192.in-addr.arpa.
129 CNAME 129.128/26
Eidnes, et. al. Best Current Practice [Page 4]
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
Some DNS implementations are not kind to special characters in domain
names, e.g. the "/" used in the above examples. As [3] makes clear,
these are legal, though some might feel unsightly. Because these are
not host names the restriction of [2] does not apply. Modern clients
and servers have an option to act in the liberal and correct fashion.
The examples here use "/" because it was felt to be more visible and
pedantic reviewers felt that the 'these are not hostnames' argument
needed to be repeated. We advise you not to be so pedantic, and to
not precisely copy the above examples, e.g. substitute a more
conservative character, such as hyphen, for "/".
5. Operational considerations
This technique is intended to be used for delegating address spaces
covering fewer than 256 addresses. For delegations covering larger
blocks of addresses the traditional methods (multiple delegations)
can be used instead.
5.1 Recommended secondary name service
Some older versions of name server software will make no effort to
find and return the pointed-to name in CNAME records if the pointed-
to name is not already known locally as cached or as authoritative
data. This can cause some confusion in resolvers, as only the CNAME
record will be returned in the response. To avoid this problem it is
recommended that the authoritative name servers for the delegating
zone (the zone containing all the CNAME records) all run as slave
(secondary) name servers for the "child" zones delegated and pointed
into via the CNAME records.
5.2 Alternative naming conventions
As a result of this method, the location of the zone containing the
actual PTR records is no longer predefined. This gives flexibility
and some examples will be presented here.
An alternative to using the first address, or the first address and
the network mask length in the corresponding address space, to name
the new zones is to use some other (non-numeric) name. Thus it is
also possible to point to an entirely different part of the DNS tree
(i.e. outside of the IN-ADDR.ARPA tree). It would be necessary to
use one of these alternate methods if two organizations somehow
shared the same physical subnet (and corresponding IP address space)
with no "neat" alignment of the addresses, but still wanted to
administrate their own IN-ADDR.ARPA mappings.
Eidnes, et. al. Best Current Practice [Page 5]
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
The following short example shows how you can point out of the IN-
ADDR.ARPA tree:
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
; ...
1 CNAME 1.A.domain.
2 CNAME 2.A.domain.
; ...
129 CNAME 129.B.domain.
130 CNAME 130.B.domain.
;
$ORIGIN A.domain.
@ IN SOA my-ns.A.domain. hostmaster.A.domain. (...)
; ...
;
host1 A 192.0.2.1
1 PTR host1
;
host2 A 192.0.2.2
2 PTR host2
;
etc.
This way you can actually end up with the name->address and the
(pointed-to) address->name mapping data in the same zone file - some
may view this as an added bonus as no separate set of secondaries for
the reverse zone is required. Do however note that the traversal via
the IN-ADDR.ARPA tree will still be done, so the CNAME records
inserted there need to point in the right direction for this to work.
Sketched below is an alternative approach using the same solution:
$ORIGIN 2.0.192.in-addr.arpa.
@ SOA my-ns.my.domain. hostmaster.my.domain. (...)
; ...
1 CNAME 1.2.0.192.in-addr.A.domain.
2 CNAME 2.2.0.192.in-addr.A.domain.
$ORIGIN A.domain.
@ SOA my-ns.A.domain. hostmaster.A.domain. (...)
; ...
;
host1 A 192.0.2.1
1.2.0.192.in-addr PTR host1
Eidnes, et. al. Best Current Practice [Page 6]
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
host2 A 192.0.2.2
2.2.0.192.in-addr PTR host2
It is clear that many possibilities exist which can be adapted to the
specific requirements of the situation at hand.
5.3 Other operational issues
Note that one cannot provide CNAME referrals twice for the same
address space, i.e. you cannot allocate a /25 prefix to one
organisation, and run IN-ADDR.ARPA this way, and then have the
organisation subnet the /25 into longer prefixes, and attempt to
employ the same technique to give each subnet control of its own
number space. This would result in a CNAME record pointing to a CNAME
record, which may be less robust overall.
Unfortunately, some old beta releases of the popular DNS name server
implementation BIND 4.9.3 had a bug which caused problems if a CNAME
record was encountered when a reverse lookup was made. The beta
releases involved have since been obsoleted, and this issue is
resolved in the released code. Some software manufacturers have
included the defective beta code in their product. In the few cases
we know of, patches from the manufacturers are available or planned
to replace the obsolete beta code involved.
6. Security Considerations
With this scheme, the "leaf sites" will need to rely on one more site
running their DNS name service correctly than they would be if they
had a /24 allocation of their own, and this may add an extra
component which will need to work for reliable name resolution.
Other than that, the authors are not aware of any additional security
issues introduced by this mechanism.
7. Conclusion
The suggested scheme gives more flexibility in delegating authority
in the IN-ADDR.ARPA domain, thus making it possible to assign address
space more efficiently without losing the ability to delegate the DNS
authority over the corresponding address to name mappings.
8. Acknowledgments
Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-
ip.domains some time ago. Alan Barrett and Sam Wilson provided
valuable comments on the newsgroup.
Eidnes, et. al. Best Current Practice [Page 7]
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert
Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony
Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer,
and Peter Koch for their review and constructive comments.
9. References
[1] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[2] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host
Table Specification", RFC 952, October 1985.
[3] Elz, R., and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
Eidnes, et. al. Best Current Practice [Page 8]
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
10. Authors' Addresses
Havard Eidnes
SINTEF RUNIT
N-7034 Trondheim
Norway
Phone: +47 73 59 44 68
Fax: +47 73 59 17 00
EMail: Havard.Eidnes@runit.sintef.no
Geert Jan de Groot
Berkeley Software Design, Inc. (BSDI)
Hendrik Staetslaan 69
5622 HM Eindhoven
The Netherlands
Phone: +31 40 2960509
Fax: +31 40 2960309
EMail: GeertJan.deGroot@bsdi.com
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
USA
Phone: +1 415 747 0204
EMail: paul@vix.com
Eidnes, et. al. Best Current Practice [Page 9]
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
11. 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.
Eidnes, et. al. Best Current Practice [Page 10]

1459
doc/rfc/rfc2373.txt
View File

File diff suppressed because it is too large Load Diff

675
doc/rfc/rfc2374.txt
View File

@@ -1,675 +0,0 @@
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
View File

@@ -1,451 +0,0 @@
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
View File

File diff suppressed because it is too large Load Diff

2635
doc/rfc/rfc2535.txt
View File

File diff suppressed because it is too large Load Diff

339
doc/rfc/rfc2536.txt
View File

@@ -1,339 +0,0 @@
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
View File

@@ -1,339 +0,0 @@
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
View File

@@ -1,563 +0,0 @@
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
View File

@@ -1,395 +0,0 @@
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
View File

@@ -1,339 +0,0 @@
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
View File

@@ -1,395 +0,0 @@
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]

2299
doc/rfc/rfc2553.txt
View File

File diff suppressed because it is too large Load Diff

395
doc/rfc/rfc2671.txt
View File

@@ -1,395 +0,0 @@
Network Working Group P. Vixie
Request for Comments: 2671 ISC
Category: Standards Track August 1999
Extension Mechanisms for DNS (EDNS0)
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
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.
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.
Vixie Standards Track [Page 1]
RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
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. One 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. The quantity of OPT
pseudo-RRs per message shall be either zero or one, but not
greater.
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.
Vixie Standards Track [Page 2]
RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
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 payload 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.
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.
4.5.2. Both requestors and responders are advised to take account of the
path's discovered MTU (if already known) when considering message
sizes.
Vixie Standards Track [Page 3]
RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
4.5.3. The requestor's maximum payload size can change over time, and
should therefore not be cached for use beyond the transaction in
which it is advertised.
4.5.4. The responder's maximum payload size can change over time, but
can be reasonably expected to remain constant between two
sequential transactions; for example, a meaningless QUERY to
discover a responder's maximum UDP payload size, followed
immediately by an UPDATE which takes advantage of this size.
(This is considered preferrable to the outright use of TCP for
oversized requests, if there is any reason to suspect that the
responder implements EDNS, and if a request will not fit in the
default 512 payload size limit.)
4.5.5. Due to transaction overhead, it is unwise to advertise an
architectural limit as a maximum UDP payload size. Just because
your stack can reassemble 64KB datagrams, don't assume that you
want to spend more than about 4KB of state memory per ongoing
transaction.
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." Requestors are encouraged
to set this to the lowest implemented level capable
of expressing a transaction, to minimize the
responder and network load of discovering the
greatest common implementation level between
requestor and responder. A requestor's version
numbering strategy should ideally be a run time
configuration option.
If a responder does not implement the VERSION level
of the request, then it answers with RCODE=BADVERS.
All responses will be limited in format to the
Vixie Standards Track [Page 4]
RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
VERSION level of the request, but the VERSION of each
response will be the highest implementation level of
the responder. In this way a requestor will learn
the implementation level of a responder as a side
effect of every response, including error responses,
including 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 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
The IANA has assigned RR type code 41 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.
Vixie Standards Track [Page 5]
RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
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.
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] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
10 - Author's Address
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
Phone: +1 650 779 7001
EMail: vixie@isc.org
Vixie Standards Track [Page 6]
RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
11 - 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Vixie Standards Track [Page 7]

Some files were not shown because too many files have changed in this diff Show More