idnits 2.17.1 draft-woodworth-bulk-rr-09.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 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 21, 2019) is 1740 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-255' is mentioned on line 701, but not defined == Missing Reference: '0-3' is mentioned on line 701, but not defined == Unused Reference: 'RFC3597' is defined on line 576, 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 (~~), 5 warnings (==), 7 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 Updates: 2308, 4033, 4034, 4035 (if CenturyLink, Inc. 5 approved) S. Bindinganaveli Raghavan 6 Intended status: Informational Hughes Network Systems 7 Expires: January 22, 2020 D. Lawrence 8 Oracle 9 July 21, 2019 11 BULK DNS Resource Records 12 draft-woodworth-bulk-rr-09 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 https://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 22, 2020. 49 Copyright Notice 51 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . 9 77 3.2.4. Final processing . . . . . . . . . . . . . . . . . . 9 78 4. Known Limitations . . . . . . . . . . . . . . . . . . . . . . 9 79 4.1. Unsupported Nameservers . . . . . . . . . . . . . . . . . 10 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 5.1. DNSSEC Signature Strategies . . . . . . . . . . . . . . . 10 82 5.1.1. On-the-fly Signatures . . . . . . . . . . . . . . . . 10 83 5.1.2. Alternative Signature Scheme . . . . . . . . . . . . 11 84 5.1.3. Non-DNSSEC Zone Support Only . . . . . . . . . . . . 11 85 5.2. DDOS Attack Vectors and Mitigation . . . . . . . . . . . 11 86 5.3. Implications of Large-Scale DNS Records . . . . . . . . . 11 87 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 92 9.2. Informative References . . . . . . . . . . . . . . . . . 13 93 Appendix A. BULK Examples . . . . . . . . . . . . . . . . . . . 14 94 A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 14 95 A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 14 96 A.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 15 97 A.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 15 98 A.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 15 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 101 1. Introduction 103 The BULK DNS resource record defines a pattern-based method for on- 104 the-fly resource record generation. It is essentially an enhanced 105 wildcard mechanism, constraining generated resource record owner 106 names to those that match a pattern of variable numeric substrings. 107 It is also akin to the $GENERATE master file directive [bind-arm] 108 without being limited to numeric values and without creating all 109 possible records in the zone data. 111 For example, consider the following record: 113 example.com. 86400 IN BULK A ( 114 pool-A-[0-255]-[0-255].example.com. 115 10.55.${1}.${2} 116 ) 118 It will answer requests for pool-A-0-0.example.com through pool- 119 A-255-255.example.com with the IPv4 addresses 10.55.0.0 through 120 10.55.255.255. 122 Much larger record sets can be defined while minimizing the 123 associated requirements for server memory and zone transfer network 124 bandwidth. 126 This record addresses a number of real-world operational problems 127 that authoritative DNS service providers experience. For example, 128 operators who host many large reverse lookup zones, even for only 129 IPv4 space in in-addr.arpa, would benefit from the disk space, memory 130 size, and zone transfer efficiencies that are gained by encapsulating 131 a simple record-generating algorithm versus enumerating all of the 132 individual records to cover the same space. 134 Production zones of tens of thousands of pattern-generated records 135 currently exist, that could be reduced to just one BULK RR. These 136 zones can look deceptively small on the primary nameserver and 137 balloon to 100MB or more when expanded, 139 BULK also allows administrators to more easily deal with singletons, 140 records in the pattern space that are an exception to the normal data 141 generation rules. Whereas a mechanism like $GENERATE may need to be 142 adjusted to account for these individual records, the processing 143 rules for BULK have explicit records more naturally override the 144 dynamically generated ones. This collision problem is not just a 145 theoretical concern, but a real source of support calls for 146 providers. 148 Pattern-generated records are also not only for the reverse DNS 149 space. Forward zones also occasionally have entries that follow 150 patterns that would be well-addressed by the BULK RR. 152 1.1. Background and Terminology 154 The reader is assumed to be familiar with the basic DNS and DNSSEC 155 concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], and 156 [RFC4035]; subsequent RFCs that update them in [RFC2181] and 157 [RFC2308]; and DNS terms in [RFC7719]. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in 162 [RFC2119] when, and only when, they appear in all capitals, as shown 163 here. 165 2. The BULK Resource Record 167 The BULK resource record enables an authoritative nameserver to 168 generate RRs for other types based upon the query received. 170 The Type value for the BULK RR type is TBD. 172 The BULK RR is class-independent. 174 2.1. BULK RDATA Wire Format 176 The RDATA for a BULK RR is as follows: 178 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Match Type | / 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Domain Name Pattern / 183 / / 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 / / 186 / Replacement Pattern / 187 / / 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Match Type identifies the type of the RRset to be generated by this 191 BULK record. It is two octets corresponding to an RR TYPE code as 192 specified in [RFC1035], Section 3.2.1. 194 Domain Name Pattern consists of a pattern encoded as a wire-format 195 fully qualified domain name. The full name is used so that numeric 196 substrings above the zone cut can be captured in addition to those in 197 the zone. It needs no length indicator for the entire field because 198 the root label marks its end. 200 Special characters are interpreted as per the following Augmented 201 Backus-Naur Form (ABNF) notation from [RFC5234]. 203 match = 1*(range / string) 205 range = "[" [decnum "-" decnum] "]" / 206 "<" [hexnum "-" hexnum] ">" 207 ; create references for substitution 208 ; limit of 32 references 209 ; [] is syntactic sugar for 0-255 210 ; <> is syntactic sugar for 00-ff 212 string = 1*(ctext / quoted-char) 214 decnum = 1*decdigit 215 ; constrained to 65535 maximum. 217 hexnum = 1*hexdigit 218 ; constrained to ffff maximum. 220 octet = %x00-FF 222 decdigit = %x30-39 223 ; 0-9 224 hexdigit = decdigit / 0x41-0x46 / 0x61-66 225 ; 0-9, A-F, a-f 227 ctext = 229 quoted-char = "\" octet 230 ; to allow special characters as literals 232 Interpretation of the Domain Name Pattern is described in detail in 233 the "BULK Replacement" section. Note that quoted-char must be stored 234 in the wire format to preserve its semantics when the BULK RR is 235 interpreted by nameservers. 237 The limit of 32 references is meant to simplify implementation 238 details. It is largely but not entirely arbitrary, as it could 239 capture every individual character of the text representation of a 240 full IPv6 address. 242 Replacement Pattern describes how the answer RRset MUST be generated 243 for the matching query. It needs no length indicator because its end 244 can be derived from the RDATA length minus Match Type and Domain Name 245 Pattern lengths. It uses the following additional ABNF elements: 247 replace = 1*(reference / string) 249 reference = "$" "{" (positions / "*") [options] "}" 251 positions = (position / posrange) 0*("," (position / posrange)) 253 posrange = position "-" position 255 position = 1*decnum 257 options = delimiter [interval [padding]] 259 delimiter = "|" 0*(ctext | quoted-char) 260 ; "\|" to use "|" as delimiter 261 ; "\\" to use "\" as delimiter 263 interval = "|" *2decdigit 265 padding = "|" *2decdigit 267 [ Is the formatting complexity beyond simple ${1}, ${2}, etc, really 268 worth it? I definitely see how it could make for shorter replacement 269 patterns, but does it enhance their clarity and usability, adding a 270 feature someone really wants? ] 272 The Replacement Pattern MUST end in the root label if it is intended 273 to represent a fully qualified domain name. 275 2.2. The BULK RR Presentation Format 277 Match Type is represented as an RR type mnemonic or with [RFC3597]'s 278 generic TYPE mechanism. 280 Domain Name Pattern is represented as a fully qualified domain name 281 as per [RFC1035] Section 5.1 rules for encoding whitespace and other 282 special characters. 284 Replacement Pattern is represented by the standard 285 text rules for master files as per [RFC1035] section 5.1. 287 It is suggested that lines longer than 80 characters be wrapped with 288 parenthetical line continuation, per [RFC1035] Section 5.1, starting 289 after Match Type and ending after Replacement Pattern. 291 3. BULK Replacement 293 When a BULK-aware authoritative nameserver receives a query for which 294 it does not have a matching name or a covering wildcard, it MUST then 295 look for BULK RRs at the zone apex, selecting all BULK RRs with a 296 Match Type that matches the query type and a Domain Name Pattern that 297 matches the query name. Note that query type ANY will select all 298 Match Types, and all query types match a CNAME or DNAME Match Type. 299 One or more answer RRs will be generated per the replacement rules 300 below. Examples are provided in an appendix. 302 By only triggering the BULK algorithm when the query name does not 303 exist, administrators are given the flexibility to explicitly 304 override the behaviour of specific names that would otherwise match 305 the BULK record's Domain Name Pattern. This is unlike BIND's 306 $GENERATE directive, which adds the generated RRs to any existing 307 names. 309 3.1. Matching the Domain Name Pattern 311 A query name matches the Domain Name Pattern if the characters that 312 appear outside the numeric ranges match exactly and those within 313 numeric ranges have values that fall within the range. Numeric 314 matches MUST be of the appropriate decimal or hexadecimal type as 315 specified by the delimiters in the pattern. For example, if a range 316 is given as [0-255], then FF does not match even though its value as 317 a hexadecimal number is within the range. Leading zeros in the 318 numeric part(s) of the qname MUST be ignored; for example, 319 001.example.com, 01.example.com and 1.example.com would all match 320 [].example.com. 322 When a query name matches a Domain Name Pattern, the value in each 323 numeric range is stored for use by the Replacement Pattern, with 324 reference numbers starting at 1 and counting from the left. For 325 example, matching the query name host-24-156 against 326 host-[0-255]-[0-255] assigns 24 to ${1} and 156 to ${2}. 328 3.2. Record Generation using Replacement Pattern 330 The Replacement Pattern generates the record data by replacing the 331 ${...} references with data captured from the query name, and copying 332 all other characters literally. 334 The simplest form of reference uses only the reference number between 335 the braces, "{" and "}". The value of the reference is simply copied 336 directly from the matching position of the query name. 338 The next form of reference notation uses the asterisk, "*". With 339 ${*}, all captured values in order of ascending position, delimited 340 by its default delimiter (described below), are placed in the answer. 341 The commercial-at, "@" symbol captures in the same way only in order 342 of descending position. 344 Numeric range references, such as ${1-4}, replaces all values 345 captured by those references, in order, delimited by the default 346 delimiter described below. To reverse the order in which they are 347 copied, reverse the upper and lower values, such as ${4-1}. This is 348 useful for generating PTR records from query names in which the 349 address is encoded in network order. 351 Similar to range references, separating positions by commas creates 352 sets for replacement. For example, ${1,4} would be replaced by the 353 first and fourth captured values, delimited its default delimiter. 354 This notation may be combined with the numeric range form, such as 355 ${3,2,1,8-4}. 357 3.2.1. Delimiters 359 A reference can specify a delimiter to use by following a vertical 360 bar, "|", with zero or more characters. Zero characters, such as in 361 ${1-3|}, means no delimiter is used, while other characters up to an 362 unescaped vertical bar or closing brace are copied between position 363 values in the replacement. The default delimiter is the hyphen, "-". 365 3.2.2. Delimiter intervals 367 A second vertical bar in the reference options introduces a delimiter 368 interval. The default behavior of a multi-position reference is to 369 combine each captured value specified with a delimiter between each. 370 With a delimiter interval the delimiters are only added between every 371 Nth value. For example, ${*|-|4} adds a hyphen between every group 372 of four captured positions. This can be a handy feature in the IPv6 373 reverse namespace where every nibble is captured as a separate value 374 and generated hostnames include sets of 4 nibbles. An empty or 0 375 value for the delimiter interval MUST be interpreted as the default 376 value of 1. 378 3.2.3. Padding length 380 The fourth and final reference option determines the field width of 381 the copied value. Shorter values MUST be padded with leading zeroes 382 ("0") and longer values MUST be truncated to the width. 384 The default behavior, and that of an explicit empty padding length, 385 is that the captured query name substring is copied exactly. A width 386 of zero "0" is a signal to "unpad", and any leading zeros MUST be 387 removed. [ Unnecessary complexity? ] 389 If a delimiter interval greater than 1 is used, captured values 390 between the intervals will be concatenated and the padding or 391 unpadding applied as a unit and not individually. An example of this 392 would be ${*||4|4} which would combine each range of 4 captured 393 values and pad or truncate them to a width of 4 characters. 395 [ If this is kept, the element/feature should probably be renamed 396 from "padding" since it is just as likely to truncate. ] 398 3.2.4. Final processing 400 The string that results from all replacements is converted to the 401 appropriate RDATA format for the record type. If the conversion 402 fails, the SERVFAIL rcode MUST be set on the response, representing a 403 misconfiguration that the server was unable to perform. [ The EDNS 404 extended-error code would be useful here. ] 406 The TTL of each RR generated by a BULK RR is the TTL of the 407 corresponding BULK record itself. [ BULK should probably have its 408 own TTL field because using that of the record itself feels like bad 409 design. On the other hand, if BULK is never meant to be queried for 410 directly and only appears in authoritative data, its own TTL is 411 pretty useless normally. ] 413 The class for the RRSet is the class of the BULK RR. 415 If the generated record type is one that uses domain names in its 416 resource record data, such as CNAME, a relative domain names MUST be 417 fully qualified with the origin domain of the BULK RR. 419 4. Known Limitations 421 This section defines known limitations of the BULK resource type. 423 4.1. Unsupported Nameservers 425 Authoritative nameservers that do not understand the semantics of the 426 new record type will not be able to deliver the intended answers even 427 when the type appears in their zone data This significantly affects 428 the interoperability of primary versus secondary authorities that are 429 not all running the same software. Adding new RRs which affect 430 handling by authoritative servers, or being unable to add them, is an 431 issue that needs to be explored more thoroughly within dnsop. 433 5. Security Considerations 435 Two known security considerations exist for the BULK resource record, 436 DNSSEC and DDOS attack vectors. 438 5.1. DNSSEC Signature Strategies 440 DNSSEC was designed to provide validation for DNS resource records, 441 requiring each tuple of owner, class, and type to have its own 442 signature. This essentially defeats the purpose of providing large 443 generated blocks of RRs in a single RR as each generated RR would 444 require its own legitimate RRSIG record. 446 In the following sections several options are discussed to address 447 this issue. Of the options, on-the-fly provides the most secure 448 solution and NPN [npn-draft] provides the most flexible. 450 5.1.1. On-the-fly Signatures 452 A significant design goal of DNSSEC was to be able to do offline 453 cryptographic signing of zone contents, keeping the key material more 454 secure. 456 On-the-fly processing requires authoritative nameservers to sign 457 generated records as they are created. Not all authoritative 458 nameserver implementations offer on-the-fly signatures, and even with 459 those that do not all operators will want to keep signing keys 460 online. This solution would either require all implementations to 461 support on-the-fly signing or be ignored by implementations which can 462 not or will not comply. 464 One possibly mitigation for addressing the risk of keeping the zone 465 signing key online would be to continue to keep the key for signing 466 positive answers offline and introduce a second key for online 467 signing of negative answers. 469 No changes to validating resolvers is required to support this 470 solution. 472 5.1.2. Alternative Signature Scheme 474 Previous versions of this draft proposed a new signature scheme using 475 a Numeric Pattern Normalization (NPN) RR. It was a method to support 476 offline signatures for BULK records, with the drawback that is 477 required updates to DNSSEC-aware resolvers. 479 That mechanism is not specific to BULK and has been removed from the 480 current draft. If there is further interest in pursuing it, it can 481 be reopened as a separate draft. 483 5.1.3. Non-DNSSEC Zone Support Only 485 As a final option zones which wish to remain entirely without DNSSEC 486 support may serve such zones without either of the above solutions 487 and records generated based on BULK RRs will require zero support 488 from recursive resolvers. 490 5.2. DDOS Attack Vectors and Mitigation 492 As an additional defense against Distributed Denial Of Service (DDOS) 493 attacks against recursive (resolving) nameservers it is highly 494 recommended shorter TTLs be used for BULK RRs than others. While 495 disabling caching with a zero TTL is not recommended, as this would 496 only result in a shift of the attack target, a balance will need to 497 be found. While this document uses 24 hours (86400 seconds) in its 498 examples, values between 300 to 900 seconds are likely more 499 appropriate and is RECOMMENDED. What is ultimately deemed 500 appropriate may differ from zone to zone and administrator to 501 administrator. 503 [ I am unclear how this helps DDOS mitigation against anyone at all, 504 and suspect this section should be removed.. ] 506 5.3. Implications of Large-Scale DNS Records 508 The production of such large-scale records in the wild may have some 509 unintended side-effects. These side-effects could be of concern or 510 add unexpected complications to DNS based security offerings or 511 forensic and anti-spam measures. While outside the scope of this 512 document, implementers of technology relying on DNS resource records 513 for critical decision making must take into consideration how the 514 existence of such a volume of records might impact their technology. 516 Solutions to the magnitude problem for BULK generated RRs are 517 expected be similar if not identical to that of existing wildcard 518 records, the core difference being the resultant RDATA will be unique 519 for each requested Domain Name within its scope. 521 The authors of this document are confident that by careful 522 consideration, negative_side-effects produced by implementing the 523 features described in this document can be eliminated from any such 524 service or product. 526 6. Privacy Considerations 528 The BULK record does not introduce any new privacy concerns to DNS 529 data. 531 7. IANA Considerations 533 IANA is requested to assign numbers for the BULK RR. 535 8. Acknowledgments 537 This document was created as an extension to the DNS infrastructure. 538 As such, many people over the years have contributed to its creation 539 and the authors are appreciative to each of them even if not thanked 540 or identified individually. 542 A special thanks is extended for the kindness, wisdom and technical 543 advice of Robert Whelton (CenturyLink, Inc.) and Gary O'Brien 544 (Secure64 Software Corp). 546 9. References 548 9.1. Normative References 550 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 551 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 552 . 554 [RFC1035] Mockapetris, P., "Domain names - implementation and 555 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 556 November 1987, . 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, 560 DOI 10.17487/RFC2119, March 1997, 561 . 563 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 564 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 565 . 567 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 568 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 569 . 571 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 572 ADDR.ARPA delegation", BCP 20, RFC 2317, 573 DOI 10.17487/RFC2317, March 1998, 574 . 576 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 577 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 578 2003, . 580 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 581 Rose, "DNS Security Introduction and Requirements", 582 RFC 4033, DOI 10.17487/RFC4033, March 2005, 583 . 585 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 586 Rose, "Resource Records for the DNS Security Extensions", 587 RFC 4034, DOI 10.17487/RFC4034, March 2005, 588 . 590 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 591 Rose, "Protocol Modifications for the DNS Security 592 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 593 . 595 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 596 Specifications: ABNF", STD 68, RFC 5234, 597 DOI 10.17487/RFC5234, January 2008, 598 . 600 9.2. Informative References 602 [bind-arm] 603 Internet Systems Consortium, "BIND 9 Configuration 604 Reference", 2016, 605 . 608 [npn-draft] 609 Internet Systems Consortium, "Numeric Pattern 610 Normalization (NPN)", 2019, 611 . 613 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 614 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 615 2015, . 617 Appendix A. BULK Examples 619 A.1. Example 1 621 $ORIGIN 2.10.in-addr.arpa. 622 @ 86400 IN BULK PTR ( 623 [0-255].[0-255].[0-255].[0-255].in-addr.arpa. 624 pool-${4-1}.example.com. 625 ) 627 A query received for the PTR of 4.3.2.10.in-addr.arpa will create the 628 references ${1} through ${4} with the first four labels of the query 629 name. The ${4-1} reference in the replacement pattern will then 630 substitute them in reverse with the default delimiter of hyphen 631 between every character and no special field width modifications. 632 The TTL of the BULK RR is used for the generated record, making the 633 response: 635 4.3.2.10.in-addr.arpa 86400 IN PTR pool-10-2-3-4.example.com. 637 A.2. Example 2 639 $ORIGIN 2.10.in-addr.arpa. 640 @ 86400 IN BULK PTR ( 641 [0-255].[0-255].[0-255].[0-255].in-addr.arpa. 642 pool-${2,1|||3}.example.com. 643 ) 645 Example 2 is similar to Example 1, except that it modifies the 646 replacement pattern. The empty option after the first vertical bar 647 causes no delimiters to be inserted, while the second empty option 648 that would keep the delimiter interval as 1. The latter is relevant 649 because the final value, padding of 3, is applied over each delimiter 650 interval even when no delimiter is used. Not all captures from the 651 substring are required to be used in the response. 653 The result is that a query for the PTR of 4.3.2.10.in-addr.arpa 654 generates this response: 656 4.3.2.10.in-addr.arpa 86400 IN PTR pool-003004.example.com. 658 [ Admittedly you can't do this very effectively without the field 659 width complexity. Is this sort of name common? Does it need 660 support? Admittedly $GENERATE had the feature, but is that reason 661 enough? ] 663 [ Change this to a hex matching example? ] 665 A.3. Example 3 667 $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 668 @ 86400 IN BULK PTR ( 669 <>.<>.<>.<>.<>.<>.<>.<>.<>.<>.<>.<>.<>.<>.<>.<> 670 poolAA-${16-8|-|4}.example.com. 671 ) 673 This example introduces IPv6 where 16 individual nibbles are captured 674 and the last 8 are combined into 2 blocks of 4, separated by a 675 hyphen. 677 A query for the IP of 2001:db8::dead:beef results in a PTR RR with 678 the value of poolAA-dead-beef.example.com. 680 A.4. Example 4 682 $ORIGIN example.com. 683 @ 86400 IN BULK AAAA ( 684 poolAA-<0-ffff>-<0-ffff>.example.com. 685 ${@|.|1}.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 686 ) 688 This example performs the reverse of example 3, where a query of 689 poolAA-dead-beef.example.com captures "dead" and "beef", reversing 690 the nibbles and using a dot (.) as the delimiter to form a valid AAAA 691 record. 693 A.5. Example 5 695 This example contains a classless IPv4 delegation on the /22 CIDR 696 boundary as defined by [RFC2317]. The network for this example is 697 "10.2.0/22" delegated to a nameserver "ns1.sub.example.com.". RRs 698 for this example are defined as: 700 $ORIGIN 2.10.in-addr.arpa. 701 @ 7200 IN BULK CNAME [0-255].[0-3] ${*|.}.0-3 702 0-3 86400 IN NS ns1.sub.example.com. 704 A query for the PTR of 25.2.2.10.in-addr.arpa is received and the 705 BULK record with the CNAME Match Type matches all query types. 25 706 and 2 are captured as references, and joined in the answer by the 707 period (".") character as a delimiter, with ".0-3" then appended 708 literally and fully qualified by the origin domain. The final 709 synthesized record is: 711 25.2.2.10.in-addr.arpa 7200 IN CNAME 25.2.0-3.2.10.in-addr.arpa. 713 [ Without $* and options complexity, the pattern to get the same 714 result is just ${1}.{$2}.0-3 which is not really significantly 715 onerous to enter, and slightly less arcane looking to comprehend. ] 717 Authors' Addresses 719 John Woodworth 720 CenturyLink, Inc. 721 4250 N Fairfax Dr 722 Arlington VA 22203 723 USA 725 Email: John.Woodworth@CenturyLink.com 727 Dean Ballew 728 CenturyLink, Inc. 729 2355 Dulles Corner Blvd, Ste 200 300 730 Herndon VA 20171 731 USA 733 Email: Dean.Ballew@CenturyLink.com 735 Shashwath Bindinganaveli Raghavan 736 Hughes Network Systems 737 11717 Exploration Lane 738 Germantown MD 20876 739 USA 741 Email: shashwath.bindinganaveliraghavan@hughes.com 743 David C Lawrence 744 Oracle 746 Email: tale@dd.org