idnits 2.17.1 draft-toorop-dnsop-dns-catalog-zones-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 9, 2020) is 1509 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Downref: Normative reference to an Experimental RFC: RFC 3123 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group L. Peltan 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track O. Sury 5 Expires: September 10, 2020 Internet Systems Consortium 6 W. Toorop 7 NLnet Labs 8 L. Vandewoestijne 9 March 9, 2020 11 DNS Catalog Zones 12 draft-toorop-dnsop-dns-catalog-zones-00 14 Abstract 16 This document describes a method for automatic DNS zone provisioning 17 among DNS primary and secondary nameservers by storing and 18 transferring the catalog of zones to be provisioned as one or more 19 regular DNS zones. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 10, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Catalog Zone Structure . . . . . . . . . . . . . . . . . . . 4 59 4.1. SOA and NS Records . . . . . . . . . . . . . . . . . . . 4 60 4.2. Zone Data . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2.1. Resource Record Format . . . . . . . . . . . . . . . 5 62 4.2.2. Multi-valued Properties . . . . . . . . . . . . . . . 6 63 4.2.3. Vendor-specific Properties . . . . . . . . . . . . . 6 64 4.3. Zone Structure . . . . . . . . . . . . . . . . . . . . . 6 65 4.3.1. List of Member Zones . . . . . . . . . . . . . . . . 7 66 4.3.2. Catalog Zone Schema Version . . . . . . . . . . . . . 7 67 4.3.3. Default Zone Configuration . . . . . . . . . . . . . 7 68 4.3.4. Zone Properties Specific to a Member Zone . . . . . . 8 69 5. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. String . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2. Booleans . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.3. Integers . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.4. Floating-Point Values . . . . . . . . . . . . . . . . . . 9 74 5.5. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.6. IP Prefix . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.7. Single Host Address . . . . . . . . . . . . . . . . . . . 10 77 6. Nameserver Behavior . . . . . . . . . . . . . . . . . . . . . 10 78 6.1. General Requirements . . . . . . . . . . . . . . . . . . 10 79 7. Updating Catalog Zones . . . . . . . . . . . . . . . . . . . 11 80 7.1. Implementation Notes . . . . . . . . . . . . . . . . . . 11 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 11.2. Informative References . . . . . . . . . . . . . . . . . 14 87 Appendix A. Open issues and discussion (to be removed before 88 final publication) . . . . . . . . . . . . . . . . . 14 89 Appendix B. Change History (to be removed before final 90 publication) . . . . . . . . . . . . . . . . . . . . 15 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 This is a simple resubmit of "draft-muks-dnsop-dns-catalog-zones-04" 96 with the authors replaced. The new authors are representatives of 97 Open Source DNS implementations and a DNS Operator who want to work 98 and cooperate on progressing this draft to produce a cross- 99 implementation DNS Catalog Zones standard. 101 The data in a DNS zone is synchronized amongst its primary and 102 secondary nameservers using AXFR and IXFR. However, the list of 103 zones served by the primary (called a catalog in [RFC1035]) is not 104 automatically synchronized with the secondaries. To add or remove a 105 zone, the administrator of a DNS nameserver farm not only has to add 106 or remove the zone from the primary, they must also add/remove the 107 zone from all secondaries, either manually or via an external 108 application. This can be both inconvenient and error-prone; it will 109 also be dependent on the nameserver implementation. 111 This document describes a method in which the catalog is represented 112 as a regular DNS zone (called a "catalog zone" here), and transferred 113 using DNS zone transfers. As zones are added to or removed from the 114 catalog zone, the changes are propagated to the secondary nameservers 115 in the normal way. The secondary nameservers then add/remove/modify 116 the zones they serve in accordance with the changes to the zone. 118 The contents and representation of catalog zones are described in 119 Section 3. Nameserver behavior is described in Section 6. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "*NOT RECOMMENDED*", "MAY", 125 and "OPTIONAL" in this document are to be interpreted as described in 126 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 Catalog zone 130 A DNS zone containing a DNS catalog, that is, a list of DNS zones 131 and associated zone configuration. 133 Member zone 134 A DNS zone whose configuration is published inside a catalog zone. 136 Zone property 137 A configuration parameter of a zone, sometimes also called a zone 138 option, represented as a key/value pair. 140 $CATZ 141 Used in examples as a placeholder to represent the domain name of 142 the catalog zone itself (c.f. $ORIGIN). 144 3. Description 146 A catalog zone is a specially crafted DNS zone that contains, as DNS 147 zone data: 149 o A list of DNS zones (called "member zones"). 151 o Default zone configuration information common to all member zones. 153 o Zone-specific configuration information. 155 An implementation of catalog zones MAY allow the catalog to contain 156 other catalog zones as member zones, but default zone configuration 157 present in a catalog zone only applies to its immediate member zones. 159 Although the contents of a catalog zone are interpreted and acted 160 upon by nameservers, a catalog zone is a regular DNS zone and so must 161 adhere to the standards for such zones. 163 A catalog zone is primarily intended for the management of a farm of 164 authoritative nameservers. It is not expected that the content of 165 catalog zones will be accessible from any recursive nameserver. 167 4. Catalog Zone Structure 169 4.1. SOA and NS Records 171 As with any other DNS zone, a catalog zone MUST have a syntactically 172 correct SOA record and one or more NS records at its apex. 174 The SOA record's SERIAL, REFRESH, RETRY and EXPIRE fields [RFC1035] 175 are used during zone transfer. A catalog zone's SOA SERIAL field 176 MUST increase when an update is made to the catalog zone's contents 177 as per serial number arithmetic defined in [RFC1982]. Otherwise, 178 secondary nameservers might not notice updates to the catalog zone's 179 contents. 181 Should the zone be made available for querying, the SOA record's 182 MINIMUM field's value is the negative cache time (as defined in 183 [RFC2308]). Since recursive nameservers are not expected to be able 184 to access (and subsequently cache) entries from a catalog zone a 185 value of zero (0) is RECOMMENDED. 187 Since there is no requirement to be able to query the catalog zone 188 via recursive namservers the NS records at the apex will not be used 189 and no parent delegation is required. However, they are still 190 required so that catalog zones are syntactically correct DNS zones. 191 Any valid DNS name can be used in the NSDNAME field of such NS 192 records [RFC1035] and they MUST be ignored. A single NS RR with an 193 NSDNAME field containing the absolute name "invalid." is RECOMMENDED 194 [RFC2606]. 196 4.2. Zone Data 198 A catalog zone contains a set of key/value pairs, where each key is 199 encapsulated within the owner name of a DNS RR and the corresponding 200 value is stored in the RR's RDATA. The specific owner name depends 201 on whether the property relates to the catalog zone itself, a member 202 zone thereof, or to default zone properties described in Section 4.3. 203 The owner names are case insensitive. 205 4.2.1. Resource Record Format 207 Each key/value pair has a defined data type, and each data type 208 accordingly uses a particular RR TYPE to represent its possible 209 values, as specified in Section 5. 211 The general form of a catalog zone record is as follows: 213 [.]..$CATZ 0 IN 215 where "" is a sequence of labels with values depending on the 216 purpose (and hence position) of the record within the catalog zone 217 (see Section 4.3) and where the "" prefix is only present 218 for multi-valued properties (see Section 4.2.2). 220 NB: Catalog zones use some RR TYPEs (such as PTR) with alternate 221 semantics to those originally defined for them. Although this may be 222 controversial, the situation is similar to other similar zone-based 223 representations such as response-policy zones [RPZ]. 225 The CLASS field of every RR in a catalog zone MUST be IN (1). This 226 is because some RR TYPEs such as APL used by catalog zones are 227 defined only for the IN class. 229 The TTL field's value is not specially defined by this memo. Catalog 230 zones are for authoritative nameserver management only and are not 231 intended for general querying via recursive resolvers and therefore a 232 value of zero (0) is RECOMMENDED. 234 It is an error for any single owner name within a catalog zone (other 235 than the apex of the zone itself) to have more than one RR associated 236 with it. 238 4.2.2. Multi-valued Properties 240 Some properties do not represent single values but instead represent 241 a collection of values. The specification for each property 242 describes whether it is single-valued or multi-valued. A multi- 243 valued property is encoded as multiple RRs where the owner name of 244 each individual RR contains a unique (user specified) DNS label. 246 So, while a single-valued key might be represented like this: 248 ..$CATZ IN TXT "value" 250 a multi-valued key would be represented like this: 252 ...$CATZ IN TXT "value 1" 253 ...$CATZ IN TXT "value 2" 254 ... 256 NB: a property that is specified to be multi-valued MUST be encoded 257 using the unique prefixed key syntax even if there is only one value 258 present. 260 The specification of any multi-valued property MUST document whether 261 the collection represents either an ordered or unordered list. In 262 the former case the ordering of the prefixes according to the usual 263 DNS canonical name ordering will determine the sort order. 265 4.2.3. Vendor-specific Properties 267 TBD: Prepare a list of zone configuration properties that are common 268 to DNS implementations. This is so that a company may manage a 269 catalog zone using a Windows DNS server as the primary, and a 270 secondary nameserver hosting service may pick up the common 271 properties and may use a different nameserver implementation such as 272 BIND or NSD on a POSIX operating system to serve it. 274 TBD: We may specify that unrecognized zone property names must be 275 ignored, or that nameserver specific properties must be specified 276 using the "x-" prefix similar to MIME type naming. 278 TBD: Any list of zone properties is ideally maintained as a registry 279 rather than within this memo. 281 4.3. Zone Structure 282 4.3.1. List of Member Zones 284 The list of member zones is specified as a multi-valued collection of 285 domain names under the owner name "zones" where "zones" is a direct 286 child domain of the catalog zone. 288 The names of member zones are represented on the RDATA side (instead 289 of as a part of owner names) so that all valid domain names may be 290 represented regardless of their length [RFC1035]. 292 For example, if a catalog zone lists three zones "example.com.", 293 "example.net." and "example.org.", the RRs would appear as follows: 295 .zones.$CATZ 0 IN PTR example.com. 296 .zones.$CATZ 0 IN PTR example.net. 297 .zones.$CATZ 0 IN PTR example.org. 299 where "" is a label that uniquely tags each record in the 300 collection, as described in Section 4.2.2. 302 Although any legal label could be used for "" it is 303 RECOMMENDED that it be a value deterministically derived from the 304 fully-qualified member zone name. The BIND9 implementation uses the 305 40 character hexadecimal representation of the SHA-1 digest 306 [FIPS.180-4.2015] of the lower-cased member zone name as encoded in 307 uncompressed wire format. 309 4.3.2. Catalog Zone Schema Version 311 The catalog zone schema version is specified by an unsigned integer 312 property with the property name "version". All catalog zones MUST 313 have this property present. Primary and secondary nameservers MUST 314 NOT use catalog zones with an unexpected value in this property, but 315 they may be transferred as ordinary zones. For this memo, the 316 "version" property value MUST be set to 2, i.e. 318 version.$CATZ 0 IN TXT "2" 320 NB: Version 1 was used in a draft version of this memo and reflected 321 the implementation first found in BIND 9.11. 323 4.3.3. Default Zone Configuration 325 Default zone configuration comprises a set of properties that are 326 applied to all member zones listed in the catalog zone unless 327 overridden my member zone-specific information. 329 All such properties are stored as child nodes of the owner name 330 "defaults" itself a direct child node of the catalog zone, e.g.: 332 example-prop.defaults.$CATZ 0 IN TXT "Example" 334 4.3.4. Zone Properties Specific to a Member Zone 336 Default zone properties can be overridden on a per-zone basis by 337 specifying the property under the the sub-domain associated with the 338 member zone in the list of zones, e.g.: 340 example-prop..zones.$CATZ 0 IN TXT "Example" 342 where "m-unique" is the label that uniquely identifies the member 343 zone name as described in Section 4.3.1. 345 NB: when a zone-specific property is multi-valued the owner name will 346 contain two unique identifiers, the left-most tagging being 347 associated with the individual value ("") and the other 348 ("") associated with the member zone itself, e.g.: 350 $ORIGIN .zones.$CATZ 351 .example-prop 0 IN TXT "Value 1" 352 .example-prop 0 IN TXT "Value 2" 353 ... 355 5. Data Types 357 This section lists the various data types defined for use within 358 catalog zones. 360 5.1. String 362 A key with a string value is represented with a TXT RR [RFC1035], 363 e.g.: 365 example-prop..zones.$CATZ 0 IN TXT "Example" 367 If the RDATA is split into multiple "" elements the 368 MUST be directly concatenated without any separating character. 370 5.2. Booleans 372 A key with a boolean value is represented with a TXT RR containing a 373 single "" with a value of "true" for true condition 374 and "false" for false condition, e.g: 376 example-prop..zones.$CATZ 0 IN TXT "false" 378 The RDATA is case-insensitive. 380 5.3. Integers 382 A key with an integer value is specified using a TXT RR containing a 383 single "". 385 A signed integer's TXT RDATA uses the representation of an unsuffixed 386 "integer constant" as defined in the C programming language standard 387 [ISO.9899.1990] (of the type matching a 64-bit signed integer on that 388 platform), with an optional minus prefix. 390 An unsigned integer's TXT RDATA uses the representation of an 391 unsuffixed "integer constant" as defined in the C programming 392 language standard [ISO.9899.1990] (of the type matching a 64-bit 393 unsigned integer on that platform). 395 For example, a property with an unsigned integer value of 300 would 396 appear as follows: 398 example-prop..zones.$CATZ 0 IN TXT "300" 400 5.4. Floating-Point Values 402 A key with a floating-point value is specified using a TXT RR 403 containing a single "". 405 A floating-point value's TXT RDATA uses the representation of an 406 unsuffixed "floating constant" as defined in the C programming 407 language standard [ISO.9899.1990]. 409 For example, a property with an unsigned integer value of 0.15 may 410 appear as follows: 412 example-prop..zones.$CATZ 0 IN TXT "15e-2" 414 5.5. Domain Name 416 A key whose value is a domain name is specified using a PTR RR 417 [RFC1035], e.g.: 419 example-prop.defaults.$CATZ 0 IN PTR ns1.example.com. 421 5.6. IP Prefix 423 A property whose value is an IP network prefix is specified using an 424 APL RR [RFC3123]. The negation flag ("!" in presentation format) may 425 be used to indicate all addresses not included within that prefix, 426 e.g. for use in Access Control Lists, e.g.: 428 Although a single APL record is capable of containing multiple 429 prefixes, for consistency of representation lists of prefixes MUST 430 use the multi-valued property syntax as documented in Section 4.2.2, 431 e.g.: 433 $ORIGIN .zones.$CATZ 434 .example-prop 0 IN APL ( 1:192.0.2.0/24 ) 435 .example-prop 0 IN APL ( !1:0.0.0.0/0 ) 437 Implementations MUST accept only the first prefix within each APL 438 record and MUST ignore any subsequent prefixes found therein. 440 5.7. Single Host Address 442 A single host address is represented using either an A or AAAA record 443 as appropriate, e.g.: 445 example-prop1..zones.$CATZ 0 IN A 192.0.2.1 446 example-prop2..zones.$CATZ 0 IN AAAA 2001:db8::1 448 6. Nameserver Behavior 450 6.1. General Requirements 452 As it is a regular DNS zone, a catalog zone can be transferred using 453 DNS zone transfers among nameservers. 455 Although they are regular DNS zones, catalog zones contain only 456 information for the management of a set of authoritative nameservers. 457 For this reason, operators may want to limit the systems able to 458 query these zones. It may be inconvenient to serve some contents of 459 catalog zones via DNS queries anyway due to the nature of their 460 representation. A separate method of querying entries inside the 461 catalog zone may be made available by nameserver implementations (see 462 Section 7.1). 464 Catalog updates should be automatic, i.e., when a nameserver that 465 supports catalog zones completes a zone transfer for a catalog zone, 466 it SHOULD apply changes to the catalog within the running nameserver 467 automatically without any manual intervention. 469 As with regular zones, primary and secondary nameservers for a 470 catalog zone may be operated by different administrators. The 471 secondary nameservers may be configured to synchronize catalog zones 472 from the primary, but the primary's administrators may not have any 473 administrative access to the secondaries. 475 A catalog zone can be updated via DNS UPDATE on a reference primary 476 nameserver, or via zone transfers. Nameservers MAY allow loading and 477 transfer of broken zones with incorrect catalog zone syntax (as they 478 are treated as regular zones), but nameservers MUST NOT process such 479 broken zones as catalog zones. For the purpose of catalog 480 processing, the broken catalogs MUST be ignored. If a broken catalog 481 zone was transferred, the newly transferred catalog zone MUST be 482 ignored (but the older copy of the catalog zone SHOULD be left 483 running subject to values in SOA fields). 485 If there is a clash between an existing member zone's name and an 486 incoming member zone's name (via transfer or update), the new 487 instance of the zone MUST be ignored and an error SHOULD be logged. 489 When zones are introduced into a catalog zone, a primary SHOULD first 490 make the new zones available for transfers before making the updated 491 catalog zone available for transfer, or sending NOTIFY for the 492 catalog zone to secondaries. Note that secondary nameservers may 493 attempt to transfer the catalog zone upon refresh timeout, so care 494 must be taken to make the member zones available before any update to 495 the list of member zones is visible in the catalog zone. 497 When zones are deleted from a catalog zone, a primary MAY delete the 498 member zone immediately after notifying secondaries. It is up to the 499 secondary nameserver to handle this condition correctly. 501 TBD: Transitive primary-secondary relationships 503 7. Updating Catalog Zones 505 TBD: Explain updating catalog zones using DNS UPDATE. 507 7.1. Implementation Notes 509 Catalog zones on secondary nameservers would have to be setup 510 manually, perhaps as static configuration, similar to how ordinary 511 DNS zones are configured. Members of such catalog zones will be 512 automatically synchronized by the secondary after the catalog zone is 513 configured. 515 An administrator may want to look at data inside a catalog zone. 516 Typical queries might include dumping the list of member zones, 517 dumping a member zone's effective configuration, querying a specific 518 property value of a member zone, etc. Because of the structure of 519 catalog zones, it may not be possible to perform these queries 520 intuitively, or in some cases, at all, using DNS QUERY. For example 521 it is not possible to enumerate the contents of a multi-valued 522 property (such as the list of member zones) with a single QUERY. 523 Implementations are therefore advised to provide a tool that uses 524 either the output of AXFR or an out-of-band method to perform queries 525 on catalog zones. 527 8. Security Considerations 529 As catalog zones are transmitted using DNS zone transfers, it is 530 absolutely essential for these transfers to be protected from 531 unexpected modifications on the route. So, catalog zone transfers 532 SHOULD be authenticated using TSIG [RFC2845]. A primary nameserver 533 SHOULD NOT serve a catalog zone for transfer without using TSIG and a 534 secondary nameserver SHOULD abandon an update to a catalog zone that 535 was received without using TSIG. 537 Use of DNS UPDATE [RFC2136] to modify the content of catalog zones 538 SHOULD similarly be authenticated using TSIG. 540 Zone transfers of member zones SHOULD similarly be authenticated 541 using TSIG [RFC2845]. The TSIG shared secrets used for member zones 542 MUST NOT be mentioned anywhere in the catalog zone data. However, 543 key identifiers may be shared within catalog zones. 545 Catalog zones do not need to be signed using DNSSEC, their zone 546 transfers being authenticated by TSIG. Signed zones MUST be handled 547 normally by nameservers, and their contents MUST NOT be DNSSEC- 548 validated. 550 9. IANA Considerations 552 This document has no IANA actions. 554 10. Acknowledgements 556 Our deepest thanks and appreciation go to Mukund Sivaraman, Stephen 557 Morris, Ray Bellis and Witold Krecicki who initiated this draft and 558 did the bulk of the work. 560 Catalog zones originated as the chosen method among various proposals 561 that were evaluated at ISC for easy zone management. The chosen 562 method of storing the catalog as a regular DNS zone was proposed by 563 Stephen Morris. 565 The initial authors discovered that Paul Vixie's earlier [Metazones] 566 proposal implemented a similar approach and reviewed it. Catalog 567 zones borrows some syntax ideas from Metazones, as both share this 568 scheme of representing the catalog as a regular DNS zone. 570 Thanks to Brian Conry, Tony Finch, Evan Hunt, Patrik Lundin, Victoria 571 Risk and Carsten Strettman for reviewing draft proposals and offering 572 comments and suggestions. 574 11. References 576 11.1. Normative References 578 [FIPS.180-4.2015] 579 National Institute of Standards and Technology, "Secure 580 Hash Standard", FIPS PUB 180-4, August 2015, 581 . 584 [ISO.9899.1990] 585 International Organization for Standardization, 586 "Programming languages - C", ISO Standard 9899, 1990. 588 [RFC1035] Mockapetris, P., "Domain names - implementation and 589 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 590 November 1987, . 592 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 593 DOI 10.17487/RFC1982, August 1996, 594 . 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 602 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 603 RFC 2136, DOI 10.17487/RFC2136, April 1997, 604 . 606 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 607 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 608 . 610 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 611 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 612 . 614 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 615 Wellington, "Secret Key Transaction Authentication for DNS 616 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 617 . 619 [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes 620 (APL RR)", RFC 3123, DOI 10.17487/RFC3123, June 2001, 621 . 623 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 624 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 625 May 2017, . 627 11.2. Informative References 629 [Metazones] 630 Vixie, P., "Federated Domain Name Service Using DNS 631 Metazones", 2005, . 633 [RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones (DNS 634 RPZ)", 2010, 635 . 637 Appendix A. Open issues and discussion (to be removed before final 638 publication) 640 Config options 641 We want catalog zones to be adopted by multiple DNS 642 implementations. Towards this, we have to generalize zone config 643 options and adopt a minimal set that we can expect most 644 implementations to support. 646 Catalog zone and member zones on different primary nameservers 647 Will it be possible to setup a catalog zone on one nameserver as 648 primary, and allow its member zones to be served by different 649 primary nameservers? 651 Transitive relationships 652 For a catalog zone, a secondary nameserver may be a primary 653 nameserver to a different set of nameservers in a nameserver farm. 654 In these transitive relationships, zone configuration options 655 (such as also-notify and allow-transfer) may differ based on the 656 location of the primary in the hierarchy. It may not be possible 657 to specify this within a catalog zone. 659 Overriding controls 660 A way to override zone config options (as prescribed by the 661 catalog zones) on secondary nameservers was requested. As this 662 would be configured outside catalog zones, it may be better to 663 leave this to implementations. 665 Appendix B. Change History (to be removed before final publication) 667 o draft-muks-dnsop-dns-catalog-zones-00 669 Initial public draft. 671 o draft-muks-dnsop-dns-catalog-zones-01 673 Added Witold, Ray as authors. Fixed typos, consistency issues. 674 Fixed references. Updated Area. Removed newly introduced custom 675 RR TYPEs. Changed schema version to 1. Changed TSIG requirement 676 from MUST to SHOULD. Removed restrictive language about use of 677 DNS QUERY. When zones are introduced into a catalog zone, a 678 primary SHOULD first make the new zones available for transfers 679 first (instead of MUST). Updated examples, esp. use IPv6 in 680 examples per Fred Baker. Add catalog zone example. 682 o draft-muks-dnsop-dns-catalog-zones-02 684 Addressed some review comments by Patrik Lundin. 686 o draft-muks-dnsop-dns-catalog-zones-03 688 Revision bump. 690 o draft-muks-dnsop-dns-catalog-zones-04 692 Reordering of sections into more logical order. Separation of 693 multi-valued properties into their own category. 695 o draft-toorop-dnsop-dns-catalog-zones-00 697 New authors to pickup the editor pen on this draft 699 Authors' Addresses 701 Libor Peltan 702 CZ.NIC 703 CZ 705 Email: libor.peltan@nic.cz 706 Ondrej Sury 707 Internet Systems Consortium 708 CZ 710 Email: ondrej@isc.org 712 Willem Toorop 713 NLnet Labs 714 Science Park 400 715 Amsterdam 1098 XH 716 Netherlands 718 Email: willem@nlnetlabs.nl 720 Leo Vandewoestijne 721 Netherlands 723 Email: leo@dns.company