draft-muks-dnsop-dns-catalog-zones.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<?rfc tocappendix="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?rfc comments="no" ?>
<?rfc inline="yes" ?>
<rfc category="exp" docName="draft-muks-dnsop-dns-catalog-zones-04" ipr="trust200902">

  <front>

    <title>DNS Catalog Zones</title>

    <author fullname="Mukund Sivaraman" initials="M." surname="Sivaraman">
      <organization>Internet Systems Consortium</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <code>94063</code>
          <region>CA</region>
          <country>US</country>
        </postal>
        <email>muks@mukund.org</email>
        <uri>http://www.isc.org/</uri>
      </address>
    </author>

    <author fullname="Stephen Morris" initials="S." surname="Morris">
      <organization>Internet Systems Consortium</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <code>94063</code>
          <region>CA</region>
          <country>US</country>
        </postal>
        <email>stephen@isc.org</email>
        <uri>http://www.isc.org/</uri>
      </address>
    </author>

    <author fullname="Ray Bellis" initials="R." surname="Bellis">
      <organization>Internet Systems Consortium</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <code>94063</code>
          <region>CA</region>
          <country>US</country>
        </postal>
        <email>ray@isc.org</email>
        <uri>http://www.isc.org/</uri>
      </address>
    </author>

    <author fullname="Witold Krecicki" initials="W." surname="Krecicki">
      <organization>Internet Systems Consortium</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <code>94063</code>
          <region>CA</region>
          <country>US</country>
        </postal>
        <email>wpk@isc.org</email>
        <uri>http://www.isc.org/</uri>
      </address>
    </author>

    <date/>

    <!-- Meta-data Declarations -->

    <area>Operations and Management Area</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- <keyword>dns</keyword> -->

    <abstract>
      <t>This document describes a method for automatic DNS zone provisioning
      among DNS primary and secondary nameservers by storing and transferring
      the catalog of zones to be provisioned as one or more regular DNS zones.
      </t>
    </abstract>

  </front>

  <middle>

    <section title="Introduction">
      <t>The data in a DNS zone is synchronized amongst its primary and
      secondary nameservers using AXFR and IXFR.  However, the list of zones
      served by the primary (called a catalog in <xref target="RFC1035" />) is
      not automatically synchronized with the secondaries. To add or remove a
      zone, the administrator of a DNS nameserver farm not only has to add or
      remove the zone from the primary, they must also add/remove the zone from
      all secondaries, either manually or via an external application. This can
      be both inconvenient and error-prone; it will also be dependent on the
      nameserver implementation.</t>

      <t>This document describes a method in which the catalog is represented as
      a regular DNS zone (called a "catalog zone" here), and transferred using
      DNS zone transfers.  As zones are added to or removed from the catalog
      zone, the changes are propagated to the secondary nameservers in the normal
      way.  The secondary nameservers then add/remove/modify the zones
      they serve in accordance with the changes to the zone.</t>

      <t>The contents and representation of catalog zones are described in <xref
      target="sec-catzones" />.  Nameserver behavior is described in <xref
      target="sec-impl" />.</t>

    </section>

    <section title="Terminology" anchor="sec-terminology">

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
      are to be interpreted as described in <xref target="RFC2119" />.  </t>

      <t>
        <list style="hanging" hangIndent="6">

          <t hangText="Catalog zone:">A DNS zone containing a DNS catalog, that
          is, a list of DNS zones and associated zone configuration.</t>

          <t hangText="Member zone:">A DNS zone whose configuration is
          published inside a catalog zone.</t>

          <t hangText="Zone property:">A configuration parameter of a
          zone, sometimes also called a zone option, represented as a
          key/value pair.</t>

          <t hangText="$CATZ:">Used in examples as a placeholder to represent
          the domain name of the catalog zone itself (c.f. $ORIGIN).</t>

        </list>
      </t>

    </section>

    <section title="Description" anchor="sec-catzones">
        <t>A catalog zone is a specially crafted DNS zone that contains, as DNS
        zone data:</t>

        <t><list style="symbols">
        <t>A list of DNS zones (called "member zones").</t>
        <t>Default zone configuration information common to all member
        zones.</t>
        <t>Zone-specific configuration information.</t>
        </list></t>

        <t>An implementation of catalog zones MAY allow the catalog to contain
        other catalog zones as member zones, but default zone configuration
        present in a catalog zone only applies to its immediate member
        zones.</t>

        <t>Although the contents of a catalog zone are interpreted and acted
        upon by nameservers, a catalog zone is a regular DNS zone and so must
        adhere to the standards for such zones.</t>

        <t>A catalog zone is primarily intended for the management of a farm of
        authoritative nameservers.  It is not expected that the content of catalog
        zones will be accessible from any recursive nameserver.</t>

      </section>

      <section title="Catalog Zone Structure" anchor="sec-contents">

        <section title="SOA and NS Records">

          <t>As with any other DNS zone, a catalog zone MUST have a syntactically
          correct SOA record and one or more NS records at its apex.</t>

          <t>The SOA record's SERIAL, REFRESH, RETRY and EXPIRE fields <xref
          target="RFC1035" /> are used during zone transfer. A catalog zone's
          SOA SERIAL field MUST increase when an update is made to the catalog
          zone's contents as per serial number arithmetic defined in <xref
          target="RFC1982" />. Otherwise, secondary nameservers might not notice
          updates to the catalog zone's contents.</t>

          <t>Should the zone be made available for querying, the SOA record's
          MINIMUM field's value is the negative cache time (as defined in
          <xref target="RFC2308"/>).  Since recursive nameservers are not
          expected to be able to access (and subsequently cache) entries
          from a catalog zone a value of zero (0) is RECOMMENDED.</t>

          <t>Since there is no requirement to be able to query the catalog zone
          via recursive namservers the NS records at the apex will not be used
          and no parent delegation is required.  However, they are still
          required so that catalog zones are syntactically correct DNS zones.
          Any valid DNS name can be used in the NSDNAME field of such NS records
          <xref target="RFC1035" /> and they MUST be ignored. A single NS RR
          with an NSDNAME field containing the absolute name "invalid." is
          RECOMMENDED <xref target="RFC2606" />.</t>
        </section>

        <section title="Zone Data" anchor="sec-data">

          <t>A catalog zone contains a set of key/value pairs, where each key is
          encapsulated within the owner name of a DNS RR and the corresponding value
          is stored in the RR's RDATA.  The specific owner name depends on whether
          the property relates to the catalog zone itself, a member zone thereof, or
          to default zone properties described in <xref target="sec-structure"/>.
          The owner names are case insensitive.</t>

          <section title="Resource Record Format">
            <t>Each key/value pair has a defined data type, and each data type
            accordingly uses a particular RR TYPE to represent its possible values, as
            specified in <xref target="sec-types" />.</t>

            <t>The general form of a catalog zone record is as follows:</t>

            <figure>
              <artwork>
      [&lt;unique-id&gt;.]&lt;key&gt;.&lt;path&gt;.$CATZ 0 IN &lt;RRTYPE&gt; &lt;value&gt;
              </artwork>
            </figure>

            <t>where &lt;path&gt; is a sequence of labels with values depending on
            the purpose (and hence position) of the record within the catalog zone
            (see <xref target="sec-structure"/>) and where the &lt;unique-id&gt;
            prefix is only present for multi-valued properties (see <xref
            target="sec-multivalue"/>).</t>

            <t>NB: Catalog zones use some RR TYPEs (such as PTR) with alternate
            semantics to those originally defined for them. Although this may be
            controversial, the situation is similar to other similar zone-based
            representations such as response-policy zones <xref target="RPZ" />.</t>

            <t>The CLASS field of every RR in a catalog zone MUST be IN (1).  This is
            because some RR TYPEs such as APL used by catalog zones are defined only
            for the IN class.</t>

            <t>The TTL field's value is not specially defined by this memo.  Catalog
            zones are for authoritative nameserver management only and are not intended
            for general querying via recursive resolvers and therefore a value of zero
            (0) is RECOMMENDED.</t>

            <t>It is an error for any single owner name within a catalog zone (other
            than the apex of the zone itself) to have more than one RR associated with
            it.</t>

          </section>

          <section title="Multi-valued Properties" anchor="sec-multivalue">

            <t>Some properties do not represent single values but instead represent a
            collection of values.  The specification for each property describes
            whether it is single-valued or multi-valued.  A multi-valued property is
            encoded as multiple RRs where the owner name of each individual RR
            contains a unique (user specified) DNS label.</t>

            <t>So, while a single-valued key might be represented like this:</t>

            <figure>
              <artwork>
              &lt;key&gt;.&lt;path&gt;.$CATZ IN TXT "value"
              </artwork>
            </figure>

            <t>a multi-valued key would be represented like this:</t>

            <figure>
              <artwork>
      &lt;unique-id-1&gt;.&lt;key&gt;.&lt;path&gt;.$CATZ IN TXT "value 1"
      &lt;unique-id-2&gt;.&lt;key&gt;.&lt;path&gt;.$CATZ IN TXT "value 2"
      ...
              </artwork>
            </figure>

            <t>NB: a property that is specified to be multi-valued MUST be encoded
            using the unique prefixed key syntax even if there is only one value
            present.</t>

            <t>The specification of any multi-valued property MUST document whether
            the collection represents either an ordered or un-ordered list.  In the
            former case the ordering of the prefixes according to the usual DNS
            canonical name ordering will determine the sort order.</t>

          </section>

          <section title="Vendor-specific Properties" anchor="sec-vsa">

            <t>TBD: Prepare a list of zone configuration properties that are common
            to DNS implementations. This is so that a company may manage a catalog
            zone using a Windows DNS server as the primary, and a secondary
            nameserver hosting service may pick up the common properties and may use
            a different nameserver implementation such as BIND or NSD on a POSIX
            operating system to serve it.</t>

            <t>TBD: We may specify that unrecognized zone property names must be
            ignored, or that nameserver specific properties must be specified using
            the "x-" prefix similar to MIME type naming.</t>

            <t>TBD: Any list of zone properties is ideally maintained as a
            registry rather than within this memo.</t>

          </section>
        </section>


        <section title="Zone Structure" anchor="sec-structure">

          <section title="List of Member Zones" anchor="sec-member-zones">

            <t>The list of member zones is specified as a multi-valued collection of
            domain names under the owner name "zones" where "zones" is a direct child
            domain of the catalog zone.</t>

            <t>The names of member zones are represented on the RDATA side
            (instead of as a part of owner names) so that all valid domain
            names may be represented regardless of their length <xref
            target="RFC1035" />.</t>

            <t>For example, if a catalog zone lists three zones "example.com.",
            "example.net." and "example.org.", the RRs would appear as follows:</t>

            <figure>
              <artwork>
        &lt;m-unique-1&gt;.zones.$CATZ 0 IN PTR example.com.
        &lt;m-unique-2&gt;.zones.$CATZ 0 IN PTR example.net.
        &lt;m-unique-3&gt;.zones.$CATZ 0 IN PTR example.org.
              </artwork>
            </figure>

            <t>where &lt;m-unique-N&gt; is a label that uniquely tags each record in
            the collection, as described in <xref target="sec-multivalue"/>.</t>

            <t>Although any legal label could be used for &lt;m-unique-N&gt;
            it is RECOMMENDED that it be a value deterministically derived
            from the fully-qualified member zone name.  The BIND9 implementation
            uses the 40 character hexadecimal representation of the SHA-1 digest
            <xref target="FIPS.180-4.2015" /> of the lower-cased member zone
            name as encoded in uncompressed wire format.</t>

          </section>

          <section title="Catalog Zone Schema Version" anchor="sec-version">
            <t>The catalog zone schema version is specified by an unsigned
            integer property with the property name "version". All catalog zones
            MUST have this property present. Primary and secondary nameservers
            MUST NOT use catalog zones with an unexpected value in this
            property, but they may be transferred as ordinary zones. For this
            memo, the "version" property value MUST be set to 2, i.e.</t>

            <figure>
              <artwork>
            version.$CATZ 0 IN TXT "2"
              </artwork>
            </figure>

            <t>NB: Version 1 was used in a draft version of this memo and reflected
            the implementation first found in BIND 9.11.</t>

          </section>

          <section title="Default Zone Configuration">

            <t>Default zone configuration comprises a set of properties that are
            applied to all member zones listed in the catalog zone unless overridden
            my member zone-specific information.</t>

            <t>All such properties are stored as child nodes of the owner name
            "defaults" itself a direct child node of the catalog zone, e.g.:</t>

            <figure>
              <artwork>
     example-prop.defaults.$CATZ 0 IN TXT "Example"
              </artwork>
            </figure>

          </section>

          <section title="Zone Properties Specific to a Member Zone">

            <t>Default zone properties can be overridden on a per-zone basis by
            specifying the property under the the sub-domain associated with the
            member zone in the list of zones, e.g.:</t>

            <figure>
              <artwork>
     example-prop.&lt;m-unique&gt;.zones.$CATZ 0 IN TXT "Example"
              </artwork>
            </figure>

            <t>where "m-unique" is the label that uniquely identifies the member zone
            name as described in <xref target="sec-member-zones"/>.</t>

            <t>NB: when a zone-specific property is multi-valued the owner name will
            contain two unique identifiers, the left-most tagging being associated
            with the individual value (&lt;unique-id-N&gt;) and the other
            (&lt;m-unique&gt;) associated with the member zone itself, e.g.: </t>

            <figure>
              <artwork>
     $ORIGIN &lt;m-unique&gt;.zones.$CATZ
     &lt;unique-id-1&gt;.example-prop 0 IN TXT "Value 1"
     &lt;unique-id-2&gt;.example-prop 0 IN TXT "Value 2"
     ...
              </artwork>
            </figure>
          </section>

        </section>
      </section>

      <section title="Data Types" anchor="sec-types">

        <t>This section lists the various data types defined for use within catalog
        zones.</t>

        <section title="String" anchor="sec-string">

          <t>A key with a string value is represented with a TXT RR <xref
          target="RFC1035" />, e.g.:</t>

          <figure>
            <artwork>
     example-prop.&lt;m-unique&gt;.zones.$CATZ 0 IN TXT "Example"
            </artwork>
          </figure>

          <t>If the RDATA is split into multiple &lt;character-string&gt; elements
          the MUST be directly concatenated without any separating character.</t>

        </section>

        <section title="Booleans" anchor="sec-bool">

          <t>A key with a boolean value is represented with a TXT RR containing a
          single &lt;character-string&gt; with a value of "true" for true condition
          and "false" for false condition, e.g:</t>

          <figure>
            <artwork>
     example-prop.&lt;m-unique&gt;.zones.$CATZ 0 IN TXT "false"
            </artwork>
          </figure>

		  <t>The RDATA is case-insensitive.</t>

        </section>

        <section title="Integers" anchor="sec-int">

          <t>A key with an integer value is specified using a TXT RR containing a
          single &lt;character-string&gt;.</t>

          <t>A signed integer's TXT RDATA uses the representation of an
          unsuffixed "integer constant" as defined in the C programming
          language standard <xref target="ISO.9899.1990" /> (of the type
          matching a 64-bit signed integer on that platform), with an
          optional minus prefix.</t>

          <t>An unsigned integer's TXT RDATA uses the representation of
          an unsuffixed "integer constant" as defined in the C
          programming language standard <xref target="ISO.9899.1990" />
          (of the type matching a 64-bit unsigned integer on that
          platform).</t>

          <t>For example, a property with an unsigned integer value of 300 would
          appear as follows:</t>

          <figure>
            <artwork>
     example-prop.&lt;m-unique&gt;.zones.$CATZ 0 IN TXT "300"
            </artwork>
          </figure>

        </section>

        <section title="Floating-Point Values" anchor="sec-float">

          <t>A key with a floating-point value is specified using a TXT RR containing
          a single &lt;character-string&gt;.</t>

          <t>A floating-point value's TXT RDATA uses the representation of an
          unsuffixed "floating constant" as defined in the C programming language
          standard <xref target="ISO.9899.1990" />.</t>

          <t>For example, a property with an unsigned integer value of 0.15 may
          appear as follows:</t>

          <figure>
            <artwork>
     example-prop.&lt;m-unique&gt;.zones.$CATZ 0 IN TXT "15e-2"
            </artwork>
          </figure>
        </section>

        <section title="Domain Name" anchor="sec-sname">

          <t>A key whose value is a domain name is specified using a PTR RR <xref
          target="RFC1035" />, e.g.:</t>

          <figure>
            <artwork>
     example-prop.defaults.$CATZ 0 IN PTR ns1.example.com.
            </artwork>
          </figure>
        </section>

        <section title="IP Prefix" anchor="sec-network">

          <t>A property whose value is an IP network prefix is specified using an APL
          RR <xref target="RFC3123"/>.  The negation flag ("!" in presentation format)
          may be used to indicate all addresses not included within that prefix, e.g.
          for use in Access Control Lists, e.g.:</t>

          <t>Although a single APL record is capable of containing multiple prefixes,
          for consistency of representation lists of prefixes MUST use the
          multi-valued property syntax as documented in <xref
          target="sec-multivalue"/>, e.g.:</t>

          <figure>
            <artwork>
     $ORIGIN &lt;m-unique&gt;.zones.$CATZ
     &lt;unique-id-1&gt;.example-prop 0 IN APL ( 1:192.0.2.0/24 )
     &lt;unique-id-2&gt;.example-prop 0 IN APL ( !1:0.0.0.0/0 )
            </artwork>
          </figure>

          <t>Implementations MUST accept only the first prefix within each APL record
          and MUST ignore any subsequent prefixes found therein.</t>

        </section>

        <section title="Single Host Address">

          <t>A single host address is represented using either an A or AAAA record as
          appropriate, e.g.:</t>

          <figure>
            <artwork>
     example-prop1.&lt;m-unique&gt;.zones.$CATZ 0 IN A 192.0.2.1
     example-prop2.&lt;m-unique&gt;.zones.$CATZ 0 IN AAAA 2001:db8::1
            </artwork>
          </figure>
        </section>

