idnits 2.17.1 draft-muks-dnsop-dns-catalog-zones-04.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 date (March 1, 2018) is 2245 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Sivaraman 3 Internet-Draft S. Morris 4 Intended status: Experimental R. Bellis 5 Expires: September 2, 2018 W. Krecicki 6 Internet Systems Consortium 7 March 1, 2018 9 DNS Catalog Zones 10 draft-muks-dnsop-dns-catalog-zones-04 12 Abstract 14 This document describes a method for automatic DNS zone provisioning 15 among DNS primary and secondary nameservers by storing and 16 transferring the catalog of zones to be provisioned as one or more 17 regular DNS zones. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 2, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Catalog Zone Structure . . . . . . . . . . . . . . . . . . . 4 57 4.1. SOA and NS Records . . . . . . . . . . . . . . . . . . . 4 58 4.2. Zone Data . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2.1. Resource Record Format . . . . . . . . . . . . . . . 5 60 4.2.2. Multi-valued Properties . . . . . . . . . . . . . . . 5 61 4.2.3. Vendor-specific Properties . . . . . . . . . . . . . 6 62 4.3. Zone Structure . . . . . . . . . . . . . . . . . . . . . 6 63 4.3.1. List of Member Zones . . . . . . . . . . . . . . . . 6 64 4.3.2. Catalog Zone Schema Version . . . . . . . . . . . . . 7 65 4.3.3. Default Zone Configuration . . . . . . . . . . . . . 7 66 4.3.4. Zone Properties Specific to a Member Zone . . . . . . 7 67 5. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.1. String . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. Booleans . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.3. Integers . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.4. Floating-Point Values . . . . . . . . . . . . . . . . . . 9 72 5.5. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.6. IP Prefix . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.7. Single Host Address . . . . . . . . . . . . . . . . . . . 10 75 6. Nameserver Behavior . . . . . . . . . . . . . . . . . . . . . 10 76 6.1. General Requirements . . . . . . . . . . . . . . . . . . 10 77 6.2. Updating Catalog Zones . . . . . . . . . . . . . . . . . 11 78 6.3. Implementation Notes . . . . . . . . . . . . . . . . . . 11 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 10.1. Normative references . . . . . . . . . . . . . . . . . . 12 84 10.2. Informative references . . . . . . . . . . . . . . . . . 13 85 Appendix A. Open issues and discussion (to be removed before 86 final publication) . . . . . . . . . . . . . . . . . 14 87 Appendix B. Change History (to be removed before final 88 publication) . . . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 The data in a DNS zone is synchronized amongst its primary and 94 secondary nameservers using AXFR and IXFR. However, the list of 95 zones served by the primary (called a catalog in [RFC1035]) is not 96 automatically synchronized with the secondaries. To add or remove a 97 zone, the administrator of a DNS nameserver farm not only has to add 98 or remove the zone from the primary, they must also add/remove the 99 zone from all secondaries, either manually or via an external 100 application. This can be both inconvenient and error-prone; it will 101 also be dependent on the nameserver implementation. 103 This document describes a method in which the catalog is represented 104 as a regular DNS zone (called a "catalog zone" here), and transferred 105 using DNS zone transfers. As zones are added to or removed from the 106 catalog zone, the changes are propagated to the secondary nameservers 107 in the normal way. The secondary nameservers then add/remove/modify 108 the zones they serve in accordance with the changes to the zone. 110 The contents and representation of catalog zones are described in 111 Section 3. Nameserver behavior is described in Section 6. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 Catalog zone: A DNS zone containing a DNS catalog, that is, a list 120 of DNS zones and associated zone configuration. 122 Member zone: A DNS zone whose configuration is published inside a 123 catalog zone. 125 Zone property: A configuration parameter of a zone, sometimes also 126 called a zone option, represented as a key/value pair. 128 $CATZ: Used in examples as a placeholder to represent the domain 129 name of the catalog zone itself (c.f. $ORIGIN). 131 3. Description 133 A catalog zone is a specially crafted DNS zone that contains, as DNS 134 zone data: 136 o A list of DNS zones (called "member zones"). 138 o Default zone configuration information common to all member zones. 140 o Zone-specific configuration information. 142 An implementation of catalog zones MAY allow the catalog to contain 143 other catalog zones as member zones, but default zone configuration 144 present in a catalog zone only applies to its immediate member zones. 146 Although the contents of a catalog zone are interpreted and acted 147 upon by nameservers, a catalog zone is a regular DNS zone and so must 148 adhere to the standards for such zones. 150 A catalog zone is primarily intended for the management of a farm of 151 authoritative nameservers. It is not expected that the content of 152 catalog zones will be accessible from any recursive nameserver. 154 4. Catalog Zone Structure 156 4.1. SOA and NS Records 158 As with any other DNS zone, a catalog zone MUST have a syntactically 159 correct SOA record and one or more NS records at its apex. 161 The SOA record's SERIAL, REFRESH, RETRY and EXPIRE fields [RFC1035] 162 are used during zone transfer. A catalog zone's SOA SERIAL field 163 MUST increase when an update is made to the catalog zone's contents 164 as per serial number arithmetic defined in [RFC1982]. Otherwise, 165 secondary nameservers might not notice updates to the catalog zone's 166 contents. 168 Should the zone be made available for querying, the SOA record's 169 MINIMUM field's value is the negative cache time (as defined in 170 [RFC2308]). Since recursive nameservers are not expected to be able 171 to access (and subsequently cache) entries from a catalog zone a 172 value of zero (0) is RECOMMENDED. 174 Since there is no requirement to be able to query the catalog zone 175 via recursive namservers the NS records at the apex will not be used 176 and no parent delegation is required. However, they are still 177 required so that catalog zones are syntactically correct DNS zones. 178 Any valid DNS name can be used in the NSDNAME field of such NS 179 records [RFC1035] and they MUST be ignored. A single NS RR with an 180 NSDNAME field containing the absolute name "invalid." is RECOMMENDED 181 [RFC2606]. 183 4.2. Zone Data 185 A catalog zone contains a set of key/value pairs, where each key is 186 encapsulated within the owner name of a DNS RR and the corresponding 187 value is stored in the RR's RDATA. The specific owner name depends 188 on whether the property relates to the catalog zone itself, a member 189 zone thereof, or to default zone properties described in Section 4.3. 190 The owner names are case insensitive. 192 4.2.1. Resource Record Format 194 Each key/value pair has a defined data type, and each data type 195 accordingly uses a particular RR TYPE to represent its possible 196 values, as specified in Section 5. 198 The general form of a catalog zone record is as follows: 200 [.]..$CATZ 0 IN 202 where is a sequence of labels with values depending on the 203 purpose (and hence position) of the record within the catalog zone 204 (see Section 4.3) and where the prefix is only present 205 for multi-valued properties (see Section 4.2.2). 207 NB: Catalog zones use some RR TYPEs (such as PTR) with alternate 208 semantics to those originally defined for them. Although this may be 209 controversial, the situation is similar to other similar zone-based 210 representations such as response-policy zones [RPZ]. 212 The CLASS field of every RR in a catalog zone MUST be IN (1). This 213 is because some RR TYPEs such as APL used by catalog zones are 214 defined only for the IN class. 216 The TTL field's value is not specially defined by this memo. Catalog 217 zones are for authoritative nameserver management only and are not 218 intended for general querying via recursive resolvers and therefore a 219 value of zero (0) is RECOMMENDED. 221 It is an error for any single owner name within a catalog zone (other 222 than the apex of the zone itself) to have more than one RR associated 223 with it. 225 4.2.2. Multi-valued Properties 227 Some properties do not represent single values but instead represent 228 a collection of values. The specification for each property 229 describes whether it is single-valued or multi-valued. A multi- 230 valued property is encoded as multiple RRs where the owner name of 231 each individual RR contains a unique (user specified) DNS label. 233 So, while a single-valued key might be represented like this: 235 ..$CATZ IN TXT "value" 237 a multi-valued key would be represented like this: 239 ...$CATZ IN TXT "value 1" 240 ...$CATZ IN TXT "value 2" 241 ... 243 NB: a property that is specified to be multi-valued MUST be encoded 244 using the unique prefixed key syntax even if there is only one value 245 present. 247 The specification of any multi-valued property MUST document whether 248 the collection represents either an ordered or un-ordered list. In 249 the former case the ordering of the prefixes according to the usual 250 DNS canonical name ordering will determine the sort order. 252 4.2.3. Vendor-specific Properties 254 TBD: Prepare a list of zone configuration properties that are common 255 to DNS implementations. This is so that a company may manage a 256 catalog zone using a Windows DNS server as the primary, and a 257 secondary nameserver hosting service may pick up the common 258 properties and may use a different nameserver implementation such as 259 BIND or NSD on a POSIX operating system to serve it. 261 TBD: We may specify that unrecognized zone property names must be 262 ignored, or that nameserver specific properties must be specified 263 using the "x-" prefix similar to MIME type naming. 265 TBD: Any list of zone properties is ideally maintained as a registry 266 rather than within this memo. 268 4.3. Zone Structure 270 4.3.1. List of Member Zones 272 The list of member zones is specified as a multi-valued collection of 273 domain names under the owner name "zones" where "zones" is a direct 274 child domain of the catalog zone. 276 The names of member zones are represented on the RDATA side (instead 277 of as a part of owner names) so that all valid domain names may be 278 represented regardless of their length [RFC1035]. 280 For example, if a catalog zone lists three zones "example.com.", 281 "example.net." and "example.org.", the RRs would appear as follows: 283 .zones.$CATZ 0 IN PTR example.com. 284 .zones.$CATZ 0 IN PTR example.net. 285 .zones.$CATZ 0 IN PTR example.org. 287 where is a label that uniquely tags each record in the 288 collection, as described in Section 4.2.2. 290 Although any legal label could be used for it is 291 RECOMMENDED that it be a value deterministically derived from the 292 fully-qualified member zone name. The BIND9 implementation uses the 293 40 character hexadecimal representation of the SHA-1 digest 294 [FIPS.180-4.2015] of the lower-cased member zone name as encoded in 295 uncompressed wire format. 297 4.3.2. Catalog Zone Schema Version 299 The catalog zone schema version is specified by an unsigned integer 300 property with the property name "version". All catalog zones MUST 301 have this property present. Primary and secondary nameservers MUST 302 NOT use catalog zones with an unexpected value in this property, but 303 they may be transferred as ordinary zones. For this memo, the 304 "version" property value MUST be set to 2, i.e. 306 version.$CATZ 0 IN TXT "2" 308 NB: Version 1 was used in a draft version of this memo and reflected 309 the implementation first found in BIND 9.11. 311 4.3.3. Default Zone Configuration 313 Default zone configuration comprises a set of properties that are 314 applied to all member zones listed in the catalog zone unless 315 overridden my member zone-specific information. 317 All such properties are stored as child nodes of the owner name 318 "defaults" itself a direct child node of the catalog zone, e.g.: 320 example-prop.defaults.$CATZ 0 IN TXT "Example" 322 4.3.4. Zone Properties Specific to a Member Zone 324 Default zone properties can be overridden on a per-zone basis by 325 specifying the property under the the sub-domain associated with the 326 member zone in the list of zones, e.g.: 328 example-prop..zones.$CATZ 0 IN TXT "Example" 330 where "m-unique" is the label that uniquely identifies the member 331 zone name as described in Section 4.3.1. 333 NB: when a zone-specific property is multi-valued the owner name will 334 contain two unique identifiers, the left-most tagging being 335 associated with the individual value () and the other 336 () associated with the member zone itself, e.g.: 338 $ORIGIN .zones.$CATZ 339 .example-prop 0 IN TXT "Value 1" 340 .example-prop 0 IN TXT "Value 2" 341 ... 343 5. Data Types 345 This section lists the various data types defined for use within 346 catalog zones. 348 5.1. String 350 A key with a string value is represented with a TXT RR [RFC1035], 351 e.g.: 353 example-prop..zones.$CATZ 0 IN TXT "Example" 355 If the RDATA is split into multiple elements the 356 MUST be directly concatenated without any separating character. 358 5.2. Booleans 360 A key with a boolean value is represented with a TXT RR containing a 361 single with a value of "true" for true condition 362 and "false" for false condition, e.g: 364 example-prop..zones.$CATZ 0 IN TXT "false" 366 The RDATA is case-insensitive. 368 5.3. Integers 370 A key with an integer value is specified using a TXT RR containing a 371 single . 373 A signed integer's TXT RDATA uses the representation of an unsuffixed 374 "integer constant" as defined in the C programming language standard 375 [ISO.9899.1990] (of the type matching a 64-bit signed integer on that 376 platform), with an optional minus prefix. 378 An unsigned integer's TXT RDATA uses the representation of an 379 unsuffixed "integer constant" as defined in the C programming 380 language standard [ISO.9899.1990] (of the type matching a 64-bit 381 unsigned integer on that platform). 383 For example, a property with an unsigned integer value of 300 would 384 appear as follows: 386 example-prop..zones.$CATZ 0 IN TXT "300" 388 5.4. Floating-Point Values 390 A key with a floating-point value is specified using a TXT RR 391 containing a single . 393 A floating-point value's TXT RDATA uses the representation of an 394 unsuffixed "floating constant" as defined in the C programming 395 language standard [ISO.9899.1990]. 397 For example, a property with an unsigned integer value of 0.15 may 398 appear as follows: 400 example-prop..zones.$CATZ 0 IN TXT "15e-2" 402 5.5. Domain Name 404 A key whose value is a domain name is specified using a PTR RR 405 [RFC1035], e.g.: 407 example-prop.defaults.$CATZ 0 IN PTR ns1.example.com. 409 5.6. IP Prefix 411 A property whose value is an IP network prefix is specified using an 412 APL RR [RFC3123]. The negation flag ("!" in presentation format) may 413 be used to indicate all addresses not included within that prefix, 414 e.g. for use in Access Control Lists, e.g.: 416 Although a single APL record is capable of containing multiple 417 prefixes, for consistency of representation lists of prefixes MUST 418 use the multi-valued property syntax as documented in Section 4.2.2, 419 e.g.: 421 $ORIGIN .zones.$CATZ 422 .example-prop 0 IN APL ( 1:192.0.2.0/24 ) 423 .example-prop 0 IN APL ( !1:0.0.0.0/0 ) 425 Implementations MUST accept only the first prefix within each APL 426 record and MUST ignore any subsequent prefixes found therein. 428 5.7. Single Host Address 430 A single host address is represented using either an A or AAAA record 431 as appropriate, e.g.: 433 example-prop1..zones.$CATZ 0 IN A 192.0.2.1 434 example-prop2..zones.$CATZ 0 IN AAAA 2001:db8::1 436 6. Nameserver Behavior 438 6.1. General Requirements 440 As it is a regular DNS zone, a catalog zone can be transferred using 441 DNS zone transfers among nameservers. 443 Although they are regular DNS zones, catalog zones contain only 444 information for the management of a set of authoritative nameservers. 445 For this reason, operators may want to limit the systems able to 446 query these zones. It may be inconvenient to serve some contents of 447 catalog zones via DNS queries anyway due to the nature of their 448 representation. A separate method of querying entries inside the 449 catalog zone may be made available by nameserver implementations (see 450 Section 6.3). 452 Catalog updates should be automatic, i.e., when a nameserver that 453 supports catalog zones completes a zone transfer for a catalog zone, 454 it SHOULD apply changes to the catalog within the running nameserver 455 automatically without any manual intervention. 457 As with regular zones, primary and secondary nameservers for a 458 catalog zone may be operated by different administrators. The 459 secondary nameservers may be configured to synchronize catalog zones 460 from the primary, but the primary's administrators may not have any 461 administrative access to the secondaries. 463 A catalog zone can be updated via DNS UPDATE on a reference primary 464 nameserver, or via zone transfers. Nameservers MAY allow loading and 465 transfer of broken zones with incorrect catalog zone syntax (as they 466 are treated as regular zones), but nameservers MUST NOT process such 467 broken zones as catalog zones. For the purpose of catalog 468 processing, the broken catalogs MUST be ignored. If a broken catalog 469 zone was transferred, the newly transferred catalog zone MUST be 470 ignored (but the older copy of the catalog zone SHOULD be left 471 running subject to values in SOA fields). 473 If there is a clash between an existing member zone's name and an 474 incoming member zone's name (via transfer or update), the new 475 instance of the zone MUST be ignored and an error SHOULD be logged. 477 When zones are introduced into a catalog zone, a primary SHOULD first 478 make the new zones available for transfers before making the updated 479 catalog zone available for transfer, or sending NOTIFY for the 480 catalog zone to secondaries. Note that secondary nameservers may 481 attempt to transfer the catalog zone upon refresh timeout, so care 482 must be taken to make the member zones available before any update to 483 the list of member zones is visible in the catalog zone. 485 When zones are deleted from a catalog zone, a primary MAY delete the 486 member zone immediately after notifying secondaries. It is up to the 487 secondary nameserver to handle this condition correctly. 489 TBD: Transitive primary-secondary relationships 491 6.2. Updating Catalog Zones 493 TBD: Explain updating catalog zones using DNS UPDATE. 495 6.3. Implementation Notes 497 Catalog zones on secondary nameservers would have to be setup 498 manually, perhaps as static configuration, similar to how ordinary 499 DNS zones are configured. Members of such catalog zones will be 500 automatically synchronized by the secondary after the catalog zone is 501 configured. 503 An administrator may want to look at data inside a catalog zone. 504 Typical queries might include dumping the list of member zones, 505 dumping a member zone's effective configuration, querying a specific 506 property value of a member zone, etc. Because of the structure of 507 catalog zones, it may not be possible to perform these queries 508 intuitively, or in some cases, at all, using DNS QUERY. For example 509 it is not possible to enumerate the contents of a multi-valued 510 property (such as the list of member zones) with a single QUERY. 511 Implementations are therefore advised to provide a tool that uses 512 either the output of AXFR or an out-of-band method to perform queries 513 on catalog zones. 515 7. Security Considerations 517 As catalog zones are transmitted using DNS zone transfers, it is 518 absolutely essential for these transfers to be protected from 519 unexpected modifications on the route. So, catalog zone transfers 520 SHOULD be authenticated using TSIG [RFC2845]. A primary nameserver 521 SHOULD NOT serve a catalog zone for transfer without using TSIG and a 522 secondary nameserver SHOULD abandon an update to a catalog zone that 523 was received without using TSIG. 525 Use of DNS UPDATE [RFC2136] to modify the content of catalog zones 526 SHOULD similarly be authenticated using TSIG. 528 Zone transfers of member zones SHOULD similarly be authenticated 529 using TSIG [RFC2845]. The TSIG shared secrets used for member zones 530 MUST NOT be mentioned anywhere in the catalog zone data. However, 531 key identifiers may be shared within catalog zones. 533 Catalog zones do not need to be signed using DNSSEC, their zone 534 transfers being authenticated by TSIG. Signed zones MUST be handled 535 normally by nameservers, and their contents MUST NOT be DNSSEC- 536 validated. 538 8. IANA Considerations 540 This document has no IANA actions. 542 9. Acknowledgements 544 Catalog zones originated as the chosen method among various proposals 545 that were evaluated at ISC for easy zone management. The chosen 546 method of storing the catalog as a regular DNS zone was proposed by 547 Stephen Morris. 549 We later discovered that Paul Vixie's earlier [Metazones] proposal 550 implemented a similar approach and reviewed it. Catalog zones 551 borrows some syntax ideas from Metazones, as both share this scheme 552 of representing the catalog as a regular DNS zone. 554 Thanks to Brian Conry, Tony Finch, Evan Hunt, Patrik Lundin, Victoria 555 Risk and Carsten Strettman for reviewing draft proposals and offering 556 comments and suggestions. 558 10. References 560 10.1. Normative references 562 [FIPS.180-4.2015] 563 National Institute of Standards and Technology, "Secure 564 Hash Standard", FIPS PUB 180-4, August 2015, 565 . 568 [ISO.9899.1990] 569 International Organization for Standardization, 570 "Programming languages - C", ISO Standard 9899, 1990. 572 [RFC1035] Mockapetris, P., "Domain names - implementation and 573 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 574 November 1987, . 576 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 577 DOI 10.17487/RFC1982, August 1996, . 580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 581 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 582 RFC2119, March 1997, . 585 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 586 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 587 RFC 2136, DOI 10.17487/RFC2136, April 1997, 588 . 590 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 591 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 592 . 594 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 595 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 596 . 598 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 599 Wellington, "Secret Key Transaction Authentication for DNS 600 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 601 . 603 [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes 604 (APL RR)", RFC 3123, DOI 10.17487/RFC3123, June 2001, 605 . 607 10.2. Informative references 609 [Metazones] 610 Vixie, P., "Federated Domain Name Service Using DNS 611 Metazones", 2005, . 613 [RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones (DNS 614 RPZ)", 2010, 615 . 617 Appendix A. Open issues and discussion (to be removed before final 618 publication) 620 1. Config options 622 We want catalog zones to be adopted by multiple DNS 623 implementations. Towards this, we have to generalize zone config 624 options and adopt a minimal set that we can expect most 625 implementations to support. 627 2. Catalog zone and member zones on different primary nameservers 629 Will it be possible to setup a catalog zone on one nameserver as 630 primary, and allow its member zones to be served by different 631 primary nameservers? 633 3. Transitive relationships 635 For a catalog zone, a secondary nameserver may be a primary 636 nameserver to a different set of nameservers in a nameserver 637 farm. In these transitive relationships, zone configuration 638 options (such as also-notify and allow-transfer) may differ based 639 on the location of the primary in the hierarchy. It may not be 640 possible to specify this within a catalog zone. 642 4. Overriding controls 644 A way to override zone config options (as prescribed by the 645 catalog zones) on secondary nameservers was requested. As this 646 would be configured outside catalog zones, it may be better to 647 leave this to implementations. 649 Appendix B. Change History (to be removed before final publication) 651 o draft-muks-dnsop-dns-catalog-zones-00 652 Initial public draft. 654 o draft-muks-dnsop-dns-catalog-zones-01 655 Added Witold, Ray as authors. Fixed typos, consistency issues. 656 Fixed references. Updated Area. Removed newly introduced custom 657 RR TYPEs. Changed schema version to 1. Changed TSIG requirement 658 from MUST to SHOULD. Removed restrictive language about use of 659 DNS QUERY. When zones are introduced into a catalog zone, a 660 primary SHOULD first make the new zones available for transfers 661 first (instead of MUST). Updated examples, esp. use IPv6 in 662 examples per Fred Baker. Add catalog zone example. 664 o draft-muks-dnsop-dns-catalog-zones-02 665 Addressed some review comments by Patrik Lundin. 667 o draft-muks-dnsop-dns-catalog-zones-03 668 Revision bump. 670 o draft-muks-dnsop-dns-catalog-zones-04 671 Reordering of sections into more logical order. 672 Separation of multi-valued properties into their own category. 674 Authors' Addresses 676 Mukund Sivaraman 677 Internet Systems Consortium 678 950 Charter Street 679 Redwood City, CA 94063 680 US 682 Email: muks@mukund.org 683 URI: http://www.isc.org/ 685 Stephen Morris 686 Internet Systems Consortium 687 950 Charter Street 688 Redwood City, CA 94063 689 US 691 Email: stephen@isc.org 692 URI: http://www.isc.org/ 694 Ray Bellis 695 Internet Systems Consortium 696 950 Charter Street 697 Redwood City, CA 94063 698 US 700 Email: ray@isc.org 701 URI: http://www.isc.org/ 702 Witold Krecicki 703 Internet Systems Consortium 704 950 Charter Street 705 Redwood City, CA 94063 706 US 708 Email: wpk@isc.org 709 URI: http://www.isc.org/