idnits 2.17.1 draft-muks-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2015) is 3112 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) == Outdated reference: A later version (-02) exists of draft-hunt-note-rr-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Morris 3 Internet-Draft M. Sivaraman 4 Intended status: Experimental Internet Systems Consortium 5 Expires: April 20, 2016 October 18, 2015 7 DNS catalog zones 8 draft-muks-dnsop-dns-catalog-zones-00 10 Abstract 12 This document describes a method for automatic zone catalog 13 provisioning and synchronization among DNS primary and secondary 14 nameservers by storing and transferring the catalogs as regular DNS 15 zones. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 20, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Catalog zones . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Description . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Resource record fields . . . . . . . . . . . . . . . . . 4 55 2.3. SOA and NS records at apex . . . . . . . . . . . . . . . 5 56 2.4. RR TYPEs to represent data . . . . . . . . . . . . . . . 5 57 2.4.1. BOOL RR TYPE (boolean condition) . . . . . . . . . . 5 58 2.4.1.1. BOOL RDATA wire format . . . . . . . . . . . . . 5 59 2.4.1.2. BOOL RDATA presentation format . . . . . . . . . 6 60 2.4.1.3. BOOL RR example . . . . . . . . . . . . . . . . . 6 61 2.4.2. FLOAT RR TYPE (floating-point value) . . . . . . . . 6 62 2.4.2.1. FLOAT RDATA wire format . . . . . . . . . . . . . 6 63 2.4.2.2. FLOAT RDATA presentation format . . . . . . . . . 6 64 2.4.2.3. FLOAT RR example . . . . . . . . . . . . . . . . 6 65 2.4.3. INT RR TYPE (64-bit signed integer value) . . . . . . 6 66 2.4.3.1. INT RDATA wire format . . . . . . . . . . . . . . 6 67 2.4.3.2. INT RDATA presentation format . . . . . . . . . . 7 68 2.4.3.3. INT RR example . . . . . . . . . . . . . . . . . 7 69 2.4.4. UINT RR TYPE (64-bit unsigned integer value) . . . . 7 70 2.4.4.1. UINT RDATA wire format . . . . . . . . . . . . . 7 71 2.4.4.2. UINT RDATA presentation format . . . . . . . . . 7 72 2.4.4.3. UINT RR example . . . . . . . . . . . . . . . . . 7 73 2.5. Zone properties map and owner names . . . . . . . . . . . 7 74 2.6. Zone property value data types . . . . . . . . . . . . . 8 75 2.6.1. Strings . . . . . . . . . . . . . . . . . . . . . . . 8 76 2.6.2. Booleans . . . . . . . . . . . . . . . . . . . . . . 8 77 2.6.3. Integers . . . . . . . . . . . . . . . . . . . . . . 9 78 2.6.4. Floating-point values . . . . . . . . . . . . . . . . 9 79 2.6.5. Single names . . . . . . . . . . . . . . . . . . . . 10 80 2.6.6. Unordered list of names . . . . . . . . . . . . . . . 10 81 2.6.7. List of network addresses . . . . . . . . . . . . . . 10 82 2.6.8. Single host address . . . . . . . . . . . . . . . . . 11 83 2.6.9. Comments . . . . . . . . . . . . . . . . . . . . . . 11 84 2.7. Catalog zone version . . . . . . . . . . . . . . . . . . 11 85 2.8. List of member zones . . . . . . . . . . . . . . . . . . 12 86 2.9. Zone configuration properties . . . . . . . . . . . . . . 12 87 2.9.1. zone-soa-default-serial . . . . . . . . . . . . . . . 12 88 2.9.2. zone-soa-default-refresh . . . . . . . . . . . . . . 12 89 2.10. Zone properties specific to a member zone . . . . . . . . 12 90 2.11. Examples of catalog zones . . . . . . . . . . . . . . . . 13 91 3. Nameserver behavior and requirements . . . . . . . . . . . . 13 92 3.1. General requirements . . . . . . . . . . . . . . . . . . 13 93 3.2. Updating catalog zones . . . . . . . . . . . . . . . . . 14 94 3.3. Implementation notes . . . . . . . . . . . . . . . . . . 14 95 4. Security considerations . . . . . . . . . . . . . . . . . . . 15 96 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 97 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 98 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 7.1. Normative references . . . . . . . . . . . . . . . . . . 16 100 7.2. Informative references . . . . . . . . . . . . . . . . . 17 101 Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 17 102 Appendix B. Open issues and discussion (to be removed before 103 final publication) . . . . . . . . . . . . . . . . . 18 104 Appendix C. Change History (to be removed before final 105 publication) . . . . . . . . . . . . . . . . . . . . 19 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 108 1. Introduction 110 DNS nameservers implement AXFR and IXFR for zone data synchronization 111 among a zone's primary its and secondary nameservers, but the list of 112 zones served by the primary (called a catalog in [RFC1035]) is not 113 automatically synchronized. The administrator of a DNS nameserver 114 farm has to manually, or via an external application layer, 115 synchronize such zone catalogs among primaries and their secondary 116 nameservers. This can be inconvenient, error-prone and dependent on 117 the nameserver implementation. 119 A method for automatic zone catalog provisioning and synchronization 120 is useful, so that the zone catalog can be maintained in a reference 121 location by an administrator, similar to zone data. 123 This document describes one such method, in which the catalog is 124 represented as a regular DNS zone called a "catalog zone", and 125 transferred using DNS zone transfers. The representation of catalogs 126 within DNS zones is specified and nameserver requirements are listed 127 so that DNS implementations can support catalog zones. 129 The contents and representation of catalog zones are described in 130 Section 2. Nameserver behavior is described in Section 3. A 131 glossary of some terms used in this memo is provided in Appendix A. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 2. Catalog zones 139 2.1. Description 141 A catalog zone is a specially crafted DNS zone that contains, as DNS 142 zone data, a list of DNS zones called member zones and associated 143 template zone configuration common to all its member zones. An 144 implementation of catalog zones MAY allow catalog zones to include 145 other catalog zones, but template zone configuration present in a 146 catalog zone only applies to its immediate member zones. A catalog 147 zone is meant to be used to provision DNS catalogs to secondary 148 nameservers via zone transfers, for the purpose of setting up member 149 zones to be served from these secondary nameservers. 151 A catalog zone uses some RR TYPEs such as PTR differently to achieve 152 its purpose. Though this may be controversial, the situation is not 153 different from other similar zone-based representations such as 154 response-policy zones [RPZ]. However, none of the RR TYPEs used by 155 catalog zones can incur any additional section processing during DNS 156 QUERY. Other than being transmitted via zone transfers, catalog 157 zones do not participate in the DNS and are not intended to be served 158 via DNS QUERY [RFC1035]. 160 Member zones' configuration is specified as a map of zone properties, 161 represented as a subtree of a node [RFC1034] in the domain name space 162 inside a catalog zone. This is described in Section 2.5. Each zone 163 property has a name and an associated value of a specific data type. 164 Zone property value data types are described in Section 2.6. A list 165 of permitted zone property names and their data types is given in 166 Section 2.9. 168 TBD: Transitive catalogs 170 2.2. Resource record fields 172 A catalog zone contains various resource records (RRs). They have 173 NAME, TYPE, CLASS, TTL, RDLENGTH and RDATA as fields [RFC1035]. 175 The NAME field contains the owner name of the respective RR. As with 176 all DNS zones, the owner name must be a child of the catalog zone 177 name. 179 The TYPE field depends on the type of catalog zone property value 180 being represented. Section 2.6 describes how various zone property 181 value types are represented. 183 The CLASS field of the RR MUST be set to the value 1 (IN) [RFC1035]. 184 This is because some RR TYPEs such as APL used by catalog zones are 185 defined only for the IN CLASS. 187 The TTL field's value is not specially defined by this memo. Catalog 188 zones do not participate in the DNS and are not intended to be served 189 via DNS QUERY [RFC1035], but this memo does not restrict their use. 191 The RDLENGTH field contains the length of the RDATA field. 193 The content of the RDATA field depends on the type of catalog zone 194 property value being represented. Section 2.6 describes how various 195 zone property value types are represented. 197 2.3. SOA and NS records at apex 199 Similar to any other DNS zone, a catalog zone would be expected to 200 have a syntactically correct SOA record and one or more NS records at 201 its apex. 203 The SOA record's SERIAL, REFRESH, RETRY and EXPIRE fields [RFC1035] 204 are used during zone transfer. A catalog zone's SOA SERIAL field 205 MUST increase when an update is made to the catalog zone's contents. 206 Otherwise, secondary nameservers may not notice updates to the 207 catalog zone's contents. 209 The SOA record's MINIMUM field's value is not specially defined by 210 this memo. Catalog zones do not participate in the DNS and are not 211 intended to be served via DNS QUERY [RFC1035], but this memo does not 212 restrict their use. 214 As catalog zones do not participate in the DNS, NS records at the 215 apex are not used but they are still required so that catalog zones 216 are syntactically correct DNS zones. No parent delegation for the 217 catalog zone is required. Any valid DNS name can be used in the 218 NSDNAME field of such NS records [RFC1035] and they MUST be ignored. 219 A single NS RR with an NSDNAME field containing the absolute name 220 "invalid." is recommended [RFC2606]. 222 2.4. RR TYPEs to represent data 224 This section introduces new RR TYPEs to represent some types of data 225 for which no convenient representation is currently available. These 226 are used in Section 2.6. These are general-purpose RR TYPEs and 227 their use is not limited to catalog zones. 229 2.4.1. BOOL RR TYPE (boolean condition) 231 The BOOL RR TYPE represents a single boolean condition in its RDATA. 233 2.4.1.1. BOOL RDATA wire format 235 The BOOL RDATA consists of a single octet (RDLENGTH is 1). A zero 236 valued octet represents the false condition and a non-zero valued 237 octet represents the true condition. Implementations SHOULD generate 238 an octet value of 1 to represent true conditions. 240 2.4.1.2. BOOL RDATA presentation format 242 The BOOL RDATA's presentation is represented with the mnemonic 243 "FALSE" for the false condition, and "TRUE" for the true condition. 244 The presentation is case-insensitive. 246 2.4.1.3. BOOL RR example 248 The following example shows BOOL RRs: 250 is-ready.example.org. 3600 IN BOOL TRUE 251 allow-query.example.org. 3600 IN BOOL False 253 2.4.2. FLOAT RR TYPE (floating-point value) 255 The FLOAT RR TYPE represents a value in IEEE 754 double-precision 256 floating-point representation in its RDATA. 258 2.4.2.1. FLOAT RDATA wire format 260 The FLOAT RDATA consists of a value in IEEE 754 double-precision 261 floating-point representation [IEEE.754.1985] in network byte order, 262 which occupies 8 octets (RDLENGTH is 8). 264 2.4.2.2. FLOAT RDATA presentation format 266 The FLOAT RDATA's presentation uses the representation of an 267 unsuffixed "floating constant" as defined in the C programming 268 language standard [ISO.9899.1990]. 270 2.4.2.3. FLOAT RR example 272 The following example shows FLOAT RRs: 274 x.sample-color.example.org. 3600 IN FLOAT 0.8 275 y.sample-color.example.org. 3600 IN FLOAT 0.2 276 z.sample-color.example.org. 3600 IN FLOAT 0.5 278 2.4.3. INT RR TYPE (64-bit signed integer value) 280 The INT RR TYPE represents a 64-bit signed integer in its RDATA. 282 2.4.3.1. INT RDATA wire format 284 The INT RDATA consists of a 64-bit signed integer in two's complement 285 representation, in network byte order, which occupies 8 octets 286 (RDLENGTH is 8). 288 2.4.3.2. INT RDATA presentation format 290 The INT RDATA's presentation uses the representation of an unsuffixed 291 "integer constant" as defined in the C programming language standard 292 [ISO.9899.1990] (of the type matching a 64-bit signed integer on that 293 platform), with an optional minus prefix. 295 Scanners must read any of the various formats possible. Printers 296 must output the RDATA in base-10 decimal format. 298 2.4.3.3. INT RR example 300 The following example shows a INT RR: 302 counter-increment.example.org. 3600 IN INT -0x1 304 2.4.4. UINT RR TYPE (64-bit unsigned integer value) 306 The UINT RR TYPE represents a 64-bit unsigned integer in its RDATA. 308 2.4.4.1. UINT RDATA wire format 310 The UINT RDATA consists of a 64-bit unsigned integer, in network byte 311 order, which occupies 8 octets (RDLENGTH is 8). 313 2.4.4.2. UINT RDATA presentation format 315 The UINT RDATA's presentation uses the representation of an 316 unsuffixed "integer constant" as defined in the C programming 317 language standard [ISO.9899.1990] (of the type matching a 64-bit 318 signed integer on that platform). 320 Scanners must read any of the various formats possible. Printers 321 must output the RDATA in base-10 decimal format. 323 2.4.4.3. UINT RR example 325 The following example shows a UINT RR: 327 max-query-rate.example.org. 3600 IN UINT 3600 329 2.5. Zone properties map and owner names 331 Member zones' configuration is specified as a map of zone properties, 332 represented as a subtree of a node [RFC1034] in the domain name space 333 inside a catalog zone. A subtree of child nodes is used for a nested 334 map, occuping another label level. A map element's key (property 335 name) is represented in the label at that level. For example, if a 336 catalog zone is named "catalog1.example.org." and contains a property 337 with name "prop0", the corresponding owner name of the node 338 representing that property is "prop0.catalog1.example.org." 340 Zone property names are case-insensitive. Each zone property may use 341 only one data type for its values. A list of permitted zone property 342 names and their data types is given in Section 2.9. 344 Many properties are single-valued, but some properties can be 345 collections with thousands of values. An example is the list of 346 member zones within a catalog zone, which can be larger than any 347 single RDATA instance can allow. Multiple RRs are used to represent 348 such properties. 350 TBD: Currently a hashing method in owner names is used to split the 351 elements of such properties with multiple RRs into individual RRsets, 352 one per RR. This needs to be revisited as IXFR and DNS UPDATE both 353 allow individual RRs within an RRset to be modified. The hashing 354 method used is described in the appropriate property value data types 355 in Section 2.6. 357 2.6. Zone property value data types 359 2.6.1. Strings 361 A property with a string value is specified using a single TXT RR 362 [RFC1035] with owner name set to the name of the property as a sub- 363 domain of the catalog zone name, and RDATA set to the property value. 365 For example, if a catalog zone is named "catalog1.example.org." and 366 contains a property "prop0" with string value "Example", the 367 corresponding RR may look as follows: 369 prop0.catalog1.example.org. 3600 IN TXT "Example" 371 Here, "prop0" can contain multiple TXT RRs at that node of the domain 372 name space [RFC1034]. The single string property SHOULD be checked 373 by the implementation. 375 2.6.2. Booleans 377 A property with a boolean value is specified using a single BOOL RR 378 (see Section 2.4.1) with owner name set to the name of the property 379 as a sub-domain of the catalog zone name, and RDATA set to the 380 property value. 382 For example, if a catalog zone is named "catalog1.example.org." and 383 contains a property "active" with boolean value false, the 384 corresponding RR may look as follows: 386 active.catalog1.example.org. 3600 IN BOOL false 388 Here, "active" can contain multiple BOOL RRs at that node of the 389 domain name space [RFC1034]. The single boolean property SHOULD be 390 checked by the implementation. 392 2.6.3. Integers 394 A property with an integer value is specified using a single INT RR 395 (see Section 2.4.3) for signed integers, or UINT RR (see 396 Section 2.4.4) for unsigned integers, with owner name set to the name 397 of the property as a sub-domain of the catalog zone name, and RDATA 398 set to the property value. 400 For example, if a catalog zone is named "catalog1.example.org." and 401 contains a property "min-ttl" with unsigned integer value 300, the 402 corresponding RR may look as follows: 404 min-ttl.catalog1.example.org. 3600 IN UINT 300 406 Here, "min-ttl" can contain multiple UINT RRs at that node of the 407 domain name space [RFC1034]. The single integer property SHOULD be 408 checked by the implementation. 410 2.6.4. Floating-point values 412 A property with a floating-point value is specified using a single 413 FLOAT RR (see Section 2.4.2) with owner name set to the name of the 414 property as a sub-domain of the catalog zone name, and RDATA set to 415 the property value. 417 For example, if a catalog zone is named "catalog1.example.org." and 418 contains a property "decay-rate" with value 0.33333333, the 419 corresponding RR may look as follows: 421 decay-rate.catalog1.example.org. 3600 IN FLOAT 0.33333333 423 Here, "decay-rate" can contain multiple FLOAT RRs at that node of the 424 domain name space [RFC1034]. The single floating-point property 425 SHOULD be checked by the implementation. 427 2.6.5. Single names 429 A property with a single name as value is specified using a PTR RR 430 [RFC1035] with owner name set to the name of the property as a sub- 431 domain of the catalog zone name, and RDATA set to the property value. 433 For example, if a catalog zone is named "catalog1.example.org." and 434 contains a property "prop1" with value "val1.example.com.", the 435 corresponding RR may look as follows: 437 prop1.catalog1.example.org. 3600 IN PTR val1.example.com. 439 Here, "prop1" can contain multiple PTR RRs at that node of the domain 440 name space [RFC1034]. The single name property SHOULD be checked by 441 the implementation. 443 2.6.6. Unordered list of names 445 Let N be an absolute name formed by concatenating the RDATA hash (see 446 Appendix A), the name of the property, and the catalog zone name in 447 that order, such that N is a unique owner name in the catalog zone. 449 Then, a property containing an unordered list of names as value is 450 specified using multiple PTR RRs [RFC1035] with owner name set to N, 451 and each RR's RDATA set to each name in the list of the property's 452 value respectively. 454 For example, if a catalog zone is named "catalog1.example.org." and 455 contains a property "prop2" with its value being an unordered list of 456 two names "a.example.com." and "b.example.com.", the corresponding 457 RRs may look as follows: 459 .prop2.catalog1.example.org. 3600 IN PTR a.example.com. 460 .prop2.catalog1.example.org. 3600 IN PTR b.example.com. 462 Here, "prop2"'s subtree child nodes (in the domain name space 463 [RFC1034]) can contain multiple PTR RRs at each child. For example, 464 .prop2 may contain multiple PTR RRs at that node. The single 465 name property SHOULD be checked by the implementation. 467 2.6.7. List of network addresses 469 A property with a list of network addresses as value is specified 470 using a single APL RR [RFC3123] with owner name set to the name of 471 the property as a sub-domain of the catalog zone name, and RDATA set 472 to the property value. In its presentation format, the "!" character 473 (corresponding to the negation flag) is used to negate a network 474 element. The exact meaning of a negated network element is left to 475 be described by the property that APL is used for. Note that the AFL 476 RR TYPE is defined only for the IN(1) RR CLASS. 478 For example, if a catalog zone is named "catalog1.example.org." and 479 contains a property "allow" with value [192.0.2.0/24, 480 198.51.100.0/24] as the list of networks, the corresponding RR may 481 look as follows: 483 allow.catalog1.example.org. 3600 IN APL (1:192.0.2.0/24 484 1:198.51.100.0/24) 486 Here, "allow" can contain multiple APL RRs at that node of the domain 487 name space [RFC1034]. The single APL RR property SHOULD be checked 488 by the implementation. 490 2.6.8. Single host address 492 A single host address is represented using the list of network 493 addresses data type (see Section 2.6.7) with a suitable network and 494 prefix to result in a single network address. 496 2.6.9. Comments 498 Comments may be added anywhere in a catalog zone using a scheme such 499 as NOTE RRs [I-D.hunt-note-rr]. This memo does not depend on NOTE 500 RRs and it is only suggested here as an informative reference. 502 2.7. Catalog zone version 504 The catalog zone version is specified by an unsigned integer property 505 with the property name "version". All catalog zones MUST have this 506 property present. Primary and secondary nameservers MUST NOT use 507 catalog zones with an unexpected value value in this property, but 508 they may be transferred as ordinary zones. For this memo, the 509 "version" property value MUST be set to 0. 511 For example, if a catalog zone is named "catalog1.example.org.", the 512 corresponding RR MUST look as follows: 514 version.catalog1.example.org. 3600 IN UINT 0 516 Here, "version" can contain multiple UINT RRs at that node of the 517 domain name space [RFC1034]. The single UINT RR property SHOULD be 518 checked by the implementation. 520 2.8. List of member zones 522 The list of member zones are specified as an unordered list (see 523 Section 2.6.6) of names under the owner name "zones" where "zones" is 524 a sub-domain of the catalog zone. 526 The names of member zones are represented on the RDATA side instead 527 of as part of owner names so that the entire name of a zone (that is 528 technically possible [RFC1035]) can be represented correctly. 530 For example, if a catalog zone is named "catalog1.example.org." and 531 lists 3 zones "example.com.", "example.net." and "example.org.", the 532 RRs may look as follows: 534 .zones.catalog1.example.org. 3600 IN PTR example.com. 535 .zones.catalog1.example.org. 3600 IN PTR example.net. 536 .zones.catalog1.example.org. 3600 IN PTR example.org. 538 2.9. Zone configuration properties 540 TBD: Prepare a list of zone configuration properties that are common 541 to DNS implementations. This is so that a company may manage a 542 catalog zone using a Windows DNS server as the primary, and a 543 secondary nameserver hosting service may pick up the common 544 properties and may use a different nameserver implementation such as 545 BIND or NSD on a POSIX operating system to serve it. 547 TBD: We may specify that unrecognized zone property names must be 548 ignored, or that nameserver specific properties must be specified 549 using the "x-" prefix similar to MIME type naming. 551 2.9.1. zone-soa-default-serial 553 TBD. 555 2.9.2. zone-soa-default-refresh 557 TBD. 559 2.10. Zone properties specific to a member zone 561 Member zones in a catalog zone share template zone configuration that 562 is common to all member zones in that catalog. This section 563 describes the syntax that can be used to specify zone properties 564 specific to single member zones. 566 Let N be an absolute name formed by concatenating the member zone 567 name hash (see Appendix A) and the catalog zone name in that order, 568 such that N is a unique owner name in the catalog zone. 570 Zone properties specific to a particular member zone are specified 571 under the respective sub-domain N. 573 For example, if a catalog zone is named "catalog1.example.org." and a 574 member zone "example.com." contains a property "prop0" with string 575 (see Section 2.6.1) value "Example", the corresponding RR may look as 576 follows: 578 prop0..catalog1.example.org. 3600 IN TXT "Example" 580 As another example, if a catalog zone is named "cat1.example.org." 581 and a member zone "example.com." contains a property "prop2" with its 582 value being an unordered list (see Section 2.6.6) of two names 583 "a.example.com." and "b.example.com.", the corresponding RRs may look 584 as follows: 586 .prop2..cat1.example.org. 3600 IN PTR a.example.com. 587 .prop2..cat1.example.org. 3600 IN PTR b.example.com. 589 2.11. Examples of catalog zones 591 TBD. 593 3. Nameserver behavior and requirements 595 3.1. General requirements 597 TBD: Explain nameserver behavior in a more detailed way here. It is 598 under-specified. 600 As it is a regular DNS zone, a catalog zone can be transferred using 601 DNS zone transfers among nameservers. Catalog zones do not 602 participate in the DNS and are not intended to be served via DNS 603 QUERY. It may be inconvenient to serve some contents of catalog 604 zones via DNS queries anyway due to the nature of their 605 representation. A separate method of querying entries inside the 606 catalog zone may be made available by nameserver implementations (see 607 Section 3.3). 609 Catalog updates should be automatic, i.e., when a nameserver that 610 supports catalog zones completes a zone transfer for a catalog zone, 611 it SHOULD apply changes to the catalog within the running nameserver 612 automatically without any manual intervention. 614 As with regular zones, primary and secondary nameservers for a 615 catalog zone may be operated by different administrators. The 616 secondary nameservers may be configured to synchronize catalog zones 617 from the primary, but the primary's administrators may not have any 618 administrative access to the secondaries. 620 A catalog zone can be updated via DNS UPDATE on a reference primary 621 nameserver, or via zone transfers. Nameservers MAY allow loading and 622 transfer of broken zones with incorrect catalog zone syntax (as they 623 are treated as regular zones), but nameservers MUST NOT process such 624 broken zones as catalog zones. For the purpose of catalog 625 processing, the broken catalogs MUST be ignored. 627 If there is a clash between an existing member zone's name and an 628 incoming member zone's name (via transfer or update), the new 629 instance of the zone MUST be ignored and an error SHOULD be logged. 631 When zones are introduced into a catalog zone, a primary MUST first 632 make the new zones available for transfers before making the updated 633 catalog zone available for transfer, or sending NOTIFY for the 634 catalog zone to secondaries. Note that secondary nameservers may 635 attempt to transfer the catalog zone upon refresh timeout, so care 636 must be taken to make the member zones available before any update to 637 the list of member zones is visible in the catalog zone. 639 When zones are deleted from a catalog zone, a primary MAY delete the 640 member zone immediately after notifying secondaries. It is up to the 641 secondary nameserver to handle this condition correctly. 643 TBD: Transitive primary-secondary relationships 645 3.2. Updating catalog zones 647 TBD: Explain updating catalog zones using DNS UPDATE. 649 3.3. Implementation notes 651 Catalog zones on secondary nameservers would have to be setup 652 manually, perhaps as static configuration, similar to how ordinary 653 DNS zones are configured. Members of such catalog zones will be 654 automatically synchronized by the secondary after the catalog zone is 655 configured. 657 An administrator would want to query data from a catalog zone. 658 Typical queries may include dumping the list of member zones, dumping 659 a member zone's effective configuration, querying a specific property 660 value of a member zone, etc. Because of the syntax of catalog zones, 661 it may not be possible to perform these queries efficiently (or in 662 some cases, at all) using DNS QUERY. The list of member zones may 663 not fit in a single DNS message. The set of present properties for a 664 zone cannot be queried using a single DNS QUERY. 666 Implementations are advised to provide a tool that uses either the 667 output of AXFR or an out-of-band method to perform queries on catalog 668 zones. 670 4. Security considerations 672 As catalog zones are transmitted using DNS zone transfers, it is 673 absolutely essential for these transfers to be protected from 674 unexpected modifications on the route. So, it is a requirement that 675 catalog zone transfers MUST be authenticated using TSIG [RFC2845]. A 676 primary nameserver MUST NOT serve a catalog zone for transfer without 677 using TSIG and a secondary nameserver MUST abandon an update to a 678 catalog zone that was received without using TSIG. 680 DNS UPDATE [RFC2136] to catalog zones similarly MUST be authenticated 681 using TSIG. 683 Zone transfers of member zones MUST similarly be authenticated using 684 TSIG [RFC2845]. The TSIG shared secrets used for member zones are 685 identical to those used for the catalog zones. Details of the shared 686 secrets MUST NOT be mentioned anywhere in the catalog zone data. 688 Catalog zones do not need to be signed using DNSSEC. Their zone 689 transfers are authenticated by TSIG. Signed zones MUST be handled 690 normally by nameservers, and their contents MUST NOT be DNSSEC- 691 validated. 693 5. IANA considerations 695 This document defines new resource record types, titled BOOL, FLOAT, 696 INT, and UINT (see Section 2.4), assigned values as follows from the 697 Resource Record (RR) TYPEs space [to be removed upon publication: 698 https://www.iana.org/assignments/dns-parameters/dns- 699 parameters.xhtml#dns-parameters-11]. 701 +-------+-------+------------------------------------------+ 702 | TYPE | Value | Meaning | 703 +-------+-------+------------------------------------------+ 704 | BOOL | TBD | Boolean value | 705 | FLOAT | TBD | IEEE 754 double-precision number | 706 | INT | TBD | 64-bit signed integer (two's complement) | 707 | UINT | TBD | 64-bit unsigned integer | 708 +-------+-------+------------------------------------------+ 710 6. Acknowledgements 712 Catalog zones originated as the chosen method among various proposals 713 that were evaluated at ISC for easy zone management. The chosen 714 method of storing the catalog as a regular DNS zone was proposed by 715 Stephen Morris. 717 We later discovered that Paul Vixie's earlier [Metazones] proposal 718 implemented a similar approach and reviewed it. Catalog zones 719 borrows some syntax ideas from Metazones, as both share this scheme 720 of representing the catalog as a regular DNS zone. 722 Thanks to Ray Bellis, Brian Conry, Evan Hunt, Witold Krecicki, 723 Victoria Risk for reviewing draft proposals and providing support, 724 comments and suggestions. 726 Thanks to BIND users who reviewed draft proposals and offered 727 comments and suggestions. 729 7. References 731 7.1. Normative references 733 [FIPS.180-1.1995] 734 National Institute of Standards and Technology, "Secure 735 Hash Standard", FIPS PUB 180-1, April 1995, 736 . 738 [IEEE.754.1985] 739 Institute of Electrical and Electronics Engineers, 740 "Standard for Binary Floating-Point Arithmetic", IEEE 741 Standard 754, August 1985. 743 [ISO.9899.1990] 744 International Organization for Standardization, 745 "Programming languages - C", ISO Standard 9899, 1990. 747 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 748 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 749 . 751 [RFC1035] Mockapetris, P., "Domain names - implementation and 752 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 753 November 1987, . 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 757 RFC2119, March 1997, 758 . 760 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 761 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 762 RFC 2136, DOI 10.17487/RFC2136, April 1997, 763 . 765 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 766 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 767 . 769 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 770 Wellington, "Secret Key Transaction Authentication for DNS 771 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 772 . 774 [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes 775 (APL RR)", RFC 3123, DOI 10.17487/RFC3123, June 2001, 776 . 778 7.2. Informative references 780 [I-D.hunt-note-rr] 781 Hunt, E. and D. Mahoney, "A DNS Resource Record for 782 Confidential Comments (NOTE RR)", draft-hunt-note-rr-01 783 (work in progress), May 2014. 785 [I-D.ietf-dnsop-dns-terminology] 786 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 787 Terminology", draft-ietf-dnsop-dns-terminology-05 (work in 788 progress), September 2015. 790 [Metazones] 791 Vixie, P., "Federated Domain Name Service Using DNS 792 Metazones", 2005, . 794 [RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones (DNS 795 RPZ)", 2010, 796 . 798 Appendix A. Glossary 800 Catalog zone: A DNS zone containing a DNS catalog, that is, a list 801 of DNS zones and associated template zone configuration common 802 to all member zones. 804 Member zone: A DNS zone whose configuration is published inside a 805 catalog zone. 807 Primary nameserver: An authoritative server configured to be the 808 source of zone transfer to one or more [secondary] nameservers. 809 Also see [I-D.ietf-dnsop-dns-terminology]. 811 RDATA hash: The hexadecimal format 40-digit SHA-1 [FIPS.180-1.1995] 812 digest, of the RDATA of the corresponding RR. For RDATA 813 containing DNS names, no name compression must be in use, i.e., 814 the name must be in its full expanded wire data format when it 815 is hashed. 817 Member zone name hash: The hexadecimal format 40-digit SHA-1 818 [FIPS.180-1.1995] digest, of a zone name in uncompressed wire 819 format. 821 Secondary nameserver: An authoritative server which uses zone 822 transfer to retrieve the zone. Also see 823 [I-D.ietf-dnsop-dns-terminology]. 825 Zone property: A configuration parameter of a zone, sometimes also 826 called a zone option. 828 Appendix B. Open issues and discussion (to be removed before final 829 publication) 831 1. Config options 833 We want catalog zones to be adopted by multiple DNS 834 implementations. Towards this, we have to generalize zone config 835 options and adopt a minimal set that we can expect most 836 implementations to support. 838 2. Catalog zone and member zones on different primary nameservers 840 Will it be possible to setup a catalog zone on one nameserver as 841 primary, and allow its member zones to be served by different 842 primary namesservers? 844 3. Transitive relationships 846 For a catalog zone, a secondary nameserver may be a primary 847 nameserver to a different set of nameservers in a nameserver 848 farm. In these transitive relationships, zone configuration 849 options (such as also-notify and allow-transfer) may differ based 850 on the location of the primary in the hierarchy. It may not be 851 possible to specify this within a catalog zone. 853 4. Templates 855 Are support for config and zone data templates useful at this 856 level? They would add complexity across implementations. If 857 added, it would be better to restrict templates at the primary 858 nameserver and let the secondary receive regular expanded zones. 860 5. Overriding controls 862 A way to override zone config options (as prescribed by the 863 catalog zones) on secondary nameservers was requested. As this 864 would be configured outside catalog zones, it may be better to 865 leave this to implementations. 867 6. Use of hashing 869 Should use of hashing be completely removed, and replaced with 870 the same common owner name for all property RRs in a collection? 871 Both IXFR and DNS UPDATE allow changing individual RRs in a 872 RRset. 874 7. Choice of hash function 876 Should a different faster hash function be chosen to replace 877 SHA-1 when computing catalog member zone name hashes? 879 8. Overriding existing RR types 881 This memo currently overrides only the PTR RR TYPE's meaning as 882 PTR is currently used for reverse lookups. But such overridden 883 use seems like a non-issue as PTR is defined to be a pointer to 884 any name in [RFC1035]. 886 9. APL limits 888 APL can only support as many networks as can fit in its RDATA. 889 Though a very large number of networks can be listed in a single 890 RDATA field, it is still limited in size. Will this limitation 891 become a problem for any users? 893 Appendix C. Change History (to be removed before final publication) 895 o draft-muks-dnsop-dns-catalog-zones-00 896 Initial public draft. 898 Authors' Addresses 900 Stephen Morris 901 Internet Systems Consortium 902 950 Charter Street 903 Redwood City, CA 94063 904 US 906 Email: stephen@isc.org 907 URI: http://www.isc.org/ 909 Mukund Sivaraman 910 Internet Systems Consortium 911 950 Charter Street 912 Redwood City, CA 94063 913 US 915 Email: muks@mukund.org 916 URI: http://www.isc.org/