<!--
        <section title="Comments">
          <t>Comments may be added anywhere in a catalog zone using a
          scheme such as NOTE RRs <xref target="I-D.hunt-note-rr"
          />. This memo does not depend on NOTE RRs and it is only
          suggested here as an informative reference.</t>
        </section>
-->

      </section>



      <section title="Nameserver Behavior" anchor="sec-impl">
        <section title="General Requirements">
          <t>As it is a regular DNS zone, a catalog zone can be transferred
          using DNS zone transfers among nameservers.</t>

          <t>Although they are regular DNS zones, catalog zones contain only
          information for the management of a set of authoritative nameservers.
          For this reason, operators may want to limit the systems able to query
          these zones. It may be inconvenient to serve some contents of catalog
          zones via DNS queries anyway due to the nature of their representation.
          A separate method of querying entries inside the catalog zone may be
          made available by nameserver implementations (see <xref
          target="sec-notes" />).</t>

          <t>Catalog updates should be automatic, i.e., when a nameserver that
          supports catalog zones completes a zone transfer for a catalog zone,
          it SHOULD apply changes to the catalog within the running nameserver
          automatically without any manual intervention.</t>

          <t>As with regular zones, primary and secondary nameservers for a
          catalog zone may be operated by different administrators. The
          secondary nameservers may be configured to synchronize catalog zones
          from the primary, but the primary's administrators may not have any
          administrative access to the secondaries.</t>

          <t>A catalog zone can be updated via DNS UPDATE on a reference primary
          nameserver, or via zone transfers. Nameservers MAY allow loading and
          transfer of broken zones with incorrect catalog zone syntax (as they
          are treated as regular zones), but nameservers MUST NOT process such
          broken zones as catalog zones. For the purpose of catalog processing,
          the broken catalogs MUST be ignored. If a broken catalog zone was
          transferred, the newly transferred catalog zone MUST be ignored (but
          the older copy of the catalog zone SHOULD be left running subject to
          values in SOA fields).</t>

          <t>If there is a clash between an existing member zone's name and an
          incoming member zone's name (via transfer or update), the new instance
          of the zone MUST be ignored and an error SHOULD be logged.</t>

          <t>When zones are introduced into a catalog zone, a primary SHOULD
          first make the new zones available for transfers before making the
          updated catalog zone available for transfer, or sending NOTIFY for the
          catalog zone to secondaries. Note that secondary nameservers may
          attempt to transfer the catalog zone upon refresh timeout, so care
          must be taken to make the member zones available before any update to
          the list of member zones is visible in the catalog zone.</t>

          <t>When zones are deleted from a catalog zone, a primary MAY delete
          the member zone immediately after notifying secondaries. It is up to
          the secondary nameserver to handle this condition correctly.</t>

          <t>TBD: Transitive primary-secondary relationships</t>
        </section>

        <section title="Updating Catalog Zones">
          <t>TBD: Explain updating catalog zones using DNS UPDATE.</t>
        </section>

        <section title="Implementation Notes" anchor="sec-notes">
          <t>Catalog zones on secondary nameservers would have to be setup
          manually, perhaps as static configuration, similar to how ordinary DNS
          zones are configured. Members of such catalog zones will be
          automatically synchronized by the secondary after the catalog zone is
          configured.</t>

          <t>An administrator may want to look at data inside a catalog zone.
          Typical queries might include dumping the list of member zones, dumping a
          member zone's effective configuration, querying a specific property value
          of a member zone, etc.  Because of the structure of catalog zones, it may
          not be possible to perform these queries intuitively, or in some cases, at
          all, using DNS QUERY.  For example it is not possible to enumerate the
          contents of a multi-valued property (such as the list of member zones) with
          a single QUERY.  Implementations are therefore advised to provide a tool
          that uses either the output of AXFR or an out-of-band method to perform
          queries on catalog zones.</t>

        </section>
      </section>

      <section title="Security Considerations">
        <t>As catalog zones are transmitted using DNS zone transfers, it is
        absolutely essential for these transfers to be protected from unexpected
        modifications on the route. So, catalog zone transfers SHOULD be
        authenticated using TSIG <xref target="RFC2845" />. A primary nameserver
        SHOULD NOT serve a catalog zone for transfer without using TSIG and a
        secondary nameserver SHOULD abandon an update to a catalog zone that was
        received without using TSIG.</t>

        <t>Use of DNS UPDATE <xref target="RFC2136" /> to modify the content of
        catalog zones SHOULD similarly be authenticated using TSIG.</t>

        <t>Zone transfers of member zones SHOULD similarly be authenticated
        using TSIG <xref target="RFC2845" />. The TSIG shared secrets used for
        member zones MUST NOT be mentioned anywhere in the catalog zone data.
        However, key identifiers may be shared within catalog zones.</t>

        <t>Catalog zones do not need to be signed using DNSSEC, their zone
        transfers being authenticated by TSIG. Signed zones MUST be handled
        normally by nameservers, and their contents MUST NOT be
        DNSSEC-validated.</t>
      </section>

      <section title="IANA Considerations">
        <t>This document has no IANA actions.</t>
      </section>

      <section title="Acknowledgements">
        <t>Catalog zones originated as the chosen method among various proposals
        that were evaluated at ISC for easy zone management. The chosen method
        of storing the catalog as a regular DNS zone was proposed by Stephen
        Morris.</t>

        <t>We later discovered that Paul Vixie's earlier <xref
        target="Metazones" /> proposal implemented a similar approach and
        reviewed it. Catalog zones borrows some syntax ideas from Metazones, as
        both share this scheme of representing the catalog as a regular DNS
        zone.</t>

        <t>Thanks to Brian Conry, Tony Finch, Evan Hunt, Patrik Lundin, Victoria Risk
        and Carsten Strettman for reviewing draft proposals and offering comments and
        suggestions.</t>

      </section>

  </middle>

  <back>

    <references title="Normative references">
      <?rfc include="reference.RFC.1035.xml"?>
      <?rfc include="reference.RFC.1982.xml"?>
      <?rfc include="reference.RFC.2119.xml"?>
      <?rfc include="reference.RFC.2136.xml"?>
      <?rfc include="reference.RFC.2308.xml"?>
      <?rfc include="reference.RFC.2606.xml"?>
      <?rfc include="reference.RFC.2845.xml"?>
      <?rfc include="reference.RFC.3123.xml"?>
      <?rfc include="reference.ISO.9899.1990.xml"?>

      <reference anchor="FIPS.180-4.2015" target="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">
        <front>
          <title>Secure Hash Standard</title>
          <author>
            <organization>National Institute of Standards and Technology</organization>
          </author>
          <date month="August" year="2015" />
        </front>
        <seriesInfo name="FIPS" value="PUB 180-4" />
      </reference>

    </references>

    <references title="Informative references">
