From c7ddab7655021d96211a26f99d9f694396c53284 Mon Sep 17 00:00:00 2001 From: Bob Halley Date: Tue, 23 Mar 1999 17:37:55 +0000 Subject: [PATCH] add RFCs and drafts --- doc/draft/draft-ietf-dnsind-apl-rr-01.txt | 335 + .../draft-ietf-dnsind-binary-labels-04.txt | 334 + doc/draft/draft-ietf-dnsind-dddd-00.txt | 336 + doc/draft/draft-ietf-dnsind-dname-03.txt | 502 ++ doc/draft/draft-ietf-dnsind-edns0-01.txt | 319 + doc/draft/draft-ietf-dnsind-edns1-02.txt | 320 + ...draft-ietf-dnsind-local-compression-04.txt | 449 ++ .../draft-ietf-dnsind-local-names-06.txt | 754 ++ doc/draft/draft-ietf-dnsind-rfc2052bis-02.txt | 560 ++ doc/draft/draft-ietf-dnsind-test-tlds-13.txt | 290 + doc/draft/draft-ietf-dnsind-tsig-08.txt | 795 ++ doc/draft/draft-ietf-dnsind-verify-00.txt | 158 + doc/draft/draft-ietf-dnssec-ar-00.txt | 618 ++ doc/draft/draft-ietf-dnssec-as-map-05.txt | 522 ++ .../draft-ietf-dnssec-indirect-key-01.txt | 464 ++ .../draft-ietf-dnssec-key-handling-00.txt | 473 ++ doc/draft/draft-ietf-dnssec-rollover-00.txt | 521 ++ doc/draft/draft-ietf-dnssec-secfail-00.txt | 291 + .../draft-ietf-dnssec-simple-update-01.txt | 278 + doc/draft/draft-ietf-dnssec-tkey-01.txt | 1045 +++ doc/draft/draft-ietf-dnssec-update2-00.txt | 871 +++ .../draft-ietf-ipngwg-bsd-api-new-06.txt | 2176 ++++++ .../draft-ietf-ipngwg-dns-lookups-03.txt | 838 ++ doc/rfc/rfc1032.txt | 781 ++ doc/rfc/rfc1033.txt | 1229 +++ doc/rfc/rfc1034.txt | 3077 ++++++++ doc/rfc/rfc1035.txt | 3077 ++++++++ doc/rfc/rfc1101.txt | 787 ++ doc/rfc/rfc1122.txt | 6844 +++++++++++++++++ doc/rfc/rfc1123.txt | 5782 ++++++++++++++ doc/rfc/rfc1183.txt | 619 ++ doc/rfc/rfc1535.txt | 283 + doc/rfc/rfc1536.txt | 675 ++ doc/rfc/rfc1537.txt | 507 ++ doc/rfc/rfc1591.txt | 395 + doc/rfc/rfc1750.txt | 1683 ++++ doc/rfc/rfc1982.txt | 394 + doc/rfc/rfc1995.txt | 451 ++ doc/rfc/rfc1996.txt | 395 + doc/rfc/rfc2052.txt | 563 ++ doc/rfc/rfc2104.txt | 620 ++ doc/rfc/rfc2119.txt | 171 + doc/rfc/rfc2136.txt | 1460 ++++ doc/rfc/rfc2137.txt | 619 ++ doc/rfc/rfc2181.txt | 842 ++ doc/rfc/rfc2308.txt | 1067 +++ doc/rfc/rfc2373.txt | 1459 ++++ doc/rfc/rfc2374.txt | 675 ++ doc/rfc/rfc2375.txt | 451 ++ doc/rfc/rfc2418.txt | 1459 ++++ doc/rfc/rfc2535.txt | 2635 +++++++ doc/rfc/rfc2536.txt | 339 + doc/rfc/rfc2537.txt | 339 + doc/rfc/rfc2538.txt | 563 ++ doc/rfc/rfc2539.txt | 395 + doc/rfc/rfc2540.txt | 339 + doc/rfc/rfc2541.txt | 395 + 57 files changed, 54619 insertions(+) create mode 100644 doc/draft/draft-ietf-dnsind-apl-rr-01.txt create mode 100644 doc/draft/draft-ietf-dnsind-binary-labels-04.txt create mode 100644 doc/draft/draft-ietf-dnsind-dddd-00.txt create mode 100644 doc/draft/draft-ietf-dnsind-dname-03.txt create mode 100644 doc/draft/draft-ietf-dnsind-edns0-01.txt create mode 100644 doc/draft/draft-ietf-dnsind-edns1-02.txt create mode 100644 doc/draft/draft-ietf-dnsind-local-compression-04.txt create mode 100644 doc/draft/draft-ietf-dnsind-local-names-06.txt create mode 100644 doc/draft/draft-ietf-dnsind-rfc2052bis-02.txt create mode 100644 doc/draft/draft-ietf-dnsind-test-tlds-13.txt create mode 100644 doc/draft/draft-ietf-dnsind-tsig-08.txt create mode 100644 doc/draft/draft-ietf-dnsind-verify-00.txt create mode 100644 doc/draft/draft-ietf-dnssec-ar-00.txt create mode 100644 doc/draft/draft-ietf-dnssec-as-map-05.txt create mode 100644 doc/draft/draft-ietf-dnssec-indirect-key-01.txt create mode 100644 doc/draft/draft-ietf-dnssec-key-handling-00.txt create mode 100644 doc/draft/draft-ietf-dnssec-rollover-00.txt create mode 100644 doc/draft/draft-ietf-dnssec-secfail-00.txt create mode 100644 doc/draft/draft-ietf-dnssec-simple-update-01.txt create mode 100644 doc/draft/draft-ietf-dnssec-tkey-01.txt create mode 100644 doc/draft/draft-ietf-dnssec-update2-00.txt create mode 100644 doc/draft/draft-ietf-ipngwg-bsd-api-new-06.txt create mode 100644 doc/draft/draft-ietf-ipngwg-dns-lookups-03.txt create mode 100644 doc/rfc/rfc1032.txt create mode 100644 doc/rfc/rfc1033.txt create mode 100644 doc/rfc/rfc1034.txt create mode 100644 doc/rfc/rfc1035.txt create mode 100644 doc/rfc/rfc1101.txt create mode 100644 doc/rfc/rfc1122.txt create mode 100644 doc/rfc/rfc1123.txt create mode 100644 doc/rfc/rfc1183.txt create mode 100644 doc/rfc/rfc1535.txt create mode 100644 doc/rfc/rfc1536.txt create mode 100644 doc/rfc/rfc1537.txt create mode 100644 doc/rfc/rfc1591.txt create mode 100644 doc/rfc/rfc1750.txt create mode 100644 doc/rfc/rfc1982.txt create mode 100644 doc/rfc/rfc1995.txt create mode 100644 doc/rfc/rfc1996.txt create mode 100644 doc/rfc/rfc2052.txt create mode 100644 doc/rfc/rfc2104.txt create mode 100644 doc/rfc/rfc2119.txt create mode 100644 doc/rfc/rfc2136.txt create mode 100644 doc/rfc/rfc2137.txt create mode 100644 doc/rfc/rfc2181.txt create mode 100644 doc/rfc/rfc2308.txt create mode 100644 doc/rfc/rfc2373.txt create mode 100644 doc/rfc/rfc2374.txt create mode 100644 doc/rfc/rfc2375.txt create mode 100644 doc/rfc/rfc2418.txt create mode 100644 doc/rfc/rfc2535.txt create mode 100644 doc/rfc/rfc2536.txt create mode 100644 doc/rfc/rfc2537.txt create mode 100644 doc/rfc/rfc2538.txt create mode 100644 doc/rfc/rfc2539.txt create mode 100644 doc/rfc/rfc2540.txt create mode 100644 doc/rfc/rfc2541.txt diff --git a/doc/draft/draft-ietf-dnsind-apl-rr-01.txt b/doc/draft/draft-ietf-dnsind-apl-rr-01.txt new file mode 100644 index 0000000000..0aeaf3e448 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-apl-rr-01.txt @@ -0,0 +1,335 @@ + + +INTERNET-DRAFT Peter Koch +Expires: August 1999 Universitaet Bielefeld +Updates: RFC 1035 February 1999 + + A DNS RR Type for Lists of IP Address Prefixes (APL RR) + draft-ietf-dnsind-apl-rr-01.txt + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments should be sent to the author or the DNSIND WG mailing list + . + +Abstract + + The Domain Name System is primarily used to translate domain names + into IPv4 addresses using A RRs. Several approaches exist to describe + networks or address ranges. This document proposes a new DNS RR type + "APL" for address prefix lists. + +1. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + Domain names herein are for explanatory purposes only and should not + be expected to lead to useful information in real life [TESTTLD]. + + + + +Koch Expires August 1999 [Page 1] + +INTERNET-DRAFT DNS APL RR February 1999 + + +2. Background + + The Domain Name System [RFC1034], [RFC1035] provides a mechanism to + assign addresses and other internet infrastructure elements to + hierarchically built domain names. Various types of resource records + have been defined, especially those for IPv4 and IPv6 [RFC1886], + [A6DNSRR] addresses. In [RFC1101] a method is described to publish + information about the address space allocated to an organisation. In + older BIND versions, a weak form of controlling access to zone data + was implemented using TXT RRs describing address ranges. + + This document proposes a new RR type for address prefix lists. + +3. APL RR Type + + An APL record has the DNS type of "APL" [draft: not yet applied for] + and a numeric value of [draft:to be assigned]. The APL RR is defined + in the IN class only. APL RRs cause no additional section processing. + +4. APL RDATA format + + The RDATA section consists of zero or more strings () of + the form + + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + | ADDRESSFAMILY | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + | N | PREFIX | MBZ | AFDLENGTH | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + / AFDPART / + | | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + + ADDRESSFAMILY 16 bit unsigned value as assigned by IANA + (see IANA Considerations) + N negation flag, indicates the presence of the + "!" character in the textual format. It has + the value "1" if the "!" was given, "0" else. + PREFIX binary coded prefix length. Upper and lower + bounds and interpretation of this value are + address family specific. + MBZ reserved, must be zero + AFDLENGTH length in octets of the following address + family dependent part. This is to deal with + yet undefined address families and variable + length addresses. + + + + +Koch Expires August 1999 [Page 2] + +INTERNET-DRAFT DNS APL RR February 1999 + + + AFDPART address family dependent part. See below. + + + This document defines the AFDPARTs for address families 1 (IPv4) and + 2 (IPv6). Future revisions may deal with additional address + families. + +4.1. AFDPART for IPv4 + + The encoding of an IPv4 address (address family 1) follows the + encoding specified for the A RR by [RFC1035], section 3.4.1. + + PREFIX specifies the number of bits of the IPv4 address starting at + the most significant bit. Legal encodings range from 0 (1 bit) to 31 + (32 bit, complete address). + + An IPv4 AFDPART has a fixed length of 4 octets. + +4.1. AFDPART for IPv6 + + The encoding of an IPv6 address (address family 2) follows the + encoding specified for the AAAA RR by [RFC1886], section 2.2. + + PREFIX specifies the number of bits of the IPv6 address starting at + the most significant bit. Legal encodings range from 0 (1 bit) to 127 + (128 bit, complete address). + + An IPv6 AFDPART has a fixed length of 16 octets. + +5. Zone File Syntax + + The textual representation of an APL RR in a DNS zone file is as + follows: + + IN APL {[!]address/prefix}* + + The data consists of zero or more strings of an address, immediately + followed by the "/" character, immediately followed by a decimal + numeric value for the prefix length. Any such string may be preceeded + by a "!" character. The strings are separated by whitespace. + +5.1. Textual Representation of IPv4 Addresses + + An IPv4 address in the
part of an is in dotted + quad notation, just as in an A RR. The has values from the + interval 1..32 (decimal), corresponding to encodings 0..31. + +5.1. Textual Representation of IPv6 Addresses + + + +Koch Expires August 1999 [Page 3] + +INTERNET-DRAFT DNS APL RR February 1999 + + + The representation of an IPv6 address in the
part of an + follows [RFC2373], section 2.2. Legal values for + are from the interval 1..128 (decimal), corresponding to encodings + 0..127. + +6. APL RR usage + + An APL RR with empty RDATA is valid and implements an empty list. + Multiple occurences of the same in a single APL RR are + allowed and MUST NOT be merged by a DNS server or resolver. + must be kept in order and MUST NOT be rearranged or + aggregated. + + A single APL RR may contain belonging to different + address families. The maximum number of is upperbounded + by the available RDATA space. + + RRSets consisting of more than one APL RR are legal but the + interpretation is left to the particular application. It may choose + to join the lists or treat them as alternatives. + + Possible applications include the publication of address ranges + similar to [RFC1101], description of zones built following [RFC2317] + and in-band access control to limit general access or zone transfer + (AXFR) availability for zone data held in DNS servers. + +7. Examples + + foo.example APL 192.168.32.0/21 !192.168.38.0/28 + + 42.168.192.IN-ADDR.ARPA APL 192.168.42.0/26 192.168.42.64/26 \ + 192.168.42.128/25 + + _axfr_.sbo.example APL 127.0.0.1/32 172.16.64.0/22 + + multicast.example APL 224.0.0.0/4 FF00:0:0:0:0:0:0:0/8 + +8. Security Considerations + + Any information obtained from the DNS should be regarded as unsafe + unless techniques specified in [RFC2065] or [TSIGRR] were used. The + definition of a new RR type does not introduce security problems into + the DNS, but usage of information made available by APL RRs may + compromise security. This includes disclosure of network topology + information and in particular the use of APL RRs to construct access + control lists. + +9. IANA Considerations + + + +Koch Expires August 1999 [Page 4] + +INTERNET-DRAFT DNS APL RR February 1999 + + + This document does not define any new namespaces. It uses the 16 bit + identifiers for address families maintained by IANA in + ftp://ftp.iana.org/in-notes/iana/assignments/address-family-numbers. + +10. Acknowledgements + + The author would like to thank Mark Andrews for his review and + constructive comments. + +11. References + + + [A6DNSRR] Crawford,M., Thomson,S., "DNS Extensions to Support IP + Version 6", , work + in progress + + [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", + RFC 1034, STD 13, November 1987 + + [RFC1035] Mockapetris,P., "Domain Names - Implementation and + Specification", RFC 1035, STD 13, November 1987 + + [RFC1101] Mockapetris,P., "DNS Encoding of Network Names and Other + Types", RFC 1101, April 1989 + + [RFC1886] Thomson,S., Huitema.,C., "DNS Extensions to support IP + version 6", RFC 1886, December 1995 + + [RFC2065] Eastlake,D., Kaufman,C. "Domain Name System Security + Extensions", RFC 2065, January 1997 + + [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997 + + [RFC2181] Elz,R., Bush,R., "Clarifications to the DNS + Specification", RFC 2181, July 1997 + + [RFC2373] Hinden,R., Deering,S., "IP Version 6 Addressing + Architecture", RFC 2373, July 1998 + + [TESTTLD] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", + , work in progress + + [TSIGRR] Vixie,P., Gudmundsson,O., Eastlake,D., Wellington,B., + "Secret Key Transaction Signatures for DNS (TSIG)", + , work in progress + + + + + +Koch Expires August 1999 [Page 5] + +INTERNET-DRAFT DNS APL RR February 1999 + + +12. Author's Address + + Peter Koch + Universitaet Bielefeld + Technische Fakultaet + Postfach 10 01 31 + D-33501 Bielefeld + Germany + +49 521 106 2902 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Koch Expires August 1999 [Page 6] + diff --git a/doc/draft/draft-ietf-dnsind-binary-labels-04.txt b/doc/draft/draft-ietf-dnsind-binary-labels-04.txt new file mode 100644 index 0000000000..9e6f22ba24 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-binary-labels-04.txt @@ -0,0 +1,334 @@ + +DNSIND Working Group Matt Crawford +Internet Draft Fermilab + March 21, 1999 + + Binary Labels in the Domain Name System + + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other documents + at any time. It is inappropriate to use Internet- Drafts as + reference material or to cite them other than as "work in progress." + + To view the list Internet-Draft Shadow Directories, see + http://www.ietf.org/shadow.html. + + +1. Introduction and Terminology + + This document defines a ``Bit-String Label'' which may appear within + domain names. This new label type compactly represents a sequence + of ``One-Bit Labels'' and enables resource records to be stored at + any bit-boundary in a binary-named section of the domain name tree. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [KWORD]. + + +2. Motivation + + Binary labels are intended to efficiently solve the problem of + storing data and delegating authority on arbitrary boundaries when + the structure of underlying name space is most naturally represented + in binary. + + + + + + + +Expires September 26, 1999 Crawford [Page 1] + +Internet Draft Binary DNS Labels March 21, 1999 + + +3. Label Format + + Up to 256 One-Bit Labels can be grouped into a single Bit-String + Label. Within a Bit-String Label the most significant or "highest + level" bit appears first. This is unlike the ordering of DNS labels + themselves, which has the least significant or "lowest level" label + first. Nonetheless, this ordering seems to be the most natural and + efficient for representing binary labels. + + Among consecutive Bit-String Labels, the bits in the first-appearing + label are less significant or "at a lower level" than the bits in + subsequent Bit-String Labels, just as ASCII labels are ordered. + + +3.1. Encoding + + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+ + |0 1| ELT | Count | Label ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+ + + (Each tic mark represents one bit.) + + + ELT 000001 binary, the six-bit extended label type [EDNS0] + assigned to the Bit-String Label. + + Count The number of significant bits in the Label field. A + Count value of zero indicates that 256 bits are + significant. (Thus the null label representing the DNS + root cannot be represented as a Bit String Label.) + + Label The bit string representing a sequence of One-Bit Labels, + with the most significant bit first. That is, the One-Bit + Label in position 17 in the diagram above represents a + subdomain of the domain represented by the One-Bit Label + in position 16, and so on. + + The Label field is padded on the right with zero to seven + pad bits to make the entire field occupy an integral + number of octets. These pad bits MUST be zero on + transmission and ignored on reception. + + A sequence of bits may be split into two or more Bit-String Labels, + but the division points have no significance and need not be + preserved. An excessively clever server implementation might split + + + +Expires September 26, 1999 Crawford [Page 2] + +Internet Draft Binary DNS Labels March 21, 1999 + + + Bit-String Labels so as to maximize the effectiveness of message + compression [DNSIS]. A simpler server might divide Bit-String + Labels at zone boundaries, if any zone boundaries happen to fall + between One-Bit Labels. + + +3.2. Textual Representation + + A Bit-String Label is represented in text -- in a zone file, for + example -- as a surrounded by the delimiters "\[" and + "]". The 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 is present, the number of digits in the + MUST be just sufficient to contain the number of bits specified by + the . If there are insignificant bits in a final + hexadecimal or octal digit, they MUST be zero. A + always has all four parts even if the associated is less + + + +Expires September 26, 1999 Crawford [Page 3] + +Internet Draft Binary DNS Labels March 21, 1999 + + + than 24, but, like the other forms, insignificant bits MUST be zero. + + Each number represented by a must be between 0 and 255, + inclusive. + + The number represented by must be between 1 and 256 + inclusive. + + The number represented by must be between 1 and 32 + inclusive. + + When the textual form of a Bit-String Label is generated by machine, + the length SHOULD be explicit, not implicit. + + +3.2.1. Examples + + The following four textual forms represent the same Bit-String + Label. + + \[b11010000011101] + \[o64072/14] + \[xd074/14] + \[208.116.0.0/14] + + The following represents two consecutive Bit-String Labels which + denote the same relative point in the DNS tree as any of the above + single Bit-String Labels. + + \[b11101].\[o640] + + + +3.3. Canonical Representation and Sort Order + + Both the wire form and the text form of binary labels have a degree + of flexibility in their grouping into multiple consecutive Bit- + String Labels. For generating and checking DNS signature records + [DNSSEC] binary labels must be in a predictable form. This + canonical form is defined as the form which has the fewest possible + Bit-String Labels and in which all except possibly the first (least + significant) label in any sequence of consecutive Bit-String Labels + is of maximum length. + + For example, the canonical form of any sequence of up to 256 One-Bit + Labels has a single Bit-String Label, and the canonical form of a + sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of + which the second and third contain 256 label bits. + + + +Expires September 26, 1999 Crawford [Page 4] + +Internet Draft Binary DNS Labels March 21, 1999 + + + The canonical sort order of domain names [DNSSEC] is extended to + encompass binary labels as follows. Sorting is still label-by- + label, from most to least significant, where a label may now be a + One-Bit Label or a standard (code 00) label. Any One-Bit Label + sorts before any standard label, and a 0 bit sorts before a 1 bit. + The absence of a label sorts before any label, as specified in + [DNSSEC]. + + For example, the following domain names are correctly sorted. + + foo.example + \[b1].foo.example + \[b100].foo.example + \[b101].foo.example + bravo.\[b10].foo.example + alpha.foo.example + + +4. Processing Rules + + A One-Bit Label never matches any other kind of label. In + particular, the DNS labels represented by the single ASCII + characters "0" and "1" do not match One-Bit Labels represented by + the bit values 0 and 1. + + +5. Discussion + + A Count of zero in the wire-form represents a 256-bit sequence, not + to optimize that particular case, but to make it completely + impossible to have a zero-bit label. + + +6. IANA Considerations + + This document defines one Extended Label Type, termed the Bit-String + Label, and requests registration of the code point 000001 binary in + the space defined by [EDNS0]. + + +7. Security Considerations + + All security considerations which apply to traditional ASCII DNS + labels apply equally to binary labels. The only new consideration + is the particular canonical representation which must be used for + creating or verifying signatures [DNSSEC] on data containing binary + labels. + + + + +Expires September 26, 1999 Crawford [Page 5] + +Internet Draft Binary DNS Labels March 21, 1999 + + +8. References + + [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234. + + [DNSIS] P.V. Mockapetris, "Domain names - implementation and + specification", RFC 1035. + + [DNSSEC]D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security + Extensions", RFC 2065. + + [EDNS0] P. Vixie, "Extension mechanisms for DNS (EDNS0)", Currently + draft-dnsind-edns0-01.txt. + + [KWORD] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels," RFC 2119. + + +9. Author's Address + + Matt Crawford + Fermilab MS 368 + PO Box 500 + Batavia, IL 60510 + USA + + Phone: +1 630 840-3461 + + EMail: crawdad@fnal.gov + + + + + + + + + + + + + + + + + + + + + + +Expires September 26, 1999 Crawford [Page 6] + diff --git a/doc/draft/draft-ietf-dnsind-dddd-00.txt b/doc/draft/draft-ietf-dnsind-dddd-00.txt new file mode 100644 index 0000000000..ad07a26b42 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-dddd-00.txt @@ -0,0 +1,336 @@ + + + + + DNSSEC Working Group Brian Wellington (TISLabs) + INTERNET-DRAFT Olafur Gudmundsson (TISLabs) + February 1999 + + + + Updates: RFC 2136 + + + + Deferred Dynamic Domain Name System (DNS) Delete Operations + + + Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + + Abstract + + This document proposes a mechanism for notifying a dynamic DNS server + that a delete operation should be performed at a certain point in the + future. This works within the framework of the current DNS dynamic + update protocol, and provides needed functionality for clients with + leased dynamic addresses. + + + + + + + + + + Expires August 1999 [Page 1] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + + 1 - Introduction + + Dynamic update operations for the Domain Name System [RFC1034, RFC1035] + are defined in [RFC2136], but there is no automated method of specifying + that records should have a fixed lifetime, or lease. + + 1.1 - Overview of DNS Dynamic Update + + DNS dynamic update defines a new DNS opcode and a new interpretation of + the DNS message if that opcode is used. An update can specify + insertions or deletions of data, along with prerequisites necessary for + the updates to occur. All tests and changes for a DNS update request + are restricted to a single zone, and are performed at the primary server + for the zone. The primary server for a dynamic zone must increment the + zone SOA serial number when an update occurs or before the next + retrieval of the SOA. + + 1.2 - Overview of DHCP leases + + DHCP [RFC2131] provides a means for a host to obtain a network address + from a DHCP server. The server may ``lease'' this address to the host, + meaning that it is valid only for the period of time specified in the + lease. The host may may extend its lease with subsequent requests, or + may issue a message to release the address back to the server when it is + no longer needed. + + 2 - Background + + When a host receives dynamic addresses with associated dynamic DNS + records, the records can be updated by either the host or the DHCP + server. If possible, update by the server is recommended, since the + server maintains lease information for each address. In some cases, + though, the server cannot update some or all of the DNS records. This + happens when the DNS and DHCP server are under different administration, + for example. + + A host can easily update its own DNS records when receiving information + from the DHCP server. It can also delete its records when shutting + down. If the host unexpectedly goes down, though, it cannot delete the + records. When the DHCP lease on the address expires and is not renewed, + the DHCP server may reassign the address. The DNS records now point to + an assigned address, but not the correct address. Until the host + updates its records again, DNS will contain bad information. + + Since the DHCP and DNS servers are often not co-located with the + clients, the possibility of a host unexpectedly going down and not + communicating with the servers is non-trivial. + + + + + Expires August 1999 [Page 2] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + + If the host could set a lease on the DNS records similar to that on its + address, the DNS records would lose validity at the same time as the + address. This would prevent bad information from remaining in DNS. DNS + has no such provision for leases, though, since this would require + storing a lease time along with each record (or each record in a dynamic + zone). + + An alternative method is suggested. A ``delete'' update is sent along + with the ``add'' update, but the delete is marked in such a way that it + will not be executed immediately. Instead, it will be stored for the + specified amount of time before being applied. If the host wishes to + extend or shorten the lifetime of the DNS record(s), it can replace the + ``deferred delete'' record, which will reset the lease time of the + record(s). The ``deferred delete'' record would, of course, also be + removed if a normal delete update was received. + + This functionality is useful for DHCP leases and maintainance of IPv6 + routing prefixes. DNSSEC compliant server can also use deferred dynamic + delete information to compute signatures of records affected by the + delete operation prior to the delete operation, using spare cycles. + + 3 - Protocol changes + + When doing a delete update operation as defined in [RFC2136] (deleting + an RR, an RRset, or all RRset from a name), the TTL field MUST be + specified as 0. An [RFC2136] compliant server will reject an update + record with a non-zero TTL. This document overloads the TTL field. If + TTL is non-zero, the value represents the number of seconds (a 32 bit + unsigned integer) before which the delete will be applied to the zone. + Thus, the delete operation will be deferred for that number of seconds, + where the number of seconds indicates the lease time. A 32 bit integer + provides for a lease time of over 136 years, which should be long enough + for most uses. + + 3.1 - Storage and execution + + Deferred delete records are stored, persistently, by the name server. + The name server SHOULD attempt to evaluate the deletes in a timely + manner. + + 3.2 - Processing of deferred deletes + + When a deferred delete is received, the server must check to see if it + matches an existing deferred delete records, where matching indicates + the same name, type, class, and rdata. If a match is found, the new + deferred delete MUST replace the old one. If the deferred delete does + not refer to any record in the server, it should fail as a normal delete + would. + + + + Expires August 1999 [Page 3] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + + 3.3 - Processing of normal deletes + + When a normal delete is received and accepted, the server MUST purge any + deferred delete that no longer refers to any records. + + 3.4 - Processing of cancellations + + The value 0xFFFFFFFF (the largest unsigned 32 bit integer) in the TTL + field has a special meaning. If a delete containing this lease time is + received, the server will unconditionally remove any matching deferred + deletes. + + 3.5 - Processing of adds + + When data is added through a dynamic update which matches a deferred + delete, there is no additional processing done. + + 3.6 - Detecting server support of Deferred Delete + + Client can determine if server supports deferred delete by the return + code of a deferred delete request by sending a ADD + Delete request to + the server, where the delete has low TTL. RFC2136 compliant server MUST + return either rcode FORMERR or NOTIMPL. Server compliant with this + document will return NOERROR. + + 4 - TTL Modification + + + 4.1 - Initial TTL Limits + + The TTL of all added or updated RRs in the Update Section SHOULD be + maximized silently to one half of the lease time. This will cause + downstream caching name servers to purge RRsets containing this RR at + least once before expiry. + + 4.2 - TTL Half Life + + Each time an RR's expiry reaches half of its previous value, that RR's + TTL will be reduced to half of its previous value, until the TTL reaches + a value less than or equal to sixty (60), i.e., one minute of real time, + at which time the TTL will not be automatically reduced further by the + primary master. It should be noted that RRs held in a server's memory + need not be swept for half life processing, as long as the TTL changes + appear when the RR next becomes externally visible, and as long as the + ``zone has changed'' processing (see below) is done at the time of the + half life expiration. + + + + + + Expires August 1999 [Page 4] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + + Whenever the TTL is automatically reduced by this process, the zone will + be considered ``changed'' for the purpose of automatic SOA SERIAL + increment (as in [RFC2136]) and real time zone slave notification + [RFC1996]. + + + 5 - Usage + + Normally, a deferred delete update will initially be sent along with an + add, although this is not required. Further updates to the deferred + delete will be sent independently. If the deferred delete is associated + with a leased address, the lease time of the update SHOULD be + approximately equal to the lease time of the address. + + 6 - Security considerations + + This addition to the dynamic DNS protocol does not affect the security + of the protocol. If security is desired, TSIG [TSIG] and/or DNSSEC + [secext2] authentication should be used, as specified in [simple-update] + or [RFC2137, update2]. The authors strongly recommend using security + along with this protocol. + + If a DNSSEC signed-zone is modified with deferred deletes, the server + must resign any affected records when the delete is executed. No + special processing is required when the delete is received. + + 7 - IANA Considerations + + None. + + 8 - References + + [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' + RFC 1034, ISI, November 1987. + + [RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification,'' RFC 1035, ISI, November 1987. + + [RFC1996] P. Vixie ``A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY),'' RFC 1996, ISC, August 1996. + + [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic + Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore + & Cisco & DEC, April 1997. + + [RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC + 2137, CyberCash, April 1997. + + + + + Expires August 1999 [Page 5] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + + [secext2] D. Eastlake ``Domain Name System Security Extensions,'' + draft-ietf-dnssec-secext2-07.txt, IBM, December 1998. + + [TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington + ``Secret Key Transaction Signatures for DNS (TSIG),'' draft- + ietf-dnsind-tsig-08.txt, ISC & TIS & IBM, February 1999. + + [simple-update] + B. Wellington ``Simple Secure Domain Name System (DNS) + Dynamic Update,'' draft-ietf-dnsind-simple-update-00.txt, + TISLabs, November 1998. + + [update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic + Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite + Systems Company, August 1998. + + 8 - Author's Address + + + Brian Wellington Olafur Gudmundsson + TISLabs at Network Associates TISLabs at Network Associates + 3060 Washington Road, Route 97 3060 Washington Road, Route 97 + Glenwood, MD 21738 Glenwood, MD 21738 + +1 443 259 2369 +1 443 259 2389 + +1 301 854 6889 (main number) +1 301 854 6889 + + + + + + + + + + + + + + + + + + + + + + + + + + + Expires August 1999 [Page 6] diff --git a/doc/draft/draft-ietf-dnsind-dname-03.txt b/doc/draft/draft-ietf-dnsind-dname-03.txt new file mode 100644 index 0000000000..f28cd1b3ea --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-dname-03.txt @@ -0,0 +1,502 @@ + +DNSIND Working Group Matt Crawford +Internet Draft Fermilab + March 21, 1999 + + Non-Terminal DNS Name Redirection + + + + +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: + + DNAME + + The format is not class-sensitive. All fields are required. The + RDATA field is a [DNSIS]. + + The DNAME RR causes type NS additional section processing. + + The effect of the DNAME record is the substitution of the record's + for its 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 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 + for its in QNAME would overflow the legal size for a + , 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 + for its in the SNAME would overflow the + legal size for a , 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 which is a + subdomain of the 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] + diff --git a/doc/draft/draft-ietf-dnsind-edns0-01.txt b/doc/draft/draft-ietf-dnsind-edns0-01.txt new file mode 100644 index 0000000000..8aefeaf902 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-edns0-01.txt @@ -0,0 +1,319 @@ + + + + + DNSIND Working Group Paul Vixie + INTERNET-DRAFT ISC + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Expires July 1999 [Page 6] + diff --git a/doc/draft/draft-ietf-dnsind-edns1-02.txt b/doc/draft/draft-ietf-dnsind-edns1-02.txt new file mode 100644 index 0000000000..d6be78be77 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-edns1-02.txt @@ -0,0 +1,320 @@ + + + + + + DNSIND Working Group Paul Vixie + INTERNET-DRAFT ISC + January, 1999 + + + Extensions to DNS (EDNS1) + + + Status of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as ``work in progress.'' + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + + + Abstract + + This document specifies a number of extensions within the Extended + DNS framework defined by [EDNS0], including several new extended + label types and the ability to ask multiple questions in a single + request. + + 1 - Rationale and Scope + + 1.1. EDNS (see [EDNS0]) specifies an extension mechanism to DNS (see + [RFC1035]) which provides for larger message sizes, additional label + types, and new message flags. + + 1.2. This document makes use of the EDNS extension mechanisms to add + several new extended label types and message options, and the ability to + ask multiple questions in a single request. + + + + + + Expires July 1999 [Page 1] + + INTERNET-DRAFT EDNS1 January 1999 + + + 2 - Affected Protocol Elements + + 2.1. Compression pointers are 14 bits in size and are relative to the + start of the DNS Message, which can be 64KB in length. 14 bits restrict + pointers to the first 16KB of the message, which makes labels introduced + in the last 48KB of the message unreachable by compression pointers. A + longer pointer format is needed. + + 2.2. DNS Messages are limited to 65535 octets in size when sent over + TCP. This acts as an effective maximum on RRset size, since multiple + TCP messages are only possible in the case of zone transfers. Some + mechanism must be created to allow normal DNS responses (other than zone + transfers) to span multiple DNS Messages when TCP is used. + + 2.3. Multiple queries in a question section have not been supported in + DNS due the applicability of some DNS Message Header flags (such as AA) + and of the RCODE field only to a single QNAME, QTYPE, and QCLASS. + Multiple questions per request are desirable, and some way of asking + them must be made available. + + 3 - Extended Label Types + + 3.1. In [EDNS0], the ``0 1'' label type was specified to denote an + extended label type, whose value is encoded in the lower six bits of the + first octet of a label, and an extended label type of ``1 1 1 1 1 1'' + was further reserved for use in future multibyte extended label types. + + 3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended + compression pointer, such that the following two octets comprise a + 16-bit compression pointer in network byte order. Like the normal + compression pointer, this pointer is relative to the start of the DNS + Message. + + 3.3. The ``0 0 0 0 0 1'' extended label type will indicate a counted bit + string label as described in [CRAW98]. + + 3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long + local compression pointer'' as described in [KOCH98]. + + + + + + + + + + + Expires July 1999 [Page 2] + + INTERNET-DRAFT EDNS1 January 1999 + + + 4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags + are structured as follows: + + +0 (MSB) +1 (LSB) + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | EXTENDED-RCODE | VERSION | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: |MD |FM |RRD|LM | Z | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + + EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. (As + defined by [EDNS0].) + + VERSION Indicates the implementation level of whoever sets it. + Full conformance with the draft standard version of this + specification is version ``1.'' Note that both + requestors and responders should set this to the highest + level they implement, that responders should send back + RCODE=BADVERS and that requestors should be prepared to + probe using lower version numbers if they receive an + RCODE=BADVERS. + + MD ``More data'' flag. Valid only in TCP streams where + message ordering and reliability are guaranteed. This + flag indicates that the current message is not the + complete request or response, and should be aggregated + with the following message(s) before being considered + complete. Such messages are called ``segmented.'' It + is an error for the RCODE (including the EXTENDED- + RCODE), AA flag, or DNS Message ID to differ among + segments of a segmented message. It is an error for TC + to be set on any message of a segmented message. Any + given RR must fit completely within a message, and all + messages will both begin and end on RR boundaries. + + FM ``First match'' flag. Notable only when multiple + questions are present. If set in a request, questions + will be processed in wire order and the first question + whose answer would have NOERROR AND ANCOUNT>0 is treated + as if it were the only question in the query message. + Otherwise, questions can be processed in any order and + all possible answer records will be included in the + response. Response FM should be ignored by requestors. + + + + + Expires July 1999 [Page 3] + + INTERNET-DRAFT EDNS1 January 1999 + + + RRD ``Recursion really desired'' flag. Notable only when a + request is processed by an intermediate name server + (``forwarder'') who is not authoritative for the zone + containing QNAME, and where QTYPE=ANY or QDCOUNT>1. If + set in a request, the intermediate name server can only + answer using unexpired cached answers (either positive + or negative) which were atomically acquired using (a) + the same QTYPE or set of QTYPEs present in the current + question and whose TTLs were each minimized to the + smallest among them when first cached, and (b) the same + FM and LM settings present in the current question. + + LM ``Longest match'' flag. If this flag is present in a + query message, then for any question whose QNAME is not + fully matched by zone or cache data, the longest + trailing label-bounded suffix of the QNAME for which + zone or cache data is present will be eligible for use + as an answer. Note that an intervening wildcard name + shall supercede this behaviour and the rules described + in [RFC1034 4.3.2, 4.3.3] shall apply, except that the + owner name of the answer will be the wildcard name + rather than the QNAME. Any of: QTYPE=ANY, or + QCLASS=ANY, or QCOUNT>1, shall be considered an error if + the LM flag is set. + + If LM is set in a request, then LM has meaning in the + response as follows: If the content of the response + would have been different without the LM flag being set + on the request, then the response LM will be set; If the + content of the response was not determined or affected + by the request LM, then the response LM will be cleared. + If the request LM was not set, then the response LM is + not meaningful and should be set to zero by responders + and ignored by requestors. + + Z Set to zero by senders and ignored by receivers, unless + modified in a subsequent specification. + + 5 - Multiple Questions for QUERY + + 5.1. If QDCOUNT>1, multiple questions are present. All questions must + be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It + is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY. + + + + + + Expires July 1999 [Page 4] + + INTERNET-DRAFT EDNS1 January 1999 + + + 5.2. RCODE and AA apply to all RRs in the answer section having the + QNAME that is shared by all questions in the question section. AA + applies to all matching answers, and will not be set unless the exact + original request was processed by an authoritative server and the + response forwarded in its entirety. + + 5.3. If a multiple question request is processed by an intermediate + server and the authority server does not support multiple questions, the + intermediate server must generate an answer iteratively by making + multiple requests of the authority server. In this case, AA must never + be set in the final answer due to lack of atomicity of the contributing + authoritative responses. + + 5.4. If iteratively processing a multiple question request using an + authority server which can only process single question requests, if any + contributing request generates a SERVFAIL response, then the final + response's RCODE should be SERVFAIL. + + 6 - Acknowledgements + + Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, + Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Michael + Patton were each instrumental in creating this specification. + + 7 - References + + [RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification,'' RFC 1035, USC/Information Sciences + Institute, November 1987. + + [EDNS0] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' Draft + draft-ietf-dnsind-edns0-XX, IETF DNSIND, September 1998 + + [CRAW98] M. Crawford, ``Binary Labels in the Domain Name System,'' + Draft draft-ietf-dnsind-binary-labels-XX, IETF DNSIND, March + 1998. + + [KOCH98] P. Koch, ``A New Scheme for the Compression of Domain + Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt. + IETF DNSIND, March 1998. + + + + + + + + + Expires July 1999 [Page 5] + + INTERNET-DRAFT EDNS1 January 1999 + + + 8 - Author's Address + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063 + +1 650 779 7001 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Expires July 1999 [Page 6] + diff --git a/doc/draft/draft-ietf-dnsind-local-compression-04.txt b/doc/draft/draft-ietf-dnsind-local-compression-04.txt new file mode 100644 index 0000000000..08ac30f6ba --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-local-compression-04.txt @@ -0,0 +1,449 @@ + + + + +INTERNET-DRAFT Peter Koch +Expires: August 1999 Universitaet Bielefeld +Updates: 1035, 1183, 2065, 2163, 2168 February 1999 + + A New Scheme for the Compression of Domain Names + draft-ietf-dnsind-local-compression-04.txt + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments should be sent to the author or the DNSIND WG mailing list + . + +Abstract + + The compression of domain names in DNS messages was introduced in + [RFC1035]. Although some remarks were made about applicability to + future defined resource record types, no method has been deployed yet + to support interoperable DNS compression for RR types specified since + then. + + This document summarizes current problems and proposes a new + compression scheme to be applied to future RR types which supports + interoperability. Also, suggestions are made how to deal with RR + types defined so far. + +1. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + + + +Koch Expires August 1999 [Page 1] + +INTERNET-DRAFT DNS Compression February 1999 + + + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + Domain names herein are for explanatory purposes only and should not + be expected to lead to useful information in real life [TESTTLD]. + +2. Background + + Domain name compression was introduced in [RFC1035], section 4.1.4, + as an optional protocol feature and later mandated by [RFC1123], + section 6.1.2.4. The intent was to reduce the message length, + especially that of UDP datagrams, by avoiding repetition of domain + names or even parts thereof. + + A domain name is internally represented by the concatenation of label + strings, where the first octet denotes the string length, not + including itself. The null string, consisting of a single octet of + zeroes, is the representation of the root domain name and also + terminates every domain name. + + As labels may be at most 63 characters long, the two most significant + bits in the length octet will always be zero. Compression works by + overloading the length octet with a second meaning. If the two MSB + have the value '1', the remainder of the length octet and the next + octet form a compression pointer, which denotes the position of the + next label of the current domain name in the message: + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | 1 1| OFFSET | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + It is important that these pointers always point backwards. + + Compression may occur in several places. First, the owner name of an + RR may be compressed. The compression target may be another owner + name or a domain name in the RDATA section of a previous RR. Second, + any domain name within the RDATA section may be compressed and the + target may be part of the same RR, being the owner name or another + domain name in the RDATA section, or it may live in a previous RR, + either as its owner or as a domain name in its RDATA section. In + fact, due to the chaining feature, combinations of the above may + occur. + +3. Problems + + While implementations shall use and must understand compressed domain + names in the RDATA section of "well known" RR types (those initially + defined in [RFC1035]), there is no interoperable way of applying + + + +Koch Expires August 1999 [Page 2] + +INTERNET-DRAFT DNS Compression February 1999 + + + compression to the RDATA section of newer RRs: + + Quote from [RFC1123], section 6.1.3.5: + Compression relies on knowledge of the format of data inside a + particular RR. Hence compression must only be used for the + contents of well-known, class-independent RRs, and must never be + used for class-specific RRs or RR types that are not well-known. + The owner name of an RR is always eligible for compression. + + DNS records in messages may travel through caching resolvers not + aware of the particular RR's type and format. These caches cannot + rearrange compression pointers in the RDATA section simply because + they do not recognize them. Handing out these RRs in a different + context later will lead to confusion if the target resolver tries to + uncompress the domain names using wrong information. This is not + restricted to intermediate caching but affects any modification to + the order of RRs in the DNS message. + +4. Local Compression + + We often observe a certain locality in the domain names used as owner + and occuring in the RDATA section, e.g. in MX or NS RRs but also in + newer RR types [RFC1183]: + + host.foo.bar.example RP adm.foo.bar.example adm.persons.bar.example + + So, to still profit from compression without putting interoperability + at risk, a new scheme is defined which limits the effect of + compression to a single RR. + + In contrast to the usual method of using offsets relative to the + start of a DNS packet we start counting at the RR owner or calculate + pointers relative to the start of the RDATA to avoid context + sensitivity. We use an additional compression indicator for a two + octet local pointer: + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | 1 0| OFFSET | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The "10" bits will indicate the use of local compression and + distinguish it from conventional compression, plain labels and EDNS + label codes [EDNS0]. Two types of pointers need to be specified: + those pointing into the owner name and those pointing into RDATA. + + A) Pointers into the owner name are interpreted as the ordinal label + number (starting at 0 for the topmost label, the TLD). This way we + avoid the need for extra decompression of the owner name during + + + +Koch Expires August 1999 [Page 3] + +INTERNET-DRAFT DNS Compression February 1999 + + + message composition or decomposition. + + The highest possible value of a compression pointer pointing into + the owner name is 254. The value 255 is reserved for future use. + + B) Pointers into the RDATA section start at the fixed value 256 for + the first octet and have a maximum value of 16383 limiting + possible targets to the first 16128 octets. The actual offset + relative to the start of RDATA is determined by subtracting 256 + from the value of the pointer. + + Local pointers MUST point to a previous occurence of the same name in + the same RR. Even domain names in another RR of the same type cannot + serve as compression targets since the order of RRs in an RRSet is + not necessarily stable. The length of the compressed name(s) MUST be + used in the length calculation for the RDLENGTH field. + +Example + + Consider a DNS message containing two resource records, one CNAME RR + and one XMPL RR, undefined and meaningless so far, with an RDATA + section consisting of two domain names: + + ab.foo.example IN CNAME bar.example + bar.example IN XMPL ab.foo.example foo.example + + In a message this appears as follows (randomly starting at octet 12): + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 12 | 2 | a | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 14 | b | 3 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 16 | f | o | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 18 | o | 7 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 20 | e | x | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 22 | a | m | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 24 | p | l | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 26 | e | 0 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + 10 octets skipped (TYPE, CLASS, TTL, RDLENGTH) + + + + +Koch Expires August 1999 [Page 4] + +INTERNET-DRAFT DNS Compression February 1999 + + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 38 | 3 | b | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 40 | a | r | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 42 | 1 1| 19 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The XMPL RR with local compression applied: + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 44 | 1 1 | 38 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + 10 octets skipped (TYPE, CLASS, TTL, RDLENGTH) + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 56 | 1 | a | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 58 | 3 | f | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 60 | o | o | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 62 | 1 0| 0 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 64 | 1 0| 258 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The first local pointer at position 62 points to the topmost label + "example" of the XMPL RR's owner. + + The second local pointer at position 64 represents the "foo.example" + and points backwards into the RDATA section, third octet, at absolute + position 58. Note that with conventional compression this example + message would have occupied less space. + +5. Interaction with DNSSEC + + The security extensions to DNS [RFC2065] mandate that domain names in + RDATA be signed only in expanded, lower case format. For RR types + using local compression the specification is changed as follows: + + Resource Records subject to local compression MUST be stored, + signed, transmitted and verified in locally compressed form. Name + expansion or canonicalization MUST NOT be performed on the RDATA + section for signing or verification. + + This way RR type transparency can be achieved, since domain names in + + + +Koch Expires August 1999 [Page 5] + +INTERNET-DRAFT DNS Compression February 1999 + + + the RDATA section are treated as arbitrary data and can be cached and + verified by resolvers not aware of the particular RR type. Old RR + types subject to conventional or no compression are not affected by + this change. + + Wildcard owners may serve as compression targets only in their fixed + part. Even if a particular query asks for a domain name which could + be used to compress the RDATA part more efficiently, this MUST NOT be + done. Otherwise signatures would be invalidated. + +6. Interaction with Binary Labels + + When constructing local compression pointers into the owner name, + every one-bit label is counted as a label. This way the compression + and decompression is independent of the actual bit-string + representation. + + For local compression pointers into the RDATA section, only bit- + string labels may serve as targets, not single one-bit labels. Bit- + string labels may be adjusted to increase compression efficiency + [BINLABELS, section 3.1] + + The internal representation of a domain name has a maximum length of + 255 [RFC 1035]. Any label consists of at least two octets, leading + to at most 127 labels per domain name plus the terminating zero + octet, which does not qualify as a compression target. With the + introduction of binary labels a domain name can consist of up to 1904 + labels (all one-bit labels). This document restricts the possible + compression targets in an owner name to the topmost 255 labels. This + limit was chosen to be consistent with [DNSSEC], section 4.1. + +7. Old RR types and deployment + + Although differences in RDATA sections by class have not yet been + reported and the concept of classes did not really spread, we are + just considering the IN class here. + + The following RR types with domain names in the RDATA section have + been defined since [RFC1035] (Standards Track, Experimental and + Informational RFCs, ignoring withdrawn types): RP [RFC1183], AFSDB + [RFC1183], RT [RFC1183], SIG [RFC2065], PX [RFC2163], NXT [RFC2065], + SRV [RFC2052], NAPTR [RFC2168], KX [RFC2230]. Some specifications do + not mention DNS compression at all, others explicitly suggest it and + only in part identify interoperability issues. Only the KX and SRV + RR types are safe as their specifications prohibit compression. + + The specification of RP, AFSDB, RT, PX, and NAPTR is hereby changed + in that domain names in the RDATA section MUST NOT be compressed and + + + +Koch Expires August 1999 [Page 6] + +INTERNET-DRAFT DNS Compression February 1999 + + + MUST NOT be compression targets. + + Local compression MUST NOT be used for owner names and it MUST NOT be + applied to domain names in RDATA sections of any RR type defined so + far. + + The specification of future RR types should explicitly select the use + of local compression or forbid RDATA domain name compression at all. + +8. Security Considerations + + The usual caveats for using unauthenticated DNS apply. This scheme is + believed not to introduce any new security problems. However, + implementors should be aware of problems caused by blindly following + compression pointers of any kind. [RFC1035] and this document limit + compression targets to previous occurences and this MUST be followed + in constructing and decoding messages. Otherwise applications might + be vulnerable to denial of service attacks launched by sending DNS + messages with infinite compression pointer loops. In addition, + pointers should be verified to really point to the start of a label + (for conventional and local RDATA pointers) and not beyond the end of + the domain name (for local owner name pointers). + + The maximum length of 255 applies to domain names in uncompressed + wire format, so care must be taken during decompression not to exceed + this limit to avoid buffer overruns. + +9. Acknowledgements + + The author would like to thank Andreas Gustafsson, Paul Vixie, Bob + Halley, Mark Andrews and Thomas Narten for their review and + constructive comments. + +10. References + + + [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", + RFC 1034, STD 13, November 1987 + + [RFC1035] Mockapetris,P., "Domain Names - Implementation and + Specification", RFC 1035, STD 13, November 1987 + + [RFC1123] Braden,R., "Requirements for Internet Hosts -- Application + and Support", RFC 1123, STD 3, October 1989 + + [RFC1183] Everhart,C., Mamakos,L., Ullmann,R., Mockapetris,P., "New + DNS RR Definitions", RFC 1183, October 1990 + + + + +Koch Expires August 1999 [Page 7] + +INTERNET-DRAFT DNS Compression February 1999 + + + [RFC2052] Gulbrandsen,A., Vixie,P. "A DNS RR for specifying the + location of services (DNS SRV)", RFC 2052, October 1996 + + [RFC2065] Eastlake,D., Kaufman,C. "Domain Name System Security + Extensions" RFC 2065, January 1997 + + [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997 + + [RFC2163] Allocchio,C., "Using the Internet DNS to Distribute MIXER + Conformant Global Address Mapping (MCGAM)", RFC 2163, + January 1998 + + [RFC2168] Daniel,R., Mealling,M., "Resolution of Uniform Resource + Identifiers using the Domain Name System", RFC 2168, June + 1997 + + [RFC2230] Atkinson,R., "Key Exchange Delegation Record for the DNS", + RFC 2230, November 1997 + + [EDNS0] Vixie,P., "Extension mechanisms for DNS (EDNS0)", draft- + ietf-dnsind-edns0-XX.txt, work in progress + + [BINLABELS] Crawford,M., "Binary Labels in the Domain Name System", + draft-ietf-dnsind-binary-labels-XX.txt, work in progress + + [TESTTLD] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", + , work in progress + + + +11. Author's Address + + Peter Koch + Universitaet Bielefeld + Technische Fakultaet + Postfach 10 01 31 + D-33501 Bielefeld + Germany + +49 521 106 2902 + + + + + + + + + + + +Koch Expires August 1999 [Page 8] + diff --git a/doc/draft/draft-ietf-dnsind-local-names-06.txt b/doc/draft/draft-ietf-dnsind-local-names-06.txt new file mode 100644 index 0000000000..15db52aa8b --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-local-names-06.txt @@ -0,0 +1,754 @@ + +INTERNET-DRAFT Local Domain Names + November 1998 + Expires May 1999 + + + + Local DNS Names + ----- --- ----- + + Donald E. Eastlake 3rd + + + +Status of This Document + + This draft, file name draft-ietf-dnsind-local-names-06.txt, is + intended to be become an Informational RFC. Distribution of this + document is unlimited. Comments should be sent to the DNS mailing + list or to the author. + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + + + +Abstract + + A set of second level domain names are defined under a new top level + domain name such that local private DNS zones can be maintained + similar to the private IP addresses reserved in [RFC 1918]. These + zone locally appear to be part of the global DNS name tree. + Additional second level domain names are assigned under this TLD for + loopback addresses and IPv6 link and site local addresses. + + + + + + + + +Donald E. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT Local DNS Names + + +Acknowledgments + + The valuable contributions of the following persons are gratefully + acknowledged: + + Dan Harrington + + Michael A. Patton + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Acknowledgments............................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Local Names Via The .local Top Level Domain.............3 + 2.1 Local DNS Server Specifics.............................6 + 2.2 Local in-addr.arpa Zones...............................7 + 2.3 Name Conflicts.........................................7 + 2.4 Nested Enclaves........................................8 + 3. Other Names in .local...................................8 + 4. Security Considerations.................................8 + 4.1 Strength of Privacy Offered............................8 + 4.2 Interaction with DNSSEC................................9 + 4.3 Network Abuse..........................................9 + + References................................................10 + Author's Address..........................................10 + Expiration and File Name..................................10 + + Appendix A: the .local zone...............................11 + + Appendix B: the .in-addr.arpa zone.......................13 + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT Local DNS Names + + +1. Introduction + + The global Internet Domain Name System (DNS) is documented in [RFC + 1034, 1035, 1591] and numerous additional Requests for Comment. It + defines a tree of names starting with root, ".", immediately below + which are top level domain names such as .com and .us. Below top + level domain names there are normally additional levels of names. + + Generally the information in the DNS is public and intended to be + globally accessible. Certainly, in the past, the model of the + Internet was one of end-to-end openness [RFC 1958]. However, with + increasing security threats and concerns, firewalls and enclaves have + appeared. In many cases, organizations have hosts or resources that + they specifically want to reference with DNS names but which they + also want to be walled off from global access and even from global + knowledge of the DNS name. + + In the realm of IP addresses, this has been accomplished by reserving + three blocks of addresses as documented in [RFC 1918]. Familiarity + with the contents of that RFC is assumed. + + In the DNS area, local private names have generally been achieved in + the past by "splitting" DNS at the enclave boundary, giving different + answers to resolvers depending or whether they are inside or outside + of the enclave, using different servers for inside and outside, etc. + as mentioned in [RFC 1918]. Such relatively complex configuration + diddling is at variance with the simple global tree structure of the + initial DNS. + + This document specifies an alternative approach to achieving the + effect of local names that is more in tune with the concept of a + single global DNS tree or at least the appearance of a single tree. + Use of this approach is not required and older techniques will + continue to work. + + [RFC 1918] requires that private IP addresses not be indirectly + exposed to the general Internet via DNS records or otherwise. This + RFC provides the recommended way to accomplish such private IP + address hiding and carves out an exception thereto for the addresses + of the servers for some zones which are children of the .local top + level domain name. + + + +2. Local Names Via The .local Top Level Domain + + The fundamental idea, as described in more detail below, is to define + second level domains under .local which are served by DNS name + servers that have private IP addresses. These server's addresses + would only be routed within the domain to which the names are local. + + +Donald E. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT Local DNS Names + + + Thus the servers, and the names and resource records inside them, + would not be directly accessible outside the enclave, if the + guidelines in this document are followed. + + The following figure shows a highly simplified overview of an example + configuration: + + +----------------------------+ + | domain/enclave A | + | | + | #====================# | + | H private IP addrs A H | + | H H | + +-----------------------O privhost1 H | + | | H H | + +-----+-----------------O privhost2 H | + | | | H H | + | | | #====================# | + | | a | | + | +--------------------O pubhost3 | + .local | | | | | + +----+ | | +----------------------------+ + | | | | + | | | | +----------------------------+ + | | | | | domain/enclave B | + (root) | | | | | | + . ----+ | | | | #====================# | + | | | | | H private IP addrs B H | + | | | | | H H | + | +--|--------------------O privhost2 H | + | | | | H H | + +-------+ +-----------------O privhost3 H | + .com | | H : H | + | | #====:===============# | + | | : | + | b +-------------O pubhost4 | + +------+ | | + | +-------------O pubhost5 | + | | | + | +----------------------------+ + | + | example + +---------------------O pubhost6 + + Starting at the bottom, pubhost6 is intended to illustrate an + ordinary host connected to the Internet with domain name + pubhost6.example.com. Though not indicated in the above diagram, + every DNS zone is in fact served by at least two hosts (and some but + substantially more). The addresses of the servers for the root (.), + .com, and example.com zones would all be in the public portion of the + + +Donald E. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT Local DNS Names + + + IP address space, i.e., in the space of all unicast IP addresses not + reserved for private use. + + Moving to the top of the figure, enclave A represents some + organization that wishes to have some hosts with publicly visible + names and some with hidden names that are visible only locally. + pubhost3.a.com is an example of a publicly visible host which would + probably have a public IP address although access to pubhost3 from + outside the enclave might be filtered or even blocked by a firewall + or the like. privhost1 and privhost2 are examples of hidden names. + If a zone with privhost1 and privhost2 in it is served by DNS servers + with private IP addresses ("private IP addresses A") such that the + servers are accessible within enclave A but not from outside enclave + A, then the information is that zone will only be locally visible. + As show in the above figure, privhost1 and privhost2 have addresses + that are also private IP addresses, making those hosts inaccessible + outside enclave A, but it is the private addresses of the DNS + servers, not of the hosts pointed to from within the private DNS + zone, that provides the protection for the DNS names and other + private DNS information. (From the above simplified diagram, it + might appear that fully qualified domain names of these hosts would + be privhost1.local and privhost2.local but the names are actually + more complex as explained in Section 2.1.) + + Finally, in the middle, another enclave is shown with two hosts with + visible names and public IP addresses, pubhost4.b.com and + pubhost5.b.com. In addition, there are two private host names + privhost2 and privhost3. The duplication of privhost2 between + enclaves A and B would not be a problem as only DNS resolvers in + enclave A can access the DNS servers with the zone having the enclave + A version of privhost2 and only DNS resolvers in enclave B can access + the DNS servers with the zone having the enclave B version of + privhost2. + + Publicly visible host names are required by [RFC 1918] to have public + (i.e., globally unique) IP addresses. Private DNS names would + normally have private IP addresses, and all do in the figure above, + but this is not required. A public IP address could be stored under + a private name. And, of course, it is possible for the same physical + host to have multiple IP addresses, including a mix of public and + private. The dotted line in the figure above is intended to indicate + that privhost3 and pubhost4 are actually the same physical machine. + The could be accomplished equally well by storing a single public + address for that host under both the public and private names or by + having the host answer to both a public IP address stored under the + public name and a private IP address stored under the private name. + In the later case you could even also store the public address along + with the private address under the private name. + + + + +Donald E. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT Local DNS Names + + +2.1 Local DNS Server Specifics + + A variety of second level names are provided in the .local zone each + of which is a delegation point to a zone with some number of name + servers in one of the private IP address space blocks. The multiple + second level names permit choice between the different private IP + blocks and different numbers of servers. Thus the actual fully + qualified name for the private host examples in the figure above + would be more like privhost1.a2.local, privhost2.a2.local, etc. (but + see Section 2.3 below). + + Glue records are provided to give private IP addresses for initial + name servers; however, it should be noted that the NS and A records + in the local zones will dominate the information stored in the .local + zone. This means that once a resolver has contacted a local server, + the list of NS RRs in the local zone on that server will control and + could contain more or different servers than were given at the chosen + .local delegation point. Nevertheless, the glue A records in the + global .local zone do place some constraints of the private IP + address of the local DNS servers implementing zones which are + children of .local. + + It is also possible for an enclave to locally configure its own + version of the .local zone. Depending on its enclave boundary + implementation, it might be able to constrain all of its internal + references to .local to use its own variant version. This version + could have whatever private addresses were desired for the name + servers involved. Such a configuration MAY be used, but it is + recommended that the globally accessible .local specified herein be + used for uniformity. That way, even a unconstrained resolver + starting from the normal root servers (i.e., an "out of the box" + resolver) will correctly resolve or fail to resolve names under + .local depending on the resolvers location in the network as + specified herein. + + It is only necessary for the local DNS servers to have private IP + addresses to achieve the effect of local names. However, care MUST + be taken that none of the local DNS servers or any server that might + cache their output is accessible by any network interface that has a + non-private IP address. Otherwise considerable confusion could + result if local names are resolved by a resolver outside a local + enclave to private IP addresses which have a different meaning for + that resolver. + + The Appendix A to this document gives the recommended initial content + of the .local zone. + + + + + + +Donald E. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT Local DNS Names + + +2.2 Local in-addr.arpa Zones + + Inverse lookup of local names corresponding to private IP addresses + needs to be provided via the in-addr.arpa zone. Appendix B contains + recommended additions to the in-addr.arpa zone (or subzones thereof) + to accomplish this. Because of the fixed naming within this zone, + different names with different numbers of servers or different + addresses can not be provided. As with the forward .local entries, + the actual NS RRs in the servers serving the private portions of the + inverse in-addr.arpa will dominate. When one of these is queried by + a resolver, it can provide information on additional servers for that + particular subzone in the private IP address portion of the in- + addr.arpa tree. + + + +2.3 Name Conflicts + + The intention is that local names would only be used in the enclave + where the entities they refer to exist, and these names would not be + exported. However, experience indicates that. despite best efforts + to avoid it, some such names will leak out via email cc's, URL's in + HTML, etc. (Such leakage occurs regardless of how the local names + are formed or whether they are accessible via the default root zone.) + These leaked private names can cause confusion if they can conflict + with global names or names local to other enclaves. Use of the + .local top level domain assures no conflict with global names. To + assure no conflict with different local fully qualified names, the + domain name of the enclave SHOULD always be prefixed to .local. + + For example, a company might have + host1.company.co.xy + as a globally accessible host and + host2.company.co.xy.b3.local + as a host for internal use only. The global name could normally be + resolvable anywhere on the Internet while the local name could not be + resolved anywhere except within the company enclave. + + Note that different names were chosen for the initial label in the + two names above, i.e., host1 and host2. The reason for this is that, + in some environments, local hosts are referred to by an unqualified + names, such as host3. For DNS look up purposes, such a name must be + expanded into a fully qualified domain name and a "search list" of + possible suffix qualifications is tried. If, for example, both + host4.school.ac.xy and host4.school.ac.xy.b3.local existed, then a + local reference to "host4" would be ambiguous and could lead to + either machine depending on the order of qualifications tried. This + order could even be different in different pieces of local software + or on different local hosts, resulting in substantial confusion. For + this reason, it is strongly recommended that disjoint name sets be + + +Donald E. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT Local DNS Names + + + used for global and local entity unqualified domain names and that + fully qualified domain names be used wherever practical. + + + +2.4 Nested Enclaves + + It is possible to have enclaves within enclaves. In general the best + way to accomplish this is to use a different portion of the private + IP address space at each nesting level of enclave. (Private IP + address space can be reused in enclaves that are siblings or the + like.) Then similar entries to those proposed here for .local can be + made in the private zone referring to name servers with addresses in + the nested enclave's private IP address space. + + + +3. Other Names in .local + + Three additional second level domain names are assigned in the .local + top level domain for other types of local names. + + In particular, link.local and site.local are reserved for use in + qualifying IPv6 link local names and site local names. + + In addition, loopback.local is assigned and given the loopback + address. + + + +4. Security Considerations + + This section discusses the strength of the privacy offered by using + subzones of .local, interactions with DNS security, and possible + interaction with network abuse. + + + +4.1 Strength of Privacy Offered + + It should be noted that the privacy of the DNS information protected + by storing it in servers with private IP addresses is not strong. It + is completely dependent on the integrity of enclave perimeter routing + to make these servers inaccessible. And it may occasionally leak out + in any case due to inclusion in email address fields, web pages, and + the like, although such leakage should be no worse than current split + DNS implementations of DNS data hiding. + + Software should not depend on local names being accessible only + within a particular enclave as someone could deliberately create the + + +Donald E. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT Local DNS Names + + + same names within a different enclave even if the names incorporate + the name of the original enclave in an attempt to avoid such + conflicts. + + + +4.2 Interaction with DNSSEC + + Although an enclave may derive some amount of security by virtue of + its isolation, it will normally be desirable to implement DNS + security [draft-ietf-dnssec-secext2-*.txt] within the enclave. The + enclave owner should generate their own keys and sign their subzone + of .local. However, a signed copy of their public key can not be + included in the .local zone as it is different for every enclave. + Thus, to authenticate the .local subzone contents, it will be + necessary to sign the KEY RR at the apex of the local subzone of + .local with the .local zone key or another key that is trusted by + local resolvers or staticly configure the public key for the .local + subzone in local resolvers. + + + +4.3 Network Abuse + + Use of the defined private server second level domain names under + return addresses, or the like, could cause DNS, SMTP, and many other + types of references to IP addresses in the [RFC 1918] blocks. This + can occur from within a firewall due to web browsing or email + processing of web pages or email from virtually anywhere in the + Internet. However, this is not a new situation as anyone who + controls any zone in the DNS, say zone.foo.example, can, although + this violates [RFC 1918], create entries therein with arbitrary IP + addresses (including multicast and undefined formats). Then, by + using these name entries in email, web links, etc., attempt to cause + a variety of spurious protocol connections to those addresses. + + Use of .local at least provides some warning that a name may be not + be correctly resolvable. + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT Local DNS Names + + +References + + RFC 1033 - M. Lottor, "Domain Administrators Operations Guide", + November 1987. + + RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", + STD 13, November 1987. + + RFC 1035 - P. Mockapetris, "Domain Names - Implementation and + Specifications", STD 13, November 1987. + + RFC 1591 - J. Postel, "Domain Name System Structure and Delegation", + 03/03/1994. + + RFC 1918 - Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. + Lear, "Address Allocation for Private Internets", 02/29/1996. + + RFC 1958 - B. Carpenter, "Architectural Principles of the Internet", + 06/06/1996. + + draft-ietf-dnssec-secext2-*.txt - D. Eastlake "Domain Name System + Security Extensions". + + + +Author's Address + + Donald E. Eastlake 3rd + IBM + 318 Acton Street + Carlisle, MA 01741 USA + + Telephone: +1 978-287-4877 + +1 914-784-7913 + FAX: +1 978-371-7148 + EMail: dee3@us.ibm.com + + + +Expiration and File Name + + This draft expires May 1999. + + Its file name is draft-ietf-dnsind-local-names-06.txt. + + + + + + + + +Donald E. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT Local DNS Names + + +Appendix A: the .local zone + + ===== The .local zone suggested initial contents ==== + + local. IN SOA ... ... ( + 1234 ; serial + 90000 ; refresh, 25 hours + 36000 ; retry, 10 hours + 3456000 ; expiry, 40 days + 43200 ) ; minimum of 12 hours + NS ... ; actual servers for .local zone + NS ... + ... + + loopback A 127.0.0.1 + AAAA 0::1 + MX 100 loopback.local. + + a2.local. NS ns1.a2.local. + NS ns2.a2.local. + ns1.a2.local. A 10.1.1.2 + ns2.a2.local. A 10.1.2.2 + + a3.local. NS ns1.a3.local. + NS ns2.a3.local. + NS ns3.a3.local. + ns1.a3.local. A 10.1.1.2 + ns2.a3.local. A 10.1.2.2 + ns3.a3.local. A 10.2.1.2 + + a4.local. NS ns1.a4.local. + NS ns2.a4.local. + NS ns3.a4.local. + NS ns4.a4.local. + ns1.a4.local. A 10.1.1.2 + ns2.a4.local. A 10.1.2.2 + ns3.a4.local. A 10.2.1.2 + ns4.a4.local. A 10.128.1.2 + + b2.local. NS ns1.b2.local. + NS ns2.b2.local. + ns1.b2.local. A 172.16.1.2 + ns2.b2.local. A 172.16.2.2 + + b3.local. NS ns1.b3.local. + NS ns2.b3.local. + NS ns3.b3.local. + ns1.b3.local. A 172.16.1.2 + ns2.b3.local. A 172.16.2.2 + ns3.b3.local. A 172.16.128.2 + + +Donald E. Eastlake 3rd [Page 11] + + +INTERNET-DRAFT Local DNS Names + + + c2.local. NS ns1.c2.local. + NS ns2.c2.local. + ns1.c2.local. A 192.168.1.2 + ns2.c2.local. A 192.168.2.2 + + c3.local. NS ns1.c3.local. + NS ns2.c3.local. + NS ns3.c3.local. + ns1.c3.local. A 192.168.1.2 + ns2.c3.local. A 192.168.2.2 + ns3.c3.local. A 192.168.128.2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 12] + + +INTERNET-DRAFT Local DNS Names + + +Appendix B: the .in-addr.arpa zone + + ===== Auggested additional entries in the in-addr.arpa zone ==== + + 10.in-addr.arpa. NS ns1.a2.local. + NS ns2.a2.local. + ns1.a2.local. A 10.1.1.2 + ns2.a2.local. A 10.1.2.2 + + 16.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + ns1.b2.local. A 172.16.1.2 ; one set of glue records + ns2.b2.local. A 172.16.2.2 ; for all the b2 cases + 17.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 18.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 19.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 20.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 21.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 22.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 23.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 24.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 25.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 26.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 27.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 28.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 29.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 30.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + 31.172.in-addr.arpa. NS ns1.b2.local. + NS ns2.b2.local. + + 168.192.in-addr.arpa. NS ns1.c2.local. + NS ns2.c2.local. + ns1.c2.local. A 192.168.1.2 + ns2.c2.local. A 102.168.2.2 + + + + +Donald E. Eastlake 3rd [Page 13] + diff --git a/doc/draft/draft-ietf-dnsind-rfc2052bis-02.txt b/doc/draft/draft-ietf-dnsind-rfc2052bis-02.txt new file mode 100644 index 0000000000..7db98afb97 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-rfc2052bis-02.txt @@ -0,0 +1,560 @@ + + + +Applications Area Arnt Gulbrandsen +INTERNET-DRAFT Troll Technologies + 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 + + + + + + + + + + + +Gulbrandsen and Vixie Proposed [Page 10] + diff --git a/doc/draft/draft-ietf-dnsind-test-tlds-13.txt b/doc/draft/draft-ietf-dnsind-test-tlds-13.txt new file mode 100644 index 0000000000..f0315eccbf --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-test-tlds-13.txt @@ -0,0 +1,290 @@ + +INTERNET-DRAFT Reserved TLDs + February 1999 + Expires August 1999 + + + + + Reserved Top Level DNS Names + -------- --- ----- --- ----- + + Donald E. Eastlake 3rd + Aliza R. Panitz + + + + + Status of This Document + + This draft is file name draft-ietf-dnsind-test-tlds-13.txt. + Distribution of this document is unlimited. Comments should be sent + to the DNS mailing list 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] + diff --git a/doc/draft/draft-ietf-dnsind-tsig-08.txt b/doc/draft/draft-ietf-dnsind-tsig-08.txt new file mode 100644 index 0000000000..374bc32fd2 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-tsig-08.txt @@ -0,0 +1,795 @@ + + + + DNSIND Working Group Paul Vixie (Ed.) (ISC) + INTERNET-DRAFT Olafur Gudmundsson (TISLabs) + Donald Eastlake 3rd (IBM) + Brian Wellington (TISLabs) + February 1999 + + Amends: RFC 1035 + + + Secret Key Transaction Signatures for DNS (TSIG) + + + Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + + Abstract + + This protocol allows for transaction level authentication using + shared secrets and one way hashing. It can be used to authenticate + dynamic updates as coming from an approved client, or to authenticate + responses as coming from an approved recursive name server. + + No provision has been made here for distributing the shared secrets; + it is expected that a network administrator will statically configure + name servers and clients using some out of band mechanism such as + sneaker-net until a secure automated mechanism for key distribution + + + + Expires August 1999 [Page 1] + + INTERNET-DRAFT DNS TSIG February 1999 + + + is available. + + 1 - Introduction + + 1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated + hierarchical distributed database system that provides information + fundamental to Internet operations, such as name <=> address translation + and mail handling information. DNS has recently been extended [RFC2065] + to provide for data origin authentication, and public key distribution, + all based on public key cryptography and public key based digital + signatures. To be practical, this form of security generally requires + extensive local caching of keys and tracing of authentication through + multiple keys and signatures to a pre-trusted locally configured key. + + 1.2. One difficulty with the [RFC2065] scheme is that common DNS + implementations include simple ``stub'' resolvers which do not have + caches. Such resolvers typically rely on a caching DNS server on + another host. It is impractical for these stub resolvers to perform + general [RFC2065] authentication and they would naturally depend on + their caching DNS server to perform such services for them. To do so + securely requires secure communication of queries and responses. + [RFC2065] provides public key transaction signatures to support this but + such signatures are very expensive computationally to generate. In + general, these require the same complex public key logic that is + impractical for stubs. This document specifies an efficient secret key + based transaction signature that avoids these difficulties. + + 1.3. A second area where use of straight [RFC2065] public key based + mechanisms may be impractical is authenticating dynamic update [RFC2136] + requests. [RFC2065] provides for request signatures but with [RFC2065] + they, like transaction signatures, require computationally expensive + public key cryptography and complex authentication logic. Secure Domain + Name System Dynamic Update ([RFC2137]) describes how different keys are + used in dynamically updated zones. This document's secret key based + signatures can be used to authenticate DNS update requests as well as + transaction responses, providing a lightweight alternative to the + protocol described by [RFC2137]. + + 1.4. A further use of this mechanishm is to protect zone transfers. In + this case the data covered would be the whole zone transfer including + any glue records sent. The protocol described by [RFC2065] does not + protect glue records and unsigned records unless SIG(0) (transaction + signature) is used. + + + + + + Expires August 1999 [Page 2] + + INTERNET-DRAFT DNS TSIG February 1999 + + + 1.5. The signature mechanism proposed in this document uses shared + secret keys to establish trust relationship between two entities. Such + keys must be protected in a fashion similar to private keys, lest a + third party masquerade as one of the intended parties (forge + signatures). There is an urgent need to provide simple and efficient + authentication between clients and local servers and this proposal + addresses that need. This proposal is unsuitable for general server to + server authentication for servers which speak with many other servers, + since key management would become unwieldy with the number of shared + keys going up quadratically. But it is suitable for many resolvers on + hosts that only talk to few recursive servers. + + 1.6. A server acting as an indirect caching resolver -- a ``forwarder'' + in common usage -- might use transaction signatures when communicating + with its small number of preconfigured ``upstream'' servers. Other uses + of DNS secret key signatures and possible systems for automatic secret + key distribution may be proposed in separate future documents. + + 1.7. New Assigned Numbers + + RRTYPE = TSIG (250) + ERROR = 0..15 (a DNS RCODE) + ERROR = 16 (BADSIG) + ERROR = 17 (BADKEY) + ERROR = 18 (BADTIME) + ERROR = 19 (BADID) + + + 2 - TSIG RR Format + + 2.1 TSIG RR Type + + To provide secret key signatures, we use a new RR type whose mnemonic is + TSIG and whose type code is 250. TSIG is a meta-RR and can not be + stored. TSIG RRs can be used for authentication between DNS entities + that have established a shared secret key. TSIG RRs are dynamically + computed to cover a particular DNS transaction and are not DNS RRs in + the usual sense. + + + + + + + + + + + Expires August 1999 [Page 3] + + INTERNET-DRAFT DNS TSIG February 1999 + + + 2.2 TSIG Calculation + + As the TSIG RRs are related to one DNS request/response, there is no + value in storing or retransmitting them, thus the TSIG RR should be + discarded once it has been used to authenticate DNS message. The only + Message Digest algorithm specified in this document is ``HMAC-MD5'' (see + [RFC1321], [RFC2104]). Other algorithms can be specified at later date. + Names and definitions of new algorithms should be registered with IANA. + All multi-octet integers in TSIG Record are sent in network byte order + (see [RFC1035 2.3.2]). + + 2.3. Record Format + + NAME A domain-like name of the key used. The name should reflect + the names of the hosts and uniquely identify the key among a + set of keys these two hosts may share at any given time. If + hosts A and B in same zone share a key then the key name could + be A-B-.. If two hosts in different zones share the + key the key name could be .A..B. It should + be possible for more than one key to be in simultaneous use + among a set of interacting hosts. The name only needs to be + meaningful to the communicating hosts but a meaningful + mnemonic name as above is strongly recommended. + + The name may be used as a local index to the key involved and + it is recommended that it be globally unique. Where a key is + just shared between two hosts, its name actually only need + only be meaningful to them but it is recommended that the key + name be mnemonic and incorporate the resolver and server host + names in that order. + + TYPE TSIG (250: Transaction SIGnature) + + CLASS ANY + + TTL 0 + + RdLen (variable) + + + + + + + + + + + Expires August 1999 [Page 4] + + INTERNET-DRAFT DNS TSIG February 1999 + + + RDATA + + Field Name Data Type Notes + ------------------------------------------------------------------ + Algorithm Name domain-name Name of the algorithm + expressed as a domain name. + Time Signed u_int48_t seconds since 1-Jan-70 UTC. + Fudge u_int16_t seconds of error permitted + in Time Signed. + Signature Size u_int16_t number of octets in Signature. + Signature octet stream defined by Algorithm Name. + Original ID u_int16_t original message ID + Error u_int16_t expanded RCODE covering + signature processing. + Other Len u_int16_t length, in octets, of Other Data. + Other Data octet stream undefined by this protocol. + + + 2.4. Example + + + NAME GW-DENVAX-0042.HOME.VIX.COM. + + TYPE TSIG + + CLASS ANY + + TTL 0 + + RdLen as appropriate + + RDATA + + Field Name Contents + ------------------------------------------- + Algorithm Name HMAC-MD5.SIG-ALG.REG.INT. + Time Signed 853804800 + Fudge 300 + Signature Size as appropriate + Signature as appropriate + Original ID as appropriate + Error 0 (NOERROR) + Other Len 0 + Other Data empty + + + + + Expires August 1999 [Page 5] + + INTERNET-DRAFT DNS TSIG February 1999 + + + 3 - Protocol Operation + + 3.1. Effects of adding TSIG to outgoing message + + Once the outgoing message has been constructed, the keyed message digest + operation can be performed. The resulting message digest will then be + stored in a TSIG which is appended to the additional data section. + Appending a transaction signature to an DNS message is not allowed to + result in a truncated response; a TCP connection must be used to prevent + the truncation. To force a TCP connection, the server is permitted to + return an answer with no data only TSIG attached and TC bit set and + RCODE 0 (NOERROR). The client should at this point retry the request + using TCP (per [RFC1035 4.2.2]). + + 3.2. TSIG processing on incoming messages + + Upon receipt of a message with a TSIG RR, the TSIG RR is copied to a + safe location, removed from the DNS Message, and decremented out of the + DNS Message Headers ARCOUNT. At this point the keyed message digest + operation is performed. If the algorithm name or key name is unknown to + the recipient, or if the message digests do not match, the whole DNS + Message must be discarded. A response with RCODE 9 (NOTAUTH) should be + sent back to the originator with TSIG ERROR 17 (BADKEY), if no key is + available to sign this message it must be sent unsigned (Signature Size + == 0 and empty signature). A message to the system operations log + should to be generated, to warn the operations staff of a possible + security incident in progress. Care should be taken to ensure that + logging of this type of event does not open the system to a denial of + service attack. + + 3.3. Time values used in TSIG calculations + + The data digested includes the two timer values in the TSIG header in + order to prevent replay attacks. If this were not done an attacker + could replay old messages but update the ``Time Signed'' and ``Fudge'' + fields to make the message look new. This data is named ``TSIG + Timers'', and for the purpose of digest calculation they are invoked in + their ``on the wire'' format, in the following order: first Time Signed, + then Fudge. For example: + + Field Name Value Wire Format Meaning + --------------------------------------------------------------------------- + Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997 + Fudge 300 01 2C 5 minutes + + + + + Expires August 1999 [Page 6] + + INTERNET-DRAFT DNS TSIG February 1999 + + + 3.4. TSIG Variables and Coverage + + When generating or verifying a transaction signature, the following data + are digested, in network byte order or wire format, as appropriate: + + 3.4.1. DNS Message + + A whole and complete DNS message in wire format, before the TSIG RR has + been added to the additional data section and before the DNS Message + Header's ARCOUNT field has been incremented to contain the TSIG RR. If + the message is of a type that can be forwarded (i.e. update) and the + message ID differs from the original message ID, the original message ID + is substituted for the message ID. + + 3.4.2. TSIG Variables + + Source Field Name Notes + ------------------------------------------------------------------------ + TSIG RR NAME Key name, in canonical wire format + TSIG RR CLASS (Always ANY in the current specification) + TSIG RR TTL (Always 0 in the current specification) + TSIG RDATA Algorithm Name in canonical wire format + TSIG RDATA Time Signed in network byte order + TSIG RDATA Fudge in network byte order + TSIG RDATA Error in network byte order + TSIG RDATA Other Len in network byte order + TSIG RDATA Other Data exactly as transmitted + + The RR RDLEN and RDATA Signature Length are not included in the hash + since they are not guaranteed to be knowable before the signature is + generated. + + The Original ID field is not included in this section, as it has already + been substituted for the message ID in the DNS header and hashed. + + ``Canonical wire format'' means uncompressed labels shifted to lower + case. The use of label types other than 00 is not defined for this + specification. + + 3.4.3. Request Signature + + Response signatures will include the request signature in their digest. + The request's signature is digested in wire format, including the + following fields: + + + + + Expires August 1999 [Page 7] + + INTERNET-DRAFT DNS TSIG February 1999 + + + Field Type Description + --------------------------------------------------------- + Signature Length u_int16_t in network byte order + Signature Data octet stream exactly as transmitted + + + 3.5. Padding + + Digested components are fed into the hashing function as a continuous + octet stream with no interfield padding. + + 4 - Protocol Details + + 4.1. TSIG generation on requests + + Client performs the message digest operation and appends TSIG to + additional data section and transmits request to server. The client + must store the message digest from the request while awaiting an answer. + Digest components for requests are: + + DNS Message (request) + TSIG Variables (response) + + + Note that some older name servers will not accept requests with a + nonempty additional data section, but clients should only attempt signed + transactions against servers who are known to support TSIG and share + some secret key with the client -- so, this is not a problem in + practice. + + 4.2. TSIG on Answers + + When a server has generated a response to a signed request, it signs the + response using the same algorithm and key. Digest components are: + + Request Signature + DNS Message (response) + TSIG Variables (response) + + + + + + + + + + + Expires August 1999 [Page 8] + + INTERNET-DRAFT DNS TSIG February 1999 + + + 4.3. TSIG on TSIG Error returns + + When a server detects an error in TSIG checks relating to the key or + signature, the server should send back an unsigned error message. If an + error is detected that does not relate to the key or signature, the + server should send back a signed error message. Digest components are: + + Request signature (if the request signature validated) + DNS Message (response) + TSIG Variables (response) + + The reason that the request is not included in this digest in some cases + is to make it possible for the client to verify the error. If the error + is not a TSIG error the response MUST be generated as specified in + [4.2]. + + 4.4. TSIG on TCP connection + + A DNS TCP session can include multiple DNS envelopes. This is, for + example commonly used by AXFR. TSIG on such a connection can be used to + protect the connection from hijacking and provide data integrity. The + TSIG MUST be included on the first and last DNS envelopes. It can be + optionally placed on any intermediary envelopes. It is expensive to + include it on every envelopes, but it MUST be placed on at least every + 100'th envelopes. The first envelope is processed as a standard answer, + and subsequent messages have the following digest components: + + Prior Digest (running) + DNS Message (current message) + TSIG Timers (current message) + + This allows client to rapidly detect when a transfer has been altered + and it can close the connection at that point and retry. Once client + TSIG check fails, the client MUST close the connection. If the client + does not get TSIG frequently enough (as specified above) it SHOULD + assume the connection has been hijacked and it SHOULD close the + connection. Client should treat this the same way as any other + interrupted transfer. + + + + + + + + + + + Expires August 1999 [Page 9] + + INTERNET-DRAFT DNS TSIG February 1999 + + + 4.5. Server TSIG checks + + Upon receipt of a message, server will check if there is a TSIG RR. If + one exists, the server is required to return a TSIG RR in the response. + The server MUST perform the following checks in the following order, + check KEY, check ID, check TIME values, check Signature. + + 4.5.1. KEY check and error handling + + If a non-forwarding server does not recognize the key used by the client + the server MUST generate an error response with RCODE 9 (NOTAUTH) and + TSIG ERROR 17 (BADKEY). This response should be unsigned as specified + in [4.3]. The server should log the error. + + 4.5.2. ID check and error handling + + If the message is has an opcode that may not be forwarded, the ID field + in the DNS header is expected to match the Original ID field in the TSIG + record. If this is not the case, the server MUST generate an error + response with RCODE 9 (NOTAUTH) and TSIG ERROR 19 (BADID). The server + MUST sign this error response with the same key the client used. + + 4.5.3. TIME check and error handling + + If the server time is outside the time interval specified by the request + (which is: Time Signed, plus/minus Fudge), the server MUST generate an + error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 (BADTIME). This + response MUST be signed by the same key. It MUST include the client's + current time in the time signed field, the server's current time in the + other data field, and 6 in the other data length field. This is done so + that the client can verify a message with a BADTIME error without the + verification detecting another BADTIME error. The data signed is + specified in [4.3]. + + 4.5.4. Signature check and error handling + + If TSIG fails to verify, the server MUST generate an error response as + specified in [4.3] with RCODE of 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG). + This response should be unsigned as specified in [4.3]. The server + should log the error. + + + + + + + + + Expires August 1999 [Page 10] + + INTERNET-DRAFT DNS TSIG February 1999 + + + 4.6. Client processing of answer + + When a client receives a response from a server it expects a TSIG from, + it first checks if the TSIG RR is present in the response. Otherwise + the response is treated as having a format error and discarded. The + client then extracts the TSIG, adjusts the ARCOUNT, and calculates the + keyed digest in the same way as the server. If the TSIG does not + validate, that response must be discarded, unless the RCODE is 9 + (NOTAUTH), in which case the client should attempt to verify the + response as it was TSIG error as specified in [4.3]. An message + containing an unsigned TSIG record or a TSIG record which fails + verification should not be considered an acceptable response; the client + should log an error and continue to wait for a signed response until the + request times out. + + 4.6.1. Key error handling + + If an RCODE on a response is 9 (NOTAUTH), and the response TSIG + validates, and the TSIG key is different from the key used on the + request, then this is a key error. Client should retry the request + using the key specified by server. This should never occur, as a server + should never sign a response with a different key than signed the + request. + + 4.6.2. ID error handling + + If an RCODE on a response is 9 (NOTAUTH), and the response TSIG + validates, and the TSIG ERROR is 19 (BADID), this means that for some + reason, the server received a forwarded message of a type that should + not be forwarded. This likely indicates a faulty server. + + 4.6.3. Time error handling + + If the response RCODE is 9 (NOTAUTH), and TSIG ERROR is 18 (BADTIME) or + the TSIG times in request and answer do not overlap, then this is a TIME + error. This is an indication that client and server are not clock + synchronized. In this case the client should log the event. DNS + resolvers MUST NOT adjust any clocks in the client based on BADTIME + errors, but the server's time in other data field should be logged. + + + + + + + + + + Expires August 1999 [Page 11] + + INTERNET-DRAFT DNS TSIG February 1999 + + + 4.6.4. Signature error handling + + If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this + is a signature error, and client MAY retry the request with a new + request ID but it would be better to try a different shared key if one + is available. Client SHOULD keep track of how many times each key has + Signature errors. Clients should log this event. + + 4.7. Special considerations for forwarding servers + + A server acting as a Forwarding Server of a DNS message should check for + the existence of the TSIG record. If the name on the TSIG is not of a + secret that the server shares with the originator the server will + forward the message unchanged including the TSIG. If the name of the + TSIG is of a key this server shares with the originator it processes the + TSIG. If the TSIG passes all checks, the forwarding server has the + obligation of including a TSIG of his own, to the destination or the + next forwarder. If no transaction security is available to the + destination and response has the AD flag (see [RFC2065]), the forwarder + MUST unset the AD flag before adding the TSIG to the answer. + + 5 - Shared Secrets + + 5.1. Secret keys are very sensitive information and all available steps + should be taken to protect them on every host on which they are stored. + Generally such hosts need to be physically protected. If they are + multi-user machines, great care should be taken that unprivileged users + have no access to keying material. Resolvers usually run unprivileged, + which means all users of a host will usually be able to see whatever + configuration data is used by the resolver. + + 5.2. A name server usually runs privileged, which means its + configuration data need not be visible to all users of the host. For + this reason, a host that implements transaction signatures should + probably be configured with a ``stub resolver'' and a local caching and + forwarding name server. This presents a special problem for [RFC2136] + which otherwise depends on clients to communicate only with a zone's + authoritative name servers. + + 5.3. Use of strong random shared secrets is essential to the security of + TSIG. See [RFC1750] for a discussion of this issue. The secret should + be at least as long as the keyed message digest , i.e., 16 bytes for + HMAC-MD5 or 20 bytes for HMAC-SHA1. + + + + + + Expires August 1999 [Page 12] + + INTERNET-DRAFT DNS TSIG February 1999 + + + 6 - Security Considerations + + 6.1. The approach specified here is computationally much less expensive + than the signatures specified in [RFC2065]. As long as the shared + secret key is not compromised, strong authentication is provided for the + last hop from a local name server to the user resolver. + + 6.2. Secret keys should be changed periodically. If the client host has + been compromised, the server should suspend the use of all secrets known + to that client. If possible, secrets should be stored in encrypted + form. Secrets should never be transmitted in the clear over any + network. This document does not address the issue on how to distribute + secrets. Secrets should never be shared by more than two entities. + + 6.3. This mechanism does not authenticate source data, only its + transmission between two parties who share some secret. The original + source data can come from a compromised zone master or can be corrupted + during transit from an authentic zone master to some ``caching + forwarder.'' However, if the server is faithfully performing the full + [RFC2065] security checks, then only security checked data will be + available to the client. + + 7 - IANA Considerations + + A new algorithm name should be a valid domain name of the type + algorithm-name.SIG-ALG.REG.INT. This requires an IETF consensus. + + Adding new error codes requires an IETF consensus. + + IANA must maintain control over the SIG-ALG.REG.INT domain. + + + + + + + + + + + + + + + + + + + Expires August 1999 [Page 13] + + INTERNET-DRAFT DNS TSIG February 1999 + + + 7 - References + + [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' + RFC 1034, ISI, November 1987. + + [RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification,'' RFC 1034, ISI, November 1987. + + [RFC1321] R. Rivest, ``The MD5 Message-Digest Algorithm,'' RFC 1321, + MIT LCS & RSA Data Security, Inc., April 1992. + + [RFC1750] D. Eastlake, S. Crocker, J. Schiller, ``Randomness + Recommendations for Security,'' RFC 1750, DEC, CyberCash & + MIT, December 1995. + + [RFC2065] D. Eastlake , C Kaufman, ``Domain Name System Security + Extensions,'' RFC 2065, CyberCash & Iris, January 1997. + + [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5 + for Message Authentication,'' RFC 2104 , IBM, UCSD & IBM, + February 1997. + + [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic + Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore + & Cisco & DEC, April 1997. + + [RFC2137] D. Eastlake 3rd ``Secure Domain Name System Dynamic Update,'' + CyberCash, April 1997. + + + + + + + + + + + + + + + + + + + + + Expires August 1999 [Page 14] + + INTERNET-DRAFT DNS TSIG February 1999 + + + 9 - Authors' Addresses + + + Paul Vixie Olafur Gudmundsson + Internet Software Consortium TIS Labs at Network Associates + 950 Charter Street 3060 Washington Road, Route 97 + Redwood City, CA 94063 Glenwood, MD 21738 + +1 650 779 7001 +1 443 259 2389 + + + Donald E. Eastlake 3rd Brian Wellington + IBM TIS Labs at Network Associates + 65 Shindegan Hill Road, RR #1 3060 Washington Road, Route 97 + Carmel, NY 10512 USA Glenwood, MD 21738 + +1 914 783 7913 +1 443 259 2369 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Expires August 1999 [Page 15] + diff --git a/doc/draft/draft-ietf-dnsind-verify-00.txt b/doc/draft/draft-ietf-dnsind-verify-00.txt new file mode 100644 index 0000000000..1837fe9e7f --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-verify-00.txt @@ -0,0 +1,158 @@ + + + INTERNET-DRAFT Mark Andrews (ISC) + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + Expires August 1999 [Page 3] + diff --git a/doc/draft/draft-ietf-dnssec-ar-00.txt b/doc/draft/draft-ietf-dnssec-ar-00.txt new file mode 100644 index 0000000000..fc1c3a332a --- /dev/null +++ b/doc/draft/draft-ietf-dnssec-ar-00.txt @@ -0,0 +1,618 @@ + + + + + +Domain Name System Security Working Group R. Watson +INTERNET DRAFT November 1997 + 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] + diff --git a/doc/draft/draft-ietf-dnssec-as-map-05.txt b/doc/draft/draft-ietf-dnssec-as-map-05.txt new file mode 100644 index 0000000000..caaf932ca7 --- /dev/null +++ b/doc/draft/draft-ietf-dnssec-as-map-05.txt @@ -0,0 +1,522 @@ + +INTERNET-DRAFT Mapping AS Number into the DNS + July 1997 + Expires January 1998 + + + + + Mapping Autonomous Systems Number into the Domain Name System + ------- ---------- ------- ------ ---- --- ------ ---- ------ + + Donald E. Eastlake 3rd + + + +Status of This Document + + This draft, file name draft-ietf-dnssec-as-map-05.txt, is intended to + be become a Best Current Practice RFC concerning utilization of the + Domain Name System (DNS) to support routing security. Distribution of + this document is unlimited. Comments should be sent to the DNS + Security Working Group mailing list 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] + diff --git a/doc/draft/draft-ietf-dnssec-indirect-key-01.txt b/doc/draft/draft-ietf-dnssec-indirect-key-01.txt new file mode 100644 index 0000000000..a4804b79f6 --- /dev/null +++ b/doc/draft/draft-ietf-dnssec-indirect-key-01.txt @@ -0,0 +1,464 @@ + +INTERNET-DRAFT Indirect KEY RRs + November 1997 + Expires May 1998 + + + + Indirect KEY RRs in the Domain Name System + -------- --- --- -- --- ------ ---- ------ + + Donald E. Eastlake 3rd + + + +Status of This Document + + This draft, file name draft-ietf-dnssec-indirect-key-01.txt, is + intended to be become a Proposed Standard RFC. Distribution of this + document is unlimited. Comments should be sent to the DNSSEC mailing + list 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] + diff --git a/doc/draft/draft-ietf-dnssec-key-handling-00.txt b/doc/draft/draft-ietf-dnssec-key-handling-00.txt new file mode 100644 index 0000000000..919b0be3bf --- /dev/null +++ b/doc/draft/draft-ietf-dnssec-key-handling-00.txt @@ -0,0 +1,473 @@ +Domain Name System Security WG Edward Lewis +INTERNET DRAFT Olafur Gudmundsson + Trusted Information Systems + November 21, 1997 + + + + Zone KEY RRSet Signing Procedure + + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires November 21, 1997 [Page 8] + + diff --git a/doc/draft/draft-ietf-dnssec-rollover-00.txt b/doc/draft/draft-ietf-dnssec-rollover-00.txt new file mode 100644 index 0000000000..4aab0f5de1 --- /dev/null +++ b/doc/draft/draft-ietf-dnssec-rollover-00.txt @@ -0,0 +1,521 @@ + +INTERNET-DRAFT DNSSEC Key Rollover + October 1998 + Expires April 1999 + + + + + Domain Name System (DNS) Security Key Rollover + ------ ---- ------ ----- -------- --- -------- + + Donald E. Eastlake 3rd, Mark Andrews + + + +Status of This Document + + This draft, file name draft-ietf-dnssec-rollover-00.txt, is intended + to be become a Proposed Standard RFC. Distribution of this document + is unlimited. Comments should be sent to the DNS security mailing + list 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] diff --git a/doc/draft/draft-ietf-dnssec-secfail-00.txt b/doc/draft/draft-ietf-dnssec-secfail-00.txt new file mode 100644 index 0000000000..67b22bb7e5 --- /dev/null +++ b/doc/draft/draft-ietf-dnssec-secfail-00.txt @@ -0,0 +1,291 @@ +Internet-Draft B. Wellington, O. Gudmundsson +DNSSEC Working Group TISLabs + August 1998 + + + + Intermediate Security Failures in DNSSEC + + + + 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 , March 1998 + + +[ERR] R. Watson, O. Gudmundsson, "Error Record (ERR) + for DNS" Internet Draft , 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 , April 1998. + + +[TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret + Key Transaction Signatures for DNS (TSIG)" Inter­ + net Draft , 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] + + diff --git a/doc/draft/draft-ietf-dnssec-simple-update-01.txt b/doc/draft/draft-ietf-dnssec-simple-update-01.txt new file mode 100644 index 0000000000..83b8c9c47b --- /dev/null +++ b/doc/draft/draft-ietf-dnssec-simple-update-01.txt @@ -0,0 +1,278 @@ + +DNSSEC Working Group Brian Wellington (TISLabs) +INTERNET-DRAFT February 1999 + + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires August 1999 [Page 5] + diff --git a/doc/draft/draft-ietf-dnssec-tkey-01.txt b/doc/draft/draft-ietf-dnssec-tkey-01.txt new file mode 100644 index 0000000000..9349a36ab7 --- /dev/null +++ b/doc/draft/draft-ietf-dnssec-tkey-01.txt @@ -0,0 +1,1045 @@ + + +DNSSEC Working Group Donald E. Eastlake, 3rd +INTERNET-DRAFT IBM +Expires: March 1999 September 1998 + + + + Secret Key Establishment for DNS (TKEY RR) + ------ --- ------------- --- --- ----- --- + + Donald E. Eastlake 3rd + + + +Status of This Document + + This draft, file name draft-ietf-dnssec-tkey-01.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 + or to the author. + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 1] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +Abstract + + [draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating and + securing Domain Name System (DNS) queries and responses using shared + secret keys via the TSIG resource record (RR). However, it provides + no mechanism for setting up such keys other than manual exchange. + This document describes a TKEY RR that can be used in a number of + different modes to establish shared secret keys between a DNS + resolver and server. + + [changes from last draft: add IANA considerations section, make time + fields module 2**32, minor edits, update author info, ...] + + + +Acknowledgments + + The substantial comments and ideas of the following persons (listed + in alphabetic order) have been incorporated herein and are gratefully + acknowledged: + + Olafur Gudmundsson + + Stuart Kwan + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 2] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +Table of Contents + + Status of This Document....................................1 + + Abstract...................................................2 + Acknowledgments............................................2 + + Table of Contents..........................................3 + + 1. Introduction............................................4 + 1.1 General Principles.....................................4 + 1.2 Overview of Contents...................................5 + + 2. The TKEY Resource Record................................6 + + 3. Exchange via Resolver Query.............................8 + 3.1 Query for Server Assigned Keying.......................8 + 3.2 Query for Diffie-Hellman Exchanged Keying..............9 + 3.3 Query for GSS-API Established.........................10 + + 4. Spontaneous Server Inclusion...........................11 + 4.1 Spontaneous Server Assigned Keying....................11 + 4.2 Spontaneous Diffie-Hellman Keying.....................11 + 4.3 Spontaneous GSS-API Exchange..........................11 + 4.4 Spontaneous Key Deletion..............................12 + + 5. TKEY Dynamic Update Requests...........................13 + 5.1 Exchange via TKEY 'Add'...............................13 + 5.2 TKEY Deletion.........................................13 + + 6. Methods of Encryption..................................14 + + 7. IANA Considerations....................................15 + + 8. Security Considerations................................16 + + References................................................17 + + Author's Address..........................................18 + Expiration and File Name..................................18 + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 3] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +1. Introduction + + The Domain Name System (DNS) is a hierarchical, distributed, highly + available database used for mapping between domain names and + addresses, for email routing, and for other information [RFC 1034, + 1035]. It has been extended to provide for public key security and + dynamic update [RFC 2136, draft-ietf-dnssec-secext2-*.txt, draft- + ietf-dnssec-update2-*.txt]. + + [draft-ietf-dnsind-tsig-*.txt] provides a means of more efficiently + authenticating and securing DNS messages using shared secret keys via + the TSIG resource record (RR) but provides no mechanism for setting + up such keys other than manual exchange. This document describes a + TKEY RR that can be used in a number of different modes to establish + such shared secret keys between a DNS resolver and server. + + + +1.1 General Principles + + TKEY is a meta-RR that is not stored or cached in the DNS and does + not appear in zone files. It supports a variety of modes for the + establishment and deletion of shared secret keys between DNS entities + such as resolvers and servers. The establishment of such a key + requires that state be maintained at both the resolver and the server + and the allocation of the resources to maintain such state may + require mutual agreement. In the absence of such agreement, servers + are free to return errors for any attempt to use TKEY and resolvers + are free to ignore any TKEY RRs they receive. + + In all cases herein, the term "resolver" includes that part of a + server which makes full and incremental [RFC 1995] zone transfer + queries as well as other queries. + + Servers are not required to implement any particular mode or modes of + the defined modes of TKEY shared secret key establishment or deletion + and may return errors for any they do not support. Based on + experience, in the future more modes may be added or some modes + described herein may be deprecated. + + The means by which the shared secret keying material exchanged via + TKEY is actually used in any particular TSIG algorithm is algorithm + dependent and is defined in connection with that algorithm. + + Note that this keying material and TSIGs that use it are associated + with DNS hosts. They are not tied to zones. They may be used to + authenticate queries and responses but they do not provide zone + stored DNS data origin authentication [draft-ietf-dnssec-secext2- + *.txt]. + + + +Donald E. Eastlake, 3rd [Page 4] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + + Two modes of TKEY, the server assigned and resolver assigned modes, + perform encryption which may effect their export or inport status for + some countries. All other aspects of DNS security, including the + SIG, KEY, NXT, and TSIG RRs and all other defined modes of TKEY + perform authentication (signatures and signature verification) only. + + + +1.2 Overview of Contents + + Section 2 below specifies the TKEY resource record (RR) and provides + a high level description of its constituent fields. + + Section 3 discusses key exchange via queries for type TKEY. This is + applicable to the server assigned, Diffie-Hellman exchange, and GSS- + API establishment modes. + + Section 4 discusses spontaneous inclusion of TKEY RRs in responses by + servers. This is applicable to key deletion and to server assigned + and Diffie-Hellman exchange key establishment. + + Section 5 discusses use of dynamic update requests for type TKEY. + This supports optional key exchange via resolver update request, + which is applicable to key deletion and to the resolver assigned + mode. + + Section 6 describes encryption methods for transmitting secret key + information. + + Section 7 covers IANA considerations in assignment of TKEY modes. + + Finally, Section 8 touches on some security considerations. + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 5] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +2. The TKEY Resource Record + + The TKEY resource record (RR) has the structure given below. Its RR + type code is 249. + + Field Type Comment + ----- ---- ------- + + NAME domain see description below + TTYPE u_int16_t TKEY + CLASS u_int16_t ignored, should be zero + TTL u_int32_t SHOULD be zero + RDLEN u_int16_t size of RDATA + RDATA: Algorithhm: domain + Inception: u_int32_t + Expiration: u_int32_t + Mode: u_int16_t + Error: u_int16_t + Key Size: u_int16_t + Key Data: octet-stream + Other Size: u_int16_t + Other Data: octet-stream undefined by this protocol + + The Name field's meaning differs somewhat with mode and context as + explained in subsequent sections. + + The TTL field SHOULD always be zero to be sure that older DNS + implementations do not cache TKEY RRs. + + The algorithm name is a domain name with the same meaning as in + [draft-ietf-dnsind-tsig-*.txt]. The algorithm determines how the + secret keying material exchanged using the TKEY RR is actually used + to derive the algorithm specific key that is used. + + The inception time and expiration time are in number of seconds since + the beginning of 1 January 1970 GMT ignoring leap seconds treated as + modulo 2**32 using ring arithmetic [RFC 1982]. In messages between a + DNS resolver to a DNS server where these fields are meaningful, they + are the either requested validity interval for the keying material + asked for or specify the validity interval of keying material + provided. To avoid reply attack, to keying material used to + authenticate TKEY keying material MUST NOT have a lifetime of more + then 2**31 seconds. This applies to keying material used in either a + TSIG or a SIG(0) transacation or request signature. + + The mode field specifies the general scheme for key agreement. Note + that implementation of TKEY as a whole and of any particular mode is + optional. The following values of the Mode octet are defined or + reserved: + + + +Donald E. Eastlake, 3rd [Page 6] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + + Value Description + ----- ----------- + 0 - reserved + 1 server/responder assignment + 2 Diffie-Hellman exchange + 3 GSS-API negotiation + 4 resolver/querier assignment + 5 key deletion + 6-65534 - available, see IANA considerations section + 65535 -reserved + + The error code field is an extended RCODE. The following values are + defined: + Value Description + ----- ----------- + 0 - no error + 1-15 a DNS RCODE + 16 BADSIG + 17 BADKEY + 18 BADTIME + 19 BADMODE + + The key data size field is an unsigned 16 bit integer in network + order which specifies the size of the key exchange data field in + octets. The meaning of the key data depends on the mode. + + The Other Size and Other Data fields are not used. The RDLEN field + MUST equal the length of the RDATA section through the end of other + data or the RR is to be considered malformed and rejected. + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 7] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +3. Exchange via Resolver Query + + One method for a resolver and a server to establish a shared secret + key for use in TSIG is through queries from the resolver for type + TKEY. Such queries MUST either be accompanied by one or more TKEY + RRs in the additional information section to indicate the mode(s) in + use and other information where required or the resolver and server + must have a prior agreement that supplies any information that would + otherwise have had to be conveyed by TKEY RR(s) in the query. + + For TKEY(s) appearing in a query, the TKEY RR name SHOULD be a domain + locally unique at the resolver (or globally unique), less than 128 + octets long, and meaningful to the resolver to distinguish keys + and/or key agreement sessions. (For resolvers not wishing to make + this use of the name, it may be specified as root to minimize + length.) For TKEY(s) appearing in a response to a query, the TKEY RR + name SHOULD be a globally unique server assigned domain. If the TKEY + in a response is the result of a query containing a TKEY with a non- + root name, that query TKEY name SHOULD be incorporated as the prefix + of the response TKEY name. + + Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY + ignore the recursive header bit in TKEY queries they receive. + + For every mode defined below, the inception and expiration times in a + query TKEY are set to the time interval for which the resolver wishes + the requested key to be valid and they are set in a successful + response to the actual time interval during which the server will + consider the key valid. Future modes may be defined which ignore the + inception and expiration time fields. + + + +3.1 Query for Server Assigned Keying + + In server assigned keying, the DNS server host generates the keying + material and it is sent to the resolver encrypted under a resolver + host key. See section 6 for description of encryption methods. + + A resolver sends a query for type TKEY accompanied by a TKEY RR + specifying the "server assignment" mode and a resolver host KEY RR to + be used in encrypting the response, both in the additional + information section. The TKEY algorithm field is set to the signature + algorithm the resolver plans to use. It is recommended that any "key + data" provided in the query TKEY be strongly mixed with server + generated randomness [RFC 1750] to derive the keying material to be + used. The KEY that appears in the query SHOULD have a zero TTL. It + need not be accompanied by a SIG(KEY) and if the query is signed by + the resolver host and that signature is verified, then any SIG(KEY) + provided MAY be ignored for key exchange purposes. The KEY RR in + + +Donald E. Eastlake, 3rd [Page 8] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + + such a query SHOULD have a name that corresponds to the resolver host + but it is only essential that it be a public key for which the + resolver has the corresponding private key so it can decrypt the + response data. + + Accepting and responding to an unsigned query of this sort may drain + some entropy from an entropy pool being maintained by the server and + used for secret key generation and so might enable an entropy + exhaustion attack. In addition, some significant amount of + computational resources may be used in the public key encryption of + response data. To protect against these effects, a server SHOULD + require such a query to be signed and MAY rate limit responses. + + The server response contains a TKEY in its answer section with the + server assigned mode. If the error field is non-zero, the query + failed for the reason given. If the error field is zero, the KEY RR + provided in the query will be echoed back and the key data portion of + the response TKEY RR will be the server assigned keying data + encrypted under the public key in the KEY RR. The name of the TKEY + RR will be the server assigned name of the key and SHOULD be globally + unique. + + + +3.2 Query for Diffie-Hellman Exchanged Keying + + Diffie-Hellman (DH) key exchange is means whereby two parties can + derive some shared secret information without requiring any secrecy + of the messages they exchange [Schneier]. Provisions have been made + for the storage of DH public keys in the DNS [draft-ietf-dnssec-dhk- + *.txt]. + + A client sends a query for type TKEY accompanied by a TKEY RR in the + additional information section specifying the "Diffie-Hellman" mode + and accompanied by a KEY RR specifying a client host Diffie-Hellman + key. The TKEY algorithm field is set to the signature algorithm the + resolver plans to use and any "key data" provided is ignored by the + server. + + Accepting and responding to an unsigned query of this sort may use + significant computation at the server; however, if the server + requires that the request be signed, then if no shared secret is in + place to permit a TSIG to be used on the request, it would be + necessary to use a SIG(0) the verification of which would impose its + own computational load. + + The server response contains a TKEY in its answer section with the + Diffie-Hellman mode. If the error field is non-zero, the query failed + for the reason given. If the error field is zero, the client host + supplied Diffie-Hellman KEY should be echoed back and a server host + + +Donald E. Eastlake, 3rd [Page 9] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + + Diffie-Hellman KEY RR will also be present. + + Both parties can calculate the same shared secret quantity from the + pair of Diffie-Hellman keys used [Schneier] provided they use the + same modulus. If the server host does not have an appropriate + Diffie-Hellman key to use for the exchange, it should return the + BADKEY error. + + + +3.3 Query for GSS-API Established + + This is described in a separate document [draft-skwan-gss-tsig-*.txt] + which should be seen for the full description. Basically, when an + acceptable symmetric key is not yet in place, the resolver can send a + query for type TKEY with a TKEY specifying the GSS-API mode in the + additional information section and a GSS-API token in the key data + portion. The server responds with a TKEY specifying the GSS-API mode + and a GSS-API token in the key data portion. The resolver and server + feed these tokens to their local GSS implementation and interate + until an error is encountered or a key (GSS-API session) is + established. A similar exchange can be used to delete a GSS-API + session. + + Any issues of possible encryption of the GSS-API token data being + transmitted are handled by the GSS-API level. In addition, the GSS- + API level provides authentication so that this mode of TKEY query and + response MAY be, but do not need to be, signed with TSIG or SIG(0). + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 10] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +4. Spontaneous Server Inclusion + + A DNS server may include TKEY RRs spontaneously as additional + information in responses. This SHOULD only be done if the server + knows the querier understands TKEY and has this option implemented. + This technique can be used to establish a server assigned key, a + Diffie-Hellman exchange key, for GSS-API exchange, and to delete a + key. A disadvantage of this technique is that there is no way for + the server to get any immediate error or success indication back and, + in the case of UDP, no way to even know if the DNS response reached + the resolver. + + + +4.1 Spontaneous Server Assigned Keying + + A server can include in the additional information section of a + response a server assignment mode TKEY with encrypted keying material + in its key data section along with a KEY RR specifying the client + public key used for the encryption. Such a response SHOULD be signed + but the KEY RR need not be signed by a SIG(KEY). A server should + only do this if there is sufficient room in a query and it has reason + to believe the resolver will understand such additional data. The + KEY RR used MUST be one for which the resolver host has the + corresponding private key or it will not be able to decrypt the + keying material. + + + +4.2 Spontaneous Diffie-Hellman Keying + + A server can include in the additional information section of a + response a Diffie-Hellman exchange mode TKEY along with two KEY RRs + specifying the client and server host public keys used for the + exchange. Such a response SHOULD be signed but the KEY RRs need not + be signed by a SIG(KEY). A server should only do this if there is + sufficient room in a query and it has reason to believe the resolver + host will understand such additional data. + + + +4.3 Spontaneous GSS-API Exchange + + A server can spontaneously include in the additional information + section of a response, a GSS-API mode TKEY. The information in the + key data section of such a TKEY is a GSS-API token which SHOULD be + fed by the resolver to its local GSS-API implementation. If such a + response is signed, the signature must verify before processing the + data. To the extent that GSS-API provides its own security, such a + response may not need to be signed. To the extent that GSS-API + + +Donald E. Eastlake, 3rd [Page 11] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + + handles duplicated messages, such a spontaneous TKEY can be sent + repeatedly, until, perhaps, a response via a GSS-API mode TKEY query + is received. + + + +4.4 Spontaneous Key Deletion + + A server can hint to a client that it has deleted a symmetric key by + spontaneously including a TKEY RR in the additional information + section of a response with the key's name and specifying the key + deletion mode. Such a response SHOULD be signed. If authenticated, + it deletes all keys with the given name whose effective time period + overlaps the inception to expiration period given in the TKEY. (If + the inception time of one symmetric key is equal to the expiration + time of another, or vice versa, they do not overlap.) Failure by a + client to receive or properly process such additional information in + a response would simply mean that the client might use a key that the + server had discarded and then get an error indication. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 12] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +5. TKEY Dynamic Update Requests + + If a DNS server supports dynamic update [RFC 2136], then dynamic + update request can be used to exchange resolver assigned symmetric + keys as described in section 5.1 below and to delete previously + exchanged keys from a server as described in section 5.2 below. + + + +5.1 Exchange via TKEY 'Add' + + Optionally, a server can accept resolver assigned keys. The keying + material must be encrypted under a server host key for protection in + transmission as described in Section 6. + + The resolver sends an update request to add a TKEY RR that specifies + the keying data with a KEY RR in the additional information section + specifying the server host public key used to encrypt the data. The + name of the key and the keying data are completely controlled by the + sending resolver so a globally unique key name SHOULD be used. The + server SHOULD require that this request be signed with a TSIG, if + there already exists an appropriate shared secret, or a SIG(0) by the + resolver host. The KEY RR used MUST be one for which the server has + the corresponding private key or it will not be able to decrypt the + keying material. + + + +5.2 TKEY Deletion + + Keys established via TKEY can be treated as soft state. Since DNS + transactions are originated by the resolver, the resolver can simply + toss keys, although it may have to go through another key exchange if + it later needs one. Similarly, the server can discard keys although + that will result in an error on receiving a query with a TSIG using + the discarded key. + + The key expiration provided in the TKEY and the ability of each party + to discard keys may be adequate but servers that support dynamic + update [RFC 2136] may optionally implement key deletion whereby the + server discards a key on receipt from a resolver of a delete request + for a TKEY with the key's name. The mode and most fields of the TKEY + being "deleted" are ignored. But, to allow for the possibility of + multiple keys with the same name but different time periods, the only + key deleted are those whose time period overlaps with that specified + by the inception and expiration in the TKEY being "deleted". + + + + + + +Donald E. Eastlake, 3rd [Page 13] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +6. Methods of Encryption + + For the server assigned and resolver assigned key exchange, the + keying material is sent within the key data field of a TKEY RR + encrypted under the private key corresponding to the public key in an + accompanying KEY RR [draft-ietf-dnssec-secext2-*.txt]. The secret + keying material being send will generally be fairly short, usually + less than 256 bits, because that is adequate for very strong + protection with modern keyed hash or symmetric algorithms. + + If the KEY RR specifies the RSA algorithm, then the keying material + is encrypted as per the description of RSA encryption in PKCS-1. + (Note, the secret keying material being sent is directly RSA + encrypted in PKCS-1 format, It is not "enveloped" under some other + symmetric algorithm.) In the unlikely event that the keying material + will not fit within one RSA modulus of the chosen public key, + additional RSA encryption blocks are included. The length of each + block is clear from the public RSA key specified and the PKCS-1 + padding makes it clear what part of the encrypted data is actually + keying material and what part is formatting or the required at least + eight bytes of random [RFC 1750] padding. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 14] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +7. IANA Considerations + + Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF + can only be assigned by an IETF standards action excluding + Experimental Standards (and 1 through 5 are assigned by this Proposed + Standard). Special consideration should be given before the + allocation of meaning for Mode field values 0x0000 and 0xFFFF. + + Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF + are allocated by an IETF consensus (i.e., at this time, an IESG vote) + excluding Experimental Standards. + + Mode field values 0x1000 through 0xEFFF are allocated based on RFC + documentation of their use or the issuance of an Experimental + Standard. + + Mode values should not be changed when the status of their use + changes. I.E. a mode value assigned for an Experimental Standard + should not be changed later just because that standard's status is + changed to Proposed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 15] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +8. Security Considerations + + To avoid different interpretations of the inception and expiration + times in TKEY RRs, resovlers and servers exchanging them must have + the same idea of what time it is. One way of doing this is with the + NTP protocol [RFC 2030] but that or any other time synchronization + MUST be done securely. + + It is recommended that the server require TKEY queries be signed. + However, for currently defined modes, relatively little damage will + be done if an unsigned query of this sort is accepted and processed, + as described below for each mode. In addition, requiring that a TKEY + query be signed by a TSIG (if there exists an acceptable exchanged + key between the parties) or a SIG(0) may itself impose significant + computational requirements on the server, particularly in verifying + SIG(0) public key signatures. + + Responses to TKEY queries SHOULD always have DNS transaction + signatures to protect the integrity of any keying data, error codes, + etc. This signature, if present, MUST use a previously established + secret (TSIG) or public (SIG(0)) key and MUST NOT use any key that + the response to be verified is itself providing. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 16] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +References + + PKCS-1 - RSA Encryption Standard (An RSA Laboratories Technical + Note). + + 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 1750 - D. Eastlake, S. Crocker & J. Schiller, "Randomness + Recommendations for Security", December 1994. + + RFC 1982 - Robert Elz, Rrandy Bush, "Serial Number Arithmetic", + 09/03/1996. + + RFC 1995 - Masatka Ohta, "Incremental Zone Transfer in DNS", August + 1996. + + RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 + for IPv4, IPv6 and OSI", October 1996. + + RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. + + draft-ietf-dnsind-tsig-*.txt - P. Vixie, O. Gudmundsson, D. + Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". + + draft-ietf-dnssec-dhk-*.txt - D. Eastlake + + draft-ietf-dnssec-update2-*.txt - Donald E. Eastlake 3rd, "Secure + Domain Name System Dynamic Update". + + draft-ietf-dnssec-secext2-*.txt - Donald E. Eastlake 3rd, "Domain + Name System Security Extensions". + + draft-skwan-gss-tsig-*.txt - S. Kwan, P. Garg, R. Viswanathan, "GSS + Algorithm for TSIG (GSS-TSIG)" + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 17] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +Author's Address + + Donald E. Eastlake 3rd + IBM + 318 Acton Street + Carlisle, MA 01741 USA + + Telephone: +1 978 287 4877 + +1 914 784 7913 + FAX: +1 978 371 7148 + email: dee3@us.ibm.com + + + +Expiration and File Name + + This draft expires March 1999. + + Its file name is draft-ietf-dnssec-tkey-01.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 18] + diff --git a/doc/draft/draft-ietf-dnssec-update2-00.txt b/doc/draft/draft-ietf-dnssec-update2-00.txt new file mode 100644 index 0000000000..860f5fa92a --- /dev/null +++ b/doc/draft/draft-ietf-dnssec-update2-00.txt @@ -0,0 +1,871 @@ + + +INTERNET-DRAFT Donald E. Eastlake 3rd +OBSOLETES RFC 2137 Transfinite Systems Company +Expires: February 1999 August 1998 + + + + Secure Domain Name System (DNS) Dynamic Update + ------ ------ ---- ------ ----- ------- ------ + + + + + +Status of This Document + + This draft, file name draft-ietf-dnssec-update2-00.txt, is intended + to become a Proposed Standard RFC obsoleting RFC 2137. Distribution + of this document is unlimited. Comments should be sent to the DNS + security mailing list 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] + diff --git a/doc/draft/draft-ietf-ipngwg-bsd-api-new-06.txt b/doc/draft/draft-ietf-ipngwg-bsd-api-new-06.txt new file mode 100644 index 0000000000..ffcfb0e6d2 --- /dev/null +++ b/doc/draft/draft-ietf-ipngwg-bsd-api-new-06.txt @@ -0,0 +1,2176 @@ + +Internet Engineering Task Force R.E. Gilligan (FreeGate) +INTERNET-DRAFT S. Thomson (Bellcore) +Obsoletes RFC 2133 Jim Bound (Compaq) + W. R. Stevens (Consultant) + January 25, 1999 + + + + + + + Basic Socket Interface Extensions for IPv6 + + + + +Status of this Memo + + This document is a submission by the Internet Protocol IPv6 + Working Group of the Internet Engineering Task Force (IETF). + Comments should be submitted to the ipng@sunroof.eng.sun.com + mailing list. + + 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), ftp.ietf.org (US East + Coast), or ftp.isi.edu (US West Coast). + + Distribution of this memo is unlimited. + + +Abstract + +The de facto standard application program interface (API) for TCP/IP +applications is the "sockets" interface. Although this API was +developed for Unix in the early 1980s it has also been implemented on a +wide variety of non-Unix systems. TCP/IP applications written using the +sockets API have in the past enjoyed a high degree of portability and we +would like the same portability with IPv6 applications. But changes are +required to the sockets API to support IPv6 and this memo describes +these changes. These include a new socket address structure to carry +IPv6 addresses, new address conversion functions, and some new socket +options. These extensions are designed to provide access to the basic +IPv6 features required by TCP and UDP applications, including +multicasting, while introducing a minimum of change into the system and +providing complete compatibility for existing IPv4 applications. +Additional extensions for advanced IPv6 features (raw sockets and access +to the IPv6 extension headers) are defined in another document [4]. + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 1] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +Table of Contents: + +1. Introduction.................................................3 +2. Design Considerations........................................3 +2.1 What Needs to be Changed....................................3 +2.2 Data Types..................................................5 +2.3 Headers.....................................................5 +2.4 Structures..................................................5 +3. Socket Interface.............................................5 +3.1 IPv6 Address Family and Protocol Family.....................5 +3.2 IPv6 Address Structure......................................6 +3.3 Socket Address Structure for 4.3BSD-Based Systems...........6 +3.4 Socket Address Structure for 4.4BSD-Based Systems...........7 +3.5 The Socket Functions........................................8 +3.6 Compatibility with IPv4 Applications........................9 +3.7 Compatibility with IPv4 Nodes...............................9 +3.8 IPv6 Wildcard Address......................................10 +3.9 IPv6 Loopback Address......................................11 +3.10 Portability Additions.....................................11 +4. Interface Identification....................................13 +4.1 Name-to-Index..............................................14 +4.2 Index-to-Name..............................................14 +4.3 Return All Interface Names and Indexes.....................15 +4.4 Free Memory................................................15 +5. Socket Options..............................................15 +5.1 Unicast Hop Limit..........................................16 +5.2 Sending and Receiving Multicast Packets....................16 +6. Library Functions...........................................18 +6.1 Nodename-to-Address Translation............................18 +6.2 Address-To-Nodename Translation............................21 +6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....22 +6.4 Protocol-Independent Nodename and Service Name Translation.22 +6.5 Socket Address Structure to Nodename and Service Name......25 +6.6 Address Conversion Functions...............................26 +6.7 Address Testing Macros.....................................27 +7. Summary of New Definitions..................................28 +8. Security Considerations.....................................29 +9. Year 2000 Considerations....................................29 +Changes From RFC 2133..........................................30 +Acknowledgments................................................32 +References.....................................................33 +Authors' Addresses.............................................33 + + + + + + + + + + + + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 2] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +1. Introduction + +While IPv4 addresses are 32 bits long, IPv6 interfaces are identified by +128-bit addresses. The socket interface makes the size of an IP address +quite visible to an application; virtually all TCP/IP applications for +BSD-based systems have knowledge of the size of an IP address. Those +parts of the API that expose the addresses must be changed to +accommodate the larger IPv6 address size. IPv6 also introduces new +features (e.g., traffic class and flowlabel), some of which must be made +visible to applications via the API. This memo defines a set of +extensions to the socket interface to support the larger address size +and new features of IPv6. + + + +2. Design Considerations + +There are a number of important considerations in designing changes to +this well-worn API: + + - The API changes should provide both source and binary + compatibility for programs written to the original API. That + is, existing program binaries should continue to operate when + run on a system supporting the new API. In addition, existing + applications that are re-compiled and run on a system supporting + the new API should continue to operate. Simply put, the API + changes for IPv6 should not break existing programs. An additonal + mechanism for implementations to verify this is to verify the new + symbols are protected by Feature Test Macros as described in IEEE Std + 1003.1. (Such Feature Test Macros are not defined by this RFC.) + + - The changes to the API should be as small as possible in order + to simplify the task of converting existing IPv4 applications to + IPv6. + + - Where possible, applications should be able to use this + API to interoperate with both IPv6 and IPv4 hosts. Applications + should not need to know which type of host they are + communicating with. + + - IPv6 addresses carried in data structures should be 64-bit + aligned. This is necessary in order to obtain optimum + performance on 64-bit machine architectures. + +Because of the importance of providing IPv4 compatibility in the API, +these extensions are explicitly designed to operate on machines that +provide complete support for both IPv4 and IPv6. A subset of this API +could probably be designed for operation on systems that support only +IPv6. However, this is not addressed in this memo. + + + +2.1 What Needs to be Changed + +The socket interface API consists of a few distinct components: + + - Core socket functions. + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 3] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + - Address data structures. + + - Name-to-address translation functions. + + - Address conversion functions. + +The core socket functions -- those functions that deal with such things +as setting up and tearing down TCP connections, and sending and +receiving UDP packets -- were designed to be transport independent. +Where protocol addresses are passed as function arguments, they are +carried via opaque pointers. A protocol-specific address data structure +is defined for each protocol that the socket functions support. +Applications must cast pointers to these protocol-specific address +structures into pointers to the generic "sockaddr" address structure +when using the socket functions. These functions need not change for +IPv6, but a new IPv6-specific address data structure is needed. + +The "sockaddr_in" structure is the protocol-specific data structure for +IPv4. This data structure actually includes 8-octets of unused space, +and it is tempting to try to use this space to adapt the sockaddr_in +structure to IPv6. Unfortunately, the sockaddr_in structure is not +large enough to hold the 16-octet IPv6 address as well as the other +information (address family and port number) that is needed. So a new +address data structure must be defined for IPv6. + +IPv6 addresses are scoped [2] so they could be link-local, site, +organization, global, or other scopes at this time undefined. To +support applications that want to be able to identify a set of +interfaces for a specific scope, the IPv6 sockaddr_in structure must +support a field that can be used by an implementation to identify a set +of interfaces identifying the scope for an IPv6 address. + +The name-to-address translation functions in the socket interface are +gethostbyname() and gethostbyaddr(). These are left as is and new +functions are defined to support IPv4 and IPv6. Additionally, the POSIX +1003.g draft [3] specifies a new nodename-to-address translation +function which is protocol independent. This function can also be used +with IPv4 and IPv6. + +The address conversion functions -- inet_ntoa() and inet_addr() -- +convert IPv4 addresses between binary and printable form. These +functions are quite specific to 32-bit IPv4 addresses. We have designed +two analogous functions that convert both IPv4 and IPv6 addresses, and +carry an address type parameter so that they can be extended to other +protocol families as well. + +Finally, a few miscellaneous features are needed to support IPv6. New +interfaces are needed to support the IPv6 traffic class, flow label, and +hop limit header fields. New socket options are needed to control the +sending and receiving of IPv6 multicast packets. + +The socket interface will be enhanced in the future to provide access to +other IPv6 features. These extensions are described in [4]. + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 4] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +2.2 Data Types + +The data types of the structure elements given in this memo are intended +to be examples, not absolute requirements. Whenever possible, data +types from Draft 6.6 (March 1997) of POSIX 1003.1g are used: uintN_t +means an unsigned integer of exactly N bits (e.g., uint16_t). We also +assume the argument data types from 1003.1g when possible (e.g., the +final argument to setsockopt() is a size_t value). Whenever buffer +sizes are specified, the POSIX 1003.1 size_t data type is used (e.g., +the two length arguments to getnameinfo()). + + + +2.3 Headers + +When function prototypes and structures are shown we show the headers +that must be #included to cause that item to be defined. + + + +2.4 Structures + +When structures are described the members shown are the ones that must +appear in an implementation. Additional, nonstandard members may also +be defined by an implementation. As an additional precaution +nonstandard members could be verified by Feature Test Macros as +described in IEEE Std 1003.1. (Such Feature Test Macros are not defined +by this RFC.) + +The ordering shown for the members of a structure is the recommended +ordering, given alignment considerations of multibyte members, but an +implementation may order the members differently. + + + +3. Socket Interface + +This section specifies the socket interface changes for IPv6. + + + +3.1 IPv6 Address Family and Protocol Family + +A new address family name, AF_INET6, is defined in . The +AF_INET6 definition distinguishes between the original sockaddr_in +address data structure, and the new sockaddr_in6 data structure. + +A new protocol family name, PF_INET6, is defined in . +Like most of the other protocol family names, this will usually be +defined to have the same value as the corresponding address family name: + + #define PF_INET6 AF_INET6 + +The PF_INET6 is used in the first argument to the socket() function to +indicate that an IPv6 socket is being created. + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 5] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +3.2 IPv6 Address Structure + +A new in6_addr structure holds a single IPv6 address and is defined as a +result of including : + + struct in6_addr { + uint8_t s6_addr[16]; /* IPv6 address */ + }; + +This data structure contains an array of sixteen 8-bit elements, which +make up one 128-bit IPv6 address. The IPv6 address is stored in network +byte order. + +The structure in6_addr above is usually implemented with an embedded +union with extra fields that force the desired alignment level in a +manner similar to BSD implementations of "struct in_addr". Those +additional implementation details are omitted here for simplicity. + +An example is as follows: + +struct in6_addr { + union { + uint8_t _S6_u8[16]; + uint32_t _S6_u32[4]; + uint64_t _S6_u64[2]; + } _S6_un; +}; +#define s6_addr _S6_un._S6_u8 + + + +3.3 Socket Address Structure for 4.3BSD-Based Systems + +In the socket interface, a different protocol-specific data structure is +defined to carry the addresses for each protocol suite. Each protocol- +specific data structure is designed so it can be cast into a protocol- +independent data structure -- the "sockaddr" structure. Each has a +"family" field that overlays the "sa_family" of the sockaddr data +structure. This field identifies the type of the data structure. + +The sockaddr_in structure is the protocol-specific address data +structure for IPv4. It is used to pass addresses between applications +and the system in the socket functions. The following sockaddr_in6 +structure holds IPv6 addresses and is defined as a result of including +the header: + + struct sockaddr_in6 { + sa_family_t sin6_family; /* AF_INET6 */ + in_port_t sin6_port; /* transport layer port # */ + uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */ + struct in6_addr sin6_addr; /* IPv6 address */ + uint32_t sin6_scope_id; /* set of interfaces for a scope */ + }; + +This structure is designed to be compatible with the sockaddr data +structure used in the 4.3BSD release. + +The sin6_family field identifies this as a sockaddr_in6 structure. This + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 6] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +field overlays the sa_family field when the buffer is cast to a sockaddr +data structure. The value of this field must be AF_INET6. + +The sin6_port field contains the 16-bit UDP or TCP port number. This +field is used in the same way as the sin_port field of the sockaddr_in +structure. The port number is stored in network byte order. + +The sin6_flowinfo field is a 32-bit field that contains two pieces of +information: the traffic class and the flow label. The contents and +interpretation of this member is specified in [1]. The sin6_flowinfo +field SHOULD be set to zero by an implementation prior to using the +sockaddr_in6 structure by an application on receive operations. + +The sin6_addr field is a single in6_addr structure (defined in the +previous section). This field holds one 128-bit IPv6 address. The +address is stored in network byte order. + +The ordering of elements in this structure is specifically designed so +that when sin6_addr field is aligned on a 64-bit boundary, the start of +the structure will also be aligned on a 64-bit boundary. This is done +for optimum performance on 64-bit architectures. + +The sin6_scope_id field is a 32-bit integer that identifies a set of +interfaces as appropriate for the scope of the address carried in the +sin6_addr field. For a link scope sin6_addr sin6_scope_id would be an +interface index. For a site scope sin6_addr, sin6_scope_id would be a +site identifier. The mapping of sin6_scope_id to an interface or set of +interfaces is left to implementation and future specifications on the +subject of site identifiers. + +Notice that the sockaddr_in6 structure will normally be larger than the +generic sockaddr structure. On many existing implementations the +sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both +being 16 bytes. Any existing code that makes this assumption needs to +be examined carefully when converting to IPv6. + + + +3.4 Socket Address Structure for 4.4BSD-Based Systems + +The 4.4BSD release includes a small, but incompatible change to the +socket interface. The "sa_family" field of the sockaddr data structure +was changed from a 16-bit value to an 8-bit value, and the space saved +used to hold a length field, named "sa_len". The sockaddr_in6 data +structure given in the previous section cannot be correctly cast into +the newer sockaddr data structure. For this reason, the following +alternative IPv6 address data structure is provided to be used on +systems based on 4.4BSD. It is defined as a result of including the + header. + + struct sockaddr_in6 { + uint8_t sin6_len; /* length of this struct */ + sa_family_t sin6_family; /* AF_INET6 */ + in_port_t sin6_port; /* transport layer port # */ + uint32_t sin6_flowinfo; /* IPv6 flow information */ + struct in6_addr sin6_addr; /* IPv6 address */ + uint32_t sin6_scope_id; /* set of interfaces for a scope */ + }; + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 7] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +The only differences between this data structure and the 4.3BSD variant +are the inclusion of the length field, and the change of the family +field to a 8-bit data type. The definitions of all the other fields are +identical to the structure defined in the previous section. + +Systems that provide this version of the sockaddr_in6 data structure +must also declare SIN6_LEN as a result of including the +header. This macro allows applications to determine whether they are +being built on a system that supports the 4.3BSD or 4.4BSD variants of +the data structure. + + + +3.5 The Socket Functions + +Applications call the socket() function to create a socket descriptor +that represents a communication endpoint. The arguments to the socket() +function tell the system which protocol to use, and what format address +structure will be used in subsequent functions. For example, to create +an IPv4/TCP socket, applications make the call: + + s = socket(PF_INET, SOCK_STREAM, 0); + +To create an IPv4/UDP socket, applications make the call: + + s = socket(PF_INET, SOCK_DGRAM, 0); + +Applications may create IPv6/TCP and IPv6/UDP sockets by simply using +the constant PF_INET6 instead of PF_INET in the first argument. For +example, to create an IPv6/TCP socket, applications make the call: + + s = socket(PF_INET6, SOCK_STREAM, 0); + +To create an IPv6/UDP socket, applications make the call: + + s = socket(PF_INET6, SOCK_DGRAM, 0); + +Once the application has created a PF_INET6 socket, it must use the +sockaddr_in6 address structure when passing addresses in to the system. +The functions that the application uses to pass addresses into the +system are: + + bind() + connect() + sendmsg() + sendto() + +The system will use the sockaddr_in6 address structure to return +addresses to applications that are using PF_INET6 sockets. The +functions that return an address from the system to an application are: + + accept() + recvfrom() + recvmsg() + getpeername() + getsockname() + +No changes to the syntax of the socket functions are needed to support + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 8] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +IPv6, since all of the "address carrying" functions use an opaque +address pointer, and carry an address length as a function argument. + + + +3.6 Compatibility with IPv4 Applications + +In order to support the large base of applications using the original +API, system implementations must provide complete source and binary +compatibility with the original API. This means that systems must +continue to support PF_INET sockets and the sockaddr_in address +structure. Applications must be able to create IPv4/TCP and IPv4/UDP +sockets using the PF_INET constant in the socket() function, as +described in the previous section. Applications should be able to hold +a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets +simultaneously within the same process. + +Applications using the original API should continue to operate as they +did on systems supporting only IPv4. That is, they should continue to +interoperate with IPv4 nodes. + + + +3.7 Compatibility with IPv4 Nodes + +The API also provides a different type of compatibility: the ability for +IPv6 applications to interoperate with IPv4 applications. This feature +uses the IPv4-mapped IPv6 address format defined in the IPv6 addressing +architecture specification [2]. This address format allows the IPv4 +address of an IPv4 node to be represented as an IPv6 address. The IPv4 +address is encoded into the low-order 32 bits of the IPv6 address, and +the high-order 96 bits hold the fixed prefix 0:0:0:0:0:FFFF. IPv4- +mapped addresses are written as follows: + + ::FFFF: + +These addresses can be generated automatically by the getipnodebyname() +function when the specified host has only IPv4 addresses (as described +in Section 6.1). + +Applications may use PF_INET6 sockets to open TCP connections to IPv4 +nodes, or send UDP packets to IPv4 nodes, by simply encoding the +destination's IPv4 address as an IPv4-mapped IPv6 address, and passing +that address, within a sockaddr_in6 structure, in the connect() or +sendto() call. When applications use PF_INET6 sockets to accept TCP +connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the +system returns the peer's address to the application in the accept(), +recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded +this way. + +Few applications will likely need to know which type of node they are +interoperating with. However, for those applications that do need to +know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is +provided. + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 9] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +3.8 IPv6 Wildcard Address + +While the bind() function allows applications to select the source IP +address of UDP packets and TCP connections, applications often want the +system to select the source address for them. With IPv4, one specifies +the address as the symbolic constant INADDR_ANY (called the "wildcard" +address) in the bind() call, or simply omits the bind() entirely. + +Since the IPv6 address type is a structure (struct in6_addr), a symbolic +constant can be used to initialize an IPv6 address variable, but cannot +be used in an assignment. Therefore systems provide the IPv6 wildcard +address in two forms. + +The first version is a global variable named "in6addr_any" that is an +in6_addr structure. The extern declaration for this variable is defined +in : + + extern const struct in6_addr in6addr_any; + +Applications use in6addr_any similarly to the way they use INADDR_ANY in +IPv4. For example, to bind a socket to port number 23, but let the +system select the source address, an application could use the following +code: + + struct sockaddr_in6 sin6; + . . . + sin6.sin6_family = AF_INET6; + sin6.sin6_flowinfo = 0; + sin6.sin6_port = htons(23); + sin6.sin6_addr = in6addr_any; /* structure assignment */ + . . . + if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) + . . . + +The other version is a symbolic constant named IN6ADDR_ANY_INIT and is +defined in . This constant can be used to initialize an +in6_addr structure: + + struct in6_addr anyaddr = IN6ADDR_ANY_INIT; + +Note that this constant can be used ONLY at declaration time. It can +not be used to assign a previously declared in6_addr structure. For +example, the following code will not work: + + /* This is the WRONG way to assign an unspecified address */ + struct sockaddr_in6 sin6; + . . . + sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */ + +Be aware that the IPv4 INADDR_xxx constants are all defined in host byte +order but the IPv6 IN6ADDR_xxx constants and the IPv6 in6addr_xxx +externals are defined in network byte order. + + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 10] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +3.9 IPv6 Loopback Address + +Applications may need to send UDP packets to, or originate TCP +connections to, services residing on the local node. In IPv4, they can +do this by using the constant IPv4 address INADDR_LOOPBACK in their +connect(), sendto(), or sendmsg() call. + +IPv6 also provides a loopback address to contact local TCP and UDP +services. Like the unspecified address, the IPv6 loopback address is +provided in two forms -- a global variable and a symbolic constant. + +The global variable is an in6_addr structure named "in6addr_loopback." +The extern declaration for this variable is defined in : + + extern const struct in6_addr in6addr_loopback; + +Applications use in6addr_loopback as they would use INADDR_LOOPBACK in +IPv4 applications (but beware of the byte ordering difference mentioned +at the end of the previous section). For example, to open a TCP +connection to the local telnet server, an application could use the +following code: + + struct sockaddr_in6 sin6; + . . . + sin6.sin6_family = AF_INET6; + sin6.sin6_flowinfo = 0; + sin6.sin6_port = htons(23); + sin6.sin6_addr = in6addr_loopback; /* structure assignment */ + . . . + if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) + . . . + +The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined in +. It can be used at declaration time ONLY; for example: + + struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT; + +Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to +a previously declared IPv6 address variable. + + + +3.10 Portability Additions + +One simple addition to the sockets API that can help application writers +is the "struct sockaddr_storage". This data structure can simplify +writing code portable across multiple address families and platforms. +This data structure is designed with the following goals. + + - It has a large enough implementation specific maximum size to store + the desired set of protocol specific socket address data structures. + Specifically, it is at least large enough to accommodate sockaddr_in + and sockaddr_in6 and possibly other protocol specific socket + addresses too. + - It is aligned at an appropriate boundary so protocol specific socket + address data structure pointers can be cast to it and access their + fields without alignment problems. (e.g. pointers to sockaddr_in6 + and/or sockaddr_in can be cast to it and access fields without alignment + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 11] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + problems). + - It has the initial field(s) isomorphic to the fields of the + "struct sockaddr" data structure on that implementation which + can be used as a discriminants for deriving the protocol in use. + These initial field(s) would on most implementations either be a + single field of type "sa_family_t" (isomorphic to sa_family field, + 16 bits) or two fields of type uint8_t and sa_family_t respectively, + (isomorphic to sa_len and sa_family_t, 8 bits each). + +An example implementation design of such a data structure would be as +follows. + +/* + * Desired design of maximum size and alignment + */ +#define _SS_MAXSIZE 128 /* Implementation specific max size */ +#define _SS_ALIGNSIZE (sizeof (int64_t)) + /* Implementation specific desired alignment */ +/* + * Definitions used for sockaddr_storage structure paddings design. + */ +#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) +#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+ + _SS_PAD1SIZE + _SS_ALIGNSIZE)) +struct sockaddr_storage { + sa_family_t __ss_family; /* address family */ + /* Following fields are implementation specific */ + char __ss_pad1[_SS_PAD1SIZE]; + /* 6 byte pad, this is to make implementation + /* specific pad up to alignment field that */ + /* follows explicit in the data structure */ + int64_t __ss_align; /* field to force desired structure */ + /* storage alignment */ + char __ss_pad2[_SS_PAD2SIZE]; + /* 112 byte pad to achieve desired size, */ + /* _SS_MAXSIZE value minus size of ss_family */ + /* __ss_pad1, __ss_align fields is 112 */ +}; + +On implementations where sockaddr data structure includes a "sa_len", +field this data structure would look like this: + +/* + * Definitions used for sockaddr_storage structure paddings design. + */ +#define _SS_PAD1SIZE (_SS_ALIGNSIZE - + (sizeof (uint8_t) + sizeof (sa_family_t)) +#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+ + _SS_PAD1SIZE + _SS_ALIGNSIZE)) +struct sockaddr_storage { + uint8_t __ss_len; /* address length */ + sa_family_t __ss_family; /* address family */ + /* Following fields are implementation specific */ + char __ss_pad1[_SS_PAD1SIZE]; + /* 6 byte pad, this is to make implementation + /* specific pad up to alignment field that */ + /* follows explicit in the data structure */ + int64_t __ss_align; /* field to force desired structure */ + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 12] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + /* storage alignment */ + char __ss_pad2[_SS_PAD2SIZE]; + /* 112 byte pad to achieve desired size, */ + /* _SS_MAXSIZE value minus size of ss_len, */ + /* __ss_family, __ss_pad1, __ss_align fields is 112 */ +}; + +The above example implementation illustrates a data structure which will +align on a 64 bit boundary. An implementation specific field +"__ss_align" along "__ss_pad1" is used to force a 64-bit alignment which +covers proper alignment good enough for needs of sockaddr_in6 (IPv6), +sockaddr_in (IPv4) address data structures. The size of padding fields +__ss_pad1 depends on the chosen alignment boundary. The size of padding +field __ss_pad2 depends on the value of overall size chosen for the +total size of the structure. This size and alignment are represented in +the above example by implementation specific (not required) constants +_SS_MAXSIZE (chosen value 128) and _SS_ALIGNMENT (with chosen value 8). +Constants _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value +112) are also for illustration and not required. The implementation +specific definitions and structure field names above start with an +underscore to denote implementation private namespace. Portable code is +not expected to access or reference those fields or constants. + +The sockaddr_storage structure solves the problem of declaring storage +for automatic variables which is large enough and aligned enough for +storing socket address data structure of any family. For example, code +with a file descriptor and without the context of the address family can +pass a pointer to a variable of this type where a pointer to a socket +address structure is expected in calls such as getpeername() and +determine the address family by accessing the received content after the +call. + +The sockaddr_storage structure may also be useful and applied to certain +other interfaces where a generic socket address large enough and aligned +for use with multiple address families may be needed. A discussion of +those interfaces is outside the scope of this document. + +Also, much existing code assumes that any socket address structure can +fit in a generic sockaddr structure. While this has been true for IPv4 +socket address structures, it has always been false for Unix domain +socket address structures (but in practice this has not been a problem) +and it is also false for IPv6 socket address structures (which can be a +problem). + +So now an application can do the following: + + struct sockaddr_storage __ss; + struct sockaddr_in6 *sin6; + sin6 = (struct sockaddr_in6 *) &__ss; + + + +4. Interface Identification + +This API uses an interface index (a small positive integer) to identify +the local interface on which a multicast group is joined (Section 5.3). +Additionally, the advanced API [4] uses these same interface indexes to +identify the interface on which a datagram is received, or to specify + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 13] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +the interface on which a datagram is to be sent. + +Interfaces are normally known by names such as "le0", "sl1", "ppp2", and +the like. On Berkeley-derived implementations, when an interface is +made known to the system, the kernel assigns a unique positive integer +value (called the interface index) to that interface. These are small +positive integers that start at 1. (Note that 0 is never used for an +interface index.) There may be gaps so that there is no current +interface for a particular positive interface index. + +This API defines two functions that map between an interface name and +index, a third function that returns all the interface names and +indexes, and a fourth function to return the dynamic memory allocated by +the previous function. How these functions are implemented is left up +to the implementation. 4.4BSD implementations can implement these +functions using the existing sysctl() function with the NET_RT_IFLIST +command. Other implementations may wish to use ioctl() for this +purpose. + + + +4.1 Name-to-Index + +The first function maps an interface name into its corresponding index. + + #include + + unsigned int if_nametoindex(const char *ifname); + +If the specified interface name does not exist, the return value is 0, +and errno is set to ENXIO. If there was a system error (such as +running out of memory), the return value is 0 and errno is set to the +proper value (e.g., ENOMEM). + + + +4.2 Index-to-Name + +The second function maps an interface index into its corresponding name. + + #include + + char *if_indextoname(unsigned int ifindex, char *ifname); + +The ifname argument must point to a buffer of at least IF_NAMESIZE bytes +into which the interface name corresponding to the specified index is +returned. (IF_NAMESIZE is also defined in and its value +includes a terminating null byte at the end of the interface name.) This +pointer is also the return value of the function. If there is no +interface corresponding to the specified index, NULL is returned, and +errno is set to ENXIO, if there was a system error (such as running out +of memory), if_indextoname returns NULL and errno would be set to the +proper value (e.g., ENOMEM). + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 14] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +4.3 Return All Interface Names and Indexes + +The if_nameindex structure holds the information about a single +interface and is defined as a result of including the header. + + struct if_nameindex { + unsigned int if_index; /* 1, 2, ... */ + char *if_name; /* null terminated name: "le0", ... */ + }; + +The final function returns an array of if_nameindex structures, one +structure per interface. + + struct if_nameindex *if_nameindex(void); + +The end of the array of structures is indicated by a structure with an +if_index of 0 and an if_name of NULL. The function returns a NULL +pointer upon an error, and would set errno to the appropriate value. + +The memory used for this array of structures along with the interface +names pointed to by the if_name members is obtained dynamically. This +memory is freed by the next function. + + + +4.4 Free Memory + +The following function frees the dynamic memory that was allocated by +if_nameindex(). + + #include + + void if_freenameindex(struct if_nameindex *ptr); + +The argument to this function must be a pointer that was returned by +if_nameindex(). + +Currently net/if.h doesn't have prototype definitions for functions and +it is recommended that these definitions be defined in net/if.h as well +and the struct if_nameindex{}. + + + +5. Socket Options + +A number of new socket options are defined for IPv6. All of these new +options are at the IPPROTO_IPV6 level. That is, the "level" parameter +in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 when using +these options. The constant name prefix IPV6_ is used in all of the new +socket options. This serves to clearly identify these options as +applying to IPv6. + +The declaration for IPPROTO_IPV6, the new IPv6 socket options, and +related constants defined in this section are obtained by including the +header . + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 15] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +5.1 Unicast Hop Limit + +A new setsockopt() option controls the hop limit used in outgoing +unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, and +it is used at the IPPROTO_IPV6 layer. The following example illustrates +how it is used: + + int hoplimit = 10; + + if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, + (char *) &hoplimit, sizeof(hoplimit)) == -1) + perror("setsockopt IPV6_UNICAST_HOPS"); + +When the IPV6_UNICAST_HOPS option is set with setsockopt(), the option +value given is used as the hop limit for all subsequent unicast packets +sent via that socket. If the option is not set, the system selects a +default value. The integer hop limit value (called x) is interpreted as +follows: + + x < -1: return an error of EINVAL + x == -1: use kernel default + 0 <= x <= 255: use x + x >= 256: return an error of EINVAL + +The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine +the hop limit value that the system will use for subsequent unicast +packets sent via that socket. For example: + + int hoplimit; + size_t len = sizeof(hoplimit); + + if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, + (char *) &hoplimit, &len) == -1) + perror("getsockopt IPV6_UNICAST_HOPS"); + else + printf("Using %d for hop limit.\n", hoplimit); + + + +5.2 Sending and Receiving Multicast Packets + +IPv6 applications may send UDP multicast packets by simply specifying an +IPv6 multicast address in the address argument of the sendto() function. + +Three socket options at the IPPROTO_IPV6 layer control some of the +parameters for sending multicast packets. Setting these options is not +required: applications may send multicast packets without using these +options. The setsockopt() options for controlling the sending of +multicast packets are summarized below. These three options can also be +used with getsockopt(). + + IPV6_MULTICAST_IF + + Set the interface to use for outgoing multicast packets. + The argument is the index of the interface to use. + + Argument type: unsigned int + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 16] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + IPV6_MULTICAST_HOPS + + Set the hop limit to use for outgoing multicast packets. + (Note a separate option - IPV6_UNICAST_HOPS - is + provided to set the hop limit to use for outgoing + unicast packets.) + + The interpretation of the argument is the same + as for the IPV6_UNICAST_HOPS option: + + x < -1: return an error of EINVAL + x == -1: use kernel default + 0 <= x <= 255: use x + x >= 256: return an error of EINVAL + + If IPV6_MULTICAST_HOPS is not set, the default is 1 + (same as IPv4 today) + + Argument type: int + + IPV6_MULTICAST_LOOP + + If a multicast datagram is sent to a group to which the sending host + itself belongs (on the outgoing interface), a copy of the datagram is + looped back by the IP layer for local delivery if this option is set to + 1. If this option is set to 0 a copy is not looped back. Other option + values return an error of EINVAL. + + If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same as + IPv4 today). + + Argument type: unsigned int + +The reception of multicast packets is controlled by the two setsockopt() +options summarized below. An error of EOPNOTSUPP is returned if these +two options are used with getsockopt(). + + IPV6_JOIN_GROUP + + Join a multicast group on a specified local interface. + If the interface index is specified as 0, + the kernel chooses the local interface. + For example, some kernels look up the multicast group + in the normal IPv6 routing table and using the resulting interface. + + Argument type: struct ipv6_mreq + + IPV6_LEAVE_GROUP + + Leave a multicast group on a specified interface. + + Argument type: struct ipv6_mreq + +The argument type of both of these options is the ipv6_mreq structure, +defined as a result of including the header; + + struct ipv6_mreq { + struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */ + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 17] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + unsigned int ipv6mr_interface; /* interface index */ + }; + +Note that to receive multicast datagrams a process must join the +multicast group and bind the UDP port to which datagrams will be sent. +Some processes also bind the multicast group address to the socket, in +addition to the port, to prevent other datagrams destined to that same +port from being delivered to the socket. + + + +6. Library Functions + +New library functions are needed to perform a variety of operations with +IPv6 addresses. Functions are needed to lookup IPv6 addresses in the +Domain Name System (DNS). Both forward lookup (nodename-to-address +translation) and reverse lookup (address-to-nodename translation) need +to be supported. Functions are also needed to convert IPv6 addresses +between their binary and textual form. + +We note that the two existing functions, gethostbyname() and +gethostbyaddr(), are left as-is. New functions are defined to handle +both IPv4 and IPv6 addresses. + + + +6.1 Nodename-to-Address Translation + +The commonly used function gethostbyname() is inadequate for many +applications, first because it provides no way for the caller to specify +anything about the types of addresses desired (IPv4 only, IPv6 only, +IPv4-mapped IPv6 are OK, etc.), and second because many implementations +of this function are not thread safe. RFC 2133 defined a function named +gethostbyname2() but this function was also inadequate, first because +its use required setting a global option (RES_USE_INET6) when IPv6 +addresses were required, and second because a flag argument is needed to +provide the caller with additional control over the types of addresses +required. + +The following function is new and must be thread safe: + + #include + #include + + struct hostent *getipnodebyname(const char *name, int af, int flags + int *error_num); + +The name argument can be either a node name or a numeric address string +(i.e., a dotted-decimal IPv4 address or an IPv6 hex address). The af +argument specifies the address family, either AF_INET or AF_INET6. The +error_num value is returned to the caller, via a pointer, with the +appropriate error code in error_num, to support thread safe error code +returns. error_num will be set to one of the following values: + + HOST_NOT_FOUND + + No such host is known. + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 18] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + NO_ADDRESS + + The server recognised the request and the name but no address + is available. Another type of request to the name server for + the domain might return an answer. + + NO_RECOVERY + + An unexpected server failure occurred which cannot be recovered. + + TRY_AGAIN + + A temporary and possibly transient error occurred, such as a + failure of a server to respond. + + +The flags argument specifies the types of addresses that are searched +for, and the types of addresses that are returned. We note that a +special flags value of AI_DEFAULT (defined below) should handle most +applications. + +That is, porting simple applications to use IPv6 replaces the call + + hptr = gethostbyname(name); + +with + + hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num); + +and changes any subsequent error diagnosis code to use error_num instead +of externally declared variables, such as h_errno. + +Applications desiring finer control over the types of addresses searched +for and returned, can specify other combinations of the flags argument. + +A flags of 0 implies a strict interpretation of the af argument: + + - If flags is 0 and af is AF_INET, then the caller wants only IPv4 + addresses. A query is made for A records. If successful, the IPv4 + addresses are returned and the h_length member of the hostent + structure will be 4, else the function returns a NULL pointer. + + - If flags is 0 and if af is AF_INET6, then the caller wants only + IPv6 addresses. A query is made for AAAA records. If successful, + the IPv6 addresses are returned and the h_length member of the + hostent structure will be 16, else the function returns a NULL + pointer. + +Other constants can be logically-ORed into the flags argument, to modify +the behavior of the function. + + - If the AI_V4MAPPED flag is specified along with an af of + AF_INET6, then the caller will accept IPv4-mapped IPv6 + addresses. That is, if no AAAA records are found then a query + is made for A records and any found are returned as IPv4-mapped + IPv6 addresses (h_length will be 16). The AI_V4MAPPED flag is + ignored unless af equals AF_INET6. + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 19] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + - The AI_ALL flag is used in conjunction with the AI_V4MAPPED + flag, and is only used with the IPv6 address family. When AI_ALL + is logically or'd with AI_V4MAPPED flag then the caller wants + all addresses: IPv6 and IPv4-mapped IPv6. A query is first made + for AAAA records and if successful, the IPv6 addresses are returned. + Another query is then made for A records and any found are returned + as IPv4-mapped IPv6 addresses. h_length will be 16. Only if both + queries fail does the function return a NULL pointer. This flag is + ignored unless af equals AF_INET6. + + - The AI_ADDRCONFIG flag specifies that a query for AAAA records + should occur only if the node has at least one IPv6 source address + configured and a query for A records should occur only if the + node has at least one IPv4 source address configured. + + For example, if the node has no IPv6 source addresses configured, + and af equals AF_INET6, and the node name being looked up has both + AAAA and A records, then: + + (a) if only AI_ADDRCONFIG is specified, the function returns a + NULL pointer; + (b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A records + are returned as IPv4-mapped IPv6 addresses; + +The special flags value of AI_DEFAULT is defined as + + #define AI_DEFAULT (AI_V4MAPPED | AI_ADDRCONFIG) + +We noted that the getipnodebyname() function must allow the name +argument to be either a node name or a literal address string (i.e., a +dotted-decimal IPv4 address or an IPv6 hex address). This saves +applications from having to call inet_pton() to handle literal address +strings. + +There are four scenarios based on the type of literal address string and +the value of the af argument. + +The two simple cases are: + +When name is a dotted-decimal IPv4 address and af equals AF_INET, or +when name is an IPv6 hex address and af equals AF_INET6. The members of +the returned hostent structure are: h_name points to a copy of the name +argument, h_aliases is a NULL pointer, h_addrtype is a copy of the af +argument, h_length is either 4 (for AF_INET) or 16 (for AF_INET6), +h_addr_list[0] is a pointer to the 4-byte or 16-byte binary address, and +h_addr_list[1] is a NULL pointer. + +When name is a dotted-decimal IPv4 address and af equals AF_INET6, and +flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is returned: +h_name points to an IPv6 hex address containing the IPv4-mapped IPv6 +address, h_aliases is a NULL pointer, h_addrtype is AF_INET6, h_length +is 16, h_addr_list[0] is a pointer to the 16-byte binary address, and +h_addr_list[1] is a NULL pointer. If AI_V4MAPPED is set (with or +without AI_ALL) return IPv4-mapped otherwise return NULL. + +It is an error when name is an IPv6 hex address and af equals AF_INET. +The function's return value is a NULL pointer and error_num equals +HOST_NOT_FOUND. + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 20] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +6.2 Address-To-Nodename Translation + +The following function has the same arguments as the existing +gethostbyaddr() function, but adds an error number. + + #include + #include + + struct hostent *getipnodebyaddr(const void *src, size_t len, int af, + int *error_num); + +As with getipnodebyname(), getipnodebyaddr() must be thread safe. The +error_num value is returned to the caller with the appropriate error +code, to support thread safe error code returns. The following error +conditions may be returned for error_num: + + HOST_NOT_FOUND + + No such host is known. + + NO_ADDRESS + + The server recognized the request and the name but no address + is available. Another type of request to the name server for + the domain might return an answer. + + NO_RECOVERY + + An unexpected server failure occurred which cannot be recovered. + + TRY_AGAIN + + A temporary and possibly transient error occurred, such as a + failure of a server to respond. + + +One possible source of confusion is the handling of IPv4-mapped IPv6 +addresses and IPv4-compatible IPv6 addresses, but the following logic +should apply. + + 1. If af is AF_INET6, and if len equals 16, and if the IPv6 address + is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address, + then skip over the first 12 bytes of the IPv6 address, set af to + AF_INET, and set len to 4. + + 2. If af is AF_INET, lookup the name for the given IPv4 address + (e.g., query for a PTR record in the in-addr.arpa domain). + + 3. If af is AF_INET6, lookup the name for the given IPv6 address + (e.g., query for a PTR record in the ip6.int domain). + + 4. If the function is returning success, then the single address that + is returned in the hostent structure is a copy of the first argument + to the function with the same address family that was passed as + an argument to this function. + +All four steps listed are performed, in order. Also note that the IPv6 +hex addresses "::" and "::1" MUST NOT be treated as IPv4-compatible + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 21] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +addresses, and if the address is "::", HOST_NOT_FOUND MUST be returned +and a query of the address not performed. + +Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return false +for "::" and "::1". + + + +6.3 Freeing memory for getipnodebyname and getipnodebyaddr + +The hostent structure does not change from its existing definition. +This structure, and the information pointed to by this structure, are +dynamically allocated by getipnodebyname and getipnodebyaddr. The +following function frees this memory: + + #include + + void freehostent(struct hostent *ptr); + + + +6.4 Protocol-Independent Nodename and Service Name Translation + +Nodename-to-address translation is done in a protocol-independent +fashion using the getaddrinfo() function that is taken from the +Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g +(Protocol Independent Interfaces) draft specification [3]. + +The official specification for this function will be the final POSIX +standard, with the following additional requirements: + + - getaddrinfo() (along with the getnameinfo() function described in + the next section) must be thread safe. + + - The AI_NUMERICHOST is new with this document. + + - All fields in socket address structures returned by getaddrinfo() + that are not filled in through an explicit argument (e.g., + sin6_flowinfo and sin_zero) must be set to 0. (This makes it easier + to compare socket address structures.) + + - getaddrinfo() must fill in the length field of a socket address structure + (e.g., sin6_len) on systems that support this field. + +We are providing this independent description of the function because +POSIX standards are not freely available (as are IETF documents). + + #include + #include + + int getaddrinfo(const char *nodename, const char *servname, + const struct addrinfo *hints, + struct addrinfo **res); + +The addrinfo structure is defined as a result of including the +header. + + struct addrinfo { + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 22] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */ + int ai_family; /* PF_xxx */ + int ai_socktype; /* SOCK_xxx */ + int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ + size_t ai_addrlen; /* length of ai_addr */ + char *ai_canonname; /* canonical name for nodename */ + struct sockaddr *ai_addr; /* binary address */ + struct addrinfo *ai_next; /* next structure in linked list */ + }; + +The return value from the function is 0 upon success or a nonzero error +code. The following names are the nonzero error codes from +getaddrinfo(), and are defined in : + + EAI_ADDRFAMILY address family for nodename not supported + EAI_AGAIN temporary failure in name resolution + EAI_BADFLAGS invalid value for ai_flags + EAI_FAIL non-recoverable failure in name resolution + EAI_FAMILY ai_family not supported + EAI_MEMORY memory allocation failure + EAI_NODATA no address associated with nodename + EAI_NONAME nodename nor servname provided, or not known + EAI_SERVICE servname not supported for ai_socktype + EAI_SOCKTYPE ai_socktype not supported + EAI_SYSTEM system error returned in errno + +The nodename and servname arguments are pointers to null-terminated +strings or NULL. One or both of these two arguments must be a non-NULL +pointer. In the normal client scenario, both the nodename and servname +are specified. In the normal server scenario, only the servname is +specified. A non-NULL nodename string can be either a node name or a +numeric host address string (i.e., a dotted-decimal IPv4 address or an +IPv6 hex address). A non-NULL servname string can be either a service +name or a decimal port number. + +The caller can optionally pass an addrinfo structure, pointed to by the +third argument, to provide hints concerning the type of socket that the +caller supports. In this hints structure all members other than +ai_flags, ai_family, ai_socktype, and ai_protocol must be zero or a NULL +pointer. A value of PF_UNSPEC for ai_family means the caller will +accept any protocol family. A value of 0 for ai_socktype means the +caller will accept any socket type. A value of 0 for ai_protocol means +the caller will accept any protocol. For example, if the caller handles +only TCP and not UDP, then the ai_socktype member of the hints structure +should be set to SOCK_STREAM when getaddrinfo() is called. If the +caller handles only IPv4 and not IPv6, then the ai_family member of the +hints structure should be set to PF_INET when getaddrinfo() is called. +If the third argument to getaddrinfo() is a NULL pointer, this is the +same as if the caller had filled in an addrinfo structure initialized to +zero with ai_family set to PF_UNSPEC. + +Upon successful return a pointer to a linked list of one or more +addrinfo structures is returned through the final argument. The caller +can process each addrinfo structure in this list by following the +ai_next pointer, until a NULL pointer is encountered. In each returned +addrinfo structure the three members ai_family, ai_socktype, and +ai_protocol are the corresponding arguments for a call to the socket() +function. In each addrinfo structure the ai_addr member points to a + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 23] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +filled-in socket address structure whose length is specified by the +ai_addrlen member. + +If the AI_PASSIVE bit is set in the ai_flags member of the hints +structure, then the caller plans to use the returned socket address +structure in a call to bind(). In this case, if the nodename argument +is a NULL pointer, then the IP address portion of the socket address +structure will be set to INADDR_ANY for an IPv4 address or +IN6ADDR_ANY_INIT for an IPv6 address. + +If the AI_PASSIVE bit is not set in the ai_flags member of the hints +structure, then the returned socket address structure will be ready for +a call to connect() (for a connection-oriented protocol) or either +connect(), sendto(), or sendmsg() (for a connectionless protocol). In +this case, if the nodename argument is a NULL pointer, then the IP +address portion of the socket address structure will be set to the +loopback address. + +If the AI_CANONNAME bit is set in the ai_flags member of the hints +structure, then upon successful return the ai_canonname member of the +first addrinfo structure in the linked list will point to a null- +terminated string containing the canonical name of the specified +nodename. + +If the AI_NUMERICHOST bit is set in the ai_flags member of the hints +structure, then a non-NULL nodename string must be a numeric host +address string. Otherwise an error of EAI_NONAME is returned. This +flag prevents any type of name resolution service (e.g., the DNS) from +being called. + +All of the information returned by getaddrinfo() is dynamically +allocated: the addrinfo structures, and the socket address structures +and canonical node name strings pointed to by the addrinfo structures. +To return this information to the system the function freeaddrinfo() is +called: + + #include + #include + + void freeaddrinfo(struct addrinfo *ai); + +The addrinfo structure pointed to by the ai argument is freed, along +with any dynamic storage pointed to by the structure. This operation is +repeated until a NULL ai_next pointer is encountered. + +To aid applications in printing error messages based on the EAI_xxx +codes returned by getaddrinfo(), the following function is defined. + + #include + #include + + char *gai_strerror(int ecode); + +The argument is one of the EAI_xxx values defined earlier and the return +value points to a string describing the error. If the argument is not +one of the EAI_xxx values, the function still returns a pointer to a +string whose contents indicate an unknown error. + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 24] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +6.5 Socket Address Structure to Nodename and Service Name + +The POSIX 1003.1g specification includes no function to perform the +reverse conversion from getaddrinfo(): to look up a nodename and service +name, given the binary address and port. Therefore, we define the +following function: + + #include + #include + + int getnameinfo(const struct sockaddr *sa, socklen_t salen, + char *host, size_t hostlen, + char *serv, size_t servlen, + int flags); + +This function looks up an IP address and port number provided by the +caller in the DNS and system-specific database, and returns text strings +for both in buffers provided by the caller. The function indicates +successful completion by a zero return value; a non-zero return value +indicates failure. + +The first argument, sa, points to either a sockaddr_in structure (for +IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP address +and port number. The salen argument gives the length of the sockaddr_in +or sockaddr_in6 structure. + +The function returns the nodename associated with the IP address in the +buffer pointed to by the host argument. The caller provides the size of +this buffer via the hostlen argument. The service name associated with +the port number is returned in the buffer pointed to by serv, and the +servlen argument gives the length of this buffer. The caller specifies +not to return either string by providing a zero value for the hostlen or +servlen arguments. Otherwise, the caller must provide buffers large +enough to hold the nodename and the service name, including the +terminating null characters. + +Unfortunately most systems do not provide constants that specify the +maximum size of either a fully-qualified domain name or a service name. +Therefore to aid the application in allocating buffers for these two +returned strings the following constants are defined in : + + #define NI_MAXHOST 1025 + #define NI_MAXSERV 32 + +The first value is actually defined as the constant MAXDNAME in recent +versions of BIND's header (older versions of BIND +define this constant to be 256) and the second is a guess based on the +services listed in the current Assigned Numbers RFC. + +The final argument is a flag that changes the default actions of this +function. By default the fully-qualified domain name (FQDN) for the +host is looked up in the DNS and returned. If the flag bit NI_NOFQDN is +set, only the nodename portion of the FQDN is returned for local hosts. + +If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be +located in the DNS, the numeric form of the host's address is returned +instead of its name (e.g., by calling inet_ntop() instead of +getipnodebyaddr()). If the flag bit NI_NAMEREQD is set, an error is + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 25] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +returned if the host's name cannot be located in the DNS. + +If the flag bit NI_NUMERICSERV is set, the numeric form of the service +address is returned (e.g., its port number) instead of its name. The +two NI_NUMERICxxx flags are required to support the "-n" flag that many +commands provide. + +A fifth flag bit, NI_DGRAM, specifies that the service is a datagram +service, and causes getservbyport() to be called with a second argument +of "udp" instead of its default of "tcp". This is required for the few +ports (e.g. 512-514) that have different services for UDP and TCP. + +These NI_xxx flags are defined in along with the AI_xxx flags +already defined for getaddrinfo(). + + + +6.6 Address Conversion Functions + +The two functions inet_addr() and inet_ntoa() convert an IPv4 address +between binary and text form. IPv6 applications need similar functions. +The following two functions convert both IPv6 and IPv4 addresses: + + #include + #include + + int inet_pton(int af, const char *src, void *dst); + + const char *inet_ntop(int af, const void *src, + char *dst, size_t size); + +The inet_pton() function converts an address in its standard text +presentation form into its numeric binary form. The af argument +specifies the family of the address. Currently the AF_INET and AF_INET6 +address families are supported. The src argument points to the string +being passed in. The dst argument points to a buffer into which the +function stores the numeric address. The address is returned in network +byte order. Inet_pton() returns 1 if the conversion succeeds, 0 if the +input is not a valid IPv4 dotted-decimal string or a valid IPv6 address +string, or -1 with errno set to EAFNOSUPPORT if the af argument is +unknown. The calling application must ensure that the buffer referred +to by dst is large enough to hold the numeric address (e.g., 4 bytes for +AF_INET or 16 bytes for AF_INET6). + +If the af argument is AF_INET, the function accepts a string in the +standard IPv4 dotted-decimal form: + + ddd.ddd.ddd.ddd + +where ddd is a one to three digit decimal number between 0 and 255. +Note that many implementations of the existing inet_addr() and +inet_aton() functions accept nonstandard input: octal numbers, +hexadecimal numbers, and fewer than four numbers. inet_pton() does not +accept these formats. + +If the af argument is AF_INET6, then the function accepts a string in +one of the standard IPv6 text forms defined in Section 2.2 of the +addressing architecture specification [2]. + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 26] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +The inet_ntop() function converts a numeric address into a text string +suitable for presentation. The af argument specifies the family of the +address. This can be AF_INET or AF_INET6. The src argument points to a +buffer holding an IPv4 address if the af argument is AF_INET, or an IPv6 +address if the af argument is AF_INET6, the address must be in network +byte order. The dst argument points to a buffer where the function will +store the resulting text string. The size argument specifies the size +of this buffer. The application must specify a non-NULL dst argument. +For IPv6 addresses, the buffer must be at least 46-octets. For IPv4 +addresses, the buffer must be at least 16-octets. In order to allow +applications to easily declare buffers of the proper size to store IPv4 +and IPv6 addresses in string form, the following two constants are +defined in : + + #define INET_ADDRSTRLEN 16 + #define INET6_ADDRSTRLEN 46 + +The inet_ntop() function returns a pointer to the buffer containing the +text string if the conversion succeeds, and NULL otherwise. Upon +failure, errno is set to EAFNOSUPPORT if the af argument is invalid or +ENOSPC if the size of the result buffer is inadequate. + + + +6.7 Address Testing Macros + +The following macros can be used to test for special IPv6 addresses. + + #include + + int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *); + int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *); + int IN6_IS_ADDR_MULTICAST (const struct in6_addr *); + int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *); + int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *); + int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *); + int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *); + + int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *); + int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *); + +The first seven macros return true if the address is of the specified +type, or false otherwise. The last five test the scope of a multicast +address and return true if the address is a multicast address of the +specified scope or false if the address is either not a multicast +address or not of the specified scope. Note that IN6_IS_ADDR_LINKLOCAL +and IN6_IS_ADDR_SITELOCAL return true only for the two local-use IPv6 +unicast addresses. These two macros do not return true for IPv6 +multicast addresses of either link-local scope or site-local scope. + + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 27] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +7. Summary of New Definitions + +The following list summarizes the constants, structure, and extern +definitions discussed in this memo, sorted by header. + + IF_NAMESIZE + struct if_nameindex{}; + + AI_ADDRCONFIG + AI_DEFAULT + AI_ALL + AI_CANONNAME + AI_NUMERICHOST + AI_PASSIVE + AI_V4MAPPED + EAI_ADDRFAMILY + EAI_AGAIN + EAI_BADFLAGS + EAI_FAIL + EAI_FAMILY + EAI_MEMORY + EAI_NODATA + EAI_NONAME + EAI_SERVICE + EAI_SOCKTYPE + EAI_SYSTEM + NI_DGRAM + NI_MAXHOST + NI_MAXSERV + NI_NAMEREQD + NI_NOFQDN + NI_NUMERICHOST + NI_NUMERICSERV + struct addrinfo{}; + + IN6ADDR_ANY_INIT + IN6ADDR_LOOPBACK_INIT + INET6_ADDRSTRLEN + INET_ADDRSTRLEN + IPPROTO_IPV6 + IPV6_JOIN_GROUP + IPV6_LEAVE_GROUP + IPV6_MULTICAST_HOPS + IPV6_MULTICAST_IF + IPV6_MULTICAST_LOOP + IPV6_UNICAST_HOPS + SIN6_LEN + extern const struct in6_addr in6addr_any; + extern const struct in6_addr in6addr_loopback; + struct in6_addr{}; + struct ipv6_mreq{}; + struct sockaddr_in6{}; + + AF_INET6 + PF_INET6 + struct sockaddr_storage; + +The following list summarizes the function and macro prototypes + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 28] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +discussed in this memo, sorted by header. + + int inet_pton(int, const char *, void *); + const char *inet_ntop(int, const void *, + char *, size_t); + + char *if_indextoname(unsigned int, char *); + unsigned int if_nametoindex(const char *); + void if_freenameindex(struct if_nameindex *); + struct if_nameindex *if_nameindex(void); + + int getaddrinfo(const char *, const char *, + const struct addrinfo *, + struct addrinfo **); + int getnameinfo(const struct sockaddr *, socklen_t, + char *, size_t, char *, size_t, int); + void freeaddrinfo(struct addrinfo *); + char *gai_strerror(int); + struct hostent *getipnodebyname(const char *, int, int, + int *); + struct hostent *getipnodebyaddr(const void *, size_t, int, + int *); + void freehostent(struct hostent *); + + int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); + int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MULTICAST(const struct in6_addr *); + int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *); + int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *); + int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *); + + + + +8. Security Considerations + +IPv6 provides a number of new security mechanisms, many of which need to +be accessible to applications. Companion memos detailing the extensions +to the socket interfaces to support IPv6 security are being written. + + + +9. Year 2000 Considerations + +There are no issues for this draft concerning the Year 2000 issue +regarding the use of dates. + + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 29] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +Changes From RFC 2133 + +Changes made in the March 1998 Edition (-01 draft): + + Changed all "hostname" to "nodename" for consistency with other IPv6 + documents. + + Section 3.3: changed comment for sin6_flowinfo to be "traffic class & + flow info" and updated corresponding text description to current + definition of these two fields. + + Section 3.10 ("Portability Additions") is new. + + Section 6: a new paragraph was added reiterating that the existing + gethostbyname() and gethostbyaddr() are not changed. + + Section 6.1: change gethostbyname3() to getnodebyname(). Add + AI_DEFAULT to handle majority of applications. Renamed + AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and IPv4 + addresses too. Defined exactly what getnodebyname() must return if + the name argument is a numeric address string. + + Section 6.2: change gethostbyaddr() to getnodebyaddr(). Reword items + 2 and 3 in the description of how to handle IPv4-mapped and IPv4- + compatible addresses to "lookup a name" for a given address, instead + of specifying what type of DNS query to issue. + + Section 6.3: added two more requirements to getaddrinfo(). + + Section 7: added the following constants to the list for : + AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED. Add union sockaddr_union and + SA_LEN to the lists for . + + Updated references. + +Changes made in the November 1997 Edition (-00 draft): + + The data types have been changed to conform with Draft 6.6 of the + Posix 1003.1g standard. + + Section 3.2: data type of s6_addr changed to "uint8_t". + + Section 3.3: data type of sin6_family changed to "sa_family_t". data + type of sin6_port changed to "in_port_t", data type of sin6_flowinfo + changed to "uint32_t". + + Section 3.4: same as Section 3.3, plus data type of sin6_len changed + to "uint8_t". + + Section 6.2: first argument of gethostbyaddr() changed from "const + char *" to "const void *" and second argument changed from "int" to + "size_t". + + Section 6.4: second argument of getnameinfo() changed from "size_t" + to "socklen_t". + + The wording was changed when new structures were defined, to be more + explicit as to which header must be included to define the structure: + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 30] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section 3.4 + (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3 + (ipv6_mreq{}), and Section 6.3 (addrinfo{}). + + Section 4: NET_RT_LIST changed to NET_RT_IFLIST. + + Section 5.1: The IPV6_ADDRFORM socket option was removed. + + Section 5.3: Added a note that an option value other than 0 or 1 for + IPV6_MULTICAST_LOOP returns an error. Added a note that + IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP can + also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and + IPV6_DROP_MEMBERSHIP cannot be used with getsockopt(). + + Section 6.1: Removed the description of gethostbyname2() and its + associated RES_USE_INET6 option, replacing it with gethostbyname3(). + + Section 6.2: Added requirement that gethostbyaddr() be thread safe. + Reworded step 4 to avoid using the RES_USE_INET6 option. + + Section 6.3: Added the requirement that getaddrinfo() and + getnameinfo() be thread safe. Added the AI_NUMERICHOST flag. + + Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and + IN6_IS_ADDR_SITELOCAL macros. + +Changes made to the draft -01 specification Sept 98 + + Changed priority to traffic class in the spec. + + Added the need for scope identification in section 2.1. + + Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and 3.4. + + Changed 3.10 to use generic storage structure to support holding IPv6 + addresses and removed the SA_LEN macro. + + Distinguished between invalid input parameters and system failures + for Interface Identification in Section 4.1 and 4.2. + + Added defaults for multicast operations in section 5.2 and changed + the names from ADD to JOIN and DROP to LEAVE to be consistent with + IPv6 multicast terminology. + + Changed getnodebyname to getipnodebyname, getnodebyaddr to + getipnodebyaddr, and added MT safe error code to function parameters + in section 6. + + Moved freehostent to its own sub-section after getipnodebyaddr now + 6.3 (so this bumps all remaining sections in section 6. + + Clarified the use of AI_ALL and AI_V4MAPPED that these are dependent + on the AF parameter and must be used as a conjunction in section 6.1. + + Removed the restriction that literal addresses cannot be used with a + flags argument in section 6.1. + + Added Year 2000 Section to the draft + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 31] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + Deleted Reference to the following because the attached is deleted from + the ID directory and has expired. But the logic from the aforementioned + draft still applies, so that was kept in Section 6.2 bullets after 3rd + paragraph. + [7] P. Vixie, "Reverse Name Lookups of Encapsulated IPv4 Addresses + in IPv6", Internet-Draft, , + May 1996. + + Deleted the following reference as it is no longer referenced. + And the draft has expired. + [3] D. McDonald, "A Simple IP Security API Extension to BSD Sockets", + Internet-Draft, , + March 1997. + + Deleted the following reference as it is no longer referenced. + [4] C. Metz, "Network Security API for Sockets", + Internet-Draft, , + January 1998. + + Update current references to current status. + + Added alignment notes for in6_addr and sin6_addr. + + Clarified further that AI_V4MAPPED must be used with a dotted IPv4 + literal address for getipnodebyname(), when address family is + AF_INET6. + + Added text to clarify "::" and "::1" when used by getipnodebyaddr(). + + + + +Acknowledgments + +Thanks to the many people who made suggestions and provided feedback to +this document, including: Werner Almesberger, Ran Atkinson, Fred Baker, +Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve Deering, +Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom Herbert, +Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron +Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave Mitton, Thomas Narten, +Josh Osborne, Craig Partridge, Jean-Luc Richier, Erik Scoredos, Keith +Sklower, Matt Thomas, Harvey Thompson, Dean D. Throop, Karen Tracey, +Glenn Trewitt, Paul Vixie, David Waitzman, Carl Williams, and Kazu +Yamamoto, + +The getaddrinfo() and getnameinfo() functions are taken from an earlier +Internet Draft by Keith Sklower. As noted in that draft, William Durst, +Steven Wise, Michael Karels, and Eric Allman provided many useful +discussions on the subject of protocol-independent name-to-address +translation, and reviewed early versions of Keith Sklower's original +proposal. Eric Allman implemented the first prototype of getaddrinfo(). +The observation that specifying the pair of name and service would +suffice for connecting to a service independent of protocol details was +made by Marshall Rose in a proposal to X/Open for a "Uniform Network +Interface". + +Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh Kacker +made many contributions to this document. Ramesh Govindan made a number + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 32] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +of contributions and co-authored an earlier version of this memo. + + + +References + + [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460 Draft Standard. + + [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", + RFC 2373, July 1998 Draft Standard. + + [3] IEEE, "Protocol Independent Interfaces", + IEEE Std 1003.1g, DRAFT 6.6, + March 1997. + + [4] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6", + RFC 2292, February 1998. + + + + +Authors' Addresses + +Robert E. Gilligan +FreeGate Corporation +1208 E. Arques Ave. +Sunnyvale, CA 94086 +Phone: +1 408 617 1004 +Email: gilligan@freegate.net + +Susan Thomson +Bell Communications Research +MRE 2P-343, 445 South Street +Morristown, NJ 07960 +Telephone: +1 201 829 4514 +Email: set@thumper.bellcore.com + +Jim Bound +Compaq Computer Corporation +110 Spitbrook Road ZK3-3/U14 +Nashua, NH 03062-2698 +Phone: +1 603 884 0400 +Email: bound@zk3.dec.com + +W. Richard Stevens +1202 E. Paseo del Zorro +Tucson, AZ 85718-2826 +Phone: +1 520 297 9416 +Email: rstevens@kohala.com + + + + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 33] diff --git a/doc/draft/draft-ietf-ipngwg-dns-lookups-03.txt b/doc/draft/draft-ietf-ipngwg-dns-lookups-03.txt new file mode 100644 index 0000000000..3f33e3d912 --- /dev/null +++ b/doc/draft/draft-ietf-ipngwg-dns-lookups-03.txt @@ -0,0 +1,838 @@ + +IPng Working Group Matt Crawford +Internet Draft Fermilab + Christian Huitema + Susan Thomson + Bellcore + December 15, 1998 + + DNS Extensions to Support IP Version 6 + + + +Status of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other documents + at any time. It is inappropriate to use Internet- Drafts as + reference material or to cite them other than as "work in progress." + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + + Distribution of this memo is unlimited. + + +1. Abstract + + This document defines the changes that need to be made to the Domain + Name System to support hosts running IP version 6 (IPv6). The + changes include a new resource record type to store an IPv6 address + in a manner which expedites network renumbering, and updated + definitions of existing query types that return Internet addresses + as part of additional section processing. + + For lookups keyed on IPv6 addresses (often called reverse lookups), + this document defines a new domain to hold the top-level delegation + information and a zone structure which allows a zone to be used + without modification for parallel copies of an address space (as for + a multihomed provider or site) and across network renumbering + events. + + + + +Expires June 20, 1999 Crawford et al. [Page 1] + +Internet Draft IPv6 DNS December 15, 1998 + + +2. Introduction + + Current support for the storage of Internet addresses in the Domain + Name System (DNS) [DNSCF, DNSIS] cannot easily be extended to + support IPv6 addresses [AARCH] since applications assume that + address queries return 32-bit IPv4 addresses only. In addition, + maintenance of address information in the DNS is one of several + obstacles which have prevented site and provider renumbering from + being feasible. + + To support the storage of IPv6 addresses without impeding + renumbering we define the following extensions. + + o A new resource record type, "A6", is defined to map a domain + name to an IPv6 address, with a provision for indirection for + leading "prefix" bits. + + o Existing queries that perform additional section processing to + locate IPv4 addresses are redefined to do that processing for + both IPv4 and IPv6 addresses. + + o A new domain, IP6.INT, is defined to support lookups based on + IPv6 address. + + o A new prefix-delegation method is defined, relying on new DNS + features [BITLBL, DNAME]. + + The changes are designed to be compatible with existing + applications. The existing support for IPv4 addresses is retained. + Transition issues related to the coexistence of both IPv4 and IPv6 + addresses in DNS are discussed in [TRANS]. + + This memo proposes a replacement for the specification in RFC 1886 + and a departure from current implementation practices. The changes + are designed to facilitate network renumbering and multihoming. + Domains employing the A6 record for IPv6 addresses can have + automatically-genrerated AAAA records to ease transition. It is + expected that after a reasonable period, RFC 1886 will become + Historic. + + The next three major sections of this document are an overview of + the facilities defined or employed by this specification, the + specification itself, and examples of use. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [KWORD]. The key + word "SUGGESTED" signifies a strength between MAY and SHOULD: it is + + + +Expires June 20, 1999 Crawford et al. [Page 2] + +Internet Draft IPv6 DNS December 15, 1998 + + + believed that compliance with the suggestion has tangible benefits + in most instances. + + +3. Overview + + This section provides an overview of the DNS facilities for storage + of IPv6 addresses and for lookups based on IPv6 address, including + those defined here and elsewhere. + + +3.1. Name-to-Address Lookup + + IPv6 addresses are stored in one or more A6 resource records. A + single A6 record may include a complete IPv6 address, or a + contiguous portion of an address and information leading to one or + more prefixes. Prefix information comprises a prefix length and a + DNS name which is in turn the owner of one or more A6 records + defining the prefix or prefixes which are needed to form one or more + complete IPv6 addresses. When the prefix length is zero, no DNS + name is present and all the leading bits of the address are + significant. There may be multiples levels of indirection and the + existence of multiple A6 records at any level multiplies the number + of IPv6 addresses which are formed. + + An application looking up an IPv6 address will generally cause the + DNS resolver to access several A6 records, and multiple IPv6 + addresses may be returned even if the queried name was the owner of + only one A6 record. The authenticity [DNSSEC] of the returned + address(es) cannot be directly verified. The A6 records which + contributed to the address(es) may of course be verified if signed. + + +3.2. Underlying Mechanisms for Reverse Lookups + + This section describes the new DNS features which this document + exploits. This section is an overview, not a specification of those + features. The reader is directed to the referenced documents for + more details on each. + + +3.2.1. Delegation on Arbitrary Boundaries + + This new scheme for reverse lookups relies on a new type of DNS + label called the "bit-string label" [BITLBL]. This label compactly + represents an arbitrary string of bits which is treated as a + hierarchical sequence of one-bit domain labels. Resource records + can thereby be stored on arbitrary bit-boundaries. + + + +Expires June 20, 1999 Crawford et al. [Page 3] + +Internet Draft IPv6 DNS December 15, 1998 + + + Examples in section 6 will employ the following textual + representation for bit-string labels, which is a subset of the + syntax defined in [BITLBL]. A base indicator "x" for hexadecimal + and a sequence of hexadecimal digits is enclosed between "\[" and + "]". The bits denoted by the digits represent a sequence of one-bit + domain labels ordered from most to least significant. (This is the + opposite of the order they would appear if listed one bit at a time, + but it appears to be a convenient notation.) The digit string may + be followed by a slash ("/") and a decimal count. If omitted, the + implicit count is equal to four times the number of hexadecimal + digits. + + Consecutive bit-string labels are equivalent (up to the limit + imposed by the size of the bit count field) to a single bit-string + label containing all the bits of the consecutive labels in the + proper order. As an example, either of the following domain names + could be used in a QCLASS=IN, QTYPE=PTR query to find the name of + the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32. + + \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.INT. + + \[x0A0020FFFE812B32/64].\[x0009/16]. + \[x07C00040/32].\[xFFF0/13].\[x2/3].IP6.INT. + + Note that bits are left-justified in a hexadecimal string. + + +3.2.2. Reusable Zones + + DNS address space delegation is implemented not by zone cuts and NS + records, but by a new analogue to the CNAME record, called the DNAME + resource record [DNAME]. The DNAME record provides alternate naming + to an entire subtree of the domain name space, rather than to a + single node. It causes some suffix of a queried name to be + substituted with a name from the DNAME record's RDATA. + + For example, a resolver or server providing recursion, while looking + up a QNAME a.b.c.d.e.f may encounter a DNAME record + + d.e.f. DNAME w.xy. + + which will cause it to look for a.b.c.w.xy. + + + + + + + + + +Expires June 20, 1999 Crawford et al. [Page 4] + +Internet Draft IPv6 DNS December 15, 1998 + + +4. Specifications + + +4.1. The A6 Record Type + + The A6 record type is specific to the IN (Internet) class and has + type number 38 (decimal). + + +4.1.1. Format + + The RDATA portion of the A6 record contains two or three fields. + + +-----------+------------------+-------------------+ + |Prefix len.| Address suffix | Prefix name | + | (1 octet) | (0..16 octets) | (0..255 octets) | + +-----------+------------------+-------------------+ + + + o A prefix length, encoded as an eight-bit unsigned integer with + value between 0 and 128 inclusive. + + o An IPv6 address suffix, encoded in network order (high-order + octet first). There MUST be exactly enough octets in this field + to contain a number of bits equal to 128 minus prefix length, + with 0 to 7 leading pad bits to make this field an integral + number of octets. + + o The name of the prefix, encoded as a domain name. This name + MUST NOT be compressed unless some future specification permits + it, and then possibly only under certain circumstances. + + The domain name component SHALL NOT be present if the prefix length + is zero. The address suffix component SHALL NOT be present if the + prefix length is 128. + + It is SUGGESTED that an A6 record intended for use as a prefix for + other A6 records have all the insignificant trailing bits in its + address suffix field set to zero. + + +4.1.2. Processing + + A query with QTYPE=A6 causes type A and type AAAA additional section + processing for the QNAME, and type A6 and type NS additional section + processing for the DNS name, if present, in its RDATA field. When + and if the type AAAA record becomes deprecated, the type AAAA + additional section processing for type A6 queries SHOULD be omitted + + + +Expires June 20, 1999 Crawford et al. [Page 5] + +Internet Draft IPv6 DNS December 15, 1998 + + + from new implementations of this specification. + + It is an error for a A6 record with prefix length L1 > 0 to refer to + a domain name which owns a A6 record with a prefix length L2 > L1. + If such a situation is encountered by a resolver, the A6 record with + the offending (larger) prefix length MUST be ignored. Robustness + precludes signalling an error if addresses can still be formed from + valid A6 records, but it is SUGGESTED that zone maintainers from + time to time check all the A6 records their zones reference. + + +4.1.3. Textual Representation + + The textual representation of the RDATA portion of the A6 resource + record in a zone file comprises two or three fields separated by + whitespace. + + o A prefix length, represented as a decimal number between 0 and + 128 inclusive, + + o the textual representation of the host's IPv6 address as defined + in [AARCH], or a suffix of that address, and + + o a domain name, if the prefix length is not zero. + + The domain name MUST be absent if the prefix length is zero. The + IPv6 address MAY be be absent if the prefix length is 128. A number + of leading address bits equal to the prefix length SHOULD be zero, + either implicitly (through the :: notation) or explicitly, as + specified in section 4.1.1. + + +4.1.4. Name Resolution Procedure + + To obtain the IPv6 address or addresses which belong to a given + hostname, a DNS client MUST obtain one or more complete chains of A6 + records, each chain beginning with a record owned by the given + hostname and including a record owned by the prefix name in that + record, and so on recursively, ending with an A6 record with a + prefix length of zero. One IPv6 address is formed from one such + chain by taking the value of each bit position from the earliest A6 + record which validly covers that position, as indicated by the + prefix length. The set of all IPv6 records for the given hostname + comprises the addresses formed from all complete chains of A6 + records beginning at that hostname, discarding records which have + invalid prefix lengths as defined in section 4.1.2. + + + + + +Expires June 20, 1999 Crawford et al. [Page 6] + +Internet Draft IPv6 DNS December 15, 1998 + + +4.2. Zone Structure for Reverse Lookups + + Very little of the new scheme's data actually appears under IP6.INT; + only the first level of delegation needs to be under that domain. + More levels of delegation could be placed under IP6.INT if some + top-level delegations were done via NS records instead of DNAME + records, but this would incur some cost in renumbering ease at the + level of TLAs [AGGR]. Therefore, it is declared here that all + address space delegations SHOULD be done by the DNAME mechanism + rather than NS. + + In addition, since uniformity in deployment will simplify + maintenance of address delegations, it is SUGGESTED that address and + prefix information be stored immediately below a DNS label "IP6". + Stated another way, conformance with this suggestion would mean that + "IP6" is the first label in the RDATA field of DNAME records which + support IPv6 reverse lookups. + + When any "reserved" or "must be zero" bits are adjacent to a + delegation boundary, the higher-level entity MUST retain those bits + in its own control and delegate only the bits over which the lower- + level entity has authority. + + To find the name of a node given its IPv6 address, a DNS client MUST + perform a query with QCLASS=IN, QTYPE=PTR on the name formed from + the 128 bit address as one or more bit-string labels [BITLBL], + followed by the two standard labels "IP6.INT". If recursive service + was not obtained from a server and the desired PTR record was not + returned, the resolver MUST handle returned DNAME records as + specified in [DNAME] and iterate. + + +5. Modifications to Existing Query Types + + All existing query types that perform type A additional section + processing, i.e. the name server (NS), mail exchange (MX), and + mailbox (MB) query types, and the experimental AFS data base (AFSDB) + and route through (RT) types, must be redefined to perform both type + A and type A6 additional section processing. These new definitions + mean that a name server may add any relevant IPv4 addresses and any + relevant A6 records available locally to the additional section of a + response when processing any one of the above queries. + + +6. Usage Illustrations + + This section provides examples of use of the mechanisms defined in + the previous section. All addresses and domains mentioned here are + + + +Expires June 20, 1999 Crawford et al. [Page 7] + +Internet Draft IPv6 DNS December 15, 1998 + + + intended to be fictitious and for illustrative purposes only. + Example delegations will be on 4-bit boundaries solely for + readability; this specification is indifferent to bit alignment. + + Use of the IPv6 aggregatable address format [AGGR] is assumed in the + examples. + + +6.1. A6 Record Chains + + Let's take the example of a site X that is multi-homed to two + "intermediate" providers A and B. The provider A is itself multi- + homed to two "transit" providers, C and D. The provider B gets its + transit service from a single provider, E. For simplicity suppose + that C, D and E all belong to the same top-level aggregate (TLA) + with identifier (including format prefix) '2345', and the TLA + authority at ALPHA-TLA.ORG assigns to C, D and E respectively the + next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 + and 2345:000E::/32. + + C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the + prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to + B. + + A assigns to X the subscriber identification '11' and B assigns the + subscriber identification '22'. As a result, the site X inherits + three address prefixes: + + o 2345:00C1:CA11::/48 from A, for routes through C. + o 2345:00D2:DA11::/48 from A, for routes through D. + o 2345:000E:EB22::/48 from B, for routes through E. + + Let us suppose that N is a node in the site X, that it is assigned + to subnet number 1 in this site, and that it uses the interface + identifier '1234:5678:9ABC:DEF0'. In our configuration, this node + will have three addresses: + + o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 + o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 + o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 + + We will assume that the site X is represented in the DNS by the + domain name X.EXAMPLE, while A, B, C, D and E are represented by + A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we + assume a subdomain "IP6" that will hold the corresponding prefixes. + The node N is identified by the domain name N.X.EXAMPLE. The + + + + + +Expires June 20, 1999 Crawford et al. [Page 8] + +Internet Draft IPv6 DNS December 15, 1998 + + + following records would then appear in X's DNS. + + $ORIGIN X.EXAMPLE. + N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 + SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 + IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. + IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. + + And elsewhere there would appear + + SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. + SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET. + + SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET. + + A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG. + + A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG. + + B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG. + + C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: + D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: + E.NET.ALPHA-TLA.ORG. A6 0 2345:000E:: + + Several more-or-less arbitrary assumptions are reflected in the + above structure. All of the following choices could have been made + differently, according to someone's notion of convenience or an + agreement between two parties. + + First, that site X has chosen to put subnet information in a + separate A6 record rather than incorporate it into each node's + A6 records. + + Second, that site X is referred to as "SUBSCRIBER-X" by both of + its providers A and B. + + Third, that site X chose to indirect its provider information + through A6 records at IP6.X.EXAMPLE containing no significant + bits. An alternative would have been to replicate each subnet + record for each provider. + + Fourth, B and E used a slightly different prefix naming + convention between themselves than did A, C and D. Each + hierarchical pair of network entities must arrange this naming + between themselves. + + Fifth, that the upward prefix referral chain topped out at + + + +Expires June 20, 1999 Crawford et al. [Page 9] + +Internet Draft IPv6 DNS December 15, 1998 + + + ALPHA-TLA.ORG. There could have been another level which + assigned the TLA values and holds A6 records containing those + bits. + + Finally, the above structure reflects an assumption that address + fields assigned by a given entity are recorded only in A6 records + held by that entity. Those bits could be entered into A6 records in + the lower-level entity's zone instead, thus: + + IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET. + IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET. + + IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET. + and so on. + + + Or the higher-level entity could hold both sorts of A6 records and + allow the lower-level entity to choose to record a copy of the + delegated bits or refer to the higher-level entity's copy. But the + general rule of avoiding data duplication suggests that the proper + place to store assigned values is with the entity that assigned + them. + + It is possible, but not necessarily recommended, for a zone + maintainer to forego the renumbering support afforded by the chaning + of A6 records and to record entire IPv6 addresses within one zone + file. + + +6.2. Reverse Mapping Zones + + Supposing that address space assignments in the TLAs with Format + Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in + zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then + the IP6.INT zone would include + + $ORIGIN IP6.INT. + \[x234500/24] DNAME IP6.ALPHA-TLA.ORG. + \[x267800/24] DNAME IP6.BRAVO-TLA.ORG. + \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY. + + Eight trailing zero bits have been included in each TLA ID to + reflect the eight reserved bits in the current aggregatable global + unicast addresses format [AGGR]. + + + + + + + +Expires June 20, 1999 Crawford et al. [Page 10] + +Internet Draft IPv6 DNS December 15, 1998 + + +6.2.1. The TLA level + + ALPHA-TLA's assignments to network providers C, D and E are + reflected in the reverse data as follows. + + \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. + \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET. + \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET. + + + +6.2.2. The ISP level + + The providers A through E carry the following delegation information + in their zone files. + + \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. + \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET. + \[xEB/8].IP6.E.NET. DNAME IP6.B.NET. + \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. + \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE. + + Note that some domain names appear in the RDATA of more than one + DNAME record. In those cases, one zone is being used to map + multiple prefixes. + + +6.2.3. The Site Level + + Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to- + name translations. This domain is now referenced by two different + DNAME records held by two different providers. + + $ORIGIN IP6.X.EXAMPLE. + \[x0001/16] DNAME SUBNET-1 + \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE. + and so on. + + SUBNET-1 need not have been named in a DNAME record; the subnet bits + could have been joined with the interface identifier. But if + subnets are treated alike in both the A6 records and in the reverse + zone, it will always be possible to keep the forward and reverse + definition data for each prefix in one zone. + + + + + + + + +Expires June 20, 1999 Crawford et al. [Page 11] + +Internet Draft IPv6 DNS December 15, 1998 + + +6.3. Lookups + + A DNS resolver looking for a hostname for the address + 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the + DNAME records shown above and would form new queries. Assuming that + it began the process knowing servers for IP6.INT, but that no server + it consulted provided recursion and none had other useful additional + information cached, the sequence of queried names and responses + would be (all with QCLASS=IN, QTYPE=PTR): + + To a server for IP6.INT: + QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.INT. + + Answer: + \[x234500/24].IP6.INT. DNAME IP6.ALPHA-TLA.ORG. + + To a server for IP6.ALPHA-TLA.ORG: + QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG. + + Answer: + \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. + + To a server for IP6.C.NET.: + QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET. + + Answer: + \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. + + To a server for IP6.A.NET.: + QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET. + + Answer: + \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. + + To a server for IP6.X.EXAMPLE.: + QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE. + + Answer: + \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE. + \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE. + + All the DNAME (and NS) records acquired along the way can be cached + to expedite resolution of addresses topologically near to this + address. And if another global address of N.X.EXAMPLE were resolved + within the TTL of the final PTR record, that record would not have + to be fetched again. + + + + + +Expires June 20, 1999 Crawford et al. [Page 12] + +Internet Draft IPv6 DNS December 15, 1998 + + +6.4. Deployment Note + + In the illustrations in section 6.1, hierarchically adjacent + entities, such as a network provider and a customer, must agree on a + DNS name which will own the definition of the delegated prefix(es). + One simple convention would be to use a bit-string label + representing exactly the bits which are assigned to the lower-level + entity by the higher. For example, "SUBSCRIBER-X" could be replaced + by "\[x11/8]". This would place the A6 record(s) defining the + delegated prefix at exactly the same point in the DNS tree as the + DNAME record associated with that delegation. The cost of this + simplification is that the lower-level zone must update its upward- + pointing A6 records when it is renumbered. This cost may be found + quite acceptable in practice. + + +7. Transition from AAAA Records + + Administrators of zones which contain A6 records can easily + accommodate deployed resolvers which understand AAAA records but not + A6 records. Such administrators can do automatic generation of AAAA + records for all of a zone's names which own A6 records by a process + which mimics the resolution of a hostname to an IPv6 address (see + section 4.1.4). Attention must be paid to the TTL assigned to a + generated AAAA record, which MUST be no more than the minimum of the + TTLs of the A6 records that were used to form the IPv6 address in + that records If the zone is secure [DNSSEC], the generated AAAA + records SHOULD be signed along with the rest of the zone data. + + A zone-specific heuristic MAY be used to avoid generation of AAAA + records for A6 records which record prefixes, although such + superfluous records would be relatively few in number and harmless. + Examples of such heuristics include omitting A6 records with a + prefix length less than the largest value found in the zone file, or + records with an address suffix field with a certain number of + trailing zero bits. + + A server providing recursive service MAY be configurable to + synthesize AAAA records from A6 records in response to clients' AAAA + queries. + + +8. Security Considerations + + The signing authority [DNSSEC] for the A6 records which determine an + IPv6 address is distributed among several entities, reflecting the + delegation path of the address space which that address occupies. + DNS Security is fully applicable to bit-string labels and DNAME + + + +Expires June 20, 1999 Crawford et al. [Page 13] + +Internet Draft IPv6 DNS December 15, 1998 + + + records. However, just as with IPv4's IN-ADDR.ARPA, authentication + of data in the reverse zones is not equivalent to authentication of + any forward data. + + +9. Acknowledgments + + The authors would like to thank the following persons for valuable + discussions and reviews: Jim Bound, Steve Deering, Robert Elz, Bob + Fink, Olafur Gudmundsson, Bob Hinden, Bill Manning, Mike O'Dell and + Ken Powell. + + +10. References + + + [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373. + + [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 + Aggregatable Global Unicast Address Format". RFC 2374. + + [BITLBL] Crawford, M., "Binary Labels in the Domain Name System", + currently draft-ietf-dnsind-binary-labels-03.txt. + + [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", + currently draft-ietf-dnsind-dname-00.txt. + + [DNSCF] Mockapetris, P. V., "Domain names - concepts and + facilities", RFC 1034. + + [DNSIS] Mockapetris, P. V., "Domain names - implementation and + specification", RFC 1035. + + [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System + Security Extensions", RFC 2065. + + [KWORD] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels," RFC 2119. + + [LOCOMP] Koch, P., "A New Scheme for the Compression of Domain + Names", currently draft-ietf-dnsind-local-compression- + 01.txt. + + [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for + + + + + + +Expires June 20, 1999 Crawford et al. [Page 14] + +Internet Draft IPv6 DNS December 15, 1998 + + + IPv6 Hosts and Routers", RFC 1933. + +11. Authors' Addresses + + Matt Crawford Christian Huitema Susan Thomson + Fermilab Bellcore Bellcore + MS 368 MCC 1J236B MCC 1C259B + PO Box 500 445 South Street 445 South Street + Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960 + USA USA USA + + +1 630 840-3461 +1 201 829-4266 +1 201 829-4514 + crawdad@fnal.gov huitema@bellcore.com set@bellcore.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires June 20, 1999 Crawford et al. [Page 15] + diff --git a/doc/rfc/rfc1032.txt b/doc/rfc/rfc1032.txt new file mode 100644 index 0000000000..0e82721cee --- /dev/null +++ b/doc/rfc/rfc1032.txt @@ -0,0 +1,781 @@ +Network Working Group M. Stahl +Request for Comments: 1032 SRI International + November 1987 + + + DOMAIN ADMINISTRATORS GUIDE + + +STATUS OF THIS MEMO + + This memo describes procedures for registering a domain with the + Network Information Center (NIC) of Defense Data Network (DDN), and + offers guidelines on the establishment and administration of a domain + in accordance with the requirements specified in RFC-920. It is + intended for use by domain administrators. This memo should be used + in conjunction with RFC-920, which is an official policy statement of + the Internet Activities Board (IAB) and the Defense Advanced Research + Projects Agency (DARPA). Distribution of this memo is unlimited. + +BACKGROUND + + Domains are administrative entities that provide decentralized + management of host naming and addressing. The domain-naming system + is distributed and hierarchical. + + The NIC is designated by the Defense Communications Agency (DCA) to + provide registry services for the domain-naming system on the DDN and + DARPA portions of the Internet. + + As registrar of top-level and second-level domains, as well as + administrator of the root domain name servers on behalf of DARPA and + DDN, the NIC is responsible for maintaining the root server zone + files and their binary equivalents. In addition, the NIC is + responsible for administering the top-level domains of "ARPA," "COM," + "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it + becomes feasible for other appropriate organizations to assume those + responsibilities. + + It is recommended that the guidelines described in this document be + used by domain administrators in the establishment and control of + second-level domains. + +THE DOMAIN ADMINISTRATOR + + The role of the domain administrator (DA) is that of coordinator, + manager, and technician. If his domain is established at the second + level or lower in the tree, the DA must register by interacting with + the management of the domain directly above his, making certain that + + + +Stahl [Page 1] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + his domain satisfies all the requirements of the administration under + which his domain would be situated. To find out who has authority + over the name space he wishes to join, the DA can ask the NIC + Hostmaster. Information on contacts for the top-level and second- + level domains can also be found on line in the file NETINFO:DOMAIN- + CONTACTS.TXT, which is available from the NIC via anonymous FTP. + + The DA should be technically competent; he should understand the + concepts and procedures for operating a domain server, as described + in RFC-1034, and make sure that the service provided is reliable and + uninterrupted. It is his responsibility or that of his delegate to + ensure that the data will be current at all times. As a manager, the + DA must be able to handle complaints about service provided by his + domain name server. He must be aware of the behavior of the hosts in + his domain, and take prompt action on reports of problems, such as + protocol violations or other serious misbehavior. The administrator + of a domain must be a responsible person who has the authority to + either enforce these actions himself or delegate them to someone + else. + + Name assignments within a domain are controlled by the DA, who should + verify that names are unique within his domain and that they conform + to standard naming conventions. He furnishes access to names and + name-related information to users both inside and outside his domain. + He should work closely with the personnel he has designated as the + "technical and zone" contacts for his domain, for many administrative + decisions will be made on the basis of input from these people. + +THE DOMAIN TECHNICAL AND ZONE CONTACT + + A zone consists of those contiguous parts of the domain tree for + which a domain server has complete information and over which it has + authority. A domain server may be authoritative for more than one + zone. The domain technical/zone contact is the person who tends to + the technical aspects of maintaining the domain's name server and + resolver software, and database files. He keeps the name server + running, and interacts with technical people in other domains and + zones to solve problems that affect his zone. + +POLICIES + + Domain or host name choices and the allocation of domain name space + are considered to be local matters. In the event of conflicts, it is + the policy of the NIC not to get involved in local disputes or in the + local decision-making process. The NIC will not act as referee in + disputes over such matters as who has the "right" to register a + particular top-level or second-level domain for an organization. The + NIC considers this a private local matter that must be settled among + + + +Stahl [Page 2] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + the parties involved prior to their commencing the registration + process with the NIC. Therefore, it is assumed that the responsible + person for a domain will have resolved any local conflicts among the + members of his domain before registering that domain with the NIC. + The NIC will give guidance, if requested, by answering specific + technical questions, but will not provide arbitration in disputes at + the local level. This policy is also in keeping with the distributed + hierarchical nature of the domain-naming system in that it helps to + distribute the tasks of solving problems and handling questions. + + Naming conventions for hosts should follow the rules specified in + RFC-952. From a technical standpoint, domain names can be very long. + Each segment of a domain name may contain up to 64 characters, but + the NIC strongly advises DAs to choose names that are 12 characters + or fewer, because behind every domain system there is a human being + who must keep track of the names, addresses, contacts, and other data + in a database. The longer the name, the more likely the data + maintainer is to make a mistake. Users also will appreciate shorter + names. Most people agree that short names are easier to remember and + type; most domain names registered so far are 12 characters or fewer. + + Domain name assignments are made on a first-come-first-served basis. + The NIC has chosen not to register individual hosts directly under + the top-level domains it administers. One advantage of the domain + naming system is that administration and data maintenance can be + delegated down a hierarchical tree. Registration of hosts at the + same level in the tree as a second-level domain would dilute the + usefulness of this feature. In addition, the administrator of a + domain is responsible for the actions of hosts within his domain. We + would not want to find ourselves in the awkward position of policing + the actions of individual hosts. Rather, the subdomains registered + under these top-level domains retain the responsibility for this + function. + + Countries that wish to be registered as top-level domains are + required to name themselves after the two-letter country code listed + in the international standard ISO-3166. In some cases, however, the + two-letter ISO country code is identical to a state code used by the + U.S. Postal Service. Requests made by countries to use the three- + letter form of country code specified in the ISO-3166 standard will + be considered in such cases so as to prevent possible conflicts and + confusion. + + + + + + + + + +Stahl [Page 3] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + +HOW TO REGISTER + + Obtain a domain questionnaire from the NIC hostmaster, or FTP the + file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA. + + Fill out the questionnaire completely. Return it via electronic mail + to HOSTMASTER@SRI-NIC.ARPA. + + The APPENDIX to this memo contains the application form for + registering a top-level or second-level domain with the NIC. It + supersedes the version of the questionnaire found in RFC-920. The + application should be submitted by the person administratively + responsible for the domain, and must be filled out completely before + the NIC will authorize establishment of a top-level or second-level + domain. The DA is responsible for keeping his domain's data current + with the NIC or with the registration agent with which his domain is + registered. For example, the CSNET and UUCP managements act as + domain filters, processing domain applications for their own + organizations. They pass pertinent information along periodically to + the NIC for incorporation into the domain database and root server + files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT + outlines this procedure. It is highly recommended that the DA review + this information periodically and provide any corrections or + additions. Corrections should be submitted via electronic mail. + +WHICH DOMAIN NAME? + + The designers of the domain-naming system initiated several general + categories of names as top-level domain names, so that each could + accommodate a variety of organizations. The current top-level + domains registered with the DDN Network Information Center are ARPA, + COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country + domains. To join one of these, a DA needs to be aware of the purpose + for which it was intended. + + "ARPA" is a temporary domain. It is by default appended to the + names of hosts that have not yet joined a domain. When the system + was begun in 1984, the names of all hosts in the Official DoD + Internet Host Table maintained by the NIC were changed by adding + of the label ".ARPA" in order to accelerate a transition to the + domain-naming system. Another reason for the blanket name changes + was to force hosts to become accustomed to using the new style + names and to modify their network software, if necessary. This + was done on a network-wide basis and was directed by DCA in DDN + Management Bulletin No. 22. Hosts that fall into this domain will + eventually move to other branches of the domain tree. + + + + + +Stahl [Page 4] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + "COM" is meant to incorporate subdomains of companies and + businesses. + + "EDU" was initiated to accommodate subdomains set up by + universities and other educational institutions. + + "GOV" exists to act as parent domain for subdomains set up by + government agencies. + + "MIL" was initiated to act as parent to subdomains that are + developed by military organizations. + + "NET" was introduced as a parent domain for various network-type + organizations. Organizations that belong within this top-level + domain are generic or network-specific, such as network service + centers and consortia. "NET" also encompasses network + management-related organizations, such as information centers and + operations centers. + + "ORG" exists as a parent to subdomains that do not clearly fall + within the other top-level domains. This may include technical- + support groups, professional societies, or similar organizations. + + One of the guidelines in effect in the domain-naming system is that a + host should have only one name regardless of what networks it is + connected to. This implies, that, in general, domain names should + not include routing information or addresses. For example, a host + that has one network connection to the Internet and another to BITNET + should use the same name when talking to either network. For a + description of the syntax of domain names, please refer to Section 3 + of RFC-1034. + +VERIFICATION OF DATA + + The verification process can be accomplished in several ways. One of + these is through the NIC WHOIS server. If he has access to WHOIS, + the DA can type the command "whois domain ". + 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 + + 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 ". 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] + diff --git a/doc/rfc/rfc1033.txt b/doc/rfc/rfc1033.txt new file mode 100644 index 0000000000..37029fd9ae --- /dev/null +++ b/doc/rfc/rfc1033.txt @@ -0,0 +1,1229 @@ +Network Working Group M. Lottor +Request For Comments: 1033 SRI International + November 1987 + + + DOMAIN ADMINISTRATORS OPERATIONS GUIDE + + + +STATUS OF THIS MEMO + + This RFC provides guidelines for domain administrators in operating a + domain server and maintaining their portion of the hierarchical + database. Familiarity with the domain system is assumed. + Distribution of this memo is unlimited. + +ACKNOWLEDGMENTS + + This memo is a formatted collection of notes and excerpts from the + references listed at the end of this document. Of particular mention + are Paul Mockapetris and Kevin Dunlap. + +INTRODUCTION + + A domain server requires a few files to get started. It will + normally have some number of boot/startup files (also known as the + "safety belt" files). One section will contain a list of possible + root servers that the server will use to find the up-to-date list of + root servers. Another section will list the zone files to be loaded + into the server for your local domain information. A zone file + typically contains all the data for a particular domain. This guide + describes the data formats that can be used in zone files and + suggested parameters to use for certain fields. If you are + attempting to do anything advanced or tricky, consult the appropriate + domain RFC's for more details. + + Note: Each implementation of domain software may require different + files. Zone files are standardized but some servers may require + other startup files. See the appropriate documentation that comes + with your software. See the appendix for some specific examples. + +ZONES + + A zone defines the contents of a contiguous section of the domain + space, usually bounded by administrative boundaries. There will + typically be a separate data file for each zone. The data contained + in a zone file is composed of entries called Resource Records (RRs). + + + + +Lottor [Page 1] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + You may only put data in your domain server that you are + authoritative for. You must not add entries for domains other than + your own (except for the special case of "glue records"). + + A domain server will probably read a file on start-up that lists the + zones it should load into its database. The format of this file is + not standardized and is different for most domain server + implementations. For each zone it will normally contain the domain + name of the zone and the file name that contains the data to load for + the zone. + +ROOT SERVERS + + A resolver will need to find the root servers when it first starts. + When the resolver boots, it will typically read a list of possible + root servers from a file. + + The resolver will cycle through the list trying to contact each one. + When it finds a root server, it will ask it for the current list of + root servers. It will then discard the list of root servers it read + from the data file and replace it with the current list it received. + + Root servers will not change very often. You can get the names of + current root servers from the NIC. + + FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to + NIC@SRI-NIC.ARPA. + + As of this date (June 1987) they are: + + SRI-NIC.ARPA 10.0.0.51 26.0.0.73 + C.ISI.EDU 10.0.0.52 + BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 + A.ISI.EDU 26.3.0.103 + +RESOURCE RECORDS + + Records in the zone data files are called resource records (RRs). + They are specified in RFC-883 and RFC-973. An RR has a standard + format as shown: + + [] [] + + The record is divided into fields which are separated by white space. + + + + The name field defines what domain name applies to the given + + + +Lottor [Page 2] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + RR. In some cases the name field can be left blank and it will + default to the name field of the previous RR. + + + + TTL stands for Time To Live. It specifies how long a domain + resolver should cache the RR before it throws it out and asks a + domain server again. See the section on TTL's. If you leave + the TTL field blank it will default to the minimum time + specified in the SOA record (described later). + + + + The class field specifies the protocol group. If left blank it + will default to the last class specified. + + + + The type field specifies what type of data is in the RR. See + the section on types. + + + + The data field is defined differently for each type and class + of data. Popular RR data formats are described later. + + The domain system does not guarantee to preserve the order of + resource records. Listing RRs (such as multiple address records) in + a certain order does not guarantee they will be used in that order. + + Case is preserved in names and data fields when loaded into the name + server. All comparisons and lookups in the name server are case + insensitive. + + Parenthesis ("(",")") are used to group data that crosses a line + boundary. + + A semicolon (";") starts a comment; the remainder of the line is + ignored. + + The asterisk ("*") is used for wildcarding. + + The at-sign ("@") denotes the current default domain name. + + + + + + + + +Lottor [Page 3] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +NAMES + + A domain name is a sequence of labels separated by dots. + + Domain names in the zone files can be one of two types, either + absolute or relative. An absolute name is the fully qualified domain + name and is terminated with a period. A relative name does not + terminate with a period, and the current default domain is appended + to it. The default domain is usually the name of the domain that was + specified in the boot file that loads each zone. + + The domain system allows a label to contain any 8-bit character. + Although the domain system has no restrictions, other protocols such + as SMTP do have name restrictions. Because of other protocol + restrictions, only the following characters are recommended for use + in a host name (besides the dot separator): + + "A-Z", "a-z", "0-9", dash and underscore + +TTL's (Time To Live) + + It is important that TTLs are set to appropriate values. The TTL is + the time (in seconds) that a resolver will use the data it got from + your server before it asks your server again. If you set the value + too low, your server will get loaded down with lots of repeat + requests. If you set it too high, then information you change will + not get distributed in a reasonable amount of time. If you leave the + TTL field blank, it will default to what is specified in the SOA + record for the zone. + + Most host information does not change much over long time periods. A + good way to set up your TTLs would be to set them at a high value, + and then lower the value if you know a change will be coming soon. + You might set most TTLs to anywhere between a day (86400) and a week + (604800). Then, if you know some data will be changing in the near + future, set the TTL for that RR down to a lower value (an hour to a + day) until the change takes place, and then put it back up to its + previous value. + + Also, all RRs with the same name, class, and type should have the + same TTL value. + +CLASSES + + The domain system was designed to be protocol independent. The class + field is used to identify the protocol group that each RR is in. + + The class of interest to people using TCP/IP software is the class + + + +Lottor [Page 4] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + "Internet". Its standard designation is "IN". + + A zone file should only contain RRs of the same class. + +TYPES + + There are many defined RR types. For a complete list, see the domain + specification RFCs. Here is a list of current commonly used types. + The data for each type is described in the data section. + + Designation Description + ========================================== + SOA Start Of Authority + NS Name Server + + A Internet Address + CNAME Canonical Name (nickname pointer) + HINFO Host Information + WKS Well Known Services + + MX Mail Exchanger + + PTR Pointer + +SOA (Start Of Authority) + + [] [] SOA ( + + + + + ) + + The Start Of Authority record designates the start of a zone. The + zone ends at the next SOA record. + + is the name of the zone. + + is the name of the host on which the master zone file + resides. + + is a mailbox for the person responsible for the zone. It is + formatted like a mailing address but the at-sign that normally + separates the user from the host name is replaced with a dot. + + is the version number of the zone file. It should be + incremented anytime a change is made to data in the zone. + + + + +Lottor [Page 5] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + is how long, in seconds, a secondary name server is to + check with the primary name server to see if an update is needed. A + good value here would be one hour (3600). + + is how long, in seconds, a secondary name server is to retry + after a failure to check for a refresh. A good value here would be + 10 minutes (600). + + is the upper limit, in seconds, that a secondary name server + is to use the data before it expires for lack of getting a refresh. + You want this to be rather large, and a nice value is 3600000, about + 42 days. + + is the minimum number of seconds to be used for TTL values + in RRs. A minimum of at least a day is a good value here (86400). + + There should only be one SOA record per zone. A sample SOA record + would look something like: + + @ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( + 45 ;serial + 3600 ;refresh + 600 ;retry + 3600000 ;expire + 86400 ) ;minimum + + +NS (Name Server) + + [] [] NS + + The NS record lists the name of a machine that provides domain + service for a particular domain. The name associated with the RR is + the domain name and the data portion is the name of a host that + provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provide + name lookup service for the domain COM then the following entries + would be used: + + COM. NS SRI-NIC.ARPA. + NS C.ISI.EDU. + + Note that the machines providing name service do not have to live in + the named domain. There should be one NS record for each server for + a domain. Also note that the name "COM" defaults for the second NS + record. + + NS records for a domain exist in both the zone that delegates the + domain, and in the domain itself. + + + +Lottor [Page 6] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +GLUE RECORDS + + If the name server host for a particular domain is itself inside the + domain, then a 'glue' record will be needed. A glue record is an A + (address) RR that specifies the address of the server. Glue records + are only needed in the server delegating the domain, not in the + domain itself. If for example the name server for domain SRI.COM was + KL.SRI.COM, then the NS record would look like this, but you will + also need to have the following A record. + + SRI.COM. NS KL.SRI.COM. + KL.SRI.COM. A 10.1.0.2 + + +A (Address) + + [] [] A
+ + The data for an A record is an internet address in dotted decimal + form. A sample A record might look like: + + SRI-NIC.ARPA. A 10.0.0.51 + + There should be one A record for each address of a host. + +CNAME ( Canonical Name) + + [] [] CNAME + + The CNAME record is used for nicknames. The name associated with the + RR is the nickname. The data portion is the official name. For + example, a machine named SRI-NIC.ARPA may want to have the nickname + NIC.ARPA. In that case, the following RR would be used: + + NIC.ARPA. CNAME SRI-NIC.ARPA. + + There must not be any other RRs associated with a nickname of the + same class. + + Nicknames are also useful when a host changes it's name. In that + case, it is usually a good idea to have a CNAME pointer so that + people still using the old name will get to the right place. + + + + + + + + + +Lottor [Page 7] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +HINFO (Host Info) + + [] [] HINFO + + The HINFO record gives information about a particular host. The data + is two strings separated by whitespace. The first string is a + hardware description and the second is software. The hardware is + usually a manufacturer name followed by a dash and model designation. + The software string is usually the name of the operating system. + + Official HINFO types can be found in the latest Assigned Numbers RFC, + the latest of which is RFC-1010. The Hardware type is called the + Machine name and the Software type is called the System name. + + Some sample HINFO records: + + SRI-NIC.ARPA. HINFO DEC-2060 TOPS20 + UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX + + +WKS (Well Known Services) + + [] [] WKS
+ + The WKS record is used to list Well Known Services a host provides. + WKS's are defined to be services on port numbers below 256. The WKS + record lists what services are available at a certain address using a + certain protocol. The common protocols are TCP or UDP. A sample WKS + record for a host offering the same services on all address would + look like: + + Official protocol names can be found in the latest Assigned Numbers + RFC, the latest of which is RFC-1010. + + SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP + WKS 10.0.0.51 UDP TIME + WKS 26.0.0.73 TCP TELNET FTP SMTP + WKS 26.0.0.73 UDP TIME + +MX (Mail Exchanger) (See RFC-974 for more details.) + + [] [] MX + + MX records specify where mail for a domain name should be delivered. + There may be multiple MX records for a particular name. The + preference value specifies the order a mailer should try multiple MX + records when delivering mail. Zero is the highest preference. + Multiple records for the same name may have the same preference. + + + +Lottor [Page 8] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + A host BAR.FOO.COM may want its mail to be delivered to the host + PO.FOO.COM and would then use the MX record: + + BAR.FOO.COM. MX 10 PO.FOO.COM. + + A host BAZ.FOO.COM may want its mail to be delivered to one of three + different machines, in the following order: + + BAZ.FOO.COM. MX 10 PO1.FOO.COM. + MX 20 PO2.FOO.COM. + MX 30 PO3.FOO.COM. + + An entire domain of hosts not connected to the Internet may want + their mail to go through a mail gateway that knows how to deliver + mail to them. If they would like mail addressed to any host in the + domain FOO.COM to go through the mail gateway they might use: + + FOO.COM. MX 10 RELAY.CS.NET. + *.FOO.COM. MX 20 RELAY.CS.NET. + + Note that you can specify a wildcard in the MX record to match on + anything in FOO.COM, but that it won't match a plain FOO.COM. + +IN-ADDR.ARPA + + The structure of names in the domain system is set up in a + hierarchical way such that the address of a name can be found by + tracing down the domain tree contacting a server for each label of + the name. Because of this 'indexing' based on name, there is no easy + way to translate a host address back into its host name. + + In order to do the reverse translation easily, a domain was created + that uses hosts' addresses as part of a name that then points to the + data for that host. In this way, there is now an 'index' to hosts' + RRs based on their address. This address mapping domain is called + IN-ADDR.ARPA. Within that domain are subdomains for each network, + based on network number. Also, for consistency and natural + groupings, the 4 octets of a host number are reversed. + + For example, the ARPANET is net 10. That means there is a domain + called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at + 51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA + (who's address is 10.0.0.51). Since the NIC is also on the MILNET + (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN- + ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The format + of these special pointers is defined below along with the examples + for the NIC. + + + + +Lottor [Page 9] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +PTR + + [] [] PTR + + The PTR record is used to let special names point to some other + location in the domain tree. They are mainly used in the IN- + ADDR.ARPA records for translation of addresses to names. PTR's + should use official names and not aliases. + + For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73 + would have the following records in the respective zone files for net + 10 and net 26: + + 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. + 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. + +GATEWAY PTR's + + The IN-ADDR tree is also used to locate gateways on a particular + network. Gateways have the same kind of PTR RRs as hosts (as above) + but in addition they have other PTRs used to locate them by network + number alone. These records have only 1, 2, or 3 octets as part of + the name depending on whether they are class A, B, or C networks, + respectively. + + Lets take the SRI-CSL gateway for example. It connects 3 different + networks, one class A, one class B and one class C. It will have the + standard RR's for a host in the CSL.SRI.COM zone: + + GW.CSL.SRI.COM. A 10.2.0.2 + A 128.18.1.1 + A 192.12.33.2 + + Also, in 3 different zones (one for each network), it will have one + of the following number to name translation pointers: + + 2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + + In addition, in each of the same 3 zones will be one of the following + gateway location pointers: + + 10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + + + + + +Lottor [Page 10] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +INSTRUCTIONS + + Adding a subdomain. + + To add a new subdomain to your domain: + + Setup the other domain server and/or the new zone file. + + Add an NS record for each server of the new domain to the zone + file of the parent domain. + + Add any necessary glue RRs. + + Adding a host. + + To add a new host to your zone files: + + Edit the appropriate zone file for the domain the host is in. + + Add an entry for each address of the host. + + Optionally add CNAME, HINFO, WKS, and MX records. + + Add the reverse IN-ADDR entry for each host address in the + appropriate zone files for each network the host in on. + + Deleting a host. + + To delete a host from the zone files: + + Remove all the hosts' resource records from the zone file of + the domain the host is in. + + Remove all the hosts' PTR records from the IN-ADDR zone files + for each network the host was on. + + Adding gateways. + + Follow instructions for adding a host. + + Add the gateway location PTR records for each network the + gateway is on. + + Deleting gateways. + + Follow instructions for deleting a host. + + Also delete the gateway location PTR records for each network + + + +Lottor [Page 11] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + the gateway was on. + +COMPLAINTS + + These are the suggested steps you should take if you are having + problems that you believe are caused by someone else's name server: + + + 1. Complain privately to the responsible person for the domain. You + can find their mailing address in the SOA record for the domain. + + 2. Complain publicly to the responsible person for the domain. + + 3. Ask the NIC for the administrative person responsible for the + domain. Complain. You can also find domain contacts on the NIC in + the file NETINFO:DOMAIN-CONTACTS.TXT + + 4. Complain to the parent domain authorities. + + 5. Ask the parent authorities to excommunicate the domain. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 12] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +EXAMPLE DOMAIN SERVER DATABASE FILES + + The following examples show how zone files are set up for a typical + organization. SRI will be used as the example organization. SRI has + decided to divided their domain SRI.COM into a few subdomains, one + for each group that wants one. The subdomains are CSL and ISTC. + + Note the following interesting items: + + There are both hosts and domains under SRI.COM. + + CSL.SRI.COM is both a domain name and a host name. + + All the domains are serviced by the same pair of domain servers. + + All hosts at SRI are on net 128.18 except hosts in the CSL domain + which are on net 192.12.33. Note that a domain does not have to + correspond to a physical network. + + The examples do not necessarily correspond to actual data in use + by the SRI domain. + + SRI Domain Organization + + +-------+ + | COM | + +-------+ + | + +-------+ + | SRI | + +-------+ + | + +----------++-----------+ + | | | + +-------+ +------+ +-------+ + | CSL | | ISTC | | Hosts | + +-------+ +------+ +-------+ + | | + +-------+ +-------+ + | Hosts | | Hosts | + +-------+ +-------+ + + + + + + + + + + +Lottor [Page 13] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "CONFIG.CMD". Since bootstrap files are not standardized, this + file is presented using a pseudo configuration file syntax.] + + load root server list from file ROOT.SERVERS + load zone SRI.COM. from file SRI.ZONE + load zone CSL.SRI.COM. from file CSL.ZONE + load zone ISTC.SRI.COM. from file ISTC.ZONE + load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE + load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 14] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "ROOT.SERVERS". Again, the format of this file is not + standardized.] + + ;list of possible root servers + SRI-NIC.ARPA 10.0.0.51 26.0.0.73 + C.ISI.EDU 10.0.0.52 + BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 + A.ISI.EDU 26.3.0.103 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 15] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "SRI.ZONE"] + + SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( + 870407 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of an hour + ) + + SRI.COM. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + MX 10 KL.SRI.COM. + + ;SRI.COM hosts + + KL A 10.1.0.2 + A 128.18.10.6 + MX 10 KL.SRI.COM. + + STRIPE A 10.4.0.2 + STRIPE A 128.18.10.4 + MX 10 STRIPE.SRI.COM. + + NIC CNAME SRI-NIC.ARPA. + + Blackjack A 128.18.2.1 + HINFO VAX-11/780 UNIX + WKS 128.18.2.1 TCP TELNET FTP + + CSL A 192.12.33.2 + HINFO FOONLY-F4 TOPS20 + WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER + MX 10 CSL.SRI.COM. + + + + + + + + + + + + + + + + + +Lottor [Page 16] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "CSL.ZONE"] + + CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( + 870330 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + CSL.SRI.COM. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + A 192.12.33.2 + + ;CSL.SRI.COM hosts + + A CNAME CSL.SRI.COM. + B A 192.12.33.3 + HINFO FOONLY-F4 TOPS20 + WKS 192.12.33.3 TCP TELNET FTP SMTP + GW A 10.2.0.2 + A 192.12.33.1 + A 128.18.1.1 + HINFO PDP-11/23 MOS + SMELLY A 192.12.33.4 + HINFO IMAGEN IMAGEN + SQUIRREL A 192.12.33.5 + HINFO XEROX-1100 INTERLISP + VENUS A 192.12.33.7 + HINFO SYMBOLICS-3600 LISPM + HELIUM A 192.12.33.30 + HINFO SUN-3/160 UNIX + ARGON A 192.12.33.31 + HINFO SUN-3/75 UNIX + RADON A 192.12.33.32 + HINFO SUN-3/75 UNIX + + + + + + + + + + + + + + + +Lottor [Page 17] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "ISTC.ZONE"] + + ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. ( + 870406 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + ISTC.SRI.COM. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + MX 10 SPAM.ISTC.SRI.COM. + + ; ISTC hosts + + joyce A 128.18.4.2 + HINFO VAX-11/750 UNIX + bozo A 128.18.0.6 + HINFO SUN UNIX + sundae A 128.18.0.11 + HINFO SUN UNIX + tsca A 128.18.0.201 + A 10.3.0.2 + HINFO VAX-11/750 UNIX + MX 10 TSCA.ISTC.SRI.COM. + tsc CNAME tsca + prmh A 128.18.0.203 + A 10.2.0.51 + HINFO PDP-11/44 UNIX + spam A 128.18.4.3 + A 10.2.0.107 + HINFO VAX-11/780 UNIX + MX 10 SPAM.ISTC.SRI.COM. + + + + + + + + + + + + + + + + + +Lottor [Page 18] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "SRINET.ZONE"] + + 18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( + 870406 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + 18.128.IN-ADDR.ARPA. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + PTR GW.CSL.SRI.COM. + + ; SRINET [128.18.0.0] Address Translations + + ; SRI.COM Hosts + 1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM. + + ; ISTC.SRI.COM Hosts + 2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM. + 6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM. + 11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM. + 201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM. + 203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM. + 3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM. + + ; CSL.SRI.COM Hosts + 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 19] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "SRI-CSL-NET.ZONE"] + + 33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( + 870404 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + 33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + PTR GW.CSL.SRI.COM. + + ; SRI-CSL-NET [192.12.33.0] Address Translations + + ; SRI.COM Hosts + 2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM. + + ; CSL.SRI.COM Hosts + 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 3.33.12.192.IN-ADDR.ARPA. PTR B.CSL.SRI.COM. + 4.33.12.192.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM. + 5.33.12.192.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM. + 7.33.12.192.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM. + 30.33.12.192.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM. + 31.33.12.192.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM. + 32.33.12.192.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM. + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 20] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +APPENDIX + + BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD + UNIX + + This section describes two BIND implementation specific files; the + boot file and the cache file. BIND has other options, files, and + specifications that are not described here. See the Name Server + Operations Guide for BIND for details. + + The boot file for BIND is usually called "named.boot". This + corresponds to file "CONFIG.CMD" in the example section. + + -------------------------------------------------------- + cache . named.ca + primary SRI.COM SRI.ZONE + primary CSL.SRI.COM CSL.ZONE + primary ISTC.SRI.COM ISTC.ZONE + primary 18.128.IN-ADDR.ARPA SRINET.ZONE + primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE + -------------------------------------------------------- + + The cache file for BIND is usually called "named.ca". This + corresponds to file "ROOT.SERVERS" in the example section. + + ------------------------------------------------- + ;list of possible root servers + . 1 IN NS SRI-NIC.ARPA. + NS C.ISI.EDU. + NS BRL-AOS.ARPA. + NS C.ISI.EDU. + ;and their addresses + SRI-NIC.ARPA. A 10.0.0.51 + A 26.0.0.73 + C.ISI.EDU. A 10.0.0.52 + BRL-AOS.ARPA. A 192.5.25.82 + A 192.5.22.82 + A 128.20.1.2 + A.ISI.EDU. A 26.3.0.103 + ------------------------------------------------- + + + + + + + + + + + +Lottor [Page 21] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +REFERENCES + + [1] Dunlap, K., "Name Server Operations Guide for BIND", CSRG, + Department of Electrical Engineering and Computer Sciences, + University of California, Berkeley, California. + + [2] Partridge, C., "Mail Routing and the Domain System", RFC-974, + CSNET CIC BBN Laboratories, January 1986. + + [3] Mockapetris, P., "Domains Names - Concepts and Facilities", + RFC-1034, USC/Information Sciences Institute, November 1987. + + [4] Mockapetris, P., "Domain Names - Implementations Specification", + RFC-1035, USC/Information Sciences Institute, November 1987. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 22] + diff --git a/doc/rfc/rfc1034.txt b/doc/rfc/rfc1034.txt new file mode 100644 index 0000000000..55cdb21fe6 --- /dev/null +++ b/doc/rfc/rfc1034.txt @@ -0,0 +1,3077 @@ +Network Working Group P. Mockapetris +Request for Comments: 1034 ISI +Obsoletes: RFCs 882, 883, 973 November 1987 + + + DOMAIN NAMES - CONCEPTS AND FACILITIES + + + +1. STATUS OF THIS MEMO + +This RFC is an introduction to the Domain Name System (DNS), and omits +many details which can be found in a companion RFC, "Domain Names - +Implementation and Specification" [RFC-1035]. That RFC assumes that the +reader is familiar with the concepts discussed in this memo. + +A subset of DNS functions and data types constitute an official +protocol. The official protocol includes standard queries and their +responses and most of the Internet class data formats (e.g., host +addresses). + +However, the domain system is intentionally extensible. Researchers are +continuously proposing, implementing and experimenting with new data +types, query types, classes, functions, etc. Thus while the components +of the official protocol are expected to stay essentially unchanged and +operate as a production service, experimental behavior should always be +expected in extensions beyond the official protocol. Experimental or +obsolete features are clearly marked in these RFCs, and such information +should be used with caution. + +The reader is especially cautioned not to depend on the values which +appear in examples to be current or complete, since their purpose is +primarily pedagogical. Distribution of this memo is unlimited. + +2. INTRODUCTION + +This RFC introduces domain style names, their use for Internet mail and +host address support, and the protocols and servers used to implement +domain name facilities. + +2.1. The history of domain names + +The impetus for the development of the domain system was growth in the +Internet: + + - Host name to address mappings were maintained by the Network + Information Center (NIC) in a single file (HOSTS.TXT) which + was FTPed by all hosts [RFC-952, RFC-953]. The total network + + + +Mockapetris [Page 1] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + bandwidth consumed in distributing a new version by this + scheme is proportional to the square of the number of hosts in + the network, and even when multiple levels of FTP are used, + the outgoing FTP load on the NIC host is considerable. + Explosive growth in the number of hosts didn't bode well for + the future. + + - The network population was also changing in character. The + timeshared hosts that made up the original ARPANET were being + replaced with local networks of workstations. Local + organizations were administering their own names and + addresses, but had to wait for the NIC to change HOSTS.TXT to + make changes visible to the Internet at large. Organizations + also wanted some local structure on the name space. + + - The applications on the Internet were getting more + sophisticated and creating a need for general purpose name + service. + + +The result was several ideas about name spaces and their management +[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a +common thread was the idea of a hierarchical name space, with the +hierarchy roughly corresponding to organizational structure, and names +using "." as the character to mark the boundary between hierarchy +levels. A design using a distributed database and generalized resources +was described in [RFC-882, RFC-883]. Based on experience with several +implementations, the system evolved into the scheme described in this +memo. + +The terms "domain" or "domain name" are used in many contexts beyond the +DNS described here. Very often, the term domain name is used to refer +to a name with structure indicated by dots, but no relation to the DNS. +This is particularly true in mail addressing [Quarterman 86]. + +2.2. DNS design goals + +The design goals of the DNS influence its structure. They are: + + - The primary goal is a consistent name space which will be used + for referring to resources. In order to avoid the problems + caused by ad hoc encodings, names should not be required to + contain network identifiers, addresses, routes, or similar + information as part of the name. + + - The sheer size of the database and frequency of updates + suggest that it must be maintained in a distributed manner, + with local caching to improve performance. Approaches that + + + +Mockapetris [Page 2] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + attempt to collect a consistent copy of the entire database + will become more and more expensive and difficult, and hence + should be avoided. The same principle holds for the structure + of the name space, and in particular mechanisms for creating + and deleting names; these should also be distributed. + + - Where there tradeoffs between the cost of acquiring data, the + speed of updates, and the accuracy of caches, the source of + the data should control the tradeoff. + + - The costs of implementing such a facility dictate that it be + generally useful, and not restricted to a single application. + We should be able to use names to retrieve host addresses, + mailbox data, and other as yet undetermined information. All + data associated with a name is tagged with a type, and queries + can be limited to a single type. + + - Because we want the name space to be useful in dissimilar + networks and applications, we provide the ability to use the + same name space with different protocol families or + management. For example, host address formats differ between + protocols, though all protocols have the notion of address. + The DNS tags all data with a class as well as the type, so + that we can allow parallel use of different formats for data + of type address. + + - We want name server transactions to be independent of the + communications system that carries them. Some systems may + wish to use datagrams for queries and responses, and only + establish virtual circuits for transactions that need the + reliability (e.g., database updates, long transactions); other + systems will use virtual circuits exclusively. + + - The system should be useful across a wide spectrum of host + capabilities. Both personal computers and large timeshared + hosts should be able to use the system, though perhaps in + different ways. + +2.3. Assumptions about usage + +The organization of the domain system derives from some assumptions +about the needs and usage patterns of its user community and is designed +to avoid many of the the complicated problems found in general purpose +database systems. + +The assumptions are: + + - The size of the total database will initially be proportional + + + +Mockapetris [Page 3] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + to the number of hosts using the system, but will eventually + grow to be proportional to the number of users on those hosts + as mailboxes and other information are added to the domain + system. + + - Most of the data in the system will change very slowly (e.g., + mailbox bindings, host addresses), but that the system should + be able to deal with subsets that change more rapidly (on the + order of seconds or minutes). + + - The administrative boundaries used to distribute + responsibility for the database will usually correspond to + organizations that have one or more hosts. Each organization + that has responsibility for a particular set of domains will + provide redundant name servers, either on the organization's + own hosts or other hosts that the organization arranges to + use. + + - Clients of the domain system should be able to identify + trusted name servers they prefer to use before accepting + referrals to name servers outside of this "trusted" set. + + - Access to information is more critical than instantaneous + updates or guarantees of consistency. Hence the update + process allows updates to percolate out through the users of + the domain system rather than guaranteeing that all copies are + simultaneously updated. When updates are unavailable due to + network or host failure, the usual course is to believe old + information while continuing efforts to update it. The + general model is that copies are distributed with timeouts for + refreshing. The distributor sets the timeout value and the + recipient of the distribution is responsible for performing + the refresh. In special situations, very short intervals can + be specified, or the owner can prohibit copies. + + - In any system that has a distributed database, a particular + name server may be presented with a query that can only be + answered by some other server. The two general approaches to + dealing with this problem are "recursive", in which the first + server pursues the query for the client at another server, and + "iterative", in which the server refers the client to another + server and lets the client pursue the query. Both approaches + have advantages and disadvantages, but the iterative approach + is preferred for the datagram style of access. The domain + system requires implementation of the iterative approach, but + allows the recursive approach as an option. + + + + + +Mockapetris [Page 4] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +The domain system assumes that all data originates in master files +scattered through the hosts that use the domain system. These master +files are updated by local system administrators. Master files are text +files that are read by a local name server, and hence become available +through the name servers to users of the domain system. The user +programs access name servers through standard programs called resolvers. + +The standard format of master files allows them to be exchanged between +hosts (via FTP, mail, or some other mechanism); this facility is useful +when an organization wants a domain, but doesn't want to support a name +server. The organization can maintain the master files locally using a +text editor, transfer them to a foreign host which runs a name server, +and then arrange with the system administrator of the name server to get +the files loaded. + +Each host's name servers and resolvers are configured by a local system +administrator [RFC-1033]. For a name server, this configuration data +includes the identity of local master files and instructions on which +non-local master files are to be loaded from foreign servers. The name +server uses the master files or copies to load its zones. For +resolvers, the configuration data identifies the name servers which +should be the primary sources of information. + +The domain system defines procedures for accessing the data and for +referrals to other name servers. The domain system also defines +procedures for caching retrieved data and for periodic refreshing of +data defined by the system administrator. + +The system administrators provide: + + - The definition of zone boundaries. + + - Master files of data. + + - Updates to master files. + + - Statements of the refresh policies desired. + +The domain system provides: + + - Standard formats for resource data. + + - Standard methods for querying the database. + + - Standard methods for name servers to refresh local data from + foreign name servers. + + + + + +Mockapetris [Page 5] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +2.4. Elements of the DNS + +The DNS has three major components: + + - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are + specifications for a tree structured name space and data + associated with the names. Conceptually, each node and leaf + of the domain name space tree names a set of information, and + query operations are attempts to extract specific types of + information from a particular set. A query names the domain + name of interest and describes the type of resource + information that is desired. For example, the Internet + uses some of its domain names to identify hosts; queries for + address resources return Internet host addresses. + + - NAME SERVERS are server programs which hold information about + the domain tree's structure and set information. A name + server may cache structure or set information about any part + of the domain tree, but in general a particular name server + has complete information about a subset of the domain space, + and pointers to other name servers that can be used to lead to + information from any part of the domain tree. Name servers + know the parts of the domain tree for which they have complete + information; a name server is said to be an AUTHORITY for + these parts of the name space. Authoritative information is + organized into units called ZONEs, and these zones can be + automatically distributed to the name servers which provide + redundant service for the data in a zone. + + - RESOLVERS are programs that extract information from name + servers in response to client requests. Resolvers must be + able to access at least one name server and use that name + server's information to answer a query directly, or pursue the + query using referrals to other name servers. A resolver will + typically be a system routine that is directly accessible to + user programs; hence no protocol is necessary between the + resolver and the user program. + +These three components roughly correspond to the three layers or views +of the domain system: + + - From the user's point of view, the domain system is accessed + through a simple procedure or OS call to a local resolver. + The domain space consists of a single tree and the user can + request information from any section of the tree. + + - From the resolver's point of view, the domain system is + composed of an unknown number of name servers. Each name + + + +Mockapetris [Page 6] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + server has one or more pieces of the whole domain tree's data, + but the resolver views each of these databases as essentially + static. + + - From a name server's point of view, the domain system consists + of separate sets of local information called zones. The name + server has local copies of some of the zones. The name server + must periodically refresh its zones from master copies in + local files or foreign name servers. The name server must + concurrently process queries that arrive from resolvers. + +In the interests of performance, implementations may couple these +functions. For example, a resolver on the same machine as a name server +might share a database consisting of the the zones managed by the name +server and the cache managed by the resolver. + +3. DOMAIN NAME SPACE and RESOURCE RECORDS + +3.1. Name space specifications and terminology + +The domain name space is a tree structure. Each node and leaf on the +tree corresponds to a resource set (which may be empty). The domain +system makes no distinctions between the uses of the interior nodes and +leaves, and this memo uses the term "node" to refer to both. + +Each node has a label, which is zero to 63 octets in length. Brother +nodes may not have the same label, although the same label can be used +for nodes which are not brothers. One label is reserved, and that is +the null (i.e., zero length) label used for the root. + +The domain name of a node is the list of the labels on the path from the +node to the root of the tree. By convention, the labels that compose a +domain name are printed or read left to right, from the most specific +(lowest, farthest from the root) to the least specific (highest, closest +to the root). + +Internally, programs that manipulate domain names should represent them +as sequences of labels, where each label is a length octet followed by +an octet string. Because all domain names end at the root, which has a +null string for a label, these internal representations can use a length +byte of zero to terminate a domain name. + +By convention, domain names can be stored with arbitrary case, but +domain name comparisons for all present domain functions are done in a +case-insensitive manner, assuming an ASCII character set, and a high +order zero bit. This means that you are free to create a node with +label "A" or a node with label "a", but not both as brothers; you could +refer to either using "a" or "A". When you receive a domain name or + + + +Mockapetris [Page 7] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +label, you should preserve its case. The rationale for this choice is +that we may someday need to add full binary domain names for new +services; existing services would not be changed. + +When a user needs to type a domain name, the length of each label is +omitted and the labels are separated by dots ("."). Since a complete +domain name ends with the root label, this leads to a printed form which +ends in a dot. We use this property to distinguish between: + + - a character string which represents a complete domain name + (often called "absolute"). For example, "poneria.ISI.EDU." + + - a character string that represents the starting labels of a + domain name which is incomplete, and should be completed by + local software using knowledge of the local domain (often + called "relative"). For example, "poneria" used in the + ISI.EDU domain. + +Relative names are either taken relative to a well known origin, or to a +list of domains used as a search list. Relative names appear mostly at +the user interface, where their interpretation varies from +implementation to implementation, and in master files, where they are +relative to a single origin domain name. The most common interpretation +uses the root "." as either the single origin or as one of the members +of the search list, so a multi-label relative name is often one where +the trailing dot has been omitted to save typing. + +To simplify implementations, the total number of octets that represent a +domain name (i.e., the sum of all label octets and label lengths) is +limited to 255. + +A domain is identified by a domain name, and consists of that part of +the domain name space that is at or below the domain name which +specifies the domain. A domain is a subdomain of another domain if it +is contained within that domain. This relationship can be tested by +seeing if the subdomain's name ends with the containing domain's name. +For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". + +3.2. Administrative guidelines on use + +As a matter of policy, the DNS technical specifications do not mandate a +particular tree structure or rules for selecting labels; its goal is to +be as general as possible, so that it can be used to build arbitrary +applications. In particular, the system was designed so that the name +space did not have to be organized along the lines of network +boundaries, name servers, etc. The rationale for this is not that the +name space should have no implied semantics, but rather that the choice +of implied semantics should be left open to be used for the problem at + + + +Mockapetris [Page 8] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +hand, and that different parts of the tree can have different implied +semantics. For example, the IN-ADDR.ARPA domain is organized and +distributed by network and host address because its role is to translate +from network or host numbers to names; NetBIOS domains [RFC-1001, RFC- +1002] are flat because that is appropriate for that application. + +However, there are some guidelines that apply to the "normal" parts of +the name space used for hosts, mailboxes, etc., that will make the name +space more uniform, provide for growth, and minimize problems as +software is converted from the older host table. The political +decisions about the top levels of the tree originated in RFC-920. +Current policy for the top levels is discussed in [RFC-1032]. MILNET +conversion issues are covered in [RFC-1031]. + +Lower domains which will eventually be broken into multiple zones should +provide branching at the top of the domain so that the eventual +decomposition can be done without renaming. Node labels which use +special characters, leading digits, etc., are likely to break older +software which depends on more restrictive choices. + +3.3. Technical guidelines on use + +Before the DNS can be used to hold naming information for some kind of +object, two needs must be met: + + - A convention for mapping between object names and domain + names. This describes how information about an object is + accessed. + + - RR types and data formats for describing the object. + +These rules can be quite simple or fairly complex. Very often, the +designer must take into account existing formats and plan for upward +compatibility for existing usage. Multiple mappings or levels of +mapping may be required. + +For hosts, the mapping depends on the existing syntax for host names +which is a subset of the usual text representation for domain names, +together with RR formats for describing host addresses, etc. Because we +need a reliable inverse mapping from address to host name, a special +mapping for addresses into the IN-ADDR.ARPA domain is also defined. + +For mailboxes, the mapping is slightly more complex. The usual mail +address @ is mapped into a domain name by +converting into a single label (regardles of dots it +contains), converting into a domain name using the usual +text format for domain names (dots denote label breaks), and +concatenating the two to form a single domain name. Thus the mailbox + + + +Mockapetris [Page 9] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by +HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this +design also must take into account the scheme for mail exchanges [RFC- +974]. + +The typical user is not concerned with defining these rules, but should +understand that they usually are the result of numerous compromises +between desires for upward compatibility with old usage, interactions +between different object definitions, and the inevitable urge to add new +features when defining the rules. The way the DNS is used to support +some object is often more crucial than the restrictions inherent in the +DNS. + +3.4. Example name space + +The following figure shows a part of the current domain name space, and +is used in many examples in this RFC. Note that the tree is a very +small subset of the actual name space. + + | + | + +---------------------+------------------+ + | | | + MIL EDU ARPA + | | | + | | | + +-----+-----+ | +------+-----+-----+ + | | | | | | | + BRL NOSC DARPA | IN-ADDR SRI-NIC ACC + | + +--------+------------------+---------------+--------+ + | | | | | + UCI MIT | UDEL YALE + | ISI + | | + +---+---+ | + | | | + LCS ACHILLES +--+-----+-----+--------+ + | | | | | | + XX A C VAXA VENERA Mockapetris + +In this example, the root domain has three immediate subdomains: MIL, +EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named +XX.LCS.MIT.EDU. All of the leaves are also domains. + +3.5. Preferred name syntax + +The DNS specifications attempt to be as general as possible in the rules + + + +Mockapetris [Page 10] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +for constructing domain names. The idea is that the name of any +existing object can be expressed as a domain name with minimal changes. +However, when assigning a domain name for an object, the prudent user +will select a name which satisfies both the rules of the domain system +and any existing rules for the object, whether these rules are published +or implied by existing programs. + +For example, when naming a mail domain, the user should satisfy both the +rules of this memo and those in RFC-822. When creating a new host name, +the old rules for HOSTS.TXT should be followed. This avoids problems +when old software is converted to use domain names. + +The following syntax will result in fewer problems with many +applications that use domain names (e.g., mail, TELNET). + + ::= | " " + + ::=