From b947c8f62ac7327c0371aa01edf253de65f22566 Mon Sep 17 00:00:00 2001 From: Andreas Gustafsson Date: Mon, 8 Nov 1999 19:37:57 +0000 Subject: [PATCH] added yet another draft --- doc/draft/draft-ietf-dnsind-dhcp-rr-00.txt | 167 +++++++++++++++++++++ 1 file changed, 167 insertions(+) create mode 100644 doc/draft/draft-ietf-dnsind-dhcp-rr-00.txt diff --git a/doc/draft/draft-ietf-dnsind-dhcp-rr-00.txt b/doc/draft/draft-ietf-dnsind-dhcp-rr-00.txt new file mode 100644 index 0000000000..6d729e2938 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-dhcp-rr-00.txt @@ -0,0 +1,167 @@ +INTERNET-DRAFT Andreas Gustafsson +draft-ietf-dnsind-dhcp-rr-00.txt Internet Engines, Inc. + October 1999 + + A DNS RR for encoding DHCP information + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet- Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Abstract + + This document describes a DNS RR for use by DHCP servers that need to + store state information in the DNS. + +Introduction + + A set of procedures to allow DHCP servers [RFC2131] to automatically + update the DNS [RFC1034, RFC1035] is proposed in [DHCPDNS]. + + A situation can arise where multiple DHCP clients request the same + DNS name from their (possibly distinct) DHCP servers. To resolve + such conflicts, [DHCPDNS] proposes storing client identifiers in the + DNS to unambiguously associate domain names with the DHCP clients + "owning" them. Early versions of [DHCPDNS] proposed using TXT + records for encoding this information; the current version specifies + the use of KEY records. + + In the interest of clarity, it would be preferable for this DHCP + +Expires April 2000 [Page 1] + +draft-ietf-dnsind-dhcp-rr-00.txt October 1999 + + information to use a distinct RR type rather than the existing KEY + type. A separate RR type can also improve efficiency by avoiding the + unnecessary transmission of unrelated KEY records. + + This memo defines a distinct RR type for use by DHCP servers, the + "DHCP" RR. + +The DHCP RR + + The DHCP RR is defined with mnemonic DHCP and type code . + +DHCP RDATA format + + The RDATA section of a DHCP RR in transmission contains RDLENGTH + bytes of binary data. The format of this data and its interpretation + by DHCP servers and clients, including the interpretation of multiple + DHCP RRs at the same domain name, are TBD. [This part of the + specification should be driven by the needs of, and written in + cooperation with, the DHCP Working Group and the authors of + [DHCPDNS]]. + + DNS software should consider the RDATA section to be opaque. In DNS + master files, the RDATA is represented as a hexadecimal string with + an optional "0x" or "0X" prefix. Periods (".") may be inserted + anywhere after the "0x" for readability. This format is identical to + that of the NSAP RR [RFC1706]. The number of hexadecimal digits MUST + be even. + +Example + + A DHCP server allocating the IPv4 address 10.0.0.1 to a client + "client.org.nil" might associate eight bytes of housekeeping + information with the client as follows: + + client.org.nil. A 10.0.0.1 + client.org.nil. DHCP 01.23.45.67.89.ab.cd.ef + +Security Considerations + + The DHCP record as such does not introduce any new security problems + into the DNS. However, care should be taken not to store sensitive + information in DHCP records, since they are published along with + other DNS data. Note that even the hardware addresses of DHCP + clients may be considered sensitive information. + +IANA Considerations + + The IANA is requested to allocate an RR type number for the DHCP + +Expires April 2000 [Page 2] + +draft-ietf-dnsind-dhcp-rr-00.txt October 1999 + + record type from the regular RR type number range. + +References + + [RFC1035] - Domain Names - Implementation and Specifications, P. + Mockapetris, November 1987. + + [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, + November 1987. + + [RFC1706] - DNS NSAP Resource Records, B. Manning, R. Colella, + October 1994. + + [RFC2131] - Dynamic Host Configuration Protocol, R. Droms, March + 1997. + + [DHCPDNS] - draft-ietf-dhc-dhcp-dns-*.txt + +Author's Address + + Andreas Gustafsson + Internet Engines, Inc. + 950 Charter Street + Redwood City, CA 94063 + USA + + Phone: +1 650 779 6004 + + Email: gson@iengines.net + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implmentation may be prepared, copied, published and + distributed, in whole or in part, without restriction of any kind, + provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + +Expires April 2000 [Page 3] + +draft-ietf-dnsind-dhcp-rr-00.txt October 1999 + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + +Expires April 2000 [Page 4]