<!--      <?rfc include="reference.I-D.hunt-note-rr.xml"?> -->
      <reference anchor="RPZ" target="http://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt">
        <front>
          <title>DNS Response Policy Zones (DNS RPZ)</title>
          <author fullname="Paul Vixie" initials="P." surname="Vixie" />
          <author fullname="Vernon Schryver" initials="V." surname="Schryver" />
          <date year="2010" />
        </front>
      </reference>
      <reference anchor="Metazones" target="http://ss.vix.su/~vixie/mz.pdf">
        <front>
          <title>Federated Domain Name Service Using DNS Metazones</title>
          <author fullname="Paul Vixie" initials="P." surname="Vixie" />
          <date year="2005" />
        </front>
      </reference>
    </references>

    <section title="Open issues and discussion (to be removed before final publication)">
      <t><list style="numbers">
        <t>Config options
        <vspace blankLines="1"/>
        We want catalog zones to be adopted by multiple DNS
        implementations. Towards this, we have to generalize zone
        config options and adopt a minimal set that we can expect
        most implementations to support.
        </t>
        <t>Catalog zone and member zones on different primary
        nameservers
        <vspace blankLines="1"/>
        Will it be possible to setup a catalog zone on one nameserver as
        primary, and allow its member zones to be served by different
        primary nameservers?
        </t>
        <t>Transitive relationships
        <vspace blankLines="1"/>
        For a catalog zone, a secondary nameserver may be a primary
        nameserver to a different set of nameservers in a nameserver
        farm. In these transitive relationships, zone configuration
        options (such as also-notify and allow-transfer) may differ
        based on the location of the primary in the hierarchy. It may
        not be possible to specify this within a catalog zone.
        </t>
        <!-- <t>Templates
        <vspace blankLines="1"/>
        Are support for config and zone data templates useful at this
        level? They would add complexity across implementations. If
        added, it would be better to restrict templates at the primary
        nameserver and let the secondary receive regular expanded zones.
        </t> -->
        <t>Overriding controls
        <vspace blankLines="1"/>
        A way to override zone config options (as prescribed by the
        catalog zones) on secondary nameservers was requested. As this
        would be configured outside catalog zones, it may be better to
        leave this to implementations.
        </t>
        <!-- <t>Use of hashing
        <vspace blankLines="1"/>
        Should use of hashing be completely removed, and replaced with
        the same common owner name for all property RRs in a collection?
        Both IXFR and DNS UPDATE allow changing individual RRs in a
        RRset.
        </t> -->
        <!-- <t>Choice of hash function
        <vspace blankLines="1"/>
        Should a different faster hash function be chosen to replace
        SHA-1 when computing catalog member zone name hashes?
        </t> -->
        <!-- <t>Overriding existing RR types
        <vspace blankLines="1"/>
        This memo currently overrides only the PTR RR TYPE's meaning as
        PTR is currently used for reverse lookups. But such overridden
        use seems like a non-issue as PTR is defined to be a pointer to
        any name in <xref target="RFC1035" />.
        </t> -->
        <!-- <t>APL limits
        <vspace blankLines="1"/>
        APL can only support as many networks as can fit in its
        RDATA. Though a very large number of networks can be listed in a
        single RDATA field, it is still limited in size. Will this
        limitation become a problem for any users?
        </t> -->
      </list></t>
    </section>



