idnits 2.17.1 draft-woodworth-bulk-rr-06.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 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 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 RFC222, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4034, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4035, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4033, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2308, 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 RFC2308, updated by this document, for RFC5378 checks: 1997-01-17) -- 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 (July 3, 2017) is 2483 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 945, but not defined == Missing Reference: '0-3' is mentioned on line 945, but not defined == Missing Reference: '0-10' is mentioned on line 903, but not defined == Unused Reference: 'RFC3597' is defined on line 790, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group J. Woodworth 3 Internet-Draft D. Ballew 4 Obsoletes: 222 (if approved) CenturyLink, Inc. 5 Updates: 2308, 4033, 4034, 4035 (if S. Bindinganaveli Raghavan 6 approved) Hughes Network Systems 7 Intended status: Standards Track D. Lawrence 8 Expires: January 4, 2018 Akamai Technologies 9 July 3, 2017 11 BULK DNS Resource Records 12 draft-woodworth-bulk-rr-06 14 Abstract 16 The BULK DNS resource record type defines a method of pattern-based 17 creation of DNS resource records based on numeric substrings of query 18 names. The intent of BULK is to simplify generic assignments in a 19 memory-efficient way that can be easily shared between the primary 20 and secondary nameservers for a zone. 22 Ed note 24 Text inside square brackets ([]) is additional background 25 information, answers to frequently asked questions, general musings, 26 etc. They will be removed before publication. This document is 27 being collaborated on in GitHub at . The most recent version of the document, open issues, etc 29 should all be available here. The authors gratefully accept pull 30 requests. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 4, 2018. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Background and Terminology . . . . . . . . . . . . . . . 4 68 2. The BULK Resource Record . . . . . . . . . . . . . . . . . . 4 69 2.1. BULK RDATA Wire Format . . . . . . . . . . . . . . . . . 4 70 2.2. The BULK RR Presentation Format . . . . . . . . . . . . . 6 71 3. BULK Replacement . . . . . . . . . . . . . . . . . . . . . . 7 72 3.1. Matching the Domain Name Pattern . . . . . . . . . . . . 7 73 3.2. Record Generation using Replacement Pattern . . . . . . . 7 74 3.2.1. Delimiters . . . . . . . . . . . . . . . . . . . . . 8 75 3.2.2. Delimiter intervals . . . . . . . . . . . . . . . . . 8 76 3.2.3. Padding length . . . . . . . . . . . . . . . . . . . 8 77 3.2.4. Final processing . . . . . . . . . . . . . . . . . . 9 78 4. The NPN Resource Record . . . . . . . . . . . . . . . . . . . 9 79 4.1. NPN RDATA Wire Format . . . . . . . . . . . . . . . . . . 10 80 4.2. The NPN RR Presentation Format . . . . . . . . . . . . . 11 81 4.3. Use and Normalization Processing of NPN RRs . . . . . . . 11 82 4.3.1. Pseudocode for NPN Normalization Processing . . . . . 13 83 4.4. Pattern Based DNSSEC support . . . . . . . . . . . . . . 13 84 5. Known Limitations . . . . . . . . . . . . . . . . . . . . . . 13 85 5.1. Unsupported Nameservers . . . . . . . . . . . . . . . . . 14 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 6.1. DNSSEC Signature Strategies . . . . . . . . . . . . . . . 14 88 6.1.1. On-the-fly Signatures . . . . . . . . . . . . . . . . 14 89 6.1.2. Normalized (NPN-Based) Signatures . . . . . . . . . . 15 90 6.1.3. Non-DNSSEC Zone Support Only . . . . . . . . . . . . 15 91 6.2. DNSSEC Validator Details . . . . . . . . . . . . . . . . 15 92 6.3. DDOS Attack Vectors and Mitigation . . . . . . . . . . . 16 93 6.4. Implications of Large-Scale DNS Records . . . . . . . . . 16 94 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 99 10.2. Informative References . . . . . . . . . . . . . . . . . 18 100 Appendix A. BULK Examples . . . . . . . . . . . . . . . . . . . 18 101 A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 18 102 A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 19 103 A.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 19 104 Appendix B. NPN Examples . . . . . . . . . . . . . . . . . . . . 20 105 B.1. EXAMPLE 1 . . . . . . . . . . . . . . . . . . . . . . . . 20 106 B.2. EXAMPLE 2 . . . . . . . . . . . . . . . . . . . . . . . . 21 107 B.3. EXAMPLE 3 . . . . . . . . . . . . . . . . . . . . . . . . 22 108 B.4. EXAMPLE 4 . . . . . . . . . . . . . . . . . . . . . . . . 22 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 111 1. Introduction 113 The BULK DNS resource record defines a pattern-based method for on- 114 the-fly resource record generation. It is essentially an enhanced 115 wildcard mechanism, constraining generated resource record owner 116 names to those that match a pattern of variable numeric substrings. 117 It is also akin to the $GENERATE master file directive [bind-arm] 118 without being limited to numeric values and without creating all 119 possible records in the zone data. 121 For example, consider the following record: 123 example.com. 86400 IN BULK A ( 124 pool-A-[0-255]-[0-255].example.com. 125 10.55.${1}.${2} 126 ) 128 It will answer requests for pool-A-0-0.example.com through pool- 129 A-255-255.example.com with the IPv4 addresses 10.55.0.0 through 130 10.55.255.255. 132 Much larger record sets can be defined while minimizing the 133 associated requirements for server memory and zone transfer network 134 bandwidth. 136 DNSSEC support is also described. The Numeric Pattern Normalization 137 (NPN) resource record provides a way of generating pattern-based 138 DNSSEC signatures, and securely performing DNSSEC validation on such 139 signatures. 141 1.1. Background and Terminology 143 The reader is assumed to be familiar with the basic DNS and DNSSEC 144 concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], and 145 [RFC4035]; subsequent RFCs that update them in [RFC2181] and 146 [RFC2308]; and DNS terms in [RFC7719]. 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 2. The BULK Resource Record 154 The BULK resource record enables an authoritative nameserver to 155 generate RRs for other types based upon the query received. 157 The Type value for the BULK RR type is TBD. 159 The BULK RR is class-independent. 161 2.1. BULK RDATA Wire Format 163 The RDATA for a BULK RR is as follows: 165 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Match Type | / 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Domain Name Pattern / 170 / / 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 / / 173 / Replacement Pattern / 174 / / 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Match Type identifies the type of the RRset to be generated by this 178 BULK record. It is two octets corresponding to an RR TYPE code as 179 specified in [RFC1035], Section 3.2.1. 181 Domain Name Pattern consists of a pattern encoded as a wire-format 182 fully qualified domain name. The full name is used so that numeric 183 substrings above the zone cut can be captured in addition to those in 184 the zone. It needs no length indicator for the entire field because 185 the root label marks its end. 187 Special characters are interpreted as per the following Augmented 188 Backus-Naur Form (ABNF) notation from [RFC5234]. 190 match = 1*(range / string) 192 range = "[" decnum "-" decnum "]" / 193 "<" hexnum "-" hexnum ">" 194 ; create references for substitution 195 ; limit of 32 references 197 string = 1*(ctext / quoted-char) 199 decnum = 1*decdigit 200 ; constrained to 65535 maximum. 202 hexnum = 1*hexdigit 203 ; constrained to ffff maximum. 205 octet = %x00-FF 207 decdigit = %x30-39 208 ; 0-9 209 hexdigit = decdigit / 0x41-0x46 / 0x61-66 210 ; 0-9, A-F, a-f 212 ctext = 214 quoted-char = "\" octet 215 ; to allow special characters as literals 217 [ Should [] and <> be allowed as short for [0-255] and <00-ff>? ] 219 Interpretation of the Domain Name Pattern is described in detail in 220 the "BULK Replacement" section. 222 The limit of 32 references is meant to simplify implementation 223 details. It is largely but not entirely arbitrary, as it could 224 capture every individual character of the text representation of a 225 full IPv6 address. 227 Replacement Pattern describes how the answer RRset MUST be generated 228 for the matching query. It needs no length indicator because its end 229 can be derived from the RDATA length minus Match Type and Domain Name 230 Pattern lengths. It uses the following additional ABNF elements: 232 replace = 1*(reference / string) 234 reference = "$" "{" (positions / "*") [options] "}" 236 positions = (position / posrange) 0*("," (position / posrange)) 238 posrange = position "-" position 240 position = 1*decnum 242 options = delimiter [interval [padding]] 244 delimiter = "|" 0*(ctext | quoted-char) 245 ; "\|" to use "|" as delimiter 246 ; "\\" to use "\" as delimiter 248 interval = "|" *2decdigit 250 padding = "|" *2decdigit 252 [ Is this complexity beyond simple ${1}, ${2}, etc, really worth it? 253 I definitely see how it could make for shorter replacement patterns, 254 but does it enhance their clarity and usability? ] 256 The Replacement Pattern MUST end in a period if it is intended to 257 represent a fully qualified domain name. 259 2.2. The BULK RR Presentation Format 261 Match Type is represented as an RR type mnemonic or with [RFC3597]'s 262 generic TYPE mechanism. 264 Domain Name Pattern is represented as a fully qualified domain name 265 as per [RFC1035] Section 5.1 rules for encoding whitespace and other 266 special characters. 268 Replacement Pattern is represented by the standard 269 text rules for master files as per [RFC1035] section 5.1. 271 It is suggested that lines longer than 80 characters be wrapped with 272 parenthetical line continuation, per [RFC1035] Section 5.1, starting 273 after Match Type and ending after Replacement Pattern. 275 3. BULK Replacement 277 When an authoritative nameserver receives a query for which it does 278 not have a matching name or a covering wildcard, it MUST then look 279 for BULK RRs at the zone apex, selecting all BULK RRs with a Match 280 Type that matches the query type and a Domain Name Pattern that 281 matches the query name. Note that query type ANY will select all 282 Match Types, and all query types match a CNAME Match Type [ and 283 DNAME? ]. One or more answer RRs will be generated per the 284 replacement rules below. Examples are provided in an appendix. 286 By only triggering the BULK algorithm when the query name does not 287 exist, administrators are given the flexibility to explicitly 288 override the behaviour of specific names that would otherwise match 289 the BULK record's Domain Name Pattern. This is unlike BIND's 290 $GENERATE directive, which adds the generated RRs to any existing 291 names. 293 3.1. Matching the Domain Name Pattern 295 A query name matches the Domain Name Pattern if the characters that 296 appear outside the numeric ranges match exactly and those within 297 numeric ranges have values that fall within the range. Numeric 298 matches MUST be of the appropriate decimal or hexadecimal type as 299 specified by the delimiters in the pattern. For example, if a range 300 is given as [0-255], then FF does not match even though its value as 301 a hexadecimal number is within the range. 303 When a query name matches a Domain Name Pattern, the value in each 304 numeric range is stored for use by the Replacement Pattern, with 305 reference numbers starting at 1 and counting from the left. For 306 example, matching the query name host-24-156 against 307 host-[0-255]-[0-255] assigns 24 to ${1} and 156 to ${2}. 309 3.2. Record Generation using Replacement Pattern 311 The Replacement Pattern generates the record data by replacing the 312 ${...} references with data captured from the query name, and copying 313 all other characters literally. 315 The simplest form of reference uses only the reference number between 316 the braces, "{" and "}". The value of the reference is simply copied 317 directly from the matching position of the query name. 319 The next form of reference notation uses the asterisk, "*". With 320 ${*}, all captured values in order of ascending position, delimited 321 by its default delimiter (described below), are placed in the answer. 323 Numeric range references, such as ${1-4}, replaces all values 324 captured by those references, in order, delimited by the default 325 delimiter described below. To reverse the order in which they are 326 copied, reverse the upper and lower values, such as ${4-1}. This is 327 useful for generating PTR records from query names in which the 328 address is encoded in network order. 330 Similar to range references, separating positions by commas creates 331 sets for replacement. For example, ${1,4} would be replaced by the 332 first and fourth captured values, delimited its default delimiter. 333 This notation may be combined with the numeric range form, such as 334 ${3,2,1,8-4}. 336 3.2.1. Delimiters 338 A reference can specify a delimiter to use by following a vertical 339 bar, "|", with zero or more characters. Zero characters, such as in 340 ${1-3|}, means no delimiter is used, while other characters up to an 341 unescaped vertical bar or closing brace are copied between position 342 values in the replacement. The default delimiter is the hyphen, "-". 344 3.2.2. Delimiter intervals 346 A second vertical bar in the reference options introduces a delimiter 347 interval. The default behavior of a multi-position reference is to 348 combine each captured value specified with a delimiter between each. 349 With a delimiter interval the delimiters are only added between every 350 Nth value. For example, ${*|-|4} adds a hyphen between every group 351 of four captured positions. This can be a handy feature in the IPv6 352 reverse namespace where every nibble is captured as a separate value 353 and generated hostnames include sets of 4 nibbles. An empty or 0 354 value for the delimiter interval MUST be interpreted as the default 355 value of 1. 357 3.2.3. Padding length 359 The fourth and final reference option determines the field width of 360 the copied value. Shorter values MUST be padded with leading zeroes 361 ("0") and longer values MUST be truncated to the width. 363 The default behavior, and that of an explicit empty padding length, 364 is that the captured query name substring is copied exactly. A width 365 of zero "0" is a signal to "unpad", and any leading zeros MUST be 366 removed. [ Unnecessary complexity? ] 368 If a delimiter interval greater than 1 is used, captured values 369 between the intervals will be concatenated and the padding or 370 unpadding applied as a unit and not individually. An example of this 371 would be ${*||4|4} which would combine each range of 4 captured 372 values and pad or truncate them to a width of 4 characters. 374 [ If this is kept, the element/feature should probably be renamed 375 from "padding" since it is just as likely to truncate. ] 377 3.2.4. Final processing 379 The string that results from all replacements is converted to the 380 appropriate RDATA format for the record type. If the conversion 381 fails, the SERVFAIL rcode MUST be set on the response. 383 The TTL of each RR generated by a BULK RR is the TTL of the 384 corresponding BULK record itself. [ BULK should probably have its 385 own TTL field because using that of the record itself feels like bad 386 design. On the other hand, if BULK is never meant to be queried for 387 directly and only appears in authoritative data, its own TTL is 388 pretty useless normally. ] 390 If the generated record type is one that uses domain names in its 391 resource record data, such as CNAME, a relative domain names MUST be 392 fully qualified with the origin domain of the BULK RR. 394 4. The NPN Resource Record 396 The Numeric Pattern Normalization (NPN) resource record provides pre- 397 processing information to reduce the number of possible variants that 398 can be generated by a BULK RR into one signable record. By 399 identifying parts of the dynamic resource record which should be 400 ignored or represented as a static value, one exemplar record and 401 signature is used to validate all other records that match the 402 pattern. 404 For example, a pattern replacement like pool-A-${1}-${2}.example.com 405 that generates PTR records for pool-A-0-0.example.com through pool- 406 A-255-255.example.com would have an NPN record that signals a 407 validating resolver to verify all pool-A-#-#.example.com names 408 against a record for pool-A-9-9.example.com. 410 Though it is imperfect in that forged records could be validated as 411 legitimate, it is nevertheless an improvement over the security 412 afforded by non-DNSSEC DNS. 414 The Type value for the NPN RR type is TBD. 416 The NPN RR is class independent and has no special TTL requirements. 418 4.1. NPN RDATA Wire Format 420 The RDATA for an NPN RR consists of a 2 octet Match Type field, a 1 421 octet Flags field, a 1 octet Owner Ignore field, a 1 octet Left 422 Ignore field and a 1 octet Right Ignore field. 424 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Match Type | Flags | Owner Ignore | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Left Ignore | Right Ignore | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Match Type indicates the type of the RRset with which this record is 433 associated. 435 Flags defines additional processing parameters for data 436 normalization. This document defines only the Period-As-Number flag 437 "." (position 5), the Hyphen-As-Number "-" (position 6) and the 438 hexadecimal flag "X" (position 7). All other flags are reserved for 439 future use. 441 0 1 2 3 4 5 6 7 442 +-+-+-+-+-+-+-+-+ 443 |Reserved |.|-|X| 444 +-+-+-+-+-+-+-+-+ 446 Bits 0-4: Reserved for future 448 Bit 5: Period As Number (.) Flag 449 If 0, periods are treated as non-digits. 450 If 1, periods will be processed as digits. 452 Bit 6: Hyphen As Number (-) Flag 453 If 0, hyphens are treated as non-digits. 454 If 1, hyphens will be processed as digits. 456 Bit 7: Hexadecimal (X) Flag 457 If 0, numeric digits include only 0-9. 458 If 1, numeric digits include a-f in addition to 0-9. 460 Owner Ignore defines the number of octets in the owner name, as 461 counted from the left, which MUST be ignored by the normalization 462 process. This field offers additional security to pattern based 463 signatures which may not be immediately apparent. By restricting the 464 leftmost characters defined by this value, ultimately the length of 465 the generated portion of the accompanying BULK RR will be confined 466 accordingly. 468 Left Ignore defines the number of octets of the generated RDATA, as 469 counted from the left, which MUST be ignored by the normalization 470 process. 472 Right Ignore defines the number of octets of the generated RDATA, as 473 counted from the right, which MUST be ignored by the normalization 474 process. 476 4.2. The NPN RR Presentation Format 478 Match Type is represented as an RR type mnemonic or with [RFC3597]'s 479 generic TYPE mechanism. 481 Flags is a string of characters indicating the status of each bit as 482 per the following table. The characters can appear in any order. 484 +------------------+-----------+-----------+ 485 | Flag | Unset | Set | 486 +------------------+-----------+-----------+ 487 | Period As Number | | . | 488 +------------------+-----------+-----------+ 489 | Hyphen As Number | | - | 490 +------------------+-----------+-----------+ 491 | Hexadecimal | 9 | f | 492 +------------------+-----------+-----------+ 494 Owner Ignore, Left Ignore, and Right Ignore are displayed as unsigned 495 decimal integers, ranging from 0 through 255. 497 4.3. Use and Normalization Processing of NPN RRs 499 [ This section needs reworking still, and should perhaps be pulled 500 out into a separate document. Notably one of issues that is not 501 really described well is that, as designed so far, at signing time 502 the NPN record has to be associated with the matching BULK record, 503 which is slightly problematic with regard to the idea that NPNs are 504 suggested to be extended to be used in the future with other 505 patterns-based record generation. Once the appropriate BULK record 506 is selected, the signer would then have to understand its semantics 507 to fake up the exemplar to sign - raising the question as to why it 508 doesn't also know the appropriate values for the Ignore fields, since 509 it will have to understand what the static and variable parts are. 511 One way around all this is to just sign the BULK record itself and 512 return it in the additional section along with the answer, so that 513 the resolver could validate not only a signature but the resulting 514 record based on the substitution algorithm. It'd still be 515 problematic for older DNSSEC validators that don't grok BULK, but no 516 more so than not grokking NPN. Unfortunately to them in both cases 517 the type-appropriate answer itself will be unsigned and thus fail 518 validation. ] 520 This document provides a minor yet significant modification to DNSSEC 521 regarding how RRsets will be signed or verified. Specifically the 522 Signature Field of [RFC4034], Section 3.1.8. Prior to processing 523 into canonical form, signed zones may contain associated RRs where; 524 owner, class and type of a non NPN RR directly corresponds with an 525 NPN RR matching owner, class and Match Type. If this condition 526 exists the NPN RR's RDATA defines details for processing the 527 associated RDATA into a "Normalized" format. Normalized data is 528 based on pre-canonical formatting and zero padded for "A" and "AAAA" 529 RR types for acceptable precision during the process. This concept 530 will become clearer in the NPN pseudocode and examples provided in 531 the sections to follow. 533 The rules for this transformation are simple: 535 o For RR's Owner field, characters from the beginning to the index 536 of the Owner Ignore value or the final string of characters 537 belonging to the zone's ORIGIN MUST NOT be modified by this 538 algorithm. While the Owner Ignore value is not used for BULK 539 records but is included with the expectation other pattern-based 540 resource records may emerge and leverage NPN records for their 541 DNSSEC support requirements. 543 o For RR's RDATA field, character from beginning to the index of 544 Left Ignore value or characters with index of Right Ignore value 545 to the end MUST NOT be modified by this algorithm. 547 o In the remaining portion of both Owner and RDATA strings of 548 numeric data, defined as character "0" through "f" or "0" through 549 "9" depending on whether or not the Hexadecimal flag is set or 550 not, MUST be consolidated to a single character and set to the 551 highest value defined by the Hexadecimal flag. Examples may be 552 found in the following section. If period-as-number or hyphen-as- 553 number flags are set whichever are used ("." or "-") would be 554 treated as part of the number and consolidated where appropriate. 556 Once the normalization has been performed the signature will continue 557 processing into canonical form using the normalized RRs in the place 558 of original ones. 560 NPN RRs MAY be included in the "Additional" section to provide a hint 561 of the NPN processing required for the verification path. 563 It is important to note, properly sizing the Ignore fields is 564 critical to minimizing the risk of spoofed signatures. Never 565 intentionally set all Ignore values to zero in order to make 566 validation easier as it places the validity of zone data at risk. 567 Only accompany RRs which are pattern derived (such as BULK) with NPN 568 records as doing so may unnecessarily reduce the confidence level of 569 generated signatures. 571 4.3.1. Pseudocode for NPN Normalization Processing 573 This section provides a simple demonstration of process flow for NPN 574 rdata normalization and DNSSEC signatures. 576 The pseudocode provided below assumes all associated RRs are valid 577 members of a DNSSEC-compatible RRset, including BULK generated ones. 579 for rr in rrset 580 if (has_NPN) 581 rr.rdata_normal = NPN_normalize 582 add_to_sigrrset 584 next 585 else 586 add_to_sigrrset 587 next 589 process_canonical_form 591 dnssec_sign 593 Similar logic MUST be used for determining DNSSEC validity of RRsets 594 in validating nameservers for signatures generated based on NPN 595 normalization. 597 4.4. Pattern Based DNSSEC support 599 The NPN resource record could be used to support other dynamic RR 600 types which do not currently exist. 602 5. Known Limitations 604 This section defines known limitations of the BULK resource type. 606 5.1. Unsupported Nameservers 608 Authoritative nameservers that do not understand the semantics of the 609 new record type will not be able to deliver the intended answers even 610 when the type appears in their zone data This significantly affects 611 the interoperability of primary versus secondary authorities that are 612 not all running the same software. Adding new RRs which affect 613 handling by authoritative servers, or being unable to add them, is an 614 issue that needs to be explored more thoroughly within dnsop. 616 On the resolver side, rolling out a new semantics in DNSSEC has also 617 proven to be difficult in the past. Lacking NPN support effectively 618 means that operators using BULK will have to forego DNSSEC signing of 619 the affected zones, or do online signing of the dynamically generated 620 records. 622 6. Security Considerations 624 Two known security considerations exist for the BULK resource record, 625 DNSSEC and DDOS attack vectors. 627 6.1. DNSSEC Signature Strategies 629 DNSSEC was designed to provide validation for DNS resource records. 630 In a nutshell this requires each (owner, class, type) tuple to have 631 its own signature. This essentially defeats the purpose of providing 632 large generated blocks of RRs in a single RR as each generated RR 633 would require its own legitimate RRSIG record. 635 In the following sections several options are discussed to address 636 this issue. Of the options, on-the-fly provides the most secure 637 solution and NPN provides the most flexible. 639 6.1.1. On-the-fly Signatures 641 This solution requires authoritative nameservers to sign generated 642 records as they are created. Not all authoritative nameserver 643 implementations offer on-the-fly signatures, and even with those that 644 do not all operators will want to keep signing keys online, so this 645 solution would either require all implementations to support on-the- 646 fly signing or be ignored by implementations which can not or will 647 not comply. 649 No changes to validating resolvers is required to support this 650 solution. 652 6.1.2. Normalized (NPN-Based) Signatures 654 This solution provides the most flexible solution as nameservers 655 without on-the-fly signing capabilities can still support signatures 656 for BULK records. The down side to this solution is it requires 657 additional DNSSEC-aware resolver support. 659 It has been pointed out that due to this limitation, creation of 660 DNSSEC-signed BULK RRs requiring NPN support SHOULD be formally 661 discouraged until such time a respectable percentage (>80%) of 662 validating resolvers in-the-wild possess NPN processing capabilities. 663 Until that time, on-the-fly signing and unsigned records offer the 664 intended capabilities of the BULK specification, while requiring zero 665 new features to support RR resolution. The authors would like to 666 encourage opening this door for pattern based technologies such as 667 NPN records as a solution to BULK RRs as well as other pattern based 668 RRs to come. Given enough time, enough nameservers will be patched 669 and upgraded for unrelated reasons and by means of simple attrition 670 can supply a level of inertia and eventually widespread adoption can 671 be assumed. 673 NPN records are likely to be a topic of great debate as to their own 674 security limitations. It is, however, the authors' belief that while 675 any logic which limits the input of digital signatures lessens the 676 validity of those signatures, the limitation is minimal and the gain 677 is significant. The main reason for this is as a general rule, RRs 678 used in a generic manner such as conventional $GENERATE RRs or 679 scripted mass pattern generated RRs have a lesser importance than 680 other RRs in managed zones. These therefore inherently pose less 681 risk by means of attack and have a much less reward by defeating 682 security measures. 684 This being said, care must still be taken to set the Ignore fields 685 appropriately to minimize exposure and only use NPN RRs to secure 686 pattern-based records such as BULK. 688 6.1.3. Non-DNSSEC Zone Support Only 690 As a final option zones which wish to remain entirely without DNSSEC 691 support may serve such zones without either of the above solutions 692 and records generated based on BULK RRs will require zero support 693 from recursive (resolving) nameservers. 695 6.2. DNSSEC Validator Details 697 Verification of DNSSEC signed BULK generated RRs may be performed 698 against on-the-fly signatures with zero modification to their 699 behavior. However, verification using NPN records would require 700 changes to the logic to incorporate processing RDATA generated by 701 BULK logic as described above so the results will be compatible. 703 6.3. DDOS Attack Vectors and Mitigation 705 As an additional defense against Distributed Denial Of Service (DDOS) 706 attacks against recursive (resolving) nameservers it is highly 707 recommended shorter TTLs be used for BULK RRs than others. While 708 disabling caching with a zero TTL is not recommended, as this would 709 only result in a shift of the attack target, a balance will need to 710 be found. While this document uses 24 hours (86400 seconds) in its 711 examples, values between 300 to 900 seconds are likely more 712 appropriate and is RECOMMENDED. What is ultimately deemed 713 appropriate may differ from zone to zone and administrator to 714 administrator. 716 [ I am unclear how this helps DDOS mitigation against anyone at all. 717 ] 719 6.4. Implications of Large-Scale DNS Records 721 The production of such large-scale records in the wild may have some 722 unintended side-effects. These side-effects could be of concern or 723 add unexpected complications to DNS based security offerings or 724 forensic and anti-spam measures. While outside the scope of this 725 document, implementers of technology relying on DNS resource records 726 for critical decision making must take into consideration how the 727 existence of such a volume of records might impact their technology. 729 Solutions to the magnitude problem for BULK generated RRs are 730 expected be similar if not identical to that of existing wildcard 731 records, the core difference being the resultant RDATA will be unique 732 for each requested Domain Name within its scope. 734 The authors of this document are confident that by careful 735 consideration, negative_side-effects produced by implementing the 736 features described in this document can be eliminated from any such 737 service or product. 739 7. Privacy Considerations 741 Neither the BULK nor NPN records introduce any new privacy concerns 742 to DNS data. 744 8. IANA Considerations 746 IANA is requested to assign numbers for two DNS resource record types 747 identified in this document: BULK and NPN. 749 9. Acknowledgments 751 This document was created as an extension to the DNS infrastructure. 752 As such, many people over the years have contributed to its creation 753 and the authors are appreciative to each of them even if not thanked 754 or identified individually. 756 A special thanks is extended for the kindness, wisdom and technical 757 advice of Robert Whelton (CenturyLink, Inc.) and Gary O'Brien 758 (Secure64). 760 10. References 762 10.1. Normative References 764 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 765 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 766 . 768 [RFC1035] Mockapetris, P., "Domain names - implementation and 769 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 770 November 1987, . 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels", BCP 14, RFC 2119, 774 DOI 10.17487/RFC2119, March 1997, 775 . 777 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 778 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 779 . 781 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 782 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 783 . 785 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 786 ADDR.ARPA delegation", BCP 20, RFC 2317, 787 DOI 10.17487/RFC2317, March 1998, 788 . 790 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 791 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 792 2003, . 794 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 795 Rose, "DNS Security Introduction and Requirements", 796 RFC 4033, DOI 10.17487/RFC4033, March 2005, 797 . 799 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 800 Rose, "Resource Records for the DNS Security Extensions", 801 RFC 4034, DOI 10.17487/RFC4034, March 2005, 802 . 804 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 805 Rose, "Protocol Modifications for the DNS Security 806 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 807 . 809 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 810 Specifications: ABNF", STD 68, RFC 5234, 811 DOI 10.17487/RFC5234, January 2008, 812 . 814 10.2. Informative References 816 [bind-arm] 817 Internet Systems Consortium, "BIND 9 Configuration 818 Reference", 2016, 819 . 822 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 823 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 824 2015, . 826 Appendix A. BULK Examples 828 A.1. Example 1 830 $ORIGIN 2.10.in-addr.arpa. 831 @ 86400 IN BULK PTR ( 832 [0-255].[0-255].[0-255].[0-255].in-addr.arpa. 833 pool-${4-1}.example.com. 834 ) 836 A query received for the PTR of 4.3.2.10.in-addr.arpa will create the 837 references ${1} through ${4} with the first four labels of the query 838 name. The ${4-1} reference in the replacement pattern will then 839 substitute them in reverse with the default delimiter of hyphen 840 between every character and no special field width modifications. 841 The TTL of the BULK RR is used for the generated record, making the 842 response: 844 4.3.2.10.in-addr.arpa 86400 IN PTR pool-10-2-3-4.example.com. 846 A.2. Example 2 848 $ORIGIN 2.10.in-addr.arpa. 849 @ 86400 IN BULK PTR ( 850 [0-255].[0-255].[0-255].[0-255].in-addr.arpa. 851 pool-${2,1|||3}.example.com. 852 ) 854 Example 2 is similar to Example 1, except that it modifies the 855 replacement pattern. The empty option after the first vertical bar 856 causes no delimiters to be inserted, while the second empty option 857 that would keep the delimiter interval as 1. The latter is relevant 858 because the final value, padding of 3, is applied over each delimiter 859 interval even when no delimiter is used. Not all captures from the 860 substring are required to be used in the response. 862 The result is that a query for the PTR of 4.3.2.10.in-addr.arpa 863 generates this response: 865 4.3.2.10.in-addr.arpa 86400 IN PTR pool-003004.example.com. 867 [ Admittedly you can't do this very effectively without the field 868 width complexity. Is this sort of name common? Does it need 869 support? Admittedly $GENERATE had the feature, but is that reason 870 enough? ] 872 [ Change this to a hex matching example? ] 874 A.3. Example 3 876 This example contains a classless IPv4 delegation on the /22 CIDR 877 boundary as defined by [RFC2317]. The network for this example is 878 "10.2.0/22" delegated to a nameserver "ns1.sub.example.com.". RRs 879 for this example are defined as: 881 $ORIGIN 2.10.in-addr.arpa. 882 @ 7200 IN BULK CNAME [0-255].[0-3] ${*|.}.0-3 883 0-3 86400 IN NS ns1.sub.example.com. 885 A query for the PTR of 25.2.2.10.in-addr.arpa is received and the 886 BULK record with the CNAME Match Type matches all query types. 25 887 and 2 are captured as references, and joined in the answer by the 888 period (".") character as a delimiter, with ".0-3" then appended 889 literally and fully qualified by the origin domain. The final 890 synthesized record is: 892 25.2.2.10.in-addr.arpa 7200 IN CNAME 25.2.0-3.2.10.in-addr.arpa. 894 [ Without $* and options complexity, the pattern to get the same 895 result is just ${1}.{$2}.0-3 which is not really significantly 896 onerous to enter, and slightly less arcane looking to comprehend. ] 898 Appendix B. NPN Examples 900 B.1. EXAMPLE 1 902 2.10.in-addr.arpa. 86400 IN BULK PTR ( 903 [0-255].[0-10].2.10.in-addr.arpa. 904 pool-A-${1}-${2}.example.com. 905 ) 906 2.10.in-addr.arpa. 86400 IN NPN PTR 9 0 7 13 908 A query for the PTR of address 10.2.3.44 would match As shown 909 previously in BULK RR examples the query would match the BULK record 910 for the query name 44.3.2.10.in-addr.arpa, generating a PTR to pool- 911 A-3-44.example.com as the answer. 913 By protecting the "Ignore" characters from the generated RR's RDATA 914 the focus for normalization becomes "3-44" as illustrated below. 916 0 1 2 3 4 5 6 7 917 v--------- 918 p o o l - A - 3 - 4 4 . e x a m p l e . c o m . 919 ---------^ 920 1 1 1 1 921 3 2 1 0 9 8 7 6 5 4 3 2 1 0 923 Everything to the left of "3-44" will remain intact, as will 924 everything to its right. The remaining characters will be processed 925 for digits between 0 and 9 as indicated by the NPN record's 926 hexadecimal flag 9, and each run of digits replaced by the single 927 character "9". The final Normalized RDATA for *.2.10.in-addr.arpa 928 would therefore become pool-A-9-9.example.com., and its signature 929 would be based on this value to cover all possible permutations of 930 the pool-A-${1}-${2}.example.com replacement pattern. 932 Since the validating nameserver would use the identical NPN record 933 for processing and comparison, all RRs generated by the BULK record 934 can now be verified with a single signature. 936 B.2. EXAMPLE 2 938 This example contains a classless IPv4 delegation on the /22 CIDR 939 boundary as defined by [RFC2317]. The network for this example is 940 "10.2.0/22" delegated to a nameserver "ns1.sub.example.com.". RRs 941 for this example are defined as: 943 $ORIGIN 2.10.in-addr.arpa. 944 0-3 86400 IN NS ns1.sub.example.com. 945 86400 IN BULK CNAME [0-255].[0-3] ${*|.}.0-3 946 86400 IN NPN CNAME 9 0 0 23 948 For this example, a query of "10.2.2.65" would enter the nameserver 949 as "65.2.2.10.in-addr.arpa." and a "CNAME" RR with the RDATA of 950 "65.2.0-3.2.10.in-addr.arpa." would be generated. 952 By protecting the "Ignore" characters from the generated RR's RDATA 953 the focus for normalization becomes "65.2" as illustrated below. 955 0 956 v--------- 957 6 5 . 2 . 0 - 3 . 2 . 1 0 . i n - a d d r . a r p a . 958 ---------^ 959 2 2 2 2 1 1 1 1 1 1 1 1 1 1 960 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 962 Everything to the left of "65.2" will remain intact as will 963 everything to its right. The remaining characters will be processed 964 for digits from 0 through 9 as indicated by the NPN record's 965 hexadecimal flag "9", with each run replaced by the single character 966 "9". The final normalized RDATA would therefore become 9.9.0- 967 3.2.10.in-addr.arpa and its signature would be based on this 968 normalized RDATA field. This new normalized string would be used as 969 an RDATA for the wildcard label of 2.10.in-addr.arpa now encompassing 970 all possible permutations of the ${*|.}.0-3.2.10.in-addr.arpa. 971 pattern. 973 As in example 1, the validatating resolver would use the same NPN 974 record for comparison. 976 B.3. EXAMPLE 3 978 This example provides reverse logic for example 1 by providing an 979 IPv4 address record for a requested hostname. For this example the 980 query is defined as an A record for pool-A-3-44.example.com, with an 981 origin of example.com. RRs for this example are defined as: 983 example.com. 86400 IN BULK A ( 984 pool-A-[0-10]-[0-255] 985 10.2.${*} 986 ) 987 example.com. 86400 IN NPN A 9 0 8 0 989 By protecting the "Ignore" characters from the generated RR's RDATA 990 the focus for normalization becomes "003.044" as illustrated below. 992 0 1 2 3 4 5 6 7 8 993 v-------------- 994 0 1 0 . 0 0 2 . 0 0 3 . 0 4 4 995 ---------------^ 996 0 998 This example illustrates a key point about NPN records; since they 999 are pre-canonical they MUST operate on a strict subset of WIRE 1000 formatted data. For A and AAAA records this means the "Ignore" 1001 fields are based on zero padded data. In this example our generated 1002 record MUST be converted into "010.002.003.044" (shown above) prior 1003 to processing. After processing, wire format would become 1004 "0x0A02032C" (shown in hexadecimal). This format would be too 1005 imprecise for normalization so padded decimal is used. 1007 Everything to the left of "003.044" will remain intact as will 1008 everything to its right. The remaining characters will be processed 1009 for digits between 0 and 9 as indicated by the NPN record's 1010 hexadecimal flag "9" and each run replaced by the single character 1011 "9". The final Normalized RDATA would therefore become 10.2.9.9 and 1012 its signature would be based on this normalized RDATA field. This 1013 new normalized A RR would be used as an RDATA for the wildcard label 1014 of "*.example.com." now encompassing all possible permutations of the 1015 10.2.${*} pattern. 1017 B.4. EXAMPLE 4 1019 This example provides similar logic for an IPv6 AAAA record. For 1020 this example the query is defined as an AAAA record for pool-A-ff- 1021 aa.example.com with an origin of example.com.. RRs for this example 1022 are defined as: 1024 example.com. 86400 IN BULK AAAA ( 1025 pool-A-[0-ffff]-[0-ffff] 1026 fc00::${1}:${2} 1027 ) 1028 example.com. 86400 IN NPN AAAA X 0 30 0 1030 By protecting the "Ignore" characters from the generated RR's RDATA 1031 the focus for normalization becomes "00ff:00aa" as illustrated below. 1033 1 1 1 1 1 1 1 1 1 1 2 2 1034 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1036 f c 0 0 : 0 0 0 0 : 0 0 0 0 : 0 0 0 0 : -/-/ 1038 4 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1039 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 1040 /-/-/- . . . . . . . . . . . . . . . . . . . . . . . . -/-/-/ 1041 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 1042 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1043 v------------------ 1044 /-/- 0 0 0 0 : 0 0 0 0 : 0 0 f f : 0 0 a a 1045 -------------------^ 1046 2 1 1 1 1 1 1 1 1 1 1 1047 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 1049 This example reinforces the point on pre-canonical processing of NPN 1050 records; they MUST operate on a strict subset of WIRE formatted data. 1051 For A and AAAA records this means the "Ignore" fields are based on 1052 zero padded data. In this example our generated record MUST be 1053 converted into "fc00:0000:0000:0000:0000:0000:00ff:00aa" (shown 1054 above) prior to processing. After processing, wire format would 1055 become "0xFC000000000000000000000000FF00AA" (shown in hexadecimal). 1056 This format is slightly misleading as it is truly only 16 bytes of 1057 WIRE data and would be too imprecise for normalization so padded 1058 hexadecimal is used. 1060 Everything to the left of "00ff:00aa" will remain intact as will 1061 everything to its right. The remaining characters will be processed 1062 for numbers between "0" and "f" as indicated by the NPN record's 1063 hexadecimal flag "X" and each run replaced by the single character 1064 "f". The final Normalized RDATA would therefore become "fc00::f:f" 1065 and its signature would be based on this "normalized" RDATA field. 1066 This new "normalized" "AAAA" RR would be used as an RDATA for the 1067 wildcard label of *.example.com now encompassing all possible 1068 permutations of the "fc00::${1}:${2}" pattern. 1070 Authors' Addresses 1072 John Woodworth 1073 CenturyLink, Inc. 1074 4250 N Fairfax Dr 1075 Arlington VA 22203 1076 USA 1078 Email: John.Woodworth@CenturyLink.com 1080 Dean Ballew 1081 CenturyLink, Inc. 1082 2355 Dulles Corner Blvd, Ste 200 300 1083 Herndon VA 20171 1084 USA 1086 Email: Dean.Ballew@CenturyLink.com 1088 Shashwath Bindinganaveli Raghavan 1089 Hughes Network Systems 1090 11717 Exploration Lane 1091 Germantown MD 20876 1092 USA 1094 Email: shashwath.bindinganaveliraghavan@hughes.com 1096 David C Lawrence 1097 Akamai Technologies 1098 150 Broadway 1099 Cambridge MA 02142-1054 1100 USA 1102 Email: tale@akamai.com