idnits 2.17.1 draft-andrews-dnsop-pd-reverse-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 5, 2013) is 3826 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) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Andrews 3 Internet-Draft ISC 4 Expires: May 9, 2014 November 5, 2013 6 Automated Delegation of IP6.ARPA reverse zones with Prefix Delegation 7 draft-andrews-dnsop-pd-reverse-02 9 Abstract 11 This document describes a method to automate the delegation of 12 IP6.ARPA reverse zones when performing Prefix Delegations. 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on May 9, 2014. 31 Copyright Notice 33 Copyright (c) 2013 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 52 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 53 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 1. Introduction 58 This document describes a method to automate the delegation of 59 IP6.ARPA reverse zones when performing Prefix Delegations. 61 This will allow home users and small businesses to have IP6.ARPA 62 zones without manual intervention on the part of the ISP. 64 2. Method 66 1) CPE device generates a RSA key pair and stores this in non- 67 volatile memory. 69 2) CPE device generates a DHCPv6 Prefix Delegation [RFC3633] request 70 which includes a KEY-RDATA option (code point TBA), which contains a 71 the rdata of a DNS KEY record containing a RSASHA256 key using the 72 public components of the previously generated RSA key pair. 74 3) DHCP server updates DNS server based on the prefix it is 75 delegating and the KEY-RDATA, using TSIG [RFC2845] for 76 authentication, and responds with prefix. If this is a new prefix 77 delegation, it will clear out all the old DNS records as part of the 78 delegation process. If there are multiple prefixes being delegated 79 the ISP's DNS server will be updated for all of them. If the 80 delegated prefix is not nibble aligned then the server will update 81 all the reverse apex names that cover the address space, i.e. 1, 2, 4 82 or 8 KEY records will be added all with the same rdata contents. 84 4) CPE device configures the nameserver built into it to serve the 85 reverse of the delegated prefixes. Alternatively it may configure 86 other nameservers to serve these zones, however the method to do that 87 is out of scope for this document. 89 5) CPE device generates a DNS UPDATE [RFC2136] which delegates the 90 reverse name space to itself and others if they have been configured. 91 It uses SIG(0) [RFC2931] to sign the request, with owner name 92 matching the reverse of the delegated prefix. 94 6) The ISP's DNS server is configured to accept self-signed requests 95 (the owner name used in the SIG(0) signature matches the owner name 96 of the data to be updated). It examines the request, looks at the 97 KEY record added by the DHCPv6 server, and decides whether the 98 request is valid. 100 3. Example 102 If 2001:DB8:1:4::/62 is delegated then KEY records for 104 4.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA KEY ... 105 5.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA KEY ... 106 6.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA KEY ... 107 7.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA KEY ... 109 will be added. The CPE device will configure the nameservers to 110 serve all of the following zones 112 4.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA 113 5.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA 114 6.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA 115 7.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA 117 then will send individual UPDATE messages to delegate each of the 118 reverse zones. 120 % nsupdate -k K4.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA 121 update add 4.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA NS ... 122 send 123 % nsupdate -k K5.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA 124 update add 5.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA NS ... 125 send 126 % nsupdate -k K6.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA 127 update add 6.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA NS ... 128 send 129 % nsupdate -k K7.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA 130 update add 7.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA NS ... 131 send 133 4. IANA Considerations 135 Allocate a DHCPv6 code point for KEY-RDATA. 137 5. Security Considerations 139 The UPDATE requests are all signed. This is a proven method for 140 securing UPDATE requests in the DNS. 142 As a RSA key is being used there is no issue with key material being 143 sent in the clear. 145 Only the CPE device and the ISP itself is capable of creating, 146 updating or destroying the delegation. 148 6. Normative References 150 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 151 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 152 RFC 2136, April 1997. 154 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 155 Wellington, "Secret Key Transaction Authentication for DNS 156 (TSIG)", RFC 2845, May 2000. 158 [RFC2931] Eastlake, D., "Secret Key Transaction Authentication for 159 DNS (TSIG)", RFC 2931, September 2000. 161 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 162 Host Configuration Protocol (DHCP) version 6", RFC 3633, 163 December 2003. 165 Author's Address 167 M. Andrews 168 Internet Systems Consortium 169 950 Charter Street 170 Redwood City, CA 94063 171 US 173 Email: marka@isc.org