idnits 2.17.1 draft-fanf-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == 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. -- The draft header indicates that this document obsoletes RFC2317, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2136, but the abstract doesn't seem to mention this, which it should. 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 (October 13, 2015) is 3111 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 5156 (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 6 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) October 13, 2015 5 Updates: 2136 (if approved) 6 Intended status: Standards Track 7 Expires: April 15, 2016 9 Classless IN-ADDR.ARPA delegation and dynamic reverse DNS UPDATE 10 draft-fanf-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. 18 It also clarifies the behaviour of dynamic reverse DNS UPDATE 19 clients. 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 April 15, 2016. 38 Copyright Notice 40 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. DNS master file $GENERATE directive . . . . . . . . . . . . . 3 57 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Classless IN-ADDR.ARPA delegation for long prefixes . . . . . 5 59 5. IN-ADDR.ARPA delegation for individual addresses . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 16 66 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 67 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 68 Appendix A. Changes since RFC2317 . . . . . . . . . . . . . . . 19 69 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 19 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 72 1. Introduction 74 Since the introduction of classless inter-domain routing (CIDR), it 75 has become common to assign IPv4 address space on non-octet 76 boundaries. This memo describes how to do IN-ADDR.ARPA delegation on 77 any non-octet boundary. There are two complementary methods, using 78 CNAME records for long prefixes (greater than 24 bits) and using 79 DNAME records for shorter prefixes. 81 The CNAME method (Section 4) makes it possible to assign IP address 82 blocks with prefixes longer than 24 bits, covering fewer than 256 83 addresses, without losing the ability to delegate authority for the 84 corresponding IN-ADDR.ARPA mappings. This method is fully compatible 85 with the original DNS lookup mechanisms specified in [RFC1034], i.e. 86 there is no need to modify the lookup algorithm used, and there 87 should be no need to modify any software which does DNS lookups. 89 For shorter prefixes IN-ADDR.ARPA space is usually delegated on octet 90 boundaries, which can lead to a proliferation of zones, for instance 91 a /17 assignment requires 128 delegations. The DNAME method 92 (Section 6) makes it possible to reduce the number of zones to match 93 the number of address space assignments. Although DNAME records 94 [RFC6672] are an extension to the original DNS specification, they 95 are sufficiently widely supported to make this method feasible. 97 There is a discussion of DNAME deployment considerations in [RFC7535] 98 section 6. 100 These methods can also be used to consolidate multiple address blocks 101 into a single DNS zone. (Section 8.) This reduces the 102 administrative overhead of managing delegations; for instance it 103 reduces the need to update DS records when DNSSEC keys are rolled. 105 While these methods interoperate well with DNS resolvers, they 106 require some care from dynamic DNS UPDATE clients that are trying to 107 change IN-ADDR.ARPA mappings. The client needs to follow the CNAME 108 and/or DNAME redirections so that its UPDATE request changes the 109 canonical PTR record without disrupting the redirections. 110 (Section 9.) 112 1.1. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 Examples use the "example" special-use domain name [RFC6761], the 119 example networks 192.0.2.0/24 [RFC5735] and 2001:db8::/32 [RFC5156], 120 and to illustrate shorter prefixes, the private network 10.0.0.0/8 121 [RFC1918]. 123 2. DNS master file $GENERATE directive 125 The examples in this memo are written using DNS master file syntax as 126 specified in [RFC1035] section 5. Some examples use the $GENERATE 127 extension, which allows you to generate multiple resource records 128 based on a numeric range and a template. 130 The syntax of the $GENERATE directive is: 132 $GENERATE range domain [ttl] [class] type rdata [comment] 134 The directive and numeric range are followed by a template resource 135 record. The ttl, class, type, and comment fields are in standard 136 master file format. 138 The range is a pair of unsigned decimal numbers separated by a "-", 139 and the left-hand (first) number is less than or equal to the right- 140 hand (last) number. The $GENERATE directive expands an instance of 141 the template for each number in the range including both endpoints. 143 range = 1*DIGIT "-" 1*DIGIT ; first-last 145 The owner domain of the template is a normal domain name, except that 146 where "$" occurs it is replaced by the generated number. A literal 147 "$" can be included by escaping it with a backslash, like "\$", or 148 doubling it, like "$$". 150 The rdata is expanded in the same way as the domain. If the rdata 151 includes white space (as in MX records, for example) then the whole 152 rdata must be quoted. If the rdata needs to be quoted, then it must 153 be quoted twice. 155 $GENERATE 0-1 $.text.example. TXT "\"slightly arcane\"" 157 Extended versions of the $GENERATE directive allow you to modify a 158 substitution by following the "$" with a clause in braces like 159 "${...}". These modifiers are not described here. 161 For example, you can use the $GENERATE directive to populate the 162 reverse zone for a DHCP pool like this: 164 $ORIGIN 2.0.192.in-addr.arpa. 165 $GENERATE 1-254 $ PTR dhcp-$.example.com. 167 This expands to: 169 $ORIGIN 2.0.192.in-addr.arpa. 170 1 PTR dhcp-1.example.com. 171 2 PTR dhcp-2.example.com. 172 ; ... 250 more records ... 173 253 PTR dhcp-253.example.com. 174 254 PTR dhcp-254.example.com. 176 3. Motivation 178 One of the problems encountered when assigning address space with a 179 longer prefix (fewer addresses) is that it seems impossible for the 180 user of the address space to maintain their own reverse ("IN- 181 ADDR.ARPA") zone autonomously. This obstacle can be overcome using 182 the reverse delegation method described below. 184 Let us assume we have assigned the address spaces to three different 185 parties as follows: 187 192.0.2.0/25 to organization A 188 192.0.2.128/26 to organization B 189 192.0.2.192/26 to organization C 191 In the classical approach, this would lead to a single zone like 192 this: 194 $ORIGIN 2.0.192.in-addr.arpa. 195 ; 196 1 PTR host1.A.example. 197 2 PTR host2.A.example. 198 3 PTR host3.A.example. 199 ; 200 129 PTR host1.B.example. 201 130 PTR host2.B.example. 202 131 PTR host3.B.example. 203 ; 204 193 PTR host1.C.example. 205 194 PTR host2.C.example. 206 195 PTR host3.C.example. 208 The administration of this zone is problematic. Authority for this 209 zone can only be delegated once, and this usually translates into 210 "this zone can only be administered by one organization." The other 211 organizations with address space that corresponds to entries in this 212 zone would thus have to depend on another organization for their 213 address to name translation. This potential problem can be avoided 214 using the method described in this memo. 216 4. Classless IN-ADDR.ARPA delegation for long prefixes 218 This section describes classless IN-ADDR.ARPA delegation for prefix 219 lengths between /25 and /31 inclusive. 221 Since a single zone (such as 2.0.192.in-addr.arpa) can only be 222 delegated once, we need more delegation points to solve our problem. 223 An extra delegation point can be introduced by extending the IN- 224 ADDR.ARPA tree downwards, by adding a label that is not entirely 225 numeric so it does not clash with the existing reverse DNS names. 227 For each /24 subdivided up using this method, there are 256 CNAME 228 records in the parent zone pointing into the child zones via these 229 extra delegation points. It is quite easy to automatically generate 230 the CNAME resource records in the parent zone once and for all, after 231 you know the way the address space is partitioned. 233 Continuing the motivating example given in Section 3, here is how you 234 can divide a /24 into a /25 and two /26 ranges. 236 $ORIGIN 2.0.192.in-addr.arpa. 237 @ IN SOA ns0.isp.example. ( ... ) 238 ; ... 239 ; 240 0-127 NS ns1.A.example. 241 0-127 NS ns2.A.example. 242 ; 243 $GENERATE 0-127 $ CNAME $.0-127 244 ; 245 128-191 NS ns1.B.example. 246 128-191 NS ns2.B.example. 247 ; 248 $GENERATE 128-191 $ CNAME $.128-191 249 ; 250 192-255 NS ns1.C.example. 251 192-255 NS ns2.C.example. 252 ; 253 $GENERATE 192-255 $ CNAME $.192-255 255 In this example the extra delegation points are named after the 256 bottom and top addresses in the delegated address range, using the 257 same format as the $GENERATE range specifier. 259 The $GENERATE directives produce 256 CNAME records which when 260 expanded look like: 262 42.2.0.192.in-addr.arpa. CNAME 42.0-127.2.0.192.in-addr.arpa. 264 The child zones might look something like: 266 $ORIGIN 0-127.2.0.192.in-addr.arpa. 267 @ IN SOA ns0.A.example. ( ... ) 268 NS ns1.A.example. 269 NS ns2.A.example. 270 ; 271 1 PTR host1.A.example. 272 2 PTR host2.A.example. 273 3 PTR host3.A.example. 275 $ORIGIN 128-191.2.0.192.in-addr.arpa. 276 @ IN SOA ns0.B.example. ( ... ) 277 NS ns1.B.example. 278 NS ns2.B.example. 279 ; 280 129 PTR host1.B.example. 281 130 PTR host2.B.example. 282 131 PTR host3.B.example. 284 $ORIGIN 192-255.2.0.192.in-addr.arpa. 285 @ IN SOA ns0.C.example. ( ... ) 286 NS ns1.C.example. 287 NS ns2.C.example. 288 ; 289 193 PTR host1.C.example. 290 194 PTR host2.C.example. 291 195 PTR host3.C.example. 293 When a client does a reverse DNS query for an IP address in this 294 range, it will get an answer like this: 296 ;; QUESTION SECTION: 297 ;42.2.0.192.in-addr.arpa. IN PTR 299 ;; ANSWER SECTION: 300 42.2.0.192.in-addr.arpa. CNAME 42.0-127.2.0.192.in-addr.arpa. 301 42.0-127.2.0.192.in-addr.arpa. PTR host42.A.example. 303 (TTL and CLASS omitted to save space.) 305 5. IN-ADDR.ARPA delegation for individual addresses 307 This section describes IN-ADDR.ARPA delegation for prefix lengths of 308 /32, that is, individual IP addresses. 310 The CNAME trick described in the previous section is not necessary 311 when delegating the reverse DNS for an individual IP address. 312 Instead you can delegate at the reverse DNS name itself (for example, 313 delegate at 42.2.0.192.in-addr.arpa), and put the PTR record at the 314 apex of the delegated zone. 316 In detail (not continuing the previous examples), say isp.example has 317 delegated the reverse DNS for 192.0.2.42/32 to their customer 318 K.example: 320 $ORIGIN 2.0.192.in-addr.arpa. 321 @ IN SOA ns0.isp.example. ( ... ) 322 ; ... 323 42 NS ns1.K.example. 324 42 NS ns2.K.example. 325 ; ... 327 The delegated zone will only have a few records at its apex: 329 $ORIGIN 42.2.0.192.in-addr.arpa. 330 @ IN SOA ns0.K.example. ( ... ) 331 NS ns1.K.example. 332 NS ns2.K.example. 333 PTR host42.K.example. 335 The CNAME method described in Section 4 is in fact not necessary. 336 You can delegate the reverse DNS for a CIDR address block by setting 337 up delegations and /32 zones for every address in the block. However 338 it is usually simpler to set up a single delegated zone and an 339 automatically-generated set of CNAME records. 341 6. Classless IN-ADDR.ARPA delegation for short prefixes 343 This section describes classless IN-ADDR.ARPA delegation for prefix 344 lengths between /9 and /23 inclusive, except for /16 which falls on 345 an octet boundary. 347 Just as you can replace lots of /32 zones with one CIDR zone and some 348 CNAME records, you can replace lots of /24 or /16 zones with one CIDR 349 zone and some DNAME records. It is equally easy to set up, though 350 the way it works is a bit more complicated. 352 DNAME records are described in [RFC6672], but here is a very terse 353 summary. Whereas a CNAME record acts as a redirect for its owner 354 name, a DNAME record acts as a redirect for descendents of its owner 355 name, but not the name itself. Whereas a wildcard CNAME redirects a 356 subtree of the DNS namespace to a single target name, a DNAME 357 redirects a subtree to corresponding names in a different subtree. 359 Say, for example, that two organizations A and B want to share 360 10.0.0.0/8, one using the bottom half and the other using the top 361 half. But they would each prefer not to have to manage 128 master 362 zones of their own and 128 secondary zones from their counterpart. 364 They can reduce this from 256 zones (one for each /16) to 2 zones 365 (one for each /9) by setting up the parent zone like this: 367 $ORIGIN 10.in-addr.arpa. 368 @ IN SOA ns0.B.example. ( ... ) 369 ; ... 370 ; 371 0-127 NS ns1.A.example. 372 0-127 NS ns2.A.example. 373 ; 374 $GENERATE 0-127 $ DNAME $.0-127 375 ; 376 128-255 NS ns1.B.example. 377 128-255 NS ns2.B.example. 378 ; 379 $GENERATE 128-255 $ DNAME $.128-255 381 The $GENERATE directives produce 256 DNAME records which when 382 expanded look like: 384 2.10.in-addr.arpa. DNAME 2.0-127.10.in-addr.arpa. 386 This DNAME record has the effect of mapping names under 2.10.in- 387 addr.arpa to corresponding names under 2.0-127.10.in-addr.arpa, like 388 this: 390 4.3.2.10.in-addr.arpa -> 4.3.2.0-127.10.in-addr.arpa 392 The child zones will look something like, 394 $ORIGIN 0-127.10.in-addr.arpa. 395 @ IN SOA ns0.A.example. ( ... ) 396 NS ns1.A.example. 397 NS ns2.A.example. 398 ; 399 4.3.2 PTR host4.A.example. ; 10.2.3.4 401 $ORIGIN 128-255.10.in-addr.arpa. 402 @ IN SOA ns0.B.example. ( ... ) 403 NS ns1.B.example. 404 NS ns2.B.example. 405 ; 406 20.100.200 PTR host20.B.example. ; 10.200.100.20 408 When a client does a reverse DNS query for an IP address in this 409 range, it will get an answer containing a DNAME record, a synthesized 410 CNAME record, and the canonical answer: 412 ;; QUESTION SECTION: 413 ;4.3.2.10.in-addr.arpa. IN PTR 415 ;; ANSWER SECTION: 416 2.10.in-addr.arpa. DNAME 2.0-127.10.in-addr.arpa. 417 4.3.2.10.in-addr.arpa. CNAME 4.3.2.0-127.10.in-addr.arpa. 418 4.3.2.0-127.10.in-addr.arpa. PTR host4.A.example. 420 (TTL and CLASS omitted to save space.) 422 7. Alternative naming conventions 424 In the sections above, we have suggested naming CIDR subdomains using 425 the same notation as $GENERATE ranges, first-last. However the 426 choice of name is just convention, and you are free to use a 427 different convention if that is more convenient for you. 429 7.1. Subnet base slash prefix length (a bad idea) 431 In its main example, the predecessor to this memo [RFC2317] suggested 432 using the subnet's first address and prefix length separated by a 433 slash, for instance, 435 $ORIGIN 2.0.192.in-addr.arpa. 436 129 CNAME 129.128/26.2.0.192.in-addr.arpa. 438 However, it then went on to say this is a bad idea. The remainder of 439 this section quotes [RFC2317]: 441 Some DNS implementations are not kind to special characters in domain 442 names, e.g. the "/" used in the above examples. As [RFC2181] makes 443 clear, these are legal, though some might feel unsightly. Because 444 these are not host names the restriction of [RFC0952] does not apply. 445 Modern clients and servers have an option to act in the liberal and 446 correct fashion. 448 The examples here use "/" because it was felt to be more visible and 449 pedantic reviewers felt that the 'these are not hostnames' argument 450 needed to be repeated. We advise you not to be so pedantic, and to 451 not precisely copy the above examples, e.g. substitute a more 452 conservative character, such as hyphen, for "/". 454 7.2. Subnet base hyphen prefix length 456 The sensible version of the [RFC2317] convention is to use the 457 subnet's first address and prefix length separated by a hyphen, for 458 instance, 460 $ORIGIN 2.0.192.in-addr.arpa. 461 129 CNAME 129.128-26.2.0.192.in-addr.arpa. 463 7.3. Subnet base only (a bad idea) 465 Another alternative mentioned in [RFC2317] is the subnet's first 466 address by itself. 468 With this convention, most addresses in the subnet have a CNAME (as 469 in Section 4), but the subnet base address does not and instead looks 470 like a /32 delegation (as in Section 5). 472 Because of its lack of uniformity we discourage you from using this 473 convention. 475 7.4. Customer ID 477 It is not necessary for the subdomain to be tied to an address range; 478 it could instead be a customer name or other ID. Then if that 479 customer's address allocation changes, their provider can just add or 480 remove CNAME or DNAME records without having to change the 481 delegation. 483 This convention can also be useful if two organizations somehow share 484 the same physical subnet (and corresponding IP address space) with no 485 "neat" CIDR split between the allocations, but they still want to 486 administrate their own IN-ADDR.ARPA mappings. 488 7.5. In the forward DNS tree 489 The CNAME or DNAME records do not have to point into a subdomain: it 490 is also possible to point to an entirely different part of the DNS 491 tree, that is, outside of the IN-ADDR.ARPA tree. This variant of our 492 running example might look like, 494 $ORIGIN 2.0.192.in-addr.arpa. 495 @ IN SOA ns0.isp.example. ( ... ) 496 ; ... 497 $GENERATE 0-127 $ CNAME $.A.example. 498 $GENERATE 128-191 $ CNAME $.B.example. 499 $GENERATE 192-255 $ CNAME $.C.example. 501 $ORIGIN A.example. 502 @ IN SOA ns0.A.example. ( ... ) 503 ; ... 504 ; 505 host1 A 192.0.2.1 506 1 PTR host1 507 ; 508 host2 A 192.0.2.2 509 2 PTR host2 510 ; 511 ; ... 513 This way you can actually end up with the name -> address and the 514 (pointed-to) address -> name mapping data in the same zone file. The 515 two mutually inverse mappings can be updated in the same DNS UPDATE 516 transaction (though this benefit should not be exaggerated: the 517 records will be still be cached separately and will time out 518 independently). Do however note that the resolver's traversal via 519 the IN-ADDR.ARPA tree will still be done, so the CNAME records 520 inserted there need to point to the right place for this to work. 522 8. Consolidated reverse DNS zones 524 This section describes how to reduce the number of reverse DNS 525 delegations. It applies to any prefix length, and can be used for 526 IPv6 as well as IPv4. 528 Section 7.5 suggests setting up DNAME and/or CNAME records to point 529 from the reverse DNS tree to the forward DNS. A significant 530 advantage of this is that it eliminates a delegation: instead of 531 having to agree on a CIDR subdomain name, an NS RRset, and a DS 532 RRset, and keep these up-to-date as name servers and DNSSEC keys 533 change, you only need to agree on a target consolidation domain name. 535 The convention we recommend is to lay out part of your forward DNS 536 namespace in the same way as the standard reverse DNS. That is, set 537 up an "in-addr" subdomain under which you place PTR records for 538 reversed dotted-quad IPv4 addresses, and/or an "ip6" subdomain under 539 which you place PTR records for reversed exploded IPv6 addresses. 540 This allows you to consolidate the reverse DNS for multiple disparate 541 address blocks into the same zone. (You can have separate 542 consolidation zones for IPv4 and IPv6, and for public and private 543 addresses.) 545 For example, say organization A decides to consolidate their reverse 546 zones. They would set up their forward DNS like this: 548 $ORIGIN A.example. 549 @ IN SOA ns0.A.example. ( ... ) 550 ; ... 551 ; 552 1.2.0.192.in-addr PTR host1 553 2.2.0.192.in-addr PTR host2 554 4.3.2.10.in-addr PTR host4 556 For long prefixes like 192.0.2.0/25, organization A asks their 557 provider to point CNAME records at their consolidation domain under 558 A.example, like this: 560 $ORIGIN 2.0.192.in-addr.arpa. 561 ; ... 562 $GENERATE 0-127 $ CNAME $.2.0.192.in-addr.A.example. 564 For short prefixes like 10.0.0.0/9, organization A asks their 565 provider to point DNAME records at their consolidation domain under 566 A.example, like this: 568 $ORIGIN 10.in-addr.arpa. 569 ; ... 570 $GENERATE 0-127 $ DNAME $.10.in-addr.A.example. 572 Similarly, for its IPv6 network 2001:db8:A::/48, organization A again 573 asks for a DNAME record, like this: 575 $ORIGIN 8.b.d.0.1.0.0.2.ip6.arpa. 576 ; ... 577 A.0.0.0 DNAME A.0.0.0.8.b.d.0.1.0.0.2.ip6.A.example. 579 To get the full benefit of a consolidated reverse zone, DNAME records 580 should be used instead of delegations. However this requires co- 581 operation from the provider of the address space. 583 It is possible to delegate the reverse DNS as usual, then put a DNAME 584 record at the apex of the delegated zone. (Unlike CNAMEs, DNAMEs do 585 not conflict with other records at the same name.) This makes the 586 reverse zone small and static, which is a small advantage, though it 587 does not avoid the other overheads of managing a delegation. 589 9. Dynamic DNS UPDATE for reverse DNS pointers 591 This section updates the DNS UPDATE specification [RFC2136]. It 592 specifies additional requirements for DNS UPDATE clients, so they can 593 dynamically change revers DNS PTR records in a way that is compatible 594 with the techniques described in the previous sections. It applies 595 both to the IPv4 reverse DNS under IN-ADDR.ARPA and the IPv6 reverse 596 DNS under IP6.ARPA. 598 These additional requirements only apply to DNS UPDATE clients that 599 wish to add, remove, or change PTR records in the reverse DNS. No 600 new requirements affect other uses of DNS UPDATE, including changes 601 to other records in the reverse DNS. (In particular, these 602 requirements do not apply if you are using DNS UPDATE to deploy 603 classless IN-ADDR.ARPA delegations.) 605 In this section, we use the term "reverse DNS query name" to mean a 606 name under IN-ADDR.ARPA or IP6.ARPA which a resolver uses when making 607 a reverse DNS query. The resolver expects this name to resolve to a 608 PTR RRset, but (as described in previous sections) it does not have 609 to be the direct owner of the PTR RRset but can instead be an alias. 611 The problem addressed by this section is that DNS UPDATE clients 612 sometimes use a reverse DNS query name in an UPDATE message without 613 checking for CNAME or DNAME redirections. If the usual reverse DNS 614 query name is an alias, then this behavior results in an attempt to 615 add or delete a PTR record to or from a node that already contains 616 the CNAME record, and the update fails. 618 Aside: Presumably the UPDATE will also fail if the node is occluded 619 below a DNAME record, but neither [RFC2136] nor [RFC6672] 620 specifies how a server out to react to attempts to UPDATE an 621 occluded domain name. 623 9.1. Requirements for updating PTR records in the reverse DNS 625 When updating a PTR record in the reverse DNS, an UPDATE client 626 SHOULD NOT simply convert the IP address to a reverse DNS query name 627 and send an UPDATE request for the PTR RRset at that name. It MUST 628 NOT assume the zone cut falls on a particular boundary such as /24 629 for IPv4 or /64 for IPv6. 631 Instead, the UPDATE client SHOULD canonicalize all reverse DNS query 632 names that it uses in its UPDATE message. It MUST ensure that all 633 the canonical names are within the same zone and that the ZNAME field 634 in the UPDATE message refers to this zone. 636 9.2. Suggested behaviour 638 In the absence of more specific configuration, a reverse DNS UPDATE 639 client can follow this procedure. 641 Send a SOA query for the reverse DNS query name. There are four 642 kinds of useful response. 644 o There is a SOA record at the query name, which is returned in the 645 answer section of the response. This can occur if the name has a 646 /32 delegation. 648 o The query name is an alias for a name with a SOA record. The 649 answer section of the response contains a CNAME chain and a SOA 650 record. 652 o The query name is not an alias. The response is NOERROR or 653 NXDOMAIN. The answer section is empty, and the authority record 654 contains a SOA record. This is the traditionally expected result. 656 o The query name is an alias. The response is NOERROR or NXDOMAIN. 657 The answer section has a CNAME chain, and the authority record 658 contains a SOA record. This is the normal case for classless IN- 659 ADDR.ARPA delegations or consolidated reverse DNS. 661 In other cases there has been some kind of problem and the DNS UPDATE 662 cannot proceed. 664 (Note that if the reverse DNS query name is under a DNAME, the 665 response will contain a DNAME in the answer section and a synthesized 666 CNAME. The UPDATE client can ignore the DNAME and just use the CNAME 667 records.) 669 (There can also be other records in the response, but they are not 670 relevant to this procedure and so are not discussed here.) 672 All of the useful responses give the DNS UPDATE client enough 673 information to construct a correct UPDATE message. 675 o The server to send the UPDATE message to comes from the SOA MNAME 676 field. 678 o The UPDATE ZNAME comes from the owner name of the SOA record. 680 o The canonical name of the PTR RRset comes from the final target of 681 the CNAME chain, or the QNAME if there are no CNAME records in the 682 answer. 684 10. Operational considerations 686 10.1. Secondary name service 688 Very old name server software might not find and return the target 689 name in CNAME records if the targte name is not already known locally 690 as cached or as authoritative data. This can cause some confusion in 691 stub resolvers, as only the CNAME record will be returned in the 692 response. To avoid this problem it is recommended that the 693 authoritative name servers for the delegating zone (the zone 694 containing all the CNAME or DNAME records) all run as secondary name 695 servers for the target zones delegated and pointed into via the 696 CNAME/DNAME records. 698 10.2. CNAME chains 700 Multiple levels of delegation using the methods described in this 701 memo lead to multi-step CNAME and/or DNAME chains. Although 702 [RFC1034] requires resolvers to handle CNAME chains robustly, such a 703 setup might be less reliable overall. 705 10.3. Mail servers 707 SMTP servers are often very picky about reverse DNS, and some are 708 known to be intolerant of DNAME records. Therefore it is wise to be 709 wary of deploying the methods described in Section 6 and Section 8 710 for IP address ranges that contain outgoing inter-domain mail 711 senders. 713 11. Security Considerations 715 With this scheme, the "leaf sites" might need to rely on one more 716 site running their DNS name service correctly than they would be if 717 they had a /24 allocation of their own, and this might add an extra 718 component which will need to work for reliable name resolution. 720 Normal reverse DNS delegations and classless delegations require more 721 frequent changes when zones are signed for DNSSEC [RFC4034] 722 [RFC4035], to update the DS records in the parent zone to track key 723 rollovers. Consolidated reverse zones (Section 8) replace 724 delegations with CNAME and/or DNAME pointers. This reduces the 725 number of secure delegations that must be managed, which should make 726 operations simpler and more robust; however it means that reverse DNS 727 resolution depends on chains of trust in the forward DNS as well as 728 the reverse DNS. This does not necessarily increase the number of 729 trusted entities in a meaningful way, if the consolidated reverse 730 zone is in the same part of the namespace as the targets of the PTR 731 records. 733 12. Acknowledgments 735 Glen A. Herrmannsfeldt described this technique (specifically the 736 Section 7.4 variant) on the comp.protocols.tcp-ip.domains newsgroup 737 in 1991 [GAH1] and in more detail in 1994 [GAH4]. Alan Barrett and 738 Sam Wilson provided valuable comments. 740 Chris Thompson described the technique in Section 8 on the bind-users 741 mailing list in 2009 [CET]. Chris Hills and Niall O'Reilly confirmed 742 they had also deployed it. 744 Petr Spacek pointed out the need to clarify the behaviour of dynamic 745 DNS UPDATE requests for reverse DNS mappings 746 [I-D.spacek-dnsop-update-clarif]. 748 Thanks to the authors of [RFC2317]: Havard Eidnes, Geert Jan de 749 Groot, and Paul Vixie. 751 13. References 753 13.1. Normative References 755 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 756 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 757 . 759 [RFC1035] Mockapetris, P., "Domain names - implementation and 760 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 761 November 1987, . 763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 764 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 765 RFC2119, March 1997, 766 . 768 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 769 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 770 RFC 2136, DOI 10.17487/RFC2136, April 1997, 771 . 773 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 774 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 775 . 777 13.2. Informative References 779 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 780 host table specification", RFC 952, DOI 10.17487/RFC0952, 781 October 1985, . 783 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 784 and E. Lear, "Address Allocation for Private Internets", 785 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 786 . 788 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 789 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 790 . 792 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 793 ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/ 794 RFC2317, March 1998, 795 . 797 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 798 Rose, "Resource Records for the DNS Security Extensions", 799 RFC 4034, DOI 10.17487/RFC4034, March 2005, 800 . 802 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 803 Rose, "Protocol Modifications for the DNS Security 804 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 805 . 807 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, DOI 808 10.17487/RFC5156, April 2008, 809 . 811 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 812 RFC 5735, DOI 10.17487/RFC5735, January 2010, 813 . 815 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 816 RFC 6761, DOI 10.17487/RFC6761, February 2013, 817 . 819 [RFC7535] Abley, J., Dickson, B., Kumari, W., and G. Michaelson, 820 "AS112 Redirection Using DNAME", RFC 7535, DOI 10.17487/ 821 RFC7535, May 2015, 822 . 824 [I-D.spacek-dnsop-update-clarif] 825 Spacek, P., "Clarifications to the Dynamic Updates in the 826 Domain Name System (DNS UPDATE) specification", draft- 827 spacek-dnsop-update-clarif-01 (work in progress), August 828 2015. 830 [GAH1] Herrmannsfeldt, G., "Re: Subnets and IN-ADDR.ARPA", April 831 1991, . 834 [GAH4] Herrmannsfeldt, G., "Re: Nonstandard subnetting", December 835 1994, . 838 [CET] Thompson, C., "Pruning the reverse zone tree", February 839 2009, . 842 Appendix A. Changes since RFC2317 844 o Use a recommended naming convention in the main example. Clearly 845 describe which alternative conventions are good and bad ideas. 847 o Add a description of /32 delegations. 849 o Add a description of using DNAME for delegations on short 850 prefixes. 852 o Emphasize the consolidated reverse DNS convention. 854 o Add a description of $GENERATE and use it in the examples. 856 o Specify new requirements on dynamic reverse DNS UPDATE clients. 858 o Better citations for Glen Herrmannsfeldt's original description. 860 Appendix B. Changelog 862 Note to RFC editor: This section should be removed before 863 publication. The important points should appear in the previous 864 section. 866 A detailed revision log can be found at 867 . 869 Author's Address 871 Tony Finch 872 University of Cambridge Information Services 873 Roger Needham Building 874 7 JJ Thomson Avenue 875 Cambridge CB3 0RB 876 England 878 Phone: +44 797 040 1426 879 Email: dot@dotat.at