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