idnits 2.17.1 draft-ietf-dnsind-dhcp-rr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC1706], [RFC2131], [DHCPDNS], [RFC1034,RFC1035]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 72: '... that of the NSAP RR [RFC1706]. The number of hexadecimal digits MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1999) is 8960 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 1706 -- No information found for draft-ietf-dhc-dhcp-dns- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DHCPDNS' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Andreas Gustafsson 2 draft-ietf-dnsind-dhcp-rr-00.txt Internet Engines, Inc. 3 October 1999 5 A DNS RR for encoding DHCP information 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes a DNS RR for use by DHCP servers that need to 31 store state information in the DNS. 33 Introduction 35 A set of procedures to allow DHCP servers [RFC2131] to automatically 36 update the DNS [RFC1034, RFC1035] is proposed in [DHCPDNS]. 38 A situation can arise where multiple DHCP clients request the same 39 DNS name from their (possibly distinct) DHCP servers. To resolve 40 such conflicts, [DHCPDNS] proposes storing client identifiers in the 41 DNS to unambiguously associate domain names with the DHCP clients 42 "owning" them. Early versions of [DHCPDNS] proposed using TXT 43 records for encoding this information; the current version specifies 44 the use of KEY records. 46 In the interest of clarity, it would be preferable for this DHCP 47 information to use a distinct RR type rather than the existing KEY 48 type. A separate RR type can also improve efficiency by avoiding the 49 unnecessary transmission of unrelated KEY records. 51 This memo defines a distinct RR type for use by DHCP servers, the 52 "DHCP" RR. 54 The DHCP RR 56 The DHCP RR is defined with mnemonic DHCP and type code . 58 DHCP RDATA format 60 The RDATA section of a DHCP RR in transmission contains RDLENGTH 61 bytes of binary data. The format of this data and its interpretation 62 by DHCP servers and clients, including the interpretation of multiple 63 DHCP RRs at the same domain name, are TBD. [This part of the 64 specification should be driven by the needs of, and written in 65 cooperation with, the DHCP Working Group and the authors of 66 [DHCPDNS]]. 68 DNS software should consider the RDATA section to be opaque. In DNS 69 master files, the RDATA is represented as a hexadecimal string with 70 an optional "0x" or "0X" prefix. Periods (".") may be inserted 71 anywhere after the "0x" for readability. This format is identical to 72 that of the NSAP RR [RFC1706]. The number of hexadecimal digits MUST 73 be even. 75 Example 77 A DHCP server allocating the IPv4 address 10.0.0.1 to a client 78 "client.org.nil" might associate eight bytes of housekeeping 79 information with the client as follows: 81 client.org.nil. A 10.0.0.1 82 client.org.nil. DHCP 01.23.45.67.89.ab.cd.ef 84 Security Considerations 86 The DHCP record as such does not introduce any new security problems 87 into the DNS. However, care should be taken not to store sensitive 88 information in DHCP records, since they are published along with 89 other DNS data. Note that even the hardware addresses of DHCP 90 clients may be considered sensitive information. 92 IANA Considerations 94 The IANA is requested to allocate an RR type number for the DHCP 95 record type from the regular RR type number range. 97 References 99 [RFC1035] - Domain Names - Implementation and Specifications, P. 100 Mockapetris, November 1987. 102 [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 103 November 1987. 105 [RFC1706] - DNS NSAP Resource Records, B. Manning, R. Colella, 106 October 1994. 108 [RFC2131] - Dynamic Host Configuration Protocol, R. Droms, March 109 1997. 111 [DHCPDNS] - draft-ietf-dhc-dhcp-dns-*.txt 113 Author's Address 115 Andreas Gustafsson 116 Internet Engines, Inc. 117 950 Charter Street 118 Redwood City, CA 94063 119 USA 121 Phone: +1 650 779 6004 123 Email: gson@iengines.net 125 Full Copyright Statement 127 Copyright (C) The Internet Society (1999). All Rights Reserved. 129 This document and translations of it may be copied and furnished to 130 others, and derivative works that comment on or otherwise explain it 131 or assist in its implmentation may be prepared, copied, published and 132 distributed, in whole or in part, without restriction of any kind, 133 provided that the above copyright notice and this paragraph are 134 included on all such copies and derivative works. However, this 135 document itself may not be modified in any way, such as by removing 136 the copyright notice or references to the Internet Society or other 137 Internet organizations, except as needed for the purpose of 138 developing Internet standards in which case the procedures for 139 copyrights defined in the Internet Standards process must be 140 followed, or as required to translate it into languages other than 141 English. 143 The limited permissions granted above are perpetual and will not be 144 revoked by the Internet Society or its successors or assigns. 146 This document and the information contained herein is provided on an 147 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 148 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 149 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 150 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 151 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."