<!--
            <t>As another example, if a catalog zone is named
            "cat1.example.org." and a member zone "example.com."  contains a
            property "prop2" with its value being an unordered list (see
            <xref target="sec-unolist" />) of two domain names
            "a.example.com."  and "b.example.com.", the corresponding RRs
            would appear as follows:</t>
            <figure>
              <artwork>
(&lt;hash&gt;.prop2.&lt;m-unique&gt;.zones.$CATZ
   0 IN PTR a.example.com.)
(&lt;hash&gt;.prop2.&lt;m-unique&gt;.zones.$CATZ
   0 IN PTR b.example.com.)
              </artwork>
            </figure>

          <section title="Example of a catalog zone">
            <figure>
              <artwork>
$ORIGIN catalog.example.org.
@           IN SOA  . . 1 3600 3600 86400 0
            IN NS   invalid.
version     IN TXT  "1"
(5960775ba382e7a4e09263fc06e7c00569b6a05c.zones
    IN PTR domain1.example.com.)
              </artwork>
            </figure>
          </section>
-->

    <section title="Change History (to be removed before final publication)">
      <t>
        <list style="symbols">

          <t>
            draft-muks-dnsop-dns-catalog-zones-00
            <vspace/>
            Initial public draft.
          </t>

          <t>
            draft-muks-dnsop-dns-catalog-zones-01
            <vspace/>
            Added Witold, Ray as authors. Fixed typos, consistency
            issues. Fixed references. Updated Area. Removed newly
            introduced custom RR TYPEs. Changed schema version to
            1. Changed TSIG requirement from MUST to SHOULD. Removed
            restrictive language about use of DNS QUERY. When zones are
            introduced into a catalog zone, a primary SHOULD first make
            the new zones available for transfers first (instead of
            MUST). Updated examples, esp. use IPv6 in examples per Fred
            Baker. Add catalog zone example.
          </t>

          <t>
            draft-muks-dnsop-dns-catalog-zones-02
            <vspace/>
            Addressed some review comments by Patrik Lundin.
          </t>

          <t>
            draft-muks-dnsop-dns-catalog-zones-03
            <vspace/>
            Revision bump.
          </t>

          <t>
            draft-muks-dnsop-dns-catalog-zones-04<vspace/>
            Reordering of sections into more logical order.<vspace/>
            Separation of multi-valued properties into their own category.
          </t>

        </list>
      </t>
    </section>

  </back>
</rfc>