idnits 2.17.1 draft-woodworth-bulk-rr-05.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-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2308, updated by this document, for RFC5378 checks: 1997-01-17) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2017) is 2617 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) == Missing Reference: '0-255' is mentioned on line 1114, but not defined == Missing Reference: '0-10' is mentioned on line 1071, but not defined == Missing Reference: '0-f' is mentioned on line 584, but not defined == Missing Reference: '0-3' is mentioned on line 1114, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 dnsop J. Woodworth 2 Internet-Draft D. Ballew 3 Updates: 2308, 4033, 4034, 4035 S. Bindinganaveli Raghavan 4 (if approved) CenturyLink, Inc. 5 Intended status: Standards Track 6 Expires: August 15, 2017 February 15, 2017 8 BULK DNS Resource Records 9 draft-woodworth-bulk-rr-05 11 Abstract 13 The BULK DNS resource record type defines a method of pattern based 14 creation of DNS resource records to be used in place of NXDOMAIN 15 errors which would normally be returned. These records are currently 16 restricted to registered DNS resource record types A, AAAA, PTR and 17 CNAME. The key benefit of the BULK resource record type is the 18 simplification of maintaining "generic" record assignments which 19 would otherwise be too many to manage or require scripts or 20 proprietary methods as bind's $GENERATE. 22 This document updates RFCs 2308, 4033, 4034 and 4035. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. Internet-Drafts are working 28 documents of the Internet Engineering Task Force (IETF). Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. The list of current Internet-Drafts is at 31 http://datatracker.ietf.org/drafts/current. 33 This document may contain material from IETF Documents or IETF 34 Contributions published or made publicly available before November 35 10, 2008. The person(s) controlling the copyright in some of this 36 material may not have granted the IETF Trust the right to allow 37 modifications of such material outside the IETF Standards Process. 38 Without obtaining an adequate license from the person(s) controlling 39 the copyright in such materials, this document may not be modified 40 outside the IETF Standards Process, and derivative works of it may 41 not be created outside the IETF Standards Process, except to format 42 it for publication as an RFC or to translate it into languages other 43 than English. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents: 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Background and Related Documents . . . . . . . . . . . 5 69 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 5 70 2. The BULK Resource Record . . . . . . . . . . . . . . . . . 5 71 2.1. BULK OPTIONAL Hidden Wildcards . . . . . . . . . . . . 5 72 2.2. BULK RDATA Wire Format . . . . . . . . . . . . . . . . 5 73 2.2.1. The Match Type Field . . . . . . . . . . . . . . 6 74 2.2.2. The Domain Name Pattern Field . . . . . . . . . . 6 75 2.2.2.1. Single hyphen . . . . . . . . . . . . . . . 7 76 2.2.2.2. Numeric ranges . . . . . . . . . . . . . . . 7 77 2.2.2.3. String values . . . . . . . . . . . . . . . 7 78 2.2.3. The Replacement Pattern Field . . . . . . . . . . 7 79 2.3. The BULK RR Presentation Format . . . . . . . . . . . 8 80 2.4. BULK RR Examples . . . . . . . . . . . . . . . . . . . 9 81 3. BULK Replacement . . . . . . . . . . . . . . . . . . . . . 9 82 3.1. Matching BULK "owner" field . . . . . . . . . . . . . 10 83 3.2. Matching the BULK "Match Type" field . . . . . . . . . 10 84 3.3. Matching the BULK "Domain Name Pattern" field . . . . 10 85 3.3.1. Automatic Domain Name Pattern matching . . . . . 11 86 3.3.2. Manual Domain Name Pattern matching . . . . . . . 11 87 3.3.2.1. Manual Domain Name Pattern matching 88 examples . . . . . . . . . . . . . . . 11 89 3.4. Record Generation using the BULK "Replacement 90 Pattern" field . . . . . . . . . . . . 14 91 3.4.1. Replacement Pattern Backreferences . . . . . . . 14 92 3.4.1.1. Backreference Notation . . . . . . . . . . . 15 93 3.4.1.1.1. Simple numeric backreference 94 replacement . . . . . . . . . . . . . 15 95 3.4.1.1.2. Star backreference replacement . . . . 15 96 3.4.1.1.3. Numeric range backreference 97 replacement . . . . . . . . . . . . . 15 98 3.4.1.1.4. Numeric set backreference 99 replacement . . . . . . . . . . . . . 15 100 3.4.1.1.5. Backreference delimiter . . . . . . . . 16 101 3.4.1.1.6. Backreference delimiter interval . . . 16 102 3.4.1.1.7. Backreference padding length . . . . . 16 103 3.4.1.1.8. Backreference Position . . . . . . . . 17 104 3.4.1.1.9. Backreference Position Negation . . . . 17 105 3.4.2. Replacement Pattern examples . . . . . . . . . . 17 106 4. The NPN Resource Record . . . . . . . . . . . . . . . . . . 19 107 4.1. NPN RDATA Wire Format . . . . . . . . . . . . . . . . 19 108 4.1.1. The Match Type field . . . . . . . . . . . . . . 19 109 4.1.2. The Flags field . . . . . . . . . . . . . . . . . 20 110 4.1.3. The Owner Ignore field . . . . . . . . . . . . . 20 111 4.1.4. The Left Ignore field . . . . . . . . . . . . . . 20 112 4.1.5. The Right Ignore field . . . . . . . . . . . . . 20 113 4.2. The NPN RR Presentation Format . . . . . . . . . . . . 21 114 4.3. Normalization Processing of NPN RRs . . . . . . . . . 21 115 4.3.1. Pseudocode for NPN Normalization Processing . . . 22 116 4.3.2. NPN Normalization Processing examples . . . . . . 23 117 5. Positive Side-Effects . . . . . . . . . . . . . . . . . . . 26 118 5.1. Record Superimposition . . . . . . . . . . . . . . . . 26 119 5.2. Pattern Based DNSSEC support . . . . . . . . . . . . . 27 120 6. Known Limitations . . . . . . . . . . . . . . . . . . . . . 27 121 6.1. Increased CPU utilization for NXDOMAIN RRs . . . . . . 27 122 6.2. Pre-Adoption Nameserver Implications . . . . . . . . . 27 123 7. Security Considerations . . . . . . . . . . . . . . . . . . 28 124 7.1. DNSSEC Signature Strategies . . . . . . . . . . . . . 28 125 7.1.1. On-the-fly (Live) Signatures . . . . . . . . . . 28 126 7.1.2. Normalized (NPN Based) Signatures . . . . . . . . 28 127 7.1.3. Non-DNSSEC Zone Support Only . . . . . . . . . . 29 128 7.2. DNSSEC Verifier Details . . . . . . . . . . . . . . . 29 129 7.3. DDOS Attack Vectors and Mitigation . . . . . . . . . . 29 130 7.4. Implications of Large Scale DNS Records . . . . . . . 30 131 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 132 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 30 133 10. References . . . . . . . . . . . . . . . . . . . . . . . . 30 134 10.1. Normative References . . . . . . . . . . . . . . . . 30 135 10.2. Informative References . . . . . . . . . . . . . . . 31 137 1. Introduction 139 The BULK DNS Resource Record (BULK) defines a maskable pattern based 140 method for real-time on-the-fly resource record generation. 141 Specifically, it allows one to manage large blocks of DNS records 142 based entirely on record owner data in the RR query and patterns (or 143 templates) designed by knowledgeable zone administrators. Existing 144 DNS resource records covered by this document are Address (A), IPv6 145 Address (AAAA), Pointer (PTR) and Canonical Name (CNAME). Although 146 other RR types are not explicitly forbidden from use with BULK logic 147 they fall outside of scope and will not be discussed in this 148 document. This document defines the purpose of this new resource 149 record (BULK), its RDATA format, its presentation format (ASCII 150 representation) as well as generated responses to matched DNS 151 queries. 153 Two Key benefits of this record type are; a) the ability to transfer 154 BULK RR intentions from primary to secondary nameservers with minimal 155 bandwidth and memory requirements; and b) the ability to manage large 156 volumes of pattern based records such as an IPv6 /64 CIDR or larger 157 in a single entry. 159 Support options for DNSSEC related complications resulting from 160 dynamically generated records are also provided in this document. 161 One such option is in the form of the Numeric Pattern Normalization 162 (NPN) resource record type also described in this document. NPN 163 resource records provide a way of generating pattern based DNSSEC 164 signatures and securely performing DNSSEC validation on such 165 signatures. 167 1.1. Background and Related Documents 169 This document assumes the reader is familiar with the basic DNS 170 concepts described in [RFC1034], [RFC1035], and the subsequent 171 documents that update them, particularly [RFC2181] and [RFC2308]. 173 The reader is also assumed to be familiar with DNSSEC basics as 174 described in [RFC4033], [RFC4034] and [RFC4035] as well as the DNS 175 cryptographic signature generation process described in [RFC4033], 176 [RFC4034], [RFC4035], [RFC2536], [RFC2931] and [RFC3110]. 178 1.2. Reserved Words 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 2. The BULK Resource Record 186 The BULK resource record consists of details which enable a DNS 187 nameserver to generate RRs of other types based upon query received 188 and patterns provided. Unless otherwise stated the letters used in 189 hexadecimal numbers (a-f) MUST be case insensitive and are assumed to 190 be lowercase. All examples in this document using hexadecimal are 191 provided in lowercase. 193 The Type value for the BULK RR type is XX. 195 The BULK RR is class independent. 197 The BULK RR has no special TTL requirements but some security 198 guidelines are offered in a later section. 200 2.1. BULK OPTIONAL Hidden Wildcards 202 The BULK RR extends current wildcard substitution logic as defined in 203 [RFC1034] by allowing a single hyphen "-" in the leftmost label to 204 represent the intent of leveraging a modified wildcard matching 205 mechanism. If this condition exists wildcard logic SHALL be used for 206 generated replacement records but not for the BULK resource records 207 themselves. This will become clearer in the "BULK Replacement" 208 section of this document. If an asterisk "*" (the standard wildcard 209 character) is used default wildcard behavior MUST be used. 211 2.2. BULK RDATA Wire Format 213 The RDATA for a BULK RR consists of a 2 octet Match Type Field, a 214 Domain Name Pattern Field and a Replacement Pattern Field. 216 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 217 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Match Type | / 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Domain Name Pattern / 221 / / 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 / / 224 / Replacement Pattern / 225 / / 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 2.2.1. The Match Type Field 230 The Match Type field identifies the type of the RRset identified by 231 this BULK record. This field consists of two octets corresponding to 232 an RR TYPE code as specified in [RFC1035], Section 3.2.1. 234 2.2.2. The Domain Name Pattern Field 236 The Domain Name Pattern Field consists of a text string which may be 237 evaluated by the sections below. The character encoding for this 238 field is [US-ASCII] and may not contain whitespace unless enclosed 239 within double-quote characters. The value of a single hyphen "-" has 240 special implications and will be discussed in greater detail below. 242 The following syntax specification uses the Augmented Backus-Naur 243 Form (ABNF) notation as specified in [RFC5234]. 245 DIGIT = 246 HEXDIG = 247 DQUOTE = 249 pattern = "-" / 1*part / DQUOTE 1*part DQUOTE 251 part = "[" range "]" / string 253 range = number [ "-" number ] 255 number = 1*DIGIT / 1*HEXDIG 257 string = 1*( %x01-5A / %x5C / %x5E-7F ) 258 ; Any [US-ASCII] character excluding 259 ; NUL and square bracket characters 260 ; "[" or "]" 262 Although allowed by [RFC2181]; the square bracket characters, "[" and 263 "]", are reserved to enclose a range specification and MUST NOT 264 appear anywhere outside of a range specification. 266 2.2.2.1. Single hyphen 268 If the domain name pattern field consists of a single hyphen it is 269 not necessary to evaluate for numeric ranges or strings. 270 Implementors SHOULD simply set a flag indicating all ranges matching 271 the query's label are true and backreferences (described in further 272 detail in the "BULK Replacement" section) will be automatically set. 274 2.2.2.2. Numeric ranges 276 Numeric ranges include decimal or hexadecimal ranges depending on 277 which record type was used in the query. This logic will be 278 described in further detail in the "Replacement Logic" section. 280 The numeric range pattern will be a range of allowed numbers lower 281 and upper values separated by a single hyphen "-". If upper and 282 lower values are identical a single numeric value (without hyphen) 283 will suffice. To easily distinguish numeric range patterns from 284 string values they MUST be enclosed within square brackets "[" and 285 "]". 287 2.2.2.3. String values 289 All values found before or after Numeric ranges (excluding single- 290 hyphen rule) are considered to be string values. These values will 291 be taken literally when evaluating for pattern matches in the "BULK 292 Replacement" section below. 294 2.2.3. The Replacement Pattern Field 296 The Replacement Pattern field describes how the answer RRset SHOULD 297 be generated for the matching query. It can either be a single 298 hyphen "-" or a string containing backreferences (described in 299 further detail in the "BULK Replacement" section). This field MUST 300 be evaluated for proper syntax for resource records of its Match Type 301 defined above. A "read" evaluation MAY be performed when a zone is 302 first committed to memory either while converting from Text to Wire 303 format (from stored zone files) or when a RR transfer is received 304 (raw Wire format). Stage two "write" evaluations MUST be performed 305 prior to returning generated replacement answers. Since logic to 306 perform a stage two evaluation is already a requirement for DNS 307 nameservers it may be easier for implementors to perform just stage 308 two evaluations. Stage-two-only evaluation may be also preferred for 309 performance purposes and is acceptable behavior. Any stage two 310 evaluation errors MUST be processed as if the record did not exist 311 and if all BULK generated records for a query answer-set evaluate to 312 errors the original condition of an NXDOMAIN error state MUST be 313 restored. 315 The following syntax specification uses the Augmented Backus-Naur 316 Form (ABNF) notation as specified in [RFC5234]. 318 DIGIT = 319 HEXDIG = 320 DQUOTE = 322 pattern = "-" / 1*part / DQUOTE 1*part DQUOTE 324 part = backreference / string 326 backreference = "$" "{" substitution "}" 328 substitution = range 0*( "," range ) [ options ] 330 substitution =/ "*" [ options ] 332 options = delimiter [ interval [ padding ] ] 334 delimiter = "|" 0*1( %x01-23 / %x25-7A / %7E-7F ) 335 ; Any single [US-ASCII] character 336 ; excluding NUL, dollar sign "$", 337 ; pipe "|" and curly brace characters 338 ; "{" or "}" 340 interval = "|" *2DIGIT 342 padding = "|" *2DIGIT 344 range = number [ "-" number ] 346 number = 1*DIGIT / 1*HEXDIG 348 string = 1*( %x01-23 / %x25-7A / %x7C / %7E-7F ) 349 ; Any [US-ASCII] character excluding 350 ; NUL, dollar sign "$" and curly brace 351 ; characters "{" or "}" 353 The dollar sign, "$", and curly brace characters, "{" and "}", are 354 reserved to enclose regular-expression-esque backreferences and MUST 355 NOT appear anywhere outside of such a backreference specification. 356 This rigidity is necessary to simplify implementation of this 357 document and may relax once adoption reaches an acceptable level and 358 demand for such an exception exists. The authors feel this 359 limitation is a reasonable limitation for the flexibility offered by 360 this document. 362 2.3. The BULK RR Presentation Format 364 The Match Type field is represented as an RR type mnemonic. When the 365 mnemonic is not known, the TYPE representation as described in 366 [RFC3597], Section 5, MUST be used. 368 The Domain Name Pattern and Replacement Pattern fields MUST be 369 presented as the TXT RR type described in [RFC1035], Section 3.3.14. 371 2.4. BULK RR Examples 373 EXAMPLE 1 374 The following BULK RR stores a block of A RRs for example.com. 376 *.example.com. 86400 IN BULK A ( 377 pool-A-[0-255]-[0-255].example.com. 378 10.55.${1}.${2} 379 ) 381 The first four fields specify the owner name, TTL, Class, and RR type 382 (BULK). Value "A" indicates that this BULK RR defines the A record 383 type (Address). Value "pool-A-[0-255]-[0-255].example.com." 384 indicates the Domain Name Pattern. Value "10.55.${1}.${2}" indicates 385 the Replacement Pattern. The owner in this example is a wildcard and 386 matches any query ending with the string right of the asterisk. 388 EXAMPLE 2 389 The following BULK RR stores the reverse block of PTR records for the 390 first example. 392 *.55.10.in-addr.arpa. 86400 IN BULK PTR ( 393 [0-255].[0-255].55.10.in-addr.arpa. 394 pool-A-${1}-${2}.example.com. 395 ) 397 The first four fields specify the owner name, TTL, Class, and RR type 398 (BULK). Value "PTR" indicates that this BULK RR defines the PTR 399 record type (Pointer). Value "[0-255].[0-255].55.10.in-addr.arpa." 400 indicates the Domain Name Pattern. Value "pool-A-${1}- 401 ${2}.example.com." indicates the Replacement Pattern. The owner in 402 this example is a wildcard and matches any query ending with the 403 string right of the asterisk. 405 Additional examples can be found in the "BULK Replacement" section. 407 3. BULK Replacement 409 The BULK Record is designed to enable DNS zone maintainers to manage 410 large blocks of DNS RRs which all conform to a common pattern. The 411 Domain Name Pattern field provides both a tertiary filter (after 412 owner and type) and a definition of all numeric pattern ranges. 414 When a query is first received by a DNS nameserver it begins its job 415 of locating an answer-set. In its simplest form this begins by 416 locating the query owner (or wildcard suffix), class and type then 417 returning any matching RR RDATA (or errors). 419 In the event no matches for the query are found the nameserver of 420 authority will return an error type defined as NXDOMAIN. In the case 421 of a "BULK" enabled authoritative nameserver an additional step MUST 422 be performed. The nameserver MUST query its local RR database for 423 any "BULK" RRs with a matching owner, class and compatible Match 424 Type. If any such RRs are found the query's owner MUST then be 425 matched against the Domain Name Pattern and all matching BULK records 426 MUST be placed into a temporary processing answer-set. This 427 temporary processing answer-set MUST then follow the Replacement 428 Pattern for each matched record and provided no errors are found 429 SHALL then write this new answer-set to the query's complete answer 430 set. Matching replacements will be of the type specified in the 431 Match Type field of the corresponding BULK RR. Additional detail is 432 provided in the following sections. 434 3.1. Matching BULK "owner" field 436 The owner field of all BULK records MUST be that of either a wildcard 437 or hidden wildcard as defined in previous sections. While a hidden 438 wildcard will not be searched for BULK records it will be added to 439 the database for use with the corresponding type field of each BULK 440 RR. This allows location of BULK records to be less conspicuous to 441 the public while still leveraging logic already included in the 442 nameserver thus minimizing the complexity of implementation. 444 A query SHALL pass the first filter stage (owner match) ONLY IF: (1) 445 an NXDOMAIN is set as the query's current answer set AND (2) the 446 query's owner ends with the BULK record's owner field past the 447 leading hyphen "-" or asterisk "*". 449 3.2. Matching the BULK "Match Type" field 451 The RR type of the received query must be compatible with that of the 452 Match Type of owners matched in the section above. That is to say a 453 query for an "A" record will only match BULK records with matching 454 owner and Match Types of "A" (or "CNAME"). All other BULK records 455 matching the query's owner are incompatible and MUST be ignored as 456 part of the selected answer set. 458 3.3. Matching the BULK "Domain Name Pattern" field 460 Assuming the RR owner and Match Type fields match the next step is to 461 find compatible Domain Name Patterns. The logic for this falls into 462 two categories; automatic and manual which are described in greater 463 detail in the following sections. 465 3.3.1. Automatic Domain Name Pattern matching 467 Automatic Domain Name Pattern matching is determined by use of a 468 single hyphen "-" as the value for Domain Name Pattern field. This 469 assumes everything matches and all hexadecimal or decimal fields will 470 be captured for use as backreferences in the Replacement Pattern 471 (described below). Automatic Domain Name Pattern matching is often 472 preferred for large blocks such as the reverse IPv6 address space for 473 the simplicity of record management. 475 3.3.2. Manual Domain Name Pattern matching 477 Manual Domain Name Pattern matching, while more complex is designed 478 to be both simple to implement and simple to use. Below is an 479 example implementation for label matching using a combination of 480 parsing by regular expression and matching of numeric ranges. 482 Domain Name Patterns evaluate to current zone ORIGIN as defined in 483 [RFC1034], Section 3. In short this means all Manual Domain Name 484 Patterns must be terminated with a period "." or are assumed relative 485 to the RR's origin. 487 Numeric Ranges are either decimal or hexadecimal as determined by 488 conditions of query. 490 If query type is "A" ranges are set to decimal. 492 If query type is "AAAA" ranges are set to hexadecimal. 494 If query type is PTR or CNAME the RR owner is used to determine 495 decimal or hexadecimal. 497 If RR owner ends in ".ip6.arpa." ranges are set to hexadecimal. 499 If RR owner does _not_ end in ".ip6.arpa." ranges are set to 500 decimal. 502 The square bracket characters, "[" and "]", are reserved to enclose a 503 range specification and MUST NOT appear anywhere outside of a range 504 specification. 506 3.3.2.1. Manual Domain Name Pattern matching examples 508 EXAMPLE 1 509 For this example the query is defined as a PTR record for "10.2.3.4" 510 with an origin of "2.10.in-addr.arpa." and the evaluating BULK RR as: 512 -.2.10.in-addr.arpa. 86400 IN BULK PTR ( 513 [0-255].[0-10] 514 pool-A-${1}-${2}.example.com. 515 ) 517 STEP 1 518 Ensure "Domain Name Pattern" is Fully Qualified 520 [0-255].[0-10] == [0-255].[0-10].2.10.in-addr.arpa. 522 STEP 2 523 Determine whether range is decimal or hexadecimal 525 Query type == "PTR" AND RR owner != "*.ip6.arpa." so range is 526 decimal. 528 STEP 3 529 Build regular expression based on fully qualified domain name 530 pattern. 532 [0-255].[0-10].2.10.in-addr.arpa. == 533 /^([0-9]{1,3})\.([0-9]{1,2})\.2\.10\.in-addr\.arpa\.$/ 535 The above regular expression simply matches numeric ranges based on 536 decimal or hexadecimal and length. Numeric range validation occurs 537 in the next step. 539 STEP 4 540 Compare captured numbers and validate ranges 542 4.3.2.10.in-addr.arpa. 543 =~ /^([0-9]{1,3})\.([0-9]{1,2})\.2\.10\.in-addr\.arpa\.$/ 545 "4" is captured and within range 0-255 (decimal) 546 "3" is captured and within range 0-10 (decimal) 548 EXAMPLE 2 549 For this example the query is defined as a PTR record for "fc00::55" 550 with an origin of "0.0.c.f.ip6.arpa." and the evaluating BULK RR as: 552 -.0.0.c.f.ip6.arpa. 86400 IN BULK PTR ( 553 - 554 pool-${1-16|}-${17- 555 28|}.example.com. 556 ) 558 STEP 1 559 Ensure "Domain Name Pattern" is Fully Qualified 561 - == [0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f]. ~~ 562 [0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f]. ~~ 563 [0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f]. ~~ 564 [0-f].[0-f].[0-f].[0-f].0.0.c.f.ip6.arpa. 566 NOTE: Data above is shown in multiple lines for clarity. 568 Since Hyphen invokes "Automatic Domain Name Pattern" matching, all 569 fields are captured for future use as backreferences. 571 STEP 2 572 Determine whether range is decimal or hexadecimal 574 Query type == "PTR" AND RR owner == "*.ip6.arpa." so range is 575 hexadecimal. 577 STEP 3 578 Build regular expression based on fully qualified domain name 579 pattern. 581 [0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f]. ~~ 582 [0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f]. ~~ 583 [0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f]. ~~ 584 [0-f].[0-f].[0-f].[0-f].0.0.c.f.ip6.arpa. == 585 /^([0-9a-f]{1}\.){28}\.0\.0\.c\.f\.ip6\.arpa\.$/ 587 NOTE: Data above is shown in multiple lines for clarity. 589 The above regular expression simply matches numeric ranges based on 590 decimal or hexadecimal and length. Numeric range validation occurs 591 in the next step. 593 STEP 4 594 Compare captured numbers and validate ranges 596 5.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0. ~~ 597 0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa. 598 =~ /^([0-9a-f]{1}\.){28}\.0\.0\.c\.f\.ip6\.arpa\.$/ 600 NOTE: Data above is shown in multiple lines for clarity. 602 "5" is captured and within range 0-f (hexadecimal) 603 "5" is captured and within range 0-f (hexadecimal) 604 ... 605 "0" is captured and within range 0-f (hexadecimal) 606 "0" is captured and within range 0-f (hexadecimal) 608 EXAMPLE 3 609 For this example the query is defined as an "AAAA" record for "pool- 610 A-ff-aa.example.com." with an origin of "example.com." and the 611 evaluating BULK RR as: 613 -.example.com. 86400 IN BULK AAAA ( 614 pool-A-[0-ffff]-[0-ffff] 615 fc00::${1}:${2} 616 ) 618 STEP 1 619 Ensure "Domain Name Pattern" is Fully Qualified 621 pool-A-[0-ffff]-[0-ffff] == pool-A-[0-ffff]-[0-ffff].example.com. 623 STEP 2 624 Determine whether range is decimal or hexadecimal 626 Query type == "AAAA" so range is hexadecimal. 628 STEP 3 629 Build regular expression based on fully qualified domain name 630 pattern. 632 pool-A-[0-ffff]-[0-ffff].example.com. == 633 /^pool-A-([0-9a-fA-F]{1,4})-([0-9a-fA-F]{1,4})\.example\.com\.$/ 635 The above regular expression simply matches numeric ranges based on 636 decimal or hexadecimal and length. Numeric range validation occurs 637 in the next step. 639 STEP 4 640 Compare captured numbers and validate ranges 642 pool-A-ff-aa.example.com. 643 =~ /^pool-A-([0-9a-fA-F]{1,4})-([0-9a-fA-F]{1,4})\.example\.com\.$/ 645 "ff" is captured and within range 0-ffff (hexadecimal) 646 "aa" is captured and within range 0-ffff (hexadecimal) 648 3.4. Record Generation using the BULK "Replacement Pattern" field 650 Once it has been determined a query meets all criteria for a BULK 651 record generation the below rules are followed to process captured 652 numeric data and Replacement Pattern into RRs to apply to the answer- 653 set. 655 3.4.1. Replacement Pattern Backreferences 657 Before a record may be generated data must be captured in the Domain 658 Name Pattern comparison step above. Each provided numeric range is 659 assigned to a temporary buffer to be used in this step. To make the 660 jobs' of zone administrators easier the order of these buffers will 661 change based on the Match Type and owner so they will default to feel 662 more natural or intuitive. Captured patterns and backreferences are 663 in the same vein as regular expressions and are intended to feel 664 "familiar". This is described in further detail (with examples) in 665 the sections below. 667 3.4.1.1. Backreference Notation 669 BULK RRs use a dollar-sign "$" and curly braces "{" and "}" to 670 enclose backreferences within the Replacement Pattern. The following 671 rules are used to determine the final replacement string. 673 3.4.1.1.1. Simple numeric backreference replacement 675 The simplest form of backreference notation is its numeric form. In 676 this form only the backreference number falls between the curly 677 braces "{" and "}". An example is "${1}" which would be replaced by 678 the value in the first capture position. Position is described in 679 detail in a later section. 681 Numeric backreference replacement indices start with one "1" to 682 maintain consistency with regular expression backreferences. 684 3.4.1.1.2. Star backreference replacement 686 The next form of backreference notation is its star (or asterisk "*") 687 form. In this form only an asterisk falls between the curly braces 688 "{" and "}". This form "${*}" would be replaced by all captured 689 values in order of ascending position delimited by its default 690 delimiter (described below). Position is described in detail in a 691 later section. 693 3.4.1.1.3. Numeric range backreference replacement 695 The next form of backreference notation is the numeric range form. In 696 this form a range of numbers falls between the curly braces "{" and 697 "}". An example of this is "${1-4}" which would be replaced by all 698 captured values within this range (1-4) in order of positions 699 provided delimited its default delimiter (described below). To 700 reverse the order of positions in this example one could simply 701 reverse the upper and lower values to look like "${4-1}". Position 702 is described in detail in a later section. 704 3.4.1.1.4. Numeric set backreference replacement 706 The next form of backreference notation is the numeric set form. In 707 this form a set of numbers falls between the curly braces "{" and "}" 708 separated by commas. An example of this is "${1,4}" which would be 709 replaced by the first and fourth captured values in the order of 710 position provided delimited its default delimiter (described 711 below). Position is described in detail in a later section. 713 This notation may be combined with the numeric range form allowing 714 specific positions or position ranges to be used. Examples would be 715 "${3,2,1,4-8}" and "${8-12,1-4}". 717 3.4.1.1.5. Backreference delimiter 719 The above sections reference a default delimiter. In an effort to 720 provide an intuitive zone management experience the default delimiter 721 will be based on the BULK RR's Match Type. For Match Type "A" the 722 default delimiter SHALL be a period ".", for Match Type "AAAA" the 723 default delimiter SHALL be a colon ":" and for Match Types "PTR" and 724 "CNAME" the default delimiter SHALL be a hyphen "-". In any case the 725 default delimiter MAY be overridden by including it in the 726 backreference braces after the set selectors and a backreference 727 field separator character, the pipe "|". An example would be "${*|- 728 }" which would force a hyphen "-" delimiter. An empty or null 729 delimiter is allowed by not specifying a delimiter character, for 730 example "${*|}", which would simply concatenate all captured values 731 in order of capture position. Position is described in detail in a 732 later section. 734 3.4.1.1.6. Backreference delimiter interval 736 The default behavior of a backreference set is to combine each 737 captured value specified with a delimiter between each. To allow 738 captured backreferences to be delimited at another interval a third 739 backreference field is provided. An example would be "${*|-|4}" 740 which would concatenate all captured values but delimiting only every 741 fourth value with hyphens "-". This can be a handy feature in the 742 IPv6 reverse namespace where every nibble is captured as a separate 743 value and generated hostnames include sets of 4 nibbles. An empty or 744 null value MUST be interpreted as "1" or every captured value. 746 3.4.1.1.7. Backreference padding length 748 When generating BULK based records a common requirement is to convert 749 from one numeric format to another, padding is among the most common 750 of these. The fourth and final backreference field determines what 751 width to pad to. An example would be "${*|||4}" which would set the 752 width of all captured values to 4 by inserting leading zeros to fill 753 the void. The default is empty or null which MUST be interpreted as 754 NO modification. A width of zero "0" has a special interpretation 755 referred to as "unpad" meaning all leading zeros MUST be removed. If 756 a value is provided captured values longer than this width MUST be 757 truncated to fit the specified width. In the case where a delimiter 758 interval is provided captured values between the intervals will be 759 concatenated and the padding or unpadding applied as a unit and not 760 individually. An example of this would be "${*||4|4}" which would 761 combine each range of 4 captured values and pad them to a width of 4 762 characters by inserting leading zeros where necessary. 764 3.4.1.1.8. Backreference Position 766 Great effort has gone into providing zone maintainers an intuitive 767 syntax. As part of this effort, the captured values will reverse 768 direction depending on several factors. 770 As a general rule of thumb, if it makes sense the numeric ranges are 771 in reverse order from query to answer then they will be reversed. 772 Otherwise they will be in the same order. 774 Take for example a simple reverse DNS lookup, from "10.2.3.4" to 775 "pool-A-3-4.example.com.". Since DNS zones are arranged according to 776 management authority the records appear reversed numerically. In this 777 example "10.2.3.4" becomes "4.3.2.10.in-addr.arpa.". One would 778 intuitively expect this reversal to be reversed so positional indices 779 of captured values would increment toward the right of the 780 Replacement Pattern. This expectation is especially important when 781 using range based replacements. 783 Formally, the rules for position reversal are as follows: 785 Match Type RRs for "PTR" are reversed for zone owners ending in 786 either ".in-addr.arpa." or "ip6.arpa.". All other Match Type RRs for 787 "PTR" are forward. 789 Match Type RRs for "A" (Address), "AAAA" (IPv6 Address) and "CNAME" 790 (Canonical Name) are forward. 792 3.4.1.1.9. Backreference Position Negation 794 To allow simple reversal of any backreference notation a single 795 exclamation point character "!" MAY be used as the first character of 796 a backreference set. Examples would be "${!*}" and "${!1-4,7}". In 797 both of the examples the backreference positions SHALL be the exact 798 mirror equivalent as those without the leading exclamation point "!". 799 This can be very important if the BULK generated replacements have 800 values in positions opposite to what is required or expected. 802 3.4.2. Replacement Pattern examples 804 This section provides examples of several BULK RR Replacement 805 Patterns. Each example is intended to further understanding for 806 implementors and DNS administrators alike. 808 EXAMPLE 1 809 For this example the query is defined as a PTR record for "10.2.3.4" 810 with an origin of "2.10.in-addr.arpa." and the evaluating BULK RR as: 812 - 86400 IN BULK PTR - pool-${*}.example.com. 814 This example contains several of the features described above. 816 First, the record owner is simply a single hyphen "-" denoting it is 817 a "hidden wildcard" (wildcard for generated records but not for 818 BULK). 820 Second, the Domain Name Pattern is also a single hyphen "-" denoting 821 all queries matching the owner's wildcard pattern for the "PTR" Match 822 Type are accepted and will be captured for use in the Replacement 823 Pattern. 825 Third, the Replacement Pattern contains a single "star" backreference 826 denoting all captured numeric (decimal) backreferences will be 827 combined with its default delimiter of hyphen "-" (for PTR) and 828 placed into the backreference's position in the answer-set. Should 829 this generate an invalid hostname the response will be NXDOMAIN 830 unless other BULK records match and are successfully generated 831 without error. 833 The owner for "10.2.3.4" is "4.3.2.10.in-addr.arpa." and creates 834 matching backreferences for "4", "3", "2" and "10" then reverses 835 their indices so "${1}" resolves to "10", "${2}" to "2", "${3}" to 836 "3" and "${4}" to "4" respectively. When applied to the Replacement 837 Pattern the answer becomes "pool-10-2-3-4.example.com.". 839 EXAMPLE 2 840 For this example the query is defined as a PTR record for "10.2.3.4" 841 with an origin of "2.10.in-addr.arpa." and the evaluating BULK RR as: 843 - 86400 IN BULK PTR - pool-${*|||3}.example.com. 845 This example expands on EXAMPLE 1 with the differences outlined 846 below. 848 The only change to the BULK RR is the Replacement Pattern includes 849 additional fields, specifically null values for delimiter and 850 interval and a padding width of 3. 852 The owner for "10.2.3.4" is "4.3.2.10.in-addr.arpa." and creates 853 matching backreferences for "4", "3", "2" and "10" and reverses their 854 indices so "${1}" resolves to "10", "${2}" to "2", "${3}" to "3" and 855 "${4}" to "4" respectively. When applied to the Replacement Pattern 856 the answer becomes "pool-010002003004.example.com.". 858 EXAMPLE 3 859 This example contains a classless IPv4 delegation on the /22 CIDR 860 boundary as defined by [RFC2317]. The network for this example is 862 "10.2.0/22" delegated to a nameserver "ns1.sub.example.com.". RRs for 863 this example are defined as: 865 $ORIGIN 2.10.in-addr.arpa. 866 0-3 86400 IN NS ns1.sub.example.com. 867 - 86400 IN BULK CNAME [0-255].[0-3] ${*|.}.0-3 869 For this example, the query would come in for "25.2.2.10.in- 870 addr.arpa.". After matching the owner filter (ending in ".2.10.in- 871 addr.arpa.") and the fully qualified domain name pattern of "[0- 872 255].[0-3].2.10.in-addr.arpa." the answer-set would include a 873 generated RR consisting of captured values "25" and "2" joined by the 874 custom delimiter of period "." then joined by ".0-3" and made fully 875 qualified. The resulting RR would be a "CNAME" with RDATA of 876 "25.2.0-3.2.10.in-addr.arpa.". This record is now one delegated to 877 "ns1.sub.example.com." as its authority and the answer-set is 878 complete. 880 4. The NPN Resource Record 882 The NPN resource record provides pre-processing directives for 883 Numeric Pattern Normalization (NPN) based RR signature generation. 885 The Type value for the NPN RR type is XX. 887 The NPN RR is class independent. 889 The NPN RR has no special TTL requirements. 891 4.1. NPN RDATA Wire Format 893 The RDATA for a NPN RR consists of a 2 octet Match Type field, a 1 894 octet Flags field, a 1 octet Owner Ignore field, a 1 octet Left 895 Ignore field and a 1 octet Right Ignore field. 897 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 898 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Match Type | Flags | Owner Ignore | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Left Ignore | Right Ignore | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 4.1.1. The Match Type field 907 The Match Type field identifies the type of the RRset identified by 908 this NPN record. 910 4.1.2. The Flags field 912 The Flags field defines additional processing parameters for data 913 normalization. This document defines only the Period-As-Number flag 914 "." (position 5), the Hyphen-As-Number "-" (position 6) and the 915 hexadecimal flag "X" (position 7). All other flags are reserved for 916 future use. 918 0 1 2 3 4 5 6 7 919 +-+-+-+-+-+-+-+-+ 920 |Reserved |.|-|X| 921 +-+-+-+-+-+-+-+-+ 923 Bits 0-4: Reserved for future 924 These flags have no default value if set to false (0). 925 Bit 5: Period As Number (.) Flag 926 This flag indicates the period (dot) will be processed as a 927 number. This flag has no default value if set to false (0). 928 Bit 6: Hyphen As Number (-) Flag 929 This flag indicates the hyphen (dash) will be processed as a 930 number. This flag has no default value if set to false (0). 931 Bit 7: Hexadecimal (X) Flag 932 This flag indicates the highest value for Normalization Processing 933 is "f". Normalization Processing will be described in a later 934 section. This flag has a default value of "9" if set to false 935 (0). 937 4.1.3. The Owner Ignore field 939 The Owner Ignore field defines the length of characters as counted 940 from the left-hand side of the owner which MUST be ignored by the 941 normalization process. This field offers additional security to 942 pattern based signatures which may not be immediately apparent. By 943 restricting the leftmost characters defined by this value, ultimately 944 the length of the generated portion of the accompanying BULK RR will 945 be confined accordingly. Normalization Processing will be described 946 further in a later section. 948 4.1.4. The Left Ignore field 950 The Left Ignore field defines the length of characters as counted 951 from the left-hand side of the generated RDATA which MUST be ignored 952 by the normalization process. Normalization Processing will be 953 described further in a later section. 955 4.1.5. The Right Ignore field 957 The Right Ignore field defines the length of characters as counted 958 from the right-hand side of the generated RDATA which MUST be ignored 959 by the normalization process. Normalization Processing will be 960 described further in a later section. 962 4.2. The NPN RR Presentation Format 964 The Match Type field is represented as an RR type mnemonic. When the 965 mnemonic is not known, the TYPE representation as described in 966 [RFC3597], Section 5, MUST be used. 968 The Flags field MUST be presented as a string of characters 969 representing each flag bit. This document defines only the period 970 ".", hyphen "-" and hexadecimal "X" flags. Flags MAY appear in any 971 order. For example; all three flags could appear as "-9." or ".f-" 972 (without the quotes). If all bits are zero all default values (if 973 defined) would be presented ("9" as currently defined). 975 All Ignore fields MUST be presented as an unsigned decimal integers 976 and fall within the 0-255 range available to a single octet. 978 4.3. Normalization Processing of NPN RRs 980 This document provides a minor yet significant modification to DNSSEC 981 regarding how RRsets will be signed or verified. Specifically the 982 Signature Field of [RFC4034], Section 3.1.8. Prior to processing 983 into canonical form, signed zones may contain associated RRs where; 984 owner, class and type of a non NPN RR directly corresponds with an 985 NPN RR matching owner, class and Match Type. If this condition 986 exists the NPN RR's RDATA defines details for processing the 987 associated RDATA into a "Normalized" format. Normalized data is 988 based on pre-canonical formatting and zero padded for "A" and "AAAA" 989 RR types for acceptable precision during the process. This concept 990 will become clearer in the NPN pseudocode and examples provided in 991 the sections to follow. 993 The rules for this transformation are simple: 995 For RR's Owner field, characters from the beginning to the index 996 of the Owner Ignore value or the final string of characters 997 belonging to the zone's ORIGIN MUST NOT be modified by this 998 algorithm. While the Owner Ignore value is not used for BULK 999 records but is included with the expectation other pattern-based 1000 resource records may emerge and leverage NPN records for their 1001 DNSSEC support requirements. 1003 For RR's RDATA field, character from beginning to the index of 1004 Left Ignore value or characters with index of Right Ignore value 1005 to the end MUST NOT be modified by this algorithm. 1007 In the remaining portion of both Owner and RDATA strings of 1008 numeric data, defined as character "0" through "f" or "0" through 1009 "9" depending on whether or not the Hexadecimal flag is set or 1010 not, MUST be consolidated to a single character and set to the 1011 highest value defined by the Hexadecimal flag. Examples may be 1012 found in the following section. If period-as-number or hyphen-as- 1013 number flags are set whichever are used ("." or "-") would be 1014 treated as part of the number and consolidated where appropriate. 1016 Once the normalization has been performed the signature will continue 1017 processing into canonical form using the normalized RRs in the place 1018 of original ones. 1020 One thing to keep in mind when calculating values for the Ignore 1021 fields is the Domain Name Pattern and Replacement Pattern fields are 1022 considered relative unless terminated by a period. When processing 1023 NPN records the fully-qualified Patterns will be used for determining 1024 which characters should be ignored. 1026 NPN RRs MAY be included in the "Additional" section to provide a hint 1027 for NPN processing required for verification path. 1029 It is important to note, properly sizing the Ignore fields is 1030 critical to minimizing the risk of spoofed signatures. Never 1031 intentionally set all Ignore values to zero in order to make 1032 validation easier as it places the validity of zone data at risk. 1033 Only accompany RRs which are pattern derived (such as BULK) with NPN 1034 records as doing so may unnecessarily reduce the confidence level of 1035 generated signatures. 1037 4.3.1. Pseudocode for NPN Normalization Processing 1039 This section provides a simple demonstration of process flow for NPN 1040 rdata normalization and DNSSEC signatures. 1042 The pseudocode provided below assumes all associated RRs are valid 1043 members of a DNSSEC compatible RRset (including BULK generated ones). 1045 for rr in rrset 1046 if (has_NPN) 1047 rr.rdata_normal = NPN_normalize 1048 add_to_sigrrset 1050 next 1051 else 1052 add_to_sigrrset 1053 next 1055 process_canonical_form 1057 dnssec_sign 1059 Similar logic MUST be used for determining DNSSEC validity of RRsets 1060 in verification (validation) nameservers for signatures generated 1061 based on NPN normalization. 1063 4.3.2. NPN Normalization Processing examples 1065 EXAMPLE 1 1066 For this example the query is defined as a PTR record for "10.2.3.44" 1067 with an origin of "2.10.in-addr.arpa." and the evaluating BULK and 1068 NPN RR as: 1070 -.2.10.in-addr.arpa. 86400 IN BULK PTR ( 1071 [0-255].[0-10] 1072 pool-A-${1}-${2}.example.com. 1073 ) 1074 *.2.10.in-addr.arpa. 86400 IN NPN PTR 9 0 7 13 1076 As shown previously in BULK RR examples the query would enter the 1077 nameserver with an owner of "44.3.2.10.in-addr.arpa." and a "PTR" RR 1078 with the RDATA of "pool-A-3-44.example.com." would be generated. 1080 By protecting the "Ignore" characters from the generated RR's RDATA 1081 the focus for normalization becomes "3-44" as illustrated below. 1083 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 1084 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 1085 v--------- 1086 p o o l - A - 3 - 4 4 . e x a m p l e . c o m . 1087 ---------^ 1088 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1089 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 1091 Everything to the left of "3-44" will remain intact as will 1092 everything to its right. The remaining characters will be processed 1093 for numbers between "0" and "9" as indicated by the NPN record's 1094 hexadecimal flag "9" and each run replaced by the single character 1095 "9". The final Normalized RDATA would therefore become "pool-A-9- 1096 9.example.com." and its signature would be based on this "normalized" 1097 RDATA field. This new "normalized" string would be used as an RDATA 1098 for the wildcard label of "*.2.10.in-addr.arpa." now encompassing all 1099 possible permutations of the "pool-A-${1}-${2}.example.com." pattern. 1101 Since the verification (validation) nameserver would use the 1102 identical NPN record for processing and comparison, all RRs generated 1103 by the BULK record can now be verified with a single wildcard 1104 signature. 1106 EXAMPLE 2 1107 This example contains a classless IPv4 delegation on the /22 CIDR 1108 boundary as defined by [RFC2317]. The network for this example is 1109 "10.2.0/22" delegated to a nameserver "ns1.sub.example.com.". RRs 1110 for this example are defined as: 1112 $ORIGIN 2.10.in-addr.arpa. 1113 0-3 86400 IN NS ns1.sub.example.com. 1114 - 86400 IN BULK CNAME [0-255].[0-3] ${*|.}.0-3 1115 * 86400 IN NPN CNAME 9 0 0 23 1117 For this example, a query of "10.2.2.65" would enter the nameserver 1118 as "65.2.2.10.in-addr.arpa." and a "CNAME" RR with the RDATA of 1119 "65.2.0-3.2.10.in-addr.arpa." would be generated. 1121 By protecting the "Ignore" characters from the generated RR's RDATA 1122 the focus for normalization becomes "65.2" as illustrated below. 1124 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 1125 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 1126 v--------- 1127 6 5 . 2 . 0 - 3 . 2 . 1 0 . i n - a d d r . a r p a . 1128 ---------^ 1129 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1130 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 1132 Everything to the left of "65.2" will remain intact as will 1133 everything to its right. The remaining characters will be processed 1134 for numbers between "0" and "9" as indicated by the NPN record's 1135 hexadecimal flag "9" and each run replaced by the single character 1136 "9". The final Normalized RDATA would therefore become "9.9.0- 1137 3.2.10.in-addr.arpa." and its signature would be based on this 1138 "normalized" RDATA field. This new "normalized" string would be used 1139 as an RDATA for the wildcard label of "*.2.10.in-addr.arpa." now 1140 encompassing all possible permutations of the "${*|.}.0-3.2.10.in- 1141 addr.arpa." pattern. 1143 As in example 1, the verification (validation) nameserver would use 1144 the same NPN record for comparison. 1146 EXAMPLE 3 1147 This example provides reverse logic for example 1 by providing an 1148 IPv4 "A" record for a requested hostname. For this example the query 1149 is defined as an "A" record for "pool-A-3-44.example.com." with an 1150 origin of "example.com.". RRs for this example are defined as: 1152 -.example.com. 86400 IN BULK A ( 1153 pool-A-[0-10]-[0-255] 1154 10.2.${*} 1155 ) 1156 *.example.com. 86400 IN NPN A 9 0 8 0 1158 By protecting the "Ignore" characters from the generated RR's RDATA 1159 the focus for normalization becomes "003.044" as illustrated below. 1161 1 1 1 1 1 1 1 1 1 1162 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 1163 v-------------- 1164 0 1 0 . 0 0 2 . 0 0 3 . 0 4 4 1165 ---------------^ 1166 1 1 1 1 1 1 1 1 1 1167 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 1169 This example illustrates a key point about NPN records; since they 1170 are pre-canonical they MUST operate on a strict subset of WIRE 1171 formatted data. For "A" and "AAAA" records this means the "Ignore" 1172 fields are based on zero padded data. In this example our generated 1173 record MUST be converted into "010.002.003.044" (shown above) prior 1174 to processing. After processing, wire format would become 1175 "0x0A02032C" (shown in hexadecimal). This format would be too 1176 imprecise for normalization so padded decimal is used. 1178 Everything to the left of "003.044" will remain intact as will 1179 everything to its right. The remaining characters will be processed 1180 for numbers between "0" and "9" as indicated by the NPN record's 1181 hexadecimal flag "9" and each run replaced by the single character 1182 "9". The final Normalized RDATA would therefore become "10.2.9.9" 1183 and its signature would be based on this "normalized" RDATA field. 1184 This new "normalized" "A" RR would be used as an RDATA for the 1185 wildcard label of "*.example.com." now encompassing all possible 1186 permutations of the "10.2.${*}" pattern. 1188 EXAMPLE 4 1189 This example provides similar logic for an IPv6 AAAA record. For 1190 this example the query is defined as an "AAAA" record for "pool-A-ff- 1191 aa.example.com." with an origin of "example.com.". RRs for this 1192 example are defined as: 1194 -.example.com. 86400 IN BULK AAAA ( 1195 pool-A-[0-ffff]-[0-ffff] 1196 fc00::${1}:${2} 1197 ) 1198 *.example.com. 86400 IN NPN AAAA X 0 30 0 1200 By protecting the "Ignore" characters from the generated RR's RDATA 1201 the focus for normalization becomes "00ff:00aa" as illustrated below. 1203 1 1 1 1 1 1 1 1 1 1 2 2 1204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1206 f c 0 0 : 0 0 0 0 : 0 0 0 0 : 0 0 0 0 : -/-/ 1208 4 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1209 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 1210 /-/-/- . . . . . . . . . . . . . . . . . . . . . . . . -/-/-/ 1211 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 1212 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1213 v------------------ 1214 /-/- 0 0 0 0 : 0 0 0 0 : 0 0 f f : 0 0 a a 1215 -------------------^ 1216 2 1 1 1 1 1 1 1 1 1 1 1217 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 1219 This example reinforces the point on pre-canonical processing of NPN 1220 records; they MUST operate on a strict subset of WIRE formatted data. 1221 For "A" and "AAAA" records this means the "Ignore" fields are based 1222 on zero padded data. In this example our generated record MUST be 1223 converted into "fc00:0000:0000:0000:0000:0000:00ff:00aa" (shown 1224 above) prior to processing. After processing, wire format would 1225 become "0xFC000000000000000000000000FF00AA" (shown in hexadecimal). 1226 This format is slightly misleading as it is truly only 16 bytes of 1227 WIRE data and would be too imprecise for normalization so padded 1228 hexadecimal is used. 1230 Everything to the left of "00ff:00aa" will remain intact as will 1231 everything to its right. The remaining characters will be processed 1232 for numbers between "0" and "f" as indicated by the NPN record's 1233 hexadecimal flag "X" and each run replaced by the single character 1234 "f". The final Normalized RDATA would therefore become "fc00::f:f" 1235 and its signature would be based on this "normalized" RDATA field. 1236 This new "normalized" "AAAA" RR would be used as an RDATA for the 1237 wildcard label of "*.example.com." now encompassing all possible 1238 permutations of the "fc00::${1}:${2}" pattern. 1240 5. Positive Side-Effects 1242 This section highlights positive side effects of some architectural 1243 decisions regarding the BULK RR design. 1245 5.1. Record Superimposition 1247 The main side-effect of the BULK RR design is superimposition. RRs 1248 created by the BULK generation process generally rely on the logic of 1249 wildcard assignment. This logic only provides answers where no 1250 others exist. This means in the reverse DNS world (network 1251 assignment) HUGE blocks of addresses can be assigned a single BULK 1252 record and where delegated to another customer or SWIP will be 1253 automatically overridden. 1255 When compared with bind's $GENERATE statement, if a singleton record 1256 such as CNAME appears within a $GENERATE range, either the CNAME or 1257 $GENERATE becomes invalid. While a BULK record range would 1258 automatically notch out the CNAME without user intervention or 1259 creating a potential management problem for the future when two 1260 $GENERATES create a hole where the CNAME no longer exists. BULK RRs 1261 would again automatically reassign the missing record to one of its 1262 own. 1264 5.2. Pattern Based DNSSEC support 1266 The NPN resource record can be used to support other dynamic RR types 1267 which do not currently exist. 1269 6. Known Limitations 1271 This section defines known limitations of the BULK resource type. 1273 6.1. Increased CPU utilization for NXDOMAIN RRs 1275 Nameserver requirements to support BULK RRs will minimally increase 1276 CPU utilization requirements compared to most RR types. However, 1277 since the inception of DNSSEC more is expected of DNS servers at a 1278 system resource level and it is the authors' belief the benefit 1279 outweighs the sacrifice. 1281 A quick comparison of BULK versus bind's $GENERATE expansion reveals 1282 much more memory would be sacrificed with $GENERATES to save the CPU 1283 cycles required to support BULK records. Additionally, $GENERATES 1284 cannot be transferred (i.e. AXFR) without expansion and an IPv6 CIDR 1285 even as small as /96 would be simply impossible. BULK on the other 1286 hand can easily support IPv6 CIDRs of /64 and much larger with very 1287 little effort. 1289 6.2. Pre-Adoption Nameserver Implications 1291 While there is an added demand on authoritative nameservers, there 1292 are no new requirements to recursive (caching) resolvers for non- 1293 DNSSEC record handling. Even authoritative nameservers are able to 1294 transfer to and from supporting nameservers with no requirement 1295 (although would be unable to return BULK generated records without 1296 support). 1298 Prior to widespread adoption on the authoritative side all generated 1299 records would be invisible if served on nameservers lacking support. 1300 Since generated records are generally NOT service impacting records 1301 this should be understood but not of great concern. 1303 Once adoption has reached an appreciable level on the producer 1304 (authoritative) side only DNSSEC requirements remain for the consumer 1305 (resolver) side. This behavior is fully expected. 1307 7. Security Considerations 1309 Two known security considerations exist for the BULK resource record, 1310 DNSSEC and DDOS attack vectors. Both are addressed in the following 1311 sections. 1313 7.1. DNSSEC Signature Strategies 1315 DNSSEC was designed to provide verification (validation) for DNS 1316 resource records. In a nutshell this requires each (owner, class, 1317 type) tuple to have its own signature. This essentially defeats the 1318 purpose of providing large generated blocks of RRs in a single RR as 1319 each generated RR would require its own legitimate RRSIG record. 1321 In the following sections several options are discussed to address 1322 this issue. Of the options, on-the-fly provides the most secure 1323 solution and NPN provides the most flexible. 1325 7.1.1. On-the-fly (Live) Signatures 1327 This solution requires authoritative nameservers to sign generated 1328 records _as_they_are_generated_. Not all authoritative nameserver 1329 implementations offer on-the-fly (realtime) signatures so this 1330 solution would either require all implementations to support on-the- 1331 fly signing or be ignored by implementations which can not or will 1332 not comply. 1334 No changes to recursive (resolving) nameservers is required to 1335 support this solution. 1337 7.1.2. Normalized (NPN Based) Signatures 1339 This solution provides the most flexible solution as nameservers 1340 without on-the-fly signing capabilities can still support signatures 1341 for BULK records. The down side to this solution is it requires 1342 DNSSEC aware recursive (resolving) nameserver support. Unless a 1343 recursive nameserver can verify the signature it is _unverifiable_. 1345 It has been pointed out due to this limitation creation of DNSSEC 1346 signed BULK RRs requiring NPN support SHOULD be formally discouraged 1347 until such time a respectable percentage (>80) of DNSSEC verification 1348 (validation) nameservers "in-the-wild" possess NPN processing 1349 capabilities. Until that time, on-the-fly signing and unsigned BULK 1350 records offer the intended capabilities of this document while 1351 requiring zero new features to support RR resolution. The authors 1352 would like to encourage opening this door for pattern based 1353 technologies such as NPN records as a solution to BULK RRs as well as 1354 other pattern based RRs to come. Given enough time, enough 1355 nameservers will be patched and upgraded for unrelated reasons and by 1356 means of simple attrition can supply a level of "inertia" and 1357 eventually widespread adoption can be assumed. 1359 NPN records are likely to be a topic of great debate as to their own 1360 security limitations. It is, however, the authors' belief; while any 1361 logic which limits the input of digital signatures, lessens the 1362 validity of such signatures, the limitation is minimal and the gain 1363 is significant. The main reason for this is as a general rule, RRs 1364 used in a generic manner such as conventional $GENERATE RRs or 1365 scripted mass pattern generated RRs have a lesser importance than 1366 other RRs in managed zones. These therefore inherently pose less 1367 risk by means of attack and have a much less reward by defeating 1368 security measures. 1370 This being said, care must still be taken to set the Ignore fields 1371 appropriately to minimize exposure and only use NPN RRs to secure 1372 pattern-based records such as BULK. 1374 7.1.3. Non-DNSSEC Zone Support Only 1376 As a final option zones which wish to remain entirely without DNSSEC 1377 support may serve such zones without either of the above solutions 1378 and records generated based on BULK RRs will require zero support 1379 from recursive (resolving) nameservers. 1381 7.2. DNSSEC Verifier Details 1383 Verification of DNSSEC signed BULK generated RRs may be performed 1384 against on-the-fly signatures with zero modification to their 1385 behavior. However, verification against NPN records would require 1386 changes to the logic to incorporate processing RDATA generated by 1387 BULK logic as described above so the results will be compatible. 1389 7.3. DDOS Attack Vectors and Mitigation 1391 As an additional defense against Distributed Denial Of Service (DDOS) 1392 attacks against recursive (resolving) nameservers it is highly 1393 recommended shorter TTLs be used for BULK RRs than others. While 1394 disabling caching with a zero TTL is not recommended (as this would 1395 only result in a shift of the attack target) a balance will need to 1396 be found. While this document uses 24 hours (86400) in its examples 1397 values between 300 to 900 are likely more appropriate and is 1398 RECOMMENDED. What is ultimately deemed appropriate may differ from 1399 zone to zone and administrator to administrator. 1401 7.4. Implications of Large Scale DNS Records 1403 The production of such large scale "records in the wild" may have 1404 some unintended side-effects. These side-effects could be of concern 1405 or add unexpected complications to DNS based security offerings or 1406 forensic and anti-spam measures. While outside the scope of this 1407 document, implementors of technology relying on DNS resource records 1408 for critical decision making must take into consideration how the 1409 existence of such a volume of records might impact their technology. 1411 Solutions to the "magnitude" problem for BULK generated RRs are 1412 expected be similar if not identical to that of existing wildcard 1413 records, the core difference being the resultant RDATA will be unique 1414 for each requested Domain Name within its scope. 1416 The authors of this document are confident that by careful 1417 consideration, _negative_side-effects_ produced by implementing the 1418 features described in this document _can_be_eliminated_ from any such 1419 service or product. 1421 8. IANA Considerations 1423 IANA is requested to assign numbers for two DNS resource record types 1424 identified in this document; BULK and NPN. 1426 9. Acknowledgments 1428 This document was created as an extension to the DNS infrastructure. 1429 As such, many people over the years have contributed to its creation 1430 and the authors are appreciative to each of them even if not thanked 1431 or identified individually. 1433 A special thanks is extended for the kindness, wisdom and technical 1434 advice of: 1436 Robert Whelton (CenturyLink, Inc.) 1438 10. References 1440 10.1. Normative References 1442 [US-ASCII] American National Standards Institute, "Coded Character 1443 Set -- 7-bit American Standard Code for Information 1444 Interchange", ANSI X3.4, 1986. 1446 [RFC1034] Mockapetris, P., "Domain names - concepts and 1447 facilities", STD 13, RFC 1034, November 1987. 1449 [RFC1035] Mockapetris, P., "Domain names - implementation and 1450 specification", STD 13, RFC 1035, November 1987. 1452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1453 Requirement Levels", BCP 14, RFC 2119, March 1997. 1455 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1456 Specification", RFC 2181, July 1997. 1458 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1459 NCACHE)", RFC 2308, March 1998. 1461 [RFC2317] Eidnes, H., de Groot, G., Vixie, P. "Classless IN- 1462 ADDR.ARPA delegation", RFC 2317, March 1998. 1464 [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name 1465 System (DNS)", RFC 2536, March 1999. 1467 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 1468 ( SIG(0)s )", RFC 2931, September 2000. 1470 [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the 1471 Domain Name System (DNS)", RFC 3110, May 2001. 1473 [RFC3597] A. Gustafsson, "Handling of Unknown DNS Resource Record 1474 (RR) Types", RFC 3597, September 2003. 1476 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1477 Rose, "DNS Security Introduction and Requirements", RFC 1478 4033, March 2005. 1480 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1481 Rose, "Resource Records for the DNS Security Extensions", 1482 RFC 4034, March 2005. 1484 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1485 Rose, "Protocol Modifications for the DNS Security 1486 Extensions", RFC 4035, March 2005. 1488 [RFC5234] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 1489 Specifications: ABNF", RFC 5234, January 2008. 1491 10.2. Informative References 1493 Authors' Addresses 1495 John Woodworth 1496 4250 North Fairfax Drive 1497 Arlington, VA 22203 1498 USA 1500 EMail: John.Woodworth@CenturyLink.com 1501 Dean Ballew 1502 2355 Dulles Corner Boulevard Suite 200 300 1503 Herndon, VA 20171 1504 USA 1506 EMail: Dean.Ballew@CenturyLink.com 1508 Shashwath Bindinganaveli Raghavan 1509 2355 Dulles Corner Boulevard Suite 200 300 1510 Herndon, VA 20171 1511 USA 1513 EMail: Shashwath.Bindinganaveliraghavan@CenturyLink.com 1515 Acknowledgement 1517 Funding for the RFC Editor function is currently provided by the 1518 Internet Society.