idnits 2.17.1 draft-spacek-dnsop-update-clarif-01.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 27, 2015) is 3164 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Spacek 3 Internet-Draft Red Hat, Inc. 4 Intended status: Standards Track August 27, 2015 5 Expires: February 28, 2016 7 Clarifications to the Dynamic Updates in the Domain Name System (DNS 8 UPDATE) specification 9 draft-spacek-dnsop-update-clarif-01 11 Abstract 13 This document clarifies interaction among Dynamic Updates in the 14 Domain Name System (DNS UPDATE), Classless IN-ADDR.ARPA delegation, 15 and Secure Domain Name System (DNS) Dynamic Update in the presence of 16 CNAME/DNAME redirections. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 28, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 2 54 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 55 4. Clarification to Requestor Behaviour . . . . . . . . . . . . 3 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1. Introduction 63 This document clarifies interaction among Dynamic Updates in the 64 Domain Name System (DNS UPDATE) [RFC2136], Classless IN-ADDR.ARPA 65 delegation [RFC2317], and Secure Domain Name System (DNS) Dynamic 66 Update [RFC3007]. 68 It was identified that common implementations using DNS update 69 protocol often ignore existence of CNAME/DNAME redirections and, as a 70 result, fail to update records if redirection is used. One common 71 example is failure to update PTR records in classless IN-ADDR.ARPA 72 zones. 74 [RFC2317] describes how to use the CNAME records in IN-ADDR.ARPA DNS 75 zones to split administrative control over IN-ADDR.ARPA data for 76 classless networks. The described method is perfectly compatible 77 with standard DNS resolution but DNS update requests need special 78 handling described in this document. 80 This clarification is applicable to parties wanting to update records 81 in IN-ADDR.ARPA and other zones without changing existing CNAME/DNAME 82 redirections. A typical example are PTR record updates in zones 83 which might potentially use [RFC2317]. This clarification is not 84 applicable to cases where the purpose of the DNS update is to change 85 CNAME/DNAME redirection. 87 2. Document Conventions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 Terms "requestor", "update message", and names of update message's 94 sections are used in the same sense as in [RFC2136]. 96 Examples involving IN-ADDR.ARPA zone and PTR records are referring to 97 [RFC2317]. 99 3. Problem Description 101 The problem described herein typically occurs when an implementation 102 intends to update resource records resolvable by using particular 103 owner name while keeping all CNAME/DNAME redirections intact. In 104 other words, the purpose of the update is to change resource records 105 associated with terminal node of (potential) chain of redirections 106 starting at a known owner name. 108 Typically, this is the case when the resource records are associated 109 with a known owner name or an owner name that is derived from data 110 obtained outside of DNS. For example, implementations often 111 translate IPv4 address to DNS owner name using the algorithm from 112 [RFC1034] section 5.2.1.4: 114 192.0.2.1 -> 1.2.0.192.in-addr.arpa. 116 The problem is that implementations often use this original node name 117 in an Update Message without checking for redirections. If the 118 original owner name contains redirection, then this behavior results 119 in an attempt to add or delete another record to or from a node that 120 already contains the CNAME record, and the update fails. 122 Such inappropriately constructed update request will be silently 123 ignored in accordance with [RFC2136] section 3.4.2.2. Alternatively, 124 an error will be reported to the requestor if the non-existence of 125 the CNAME record was added as a prerequisite to the Update Message. 127 4. Clarification to Requestor Behaviour 129 Please see applicability note in Introduction (Section 1, Paragraph 130 4). 132 A Requestor MUST resolve (canonicalize) the original owner name (e.g. 133 the one derived from an IPv4 address) to a canonical owner name 134 before constructing the Update Message. The requestor MUST follow 135 whole chain of redirections until the terminal node of the chain is 136 reached and use canonical name found at the terminal node. 137 Implementations MUST detect infinite loops. 139 Canonical owner name MUST be used instead of the original owner name 140 in the resulting Update Message: 142 o All names used in the Prerequisite and Update sections MUST be 143 canonicalized as specified above. Only prerequisites concerning 144 the CNAME or DNAME records are an exception to this rule and 145 should not be canonicalized. 147 o ZNAME in the Zone Section has to contain the name of the zone that 148 encloses the canonical owner names. 150 o An implementation MAY chose to use canonicalized names in RDATA 151 and an Additional Section. This is an application specific 152 decision. 154 5. IANA Considerations 156 This draft does not involve IANA Considerations. 158 6. Security Considerations 160 Canonicalization process changes the owner name which is going to be 161 affected by the update. An active attacker might interfere with the 162 canonicalization process and trick the requestor to update a node of 163 the attacker's choice if the canonicalization process is not secured 164 by using DNSSEC or by other means. 166 Security properties of DNS updates using only DNS UPDATE [RFC2136] 167 without any security mechanisms on top of it are vulnerable anyway 168 because an active attacker can very well modify the update message 169 itself. 171 Canonicalization generally increases overall risk for implementations 172 of Secure DNS Dynamic Update [RFC3007] because an attacker might have 173 a chance to modify the owner name in an Update Message before the 174 message is signed by the requestor. An implementation might decide 175 to accept canonicalized names only on condition that the overall 176 security status of the canonicalization process is sufficient 177 according to the local policy. Because the chain of redirections 178 might involve multiple DNS zones, implementations MUST use the lowest 179 security status from all links in the chain of redirections when 180 doing security decisions. 182 For example, a strict implementation might accept canonicalized names 183 only on condition that all redirections were secured by DNSSEC and 184 the security state of all redirections was "secure". Another 185 implementation might decide that security checks on a server side are 186 sufficient, so requestors will accept canonical names obtained using 187 insecure protocols. In case of PTR records, a server might require 188 the TCP transport and map an IP address of the requestor to the 189 canonical owner name and/or check data in an Update Message with the 190 requestor's identity. 192 7. Normative References 194 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 195 STD 13, RFC 1034, November 1987. 197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 198 Requirement Levels", BCP 14, RFC 2119, March 1997. 200 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 201 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 202 RFC 2136, April 1997. 204 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 205 ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. 207 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 208 Update", RFC 3007, November 2000. 210 Author's Address 212 Petr Spacek 213 Red Hat, Inc. 215 Email: pspacek@redhat.com