idnits 2.17.1 draft-ietf-dnsop-rfc2317bis-00.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2136, updated by this document, for RFC5378 checks: 1995-02-15) -- 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 (January 13, 2016) is 3026 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 informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations T. Finch 3 Internet-Draft University of Cambridge 4 Obsoletes: 2317 (if approved) January 13, 2016 5 Updates: 2136 (if approved) 6 Intended status: Standards Track 7 Expires: July 16, 2016 9 Classless IN-ADDR.ARPA delegation and dynamic reverse DNS UPDATE 10 draft-ietf-dnsop-rfc2317bis-00 12 Abstract 14 This memo describes how to do IN-ADDR.ARPA delegation on any non- 15 octet boundary, and how to consolidate reverse DNS for multiple 16 address blocks into one zone. It obsoletes RFC 2317. 18 It also clarifies the behaviour of dynamic reverse DNS UPDATE 19 clients. It updates RFC 2136. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 16, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. DNS master file $GENERATE directive . . . . . . . . . . . . . 4 57 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Classless IN-ADDR.ARPA delegation for long prefixes . . . . . 6 59 5. IN-ADDR.ARPA delegation for individual addresses . . . . . . . 8 60 6. Classless IN-ADDR.ARPA delegation for short prefixes . . . . . 8 61 7. Alternative naming conventions . . . . . . . . . . . . . . . . 10 62 8. Consolidated reverse DNS zones . . . . . . . . . . . . . . . . 12 63 9. Dynamic DNS UPDATE for reverse DNS pointers . . . . . . . . . 14 64 10. Operational considerations . . . . . . . . . . . . . . . . . . 16 65 11. Security considerations . . . . . . . . . . . . . . . . . . . 17 66 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 67 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 68 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 70 14.2. Informative References . . . . . . . . . . . . . . . . . 19 71 Appendix A. Changes since RFC2317 . . . . . . . . . . . . . . . . 20 72 Appendix B. Questions for reviewers . . . . . . . . . . . . . . . 21 73 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . . 21 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 76 1. Introduction 78 Since the introduction of classless inter-domain routing (CIDR), it 79 has become common to assign IPv4 address space on non-octet 80 boundaries. This memo describes how to do IN-ADDR.ARPA delegation on 81 any non-octet boundary. There are two complementary methods, using 82 CNAME records for long prefixes (greater than 24 bits) and using 83 DNAME records for shorter prefixes. 85 The CNAME method (Section 4) makes it possible to assign IP address 86 blocks with prefixes longer than 24 bits, covering fewer than 256 87 addresses, without losing the ability to delegate authority for the 88 corresponding IN-ADDR.ARPA mappings. This method is fully compatible 89 with the original DNS lookup mechanisms specified in [RFC1034], i.e. 90 there is no need to modify the lookup algorithm used, and there 91 should be no need to modify any software which does DNS lookups. 93 For shorter prefixes IN-ADDR.ARPA space is usually delegated on octet 94 boundaries, which can lead to a proliferation of zones, for instance 95 a /17 assignment requires 128 delegations. The DNAME method 96 (Section 6) makes it possible to reduce the number of zones to match 97 the number of address space assignments. Although DNAME records 98 [RFC6672] are an extension to the original DNS specification, they 99 are sufficiently widely supported to make this method feasible. 100 There is a discussion of DNAME deployment considerations in [RFC7535] 101 section 6. 103 These methods can also be used to consolidate multiple address blocks 104 into a single DNS zone. (Section 8.) This reduces the 105 administrative overhead of managing delegations; for instance it 106 reduces the need to update DS records when DNSSEC keys are rolled. 108 While these methods interoperate well with DNS resolvers, they 109 require some care from dynamic DNS UPDATE clients that are trying to 110 change IN-ADDR.ARPA mappings. The client needs to follow the CNAME 111 and/or DNAME redirections so that its UPDATE request changes the 112 canonical PTR record without disrupting the redirections. 113 (Section 9.) 115 1.1. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 Examples use the "example" special-use domain name [RFC6761], the 122 example networks 192.0.2.0/24 and 2001:db8::/32 [RFC6890], and to 123 illustrate shorter prefixes, the private network 10.0.0.0/8 125 [RFC1918]. 127 2. DNS master file $GENERATE directive 129 The examples in this memo are written using DNS master file syntax as 130 specified in [RFC1035] section 5. Some examples use the $GENERATE 131 extension, which allows you to generate multiple resource records 132 based on a numeric range and a template. The $GENERATE extension is 133 well-known but it is not supported by all DNS master file readers. 135 The syntax of the $GENERATE directive is: 137 $GENERATE range domain [ttl] [class] type rdata [comment] 139 The directive and numeric range are followed by a template resource 140 record. The ttl, class, type, and comment fields are in standard 141 master file format. 143 The range is a pair of unsigned decimal numbers separated by a "-", 144 and the left-hand (first) number is less than or equal to the right- 145 hand (last) number. The $GENERATE directive expands an instance of 146 the template for each number in the range including both endpoints. 148 range = 1*DIGIT "-" 1*DIGIT ; first-last 150 The owner domain of the template is a normal domain name, except that 151 where "$" occurs it is replaced by the generated number. A literal 152 "$" can be included by escaping it with a backslash, like "\$", or 153 doubling it, like "$$". 155 The rdata is expanded in the same way as the domain. If the rdata 156 includes white space (as in MX records, for example) then the whole 157 rdata must be quoted. If the rdata needs to be quoted, then it must 158 be quoted twice. 160 $GENERATE 0-1 $.text.example. TXT "\"slightly arcane\"" 162 Extended versions of the $GENERATE directive allow you to modify a 163 substitution by following the "$" with a clause in braces like 164 "${...}". These modifiers are not described here. 166 For example, you can use the $GENERATE directive to populate the 167 reverse zone for a DHCP pool like this: 169 $ORIGIN 2.0.192.in-addr.arpa. 170 $GENERATE 1-254 $ PTR dhcp-$.example.com. 172 This expands to: 174 $ORIGIN 2.0.192.in-addr.arpa. 175 1 PTR dhcp-1.example.com. 176 2 PTR dhcp-2.example.com. 177 ; ... 250 more records ... 178 253 PTR dhcp-253.example.com. 179 254 PTR dhcp-254.example.com. 181 3. Motivation 183 One of the problems encountered when assigning address space with a 184 longer prefix (fewer addresses) is that it seems impossible for the 185 user of the address space to maintain their own reverse ("IN- 186 ADDR.ARPA") zone autonomously. This obstacle can be overcome using 187 the reverse delegation method described below. 189 Let us assume we have assigned the address spaces to three different 190 parties as follows: 192 192.0.2.0/25 to organization A 193 192.0.2.128/26 to organization B 194 192.0.2.192/26 to organization C 196 In the classical approach, this would lead to a single zone like 197 this: 199 $ORIGIN 2.0.192.in-addr.arpa. 200 ; 201 1 PTR host1.A.example. 202 2 PTR host2.A.example. 203 3 PTR host3.A.example. 204 ; 205 129 PTR host1.B.example. 206 130 PTR host2.B.example. 207 131 PTR host3.B.example. 208 ; 209 193 PTR host1.C.example. 210 194 PTR host2.C.example. 211 195 PTR host3.C.example. 213 The administration of this zone is problematic. Authority for this 214 zone can only be delegated once, and this usually translates into 215 "this zone can only be administered by one organization." The other 216 organizations with address space that corresponds to entries in this 217 zone would thus have to depend on another organization for their 218 address to name translation. This potential problem can be avoided 219 using the method described in this memo. 221 4. Classless IN-ADDR.ARPA delegation for long prefixes 223 This section describes classless IN-ADDR.ARPA delegation for prefix 224 lengths between /25 and /31 inclusive. 226 Since a single zone (such as 2.0.192.in-addr.arpa) can only be 227 delegated once, we need more delegation points to solve our problem. 228 An extra delegation point can be introduced by extending the IN- 229 ADDR.ARPA tree downwards, by adding a label that is not entirely 230 numeric so it does not clash with the existing reverse DNS names. 232 For each /24 subdivided up using this method, there are 256 CNAME 233 records in the parent zone pointing into the child zones via these 234 extra delegation points. It is quite easy to automatically generate 235 the CNAME resource records in the parent zone once and for all, after 236 you know the way the address space is partitioned. 238 Continuing the motivating example given in Section 3, here is how you 239 can divide a /24 into a /25 and two /26 ranges. 241 $ORIGIN 2.0.192.in-addr.arpa. 242 @ IN SOA ns0.isp.example. ( ... ) 243 ; ... 244 ; 245 0-127 NS ns1.A.example. 246 0-127 NS ns2.A.example. 247 ; 248 $GENERATE 0-127 $ CNAME $.0-127 249 ; 250 128-191 NS ns1.B.example. 251 128-191 NS ns2.B.example. 252 ; 253 $GENERATE 128-191 $ CNAME $.128-191 254 ; 255 192-255 NS ns1.C.example. 256 192-255 NS ns2.C.example. 257 ; 258 $GENERATE 192-255 $ CNAME $.192-255 260 In this example the extra delegation points are named after the 261 bottom and top addresses in the delegated address range, using the 262 same format as the $GENERATE range specifier. 264 The $GENERATE directives produce 256 CNAME records which when 265 expanded look like: 267 42.2.0.192.in-addr.arpa. CNAME 42.0-127.2.0.192.in-addr.arpa. 269 The child zones might look something like: 271 $ORIGIN 0-127.2.0.192.in-addr.arpa. 272 @ IN SOA ns0.A.example. ( ... ) 273 NS ns1.A.example. 274 NS ns2.A.example. 275 ; 276 1 PTR host1.A.example. 277 2 PTR host2.A.example. 278 3 PTR host3.A.example. 280 $ORIGIN 128-191.2.0.192.in-addr.arpa. 281 @ IN SOA ns0.B.example. ( ... ) 282 NS ns1.B.example. 283 NS ns2.B.example. 284 ; 285 129 PTR host1.B.example. 286 130 PTR host2.B.example. 287 131 PTR host3.B.example. 289 $ORIGIN 192-255.2.0.192.in-addr.arpa. 290 @ IN SOA ns0.C.example. ( ... ) 291 NS ns1.C.example. 292 NS ns2.C.example. 293 ; 294 193 PTR host1.C.example. 295 194 PTR host2.C.example. 296 195 PTR host3.C.example. 298 When a client does a reverse DNS query for an IP address in this 299 range, it will get an answer like this: 301 ;; QUESTION SECTION: 302 ;42.2.0.192.in-addr.arpa. IN PTR 304 ;; ANSWER SECTION: 305 42.2.0.192.in-addr.arpa. CNAME 42.0-127.2.0.192.in-addr.arpa. 306 42.0-127.2.0.192.in-addr.arpa. PTR host42.A.example. 308 (TTL and CLASS omitted to save space.) 310 5. IN-ADDR.ARPA delegation for individual addresses 312 This section describes IN-ADDR.ARPA delegation for prefix lengths of 313 /32, that is, individual IP addresses. 315 The CNAME trick described in the previous section is not necessary 316 when delegating the reverse DNS for an individual IP address. 317 Instead you can delegate at the reverse DNS name itself (for example, 318 delegate at 42.2.0.192.in-addr.arpa), and put the PTR record at the 319 apex of the delegated zone. 321 In detail (not continuing the previous examples), say isp.example has 322 delegated the reverse DNS for 192.0.2.42/32 to their customer 323 K.example: 325 $ORIGIN 2.0.192.in-addr.arpa. 326 @ IN SOA ns0.isp.example. ( ... ) 327 ; ... 328 42 NS ns1.K.example. 329 42 NS ns2.K.example. 330 ; ... 332 The delegated zone will only have a few records at its apex: 334 $ORIGIN 42.2.0.192.in-addr.arpa. 335 @ IN SOA ns0.K.example. ( ... ) 336 NS ns1.K.example. 337 NS ns2.K.example. 338 PTR host42.K.example. 340 The CNAME method described in Section 4 is in fact not necessary. 341 You can delegate the reverse DNS for a CIDR address block by setting 342 up delegations and /32 zones for every address in the block. However 343 it is usually simpler to set up a single delegated zone and an 344 automatically-generated set of CNAME records. 346 6. Classless IN-ADDR.ARPA delegation for short prefixes 348 This section describes classless IN-ADDR.ARPA delegation for prefix 349 lengths between /9 and /23 inclusive, except for /16 which falls on 350 an octet boundary. 352 Just as you can replace lots of /32 zones with one CIDR zone and some 353 CNAME records, you can replace lots of /24 or /16 zones with one CIDR 354 zone and some DNAME records. It is equally easy to set up, though 355 the way it works is a bit more complicated. 357 DNAME records are described in [RFC6672], but here is a very terse 358 summary. Whereas a CNAME record acts as a redirect for its owner 359 name, a DNAME record acts as a redirect for descendents of its owner 360 name, but not the name itself. Whereas a wildcard CNAME redirects a 361 subtree of the DNS namespace to a single target name, a DNAME 362 redirects a subtree to corresponding names in a different subtree. 364 Say, for example, that two organizations A and B want to share 365 10.0.0.0/8, one using the bottom half and the other using the top 366 half. But they would each prefer not to have to manage 128 master 367 zones of their own and 128 secondary zones from their counterpart. 369 They can reduce this from 256 zones (one for each /16) to 2 zones 370 (one for each /9) by setting up the parent zone like this: 372 $ORIGIN 10.in-addr.arpa. 373 @ IN SOA ns0.B.example. ( ... ) 374 ; ... 375 ; 376 0-127 NS ns1.A.example. 377 0-127 NS ns2.A.example. 378 ; 379 $GENERATE 0-127 $ DNAME $.0-127 380 ; 381 128-255 NS ns1.B.example. 382 128-255 NS ns2.B.example. 383 ; 384 $GENERATE 128-255 $ DNAME $.128-255 386 The $GENERATE directives produce 256 DNAME records which when 387 expanded look like: 389 2.10.in-addr.arpa. DNAME 2.0-127.10.in-addr.arpa. 391 This DNAME record has the effect of mapping names under 2.10.in- 392 addr.arpa to corresponding names under 2.0-127.10.in-addr.arpa, like 393 this: 395 4.3.2.10.in-addr.arpa -> 4.3.2.0-127.10.in-addr.arpa 397 The child zones will look something like, 399 $ORIGIN 0-127.10.in-addr.arpa. 400 @ IN SOA ns0.A.example. ( ... ) 401 NS ns1.A.example. 402 NS ns2.A.example. 403 ; 404 4.3.2 PTR host4.A.example. ; 10.2.3.4 405 $ORIGIN 128-255.10.in-addr.arpa. 406 @ IN SOA ns0.B.example. ( ... ) 407 NS ns1.B.example. 408 NS ns2.B.example. 409 ; 410 20.100.200 PTR host20.B.example. ; 10.200.100.20 412 When a client does a reverse DNS query for an IP address in this 413 range, it will get an answer containing a DNAME record, a synthesized 414 CNAME record, and the canonical answer: 416 ;; QUESTION SECTION: 417 ;4.3.2.10.in-addr.arpa. IN PTR 419 ;; ANSWER SECTION: 420 2.10.in-addr.arpa. DNAME 2.0-127.10.in-addr.arpa. 421 4.3.2.10.in-addr.arpa. CNAME 4.3.2.0-127.10.in-addr.arpa. 422 4.3.2.0-127.10.in-addr.arpa. PTR host4.A.example. 424 (TTL and CLASS omitted to save space.) 426 7. Alternative naming conventions 428 In the sections above, we have suggested naming CIDR subdomains using 429 the same notation as $GENERATE ranges, first-last. However the 430 choice of name is just convention, and you are free to use a 431 different convention if that is more convenient for you. 433 7.1. Subnet base slash prefix length (a bad idea) 435 In its main example, the predecessor to this memo [RFC2317] suggested 436 using the subnet's first address and prefix length separated by a 437 slash, for instance, 439 $ORIGIN 2.0.192.in-addr.arpa. 440 129 CNAME 129.128/26.2.0.192.in-addr.arpa. 442 One problem with putting a slash in the zone name is that it is 443 common to give zone master files the same name as the zone they 444 describe; this is troublesome if the zone name includes a directory 445 separator. 447 In fact, [RFC2317] went on to say this convention is a bad idea. The 448 remainder of this section quotes the paragraphs that explain why you 449 should not follow this example: 451 Some DNS implementations are not kind to special characters in domain 452 names, e.g. the "/" used in the above examples. As [RFC2181] makes 453 clear, these are legal, though some might feel unsightly. Because 454 these are not host names the restriction of [RFC0952] does not apply. 455 Modern clients and servers have an option to act in the liberal and 456 correct fashion. 458 The examples here use "/" because it was felt to be more visible and 459 pedantic reviewers felt that the 'these are not hostnames' argument 460 needed to be repeated. We advise you not to be so pedantic, and to 461 not precisely copy the above examples, e.g. substitute a more 462 conservative character, such as hyphen, for "/". 464 7.2. Subnet base hyphen prefix length 466 The sensible version of the [RFC2317] convention is to use the 467 subnet's first address and prefix length separated by a hyphen, for 468 instance, 470 $ORIGIN 2.0.192.in-addr.arpa. 471 129 CNAME 129.128-26.2.0.192.in-addr.arpa. 473 This convention has the advantage of matching the way that address 474 assignments are configured for routing. However the first-last 475 convention is able to use a single DNS delegation covering adjacent 476 CIDR blocks; for instance, a /25 and an adjacent /26 can be covered 477 by a single delegation for 0-191. 479 7.3. Subnet base only (a bad idea) 481 Another alternative mentioned in [RFC2317] is the subnet's first 482 address by itself. 484 With this convention, most addresses in the subnet have a CNAME (as 485 in Section 4), but the subnet base address does not and instead looks 486 like a /32 delegation (as in Section 5). 488 Because of its lack of uniformity we discourage you from using this 489 convention. 491 7.4. Customer ID 493 It is not necessary for the subdomain to be tied to an address range; 494 it could instead be a customer name or other ID. Then if that 495 customer's address allocation changes, their provider can just add or 496 remove CNAME or DNAME records without having to change the 497 delegation. 499 This convention can also be useful if two organizations somehow share 500 the same physical subnet (and corresponding IP address space) with no 501 "neat" split between the allocations, but they still want to 502 administrate their own IN-ADDR.ARPA mappings. 504 7.5. In the forward DNS tree 506 The CNAME or DNAME records do not have to point into a subdomain: it 507 is also possible to point to an entirely different part of the DNS 508 tree, that is, outside of the IN-ADDR.ARPA tree. This variant of our 509 running example might look like, 511 $ORIGIN 2.0.192.in-addr.arpa. 512 @ IN SOA ns0.isp.example. ( ... ) 513 ; ... 514 $GENERATE 0-127 $ CNAME $.A.example. 515 $GENERATE 128-191 $ CNAME $.B.example. 516 $GENERATE 192-255 $ CNAME $.C.example. 518 $ORIGIN A.example. 519 @ IN SOA ns0.A.example. ( ... ) 520 ; ... 521 ; 522 host1 A 192.0.2.1 523 1 PTR host1 524 ; 525 host2 A 192.0.2.2 526 2 PTR host2 527 ; 528 ; ... 530 This way you can actually end up with the name -> address and the 531 (pointed-to) address -> name mapping data in the same zone file. The 532 two mutually inverse mappings can be updated in the same DNS UPDATE 533 transaction (though this benefit should not be exaggerated: the 534 records will still be cached separately and will time out 535 independently). Do however note that the resolver's traversal via 536 the IN-ADDR.ARPA tree will still be done, so the CNAME records 537 inserted there need to point to the right place for this to work. 539 8. Consolidated reverse DNS zones 541 This section describes how to reduce the number of reverse DNS 542 delegations. It applies to any prefix length, and can be used for 543 IPv6 as well as IPv4. 545 Section 7.5 suggests setting up DNAME and/or CNAME records to point 546 from the reverse DNS tree to the forward DNS. A significant 547 advantage of this is that it eliminates a delegation: instead of 548 having to agree on a CIDR subdomain name, an NS RRset, and a DS 549 RRset, and keep these up-to-date as name servers and DNSSEC keys 550 change, you only need to agree on a target consolidation domain name. 552 The convention we recommend is to lay out part of your forward DNS 553 namespace in the same way as the standard reverse DNS. That is, set 554 up an "in-addr" subdomain under which you place PTR records for 555 reversed dotted-quad IPv4 addresses, and/or an "ip6" subdomain under 556 which you place PTR records for reversed exploded IPv6 addresses. 557 This allows you to consolidate the reverse DNS for multiple disparate 558 address blocks into the same zone. (You can have separate 559 consolidation zones for IPv4 and IPv6, and for public and private 560 addresses.) 562 For example, say organization A decides to consolidate their reverse 563 zones. They would set up their forward DNS like this: 565 $ORIGIN A.example. 566 @ IN SOA ns0.A.example. ( ... ) 567 ; ... 568 ; 569 1.2.0.192.in-addr PTR host1 570 2.2.0.192.in-addr PTR host2 571 4.3.2.10.in-addr PTR host4 573 For long prefixes like 192.0.2.0/25, organization A asks their 574 provider to point CNAME records at their consolidation domain under 575 A.example, like this: 577 $ORIGIN 2.0.192.in-addr.arpa. 578 ; ... 579 $GENERATE 0-127 $ CNAME $.2.0.192.in-addr.A.example. 581 For short prefixes like 10.0.0.0/9, organization A asks their 582 provider to point DNAME records at their consolidation domain under 583 A.example, like this: 585 $ORIGIN 10.in-addr.arpa. 586 ; ... 587 $GENERATE 0-127 $ DNAME $.10.in-addr.A.example. 589 Similarly, for its IPv6 network 2001:db8:A::/48, organization A again 590 asks for a DNAME record, like this: 592 $ORIGIN 8.b.d.0.1.0.0.2.ip6.arpa. 593 ; ... 594 A.0.0.0 DNAME A.0.0.0.8.b.d.0.1.0.0.2.ip6.A.example. 596 To get the full benefit of a consolidated reverse zone, DNAME records 597 should be used instead of delegations. However this requires co- 598 operation from the provider of the address space. 600 Instead of inserting DNAME records in the provider's reverse DNS 601 zone, you can add delegations on octet boundaries as usual, and put 602 DNAME records at the apex of the delegated zones. (Unlike CNAMEs, 603 DNAMEs do not conflict with other records at the same name.) This 604 makes the reverse zones small and static, which is a small advantage, 605 though it does not avoid the other overheads of managing a 606 delegation. 608 9. Dynamic DNS UPDATE for reverse DNS pointers 610 This section updates the DNS UPDATE specification [RFC2136]. It 611 specifies additional requirements for DNS UPDATE clients, so they can 612 dynamically change reverse DNS records in a way that is compatible 613 with the techniques described in the previous sections. It applies 614 both to the IPv4 reverse DNS under IN-ADDR.ARPA and the IPv6 reverse 615 DNS under IP6.ARPA. 617 These additional requirements only apply to DNS UPDATE clients that 618 wish to add, remove, or change endpoint records in the reverse DNS. 619 These requirements do not apply if you are using DNS UPDATE for other 620 purposes, such as altering zone apex or delegation records, or CNAME 621 or DNAME records - which you need to do if you are using DNS UPDATE 622 to deploy classless IN-ADDR.ARPA delegations. These requirements do 623 not affect uses of DNS UPDATE outside the IN-ADDR.ARPA and IP6.ARPA 624 sub-trees. 626 In this section, we use the term "reverse DNS query name" to mean a 627 name under IN-ADDR.ARPA or IP6.ARPA which a resolver uses when making 628 a reverse DNS query. The resolver expects this name to resolve to a 629 PTR RRset or other endpoint records, but (as described in previous 630 sections) the query name does not have to be the direct owner of the 631 endpoint records but can instead be an alias. 633 We use the term "endpoint records" as a generalization of the PTR 634 RRset, since the reverse DNS can include other information about an 635 IP address - not just its host name. For instance, the EUI48 and 636 EUI64 RRtypes are intended for mapping from IP addresses to MAC 637 addresses [RFC7043]. 639 The problem addressed by this section is that DNS UPDATE clients 640 sometimes use a reverse DNS query name in an UPDATE message without 641 checking for CNAME or DNAME redirections. If the usual reverse DNS 642 query name is an alias, then this behavior results in an attempt to 643 add or delete an endpoint record to or from a node that already 644 contains the CNAME record, and the update fails. 646 Aside: Presumably the UPDATE will also fail if the node is occluded 647 below a DNAME record, but neither [RFC2136] nor [RFC6672] 648 specifies how a server ought to react to attempts to UPDATE an 649 occluded domain name. 651 9.1. Requirements for updating PTR records in the reverse DNS 653 When updating a endpoint records in the reverse DNS, an UPDATE client 654 SHOULD NOT simply convert the IP address to a reverse DNS query name 655 and send an UPDATE request for the records at that name. It MUST NOT 656 assume the zone cut falls on a particular boundary such as /24 for 657 IPv4 or /64 for IPv6. 659 Instead, the UPDATE client SHOULD canonicalize all reverse DNS query 660 names that it uses in its UPDATE message. It MUST ensure that all 661 the canonical names are within the same zone and that the ZNAME field 662 in the UPDATE message refers to this zone. 664 9.2. Suggested behaviour 666 In the absence of more specific configuration, a reverse DNS UPDATE 667 client can follow this procedure. 669 Send a SOA query for the reverse DNS query name. There are four 670 kinds of useful response. 672 o There is a SOA record at the query name, which is returned in the 673 answer section of the response. This can occur if the name has a 674 /32 delegation. 676 o The query name is an alias for a name with a SOA record. The 677 answer section of the response contains a CNAME chain and a SOA 678 record. 680 o The query name is not an alias. The response is NOERROR or 681 NXDOMAIN. The answer section is empty, and the authority record 682 contains a SOA record. This is the traditionally expected result. 684 o The query name is an alias. The response is NOERROR or NXDOMAIN. 685 The answer section has a CNAME chain, and the authority record 686 contains a SOA record. This is the normal case for classless IN- 687 ADDR.ARPA delegations or consolidated reverse DNS. 689 In other cases there has been some kind of problem and the DNS UPDATE 690 cannot proceed. 692 (Note that if the reverse DNS query name is under a DNAME, the 693 response will contain a DNAME in the answer section and a synthesized 694 CNAME. The UPDATE client can ignore the DNAME and just use the CNAME 695 records.) 697 (There can also be other records in the response, but they are not 698 relevant to this procedure and so are not discussed here.) 700 All of the useful responses give the DNS UPDATE client enough 701 information to construct a correct UPDATE message. 703 o The server to send the UPDATE message to comes from the SOA MNAME 704 field. 706 o The UPDATE ZNAME comes from the owner name of the SOA record. 708 o The canonical name of the endpoint records comes from the final 709 target of the CNAME chain, or the QNAME if there are no CNAME 710 records in the answer. 712 10. Operational considerations 714 10.1. Secondary name service 716 Very old name server software might not find and return the target 717 name in CNAME records if the targte name is not already known locally 718 as cached or as authoritative data. This can cause some confusion in 719 stub resolvers, as only the CNAME record will be returned in the 720 response. To avoid this problem it is recommended that the 721 authoritative name servers for the delegating zone (the zone 722 containing all the CNAME or DNAME records) all run as secondary name 723 servers for the target zones delegated and pointed into via the 724 CNAME/DNAME records. 726 10.2. CNAME chains 728 Multiple levels of delegation using the methods described in this 729 memo lead to multi-step CNAME and/or DNAME chains. Although 730 [RFC1034] requires resolvers to handle CNAME chains robustly, such a 731 setup might be less reliable overall. 733 10.3. Mail servers 735 SMTP servers are often very picky about reverse DNS, and some are 736 known to be intolerant of DNAME records. Therefore it is wise to be 737 wary of deploying the methods described in Section 6 and Section 8 738 for IP address ranges that contain outgoing inter-domain mail 739 senders. 741 10.4. Workaround for DNS UPDATE interoperability problems 743 If you have the problem described in Section 9 because your reverse 744 DNS UPDATE client does not follow the new requirements in that 745 section, you might be able to work around it by using /32 delegations 746 as described in Section 5. This allows you to eliminate the CNAME 747 records used by the normal classless delegation method (Section 4) at 748 the cost of requiring more zones. And with /32 delegations, the 749 canonical owner name of the PTR records is the usual reverse DNS 750 query name, so the UPDATE client does not need to chase CNAME chains. 752 11. Security considerations 754 11.1. Classless delegation 756 With this scheme, the "leaf sites" might need to rely on one more 757 site running their DNS name service correctly than they would be if 758 they had a /24 allocation of their own, and this might add an extra 759 component which will need to work for reliable name resolution. 761 11.2. Consolidated reverse zones 763 Normal reverse DNS delegations and classless delegations require more 764 frequent changes when zones are signed for DNSSEC [RFC4033], to 765 update the DS records in the parent zone to track key rollovers. 766 Consolidated reverse zones (Section 8) replace delegations with CNAME 767 and/or DNAME pointers. This reduces the number of secure delegations 768 that must be managed, which should make operations simpler and more 769 robust; however it means that reverse DNS resolution depends on 770 chains of trust in the forward DNS as well as the reverse DNS. This 771 does not necessarily increase the number of trusted entities in a 772 meaningful way, if the consolidated reverse zone is in the same part 773 of the namespace as the targets of the PTR records. 775 11.3. Reverse DNS UPDATE 777 The canonicalization process changes the owner name that will be 778 affected by the update. An active attacker might interfere with the 779 canonicalization process and trick the requestor to update a node of 780 the attacker's choice if the canonicalization process is not secured 781 by using TSIG [RFC2845] or DNSSEC [RFC4033] or other means. 783 When using DNSSEC, an implementation might decide to accept 784 canonicalized names only on condition that the overall security 785 status of the canonicalization process is sufficient according to the 786 local policy. Because the chain of redirections might involve 787 multiple DNS zones, implementations MUST use the lowest security 788 status from all links in the chain of redirections when doing 789 security decisions. 791 12. IANA considerations 793 This memo does not require any action from the IANA. 795 13. Acknowledgments 797 Glen A. Herrmannsfeldt described this technique (specifically the 798 Section 7.4 variant) on the comp.protocols.tcp-ip.domains newsgroup 799 in 1991 [GAH1] and in more detail in 1994 [GAH4]. Alan Barrett and 800 Sam Wilson provided valuable comments. 802 Chris Thompson described the technique in Section 8 on the bind-users 803 mailing list in 2009 [CET1] [CET2]. Chris Hills and Niall O'Reilly 804 confirmed they had also deployed it. 806 Petr Spacek pointed out the need to clarify the behaviour of dynamic 807 DNS UPDATE requests for reverse DNS mappings 808 [I-D.spacek-dnsop-update-clarif]. 810 Thanks to the authors of [RFC2317]: Havard Eidnes, Geert Jan de 811 Groot, and Paul Vixie. 813 Thanks to the following people for their helpful comments about this 814 memo: Peter van Dijk, Bob Harold, Niall O'Reilly, Petr Spacek, Chris 815 Thompson, Paul Vixie. 817 14. References 819 14.1. Normative References 821 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 822 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 823 . 825 [RFC1035] Mockapetris, P., "Domain names - implementation and 826 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 827 November 1987, . 829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 831 RFC2119, March 1997, 832 . 834 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 835 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 836 RFC 2136, DOI 10.17487/RFC2136, April 1997, 837 . 839 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 840 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 841 . 843 14.2. Informative References 845 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 846 host table specification", RFC 952, DOI 10.17487/RFC0952, 847 October 1985, . 849 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 850 and E. Lear, "Address Allocation for Private Internets", 851 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 852 . 854 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 855 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 856 . 858 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 859 ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/ 860 RFC2317, March 1998, 861 . 863 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 864 Wellington, "Secret Key Transaction Authentication for DNS 865 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 866 . 868 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 869 Rose, "DNS Security Introduction and Requirements", 870 RFC 4033, DOI 10.17487/RFC4033, March 2005, 871 . 873 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 874 RFC 6761, DOI 10.17487/RFC6761, February 2013, 875 . 877 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 878 "Special-Purpose IP Address Registries", BCP 153, 879 RFC 6890, DOI 10.17487/RFC6890, April 2013, 880 . 882 [RFC7043] Abley, J., "Resource Records for EUI-48 and EUI-64 883 Addresses in the DNS", RFC 7043, DOI 10.17487/RFC7043, 884 October 2013, . 886 [RFC7535] Abley, J., Dickson, B., Kumari, W., and G. Michaelson, 887 "AS112 Redirection Using DNAME", RFC 7535, DOI 10.17487/ 888 RFC7535, May 2015, 889 . 891 [I-D.spacek-dnsop-update-clarif] 892 Spacek, P., "Clarifications to the Dynamic Updates in the 893 Domain Name System (DNS UPDATE) specification", 894 draft-spacek-dnsop-update-clarif-01 (work in progress), 895 August 2015. 897 [GAH1] Herrmannsfeldt, G., "Re: Subnets and IN-ADDR.ARPA", 898 April 1991, . 901 [GAH4] Herrmannsfeldt, G., "Re: Nonstandard subnetting", 902 December 1994, . 905 [CET1] Thompson, C., "Pruning the reverse zone tree", 906 February 2009, . 909 (Message to the bind-users mailing list) 911 [CET2] Thompson, C., "Pruning the reverse zone tree", 912 February 2009, . 915 (Maintained copy of the prune-reverse-zone notes) 917 Appendix A. Changes since RFC2317 919 o Use a recommended naming convention in the main example. Clearly 920 describe which alternative conventions are good and bad ideas. 922 o Add a description of /32 delegations. 924 o Add a description of using DNAME for delegations on short 925 prefixes. 927 o Emphasize the consolidated reverse DNS convention. 929 o Add a description of $GENERATE and use it in the examples. 931 o Specify new requirements on dynamic reverse DNS UPDATE clients. 933 o Better citations for Glen Herrmannsfeldt's original description. 935 Appendix B. Questions for reviewers 937 Is the $GENERATE section a good idea? Should it be ditched? Or 938 maybe promoted to its own document? 940 RFC 2317 is BCP 20. Should this document be moved to the standards 941 track, since it updates RFC 2136? Or should the UPDATE amendment be 942 a separate document? 944 I have generally avoided RFC 2119 keywords in the sections describing 945 how to set up classless delegations, since those sections contain 946 operational advice rather than implementation requirements. Other 947 opinions welcome. 949 Is the indirection problem specific to classless reverse DNS (which 950 is the approach I took) or does it apply to the forward DNS as well? 951 Suggestions for wording welcome. 953 Is the detailed UPDATE behaviour sensible? 955 Appendix C. Changelog 957 Note to RFC editor: This section should be removed before 958 publication. The important points should appear in the previous 959 section. 961 A detailed revision log can be found at 962 . 964 C.1. Chnages between -00 and -01 966 o Note troublesome zone file names. 968 o Clarify DNAME-at-apex 970 o Notes on first-last vs first-prefixlen 971 o Compatibility note about $GENERATE 973 o Note possible workaround for reverse DNS UPDATE canonicalization 974 problem. 976 o Accommodate more than just PTR records in the reverse DNS. 978 o Incorporate some security considerations from 979 [I-D.spacek-dnsop-update-clarif] 981 Author's Address 983 Tony Finch 984 University of Cambridge Information Services 985 Roger Needham Building 986 7 JJ Thomson Avenue 987 Cambridge CB3 0RB 988 England 990 Phone: +44 797 040 1426 991 Email: dot@dotat.at