DNSEXT Working Group P. Vixie, ISC INTERNET-DRAFT <draft-vixie-dnsext-dnsshadow-00.txt> Creation Date: 2010-02-26 Intended Status: Full Standard Use of DNS to Carry Configuration Metadata Concerning Automatic Replication of Zones Abstract Whenever it is desireable to exactly replicated the content of a DNS zone into one or more other DNS zones so that the content is reachable by multiple names at different zone apexes, it is likewise desireable that this behaviour be automated so that cooperating primary and secondary nameservers can generate and serve the entire set of shadows without human intervention and in an open multivendor manner. This document describes a new CLONE resource record for a zone apex which can guide such cooperation. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 31, 2010. Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Expires 2010-08-26 [Page 1]
INTERNET-DRAFT 2010-02-26 DNS-SHADOW This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction 1.1. Replication of DNS content so that it is reachable by multiple names at different zone apexes requires multiple delegation NS RRsets which might be in multiple parent zones (consider VIX.COM vs. VIXIE.SF.CA.US). Parent zone administrators (including registrars and registries) and zone administrators (including registrants) can use existing tools to maintain these delegations, and the resulting NS RRsets will flow through the existing authority servers using existing mechanisms such as DNS NOTIFY and DNS IXFR for propagation. 1.2. Zones replicated in this way must propagate through a multivendor network of primary and secondary name servers, even when the replication target list changes over time (for example, more brands under trademark), in an automated fashion. New coordinated human effort across a network of authority servers every time a zone is replicated to a new target namespace should be avoided. 1.3. The term "Amber zone" will be used to describe the original zone whose content is being replicated to new namespaces under different apexes. The term "Shadow zone" will be used to describe the replicated zone content as it appear in new namespaces under different apexes. 2. Data Model 2.1. DNS RDATA for RR types not explicitly named in [RFC1035] may be opaque to all secondary and recursive servers, and to stub resolvers. Only the primary master and the far-end application are required to understand an RDATA. Since some of these RDATA may contain domain names relative to the zone apex, the replication of Amber zone data toward Shadow zones must be performed on the primary master server. Such replication must occur every time a new Shadow target becomes known, and the Shadow zones must be updated or regenerated every time the corresponding Amber zone is changed. Expires 2010-08-26 [Page 2]
INTERNET-DRAFT 2010-02-26 DNS-SHADOW 2.2. Shadow zone generation and replication might lag slightly behind the corresponding Amber zone, but nominally the SOA SERIAL should be identical across an Amber zone and its Shadows, and the only differences in zone content will be where relative names were used in the Amber zone's content and were therefore qualified differently in the Shadow zones. When generating a Shadow zone, the primary master will not copy the apex SHADOW RRset, in order to prevent Shadow zones from being incorrectly treated as Amber zones. 2.2.1. For example, if an Amber zone at VIX.COM has a master file which describe an apex MX RR with an unqualified MX EXCHANGE domain name such as MAIL1, then the MX target in the Amber zone will be MAIL1.VIX.COM. A Shadow of this zone whose apex is VIXIE.SF.CA.US will show this MX EXCHANGE as MAIL1.VIXIE.SF.CA.US. This may require configuration changes to supporting applications such as SMTP servers. This behaviour can be prevented by using fully qualified names wherever the name of the Amber zone, and not the name of its various Shadow zones, is to be published in the RDATA. Such prevention is likely to be important for NS NSDNAMEs whose names are within the zone itself, and where the creation of per-Shadow nameserver names is an explicit non-goal of the zone administrator. 2.3. Shadow zone content is propagaged through the authority server network using existing DNS protocols such as DNS NOTIFY and DNS IXFR, and is retrieved and consumed using existing DNS verbs such as QUERY. There are no CNAMEs. any other indication that the Shadow names are not real first class names. As a result, names within Shadow zones can be used as MX EXCHANGE names or NS NSDNAME names or anywhere else within DNS that a domain name is the target of an RDATA whose target must be a canonical name rather than an alias name. 3. Details 3.1. In the Amber zone, a SHADOW RRset will enumerate the other zone apexes at which it's desired that the zone's content be replicated. For example: $ORIGIN vix.com. ... @ IN SHADOW vixie.com. @ IN SHADOW vixie.sf.ca.us. ... This RRset will be propagated normally through the authority server network, and will thus be part of the authoritative local data for Expires 2010-08-26 [Page 3]
INTERNET-DRAFT 2010-02-26 DNS-SHADOW this zone as held by the primary master server and all secondary servers. This RRset will not appear in any Shadow of this Amber zone. 3.2. The primary master server will keep track of what zones contain apex SHADOW RRsets and will treat such zones as Amber zones. Upon startup or upon any change to a SHADOW RRset, the primary master server will maintain a Shadow zone for each apex SHADOW RR in each Amber zone. Configuration of a Shadow zone will be a copy, along with any access-control or other local information, of the corresponding Amber zone's configuration. Content of a Shadow zone will be generated by parsing the Amber zone's master file using a different default $ORIGIN. DNS NOTIFY messages will be sent for each Shadow zone as and when such content generation process completes. Changes to the Amber zone's master file will cause regeneration of each associated Shadow zone. Changes to a master file that involve adding or deleting apex SHADOW RRs will cause corresponding changes to the list of Shadows of that zones. 3.3. A secondary nameserver will, upon startup and upon receiving a new version of a zone, keep track of what zones contain apex SHADOW RRsets, and will treat such as Amber zones. For each Shadow zone, the zone configuration including any access-control or other local information will be copied from the associated Amber zone. This means a Shadow zone's master server list will automatically be the same as the associated Amber zone's master server list. Changes to an Amber zone that involve adding or deleting apex SHADOW RRs will cause corresponding changes to the list of Shadows of that zones. There is no other special processing required by secondary server -- once a Shadow zone has been transferred in the normal way it will be served in the normal way, including downstream DNS NOTIFY messages if the DNS IXFR/AXFR dependency graph is deep and if this would be done for the associated Amber zone. 3.4. UPDATE messages received by the primary master server whose ZONE section or whose implied zone apex is a Shadow zone, shall be rejected with error code 9 (NOTAUTH). This is to avoid the need to modify the UPDATE message to change fully qualified names under the Shadow zone's apex to be under the Amber zone's apex instead, which would be ambiguous since some such names might be intentionally within the Shadow zone, and the update may contain new DNSSEC signatures for new or changed RRsets. An update to an Amber zone will cause regeneration of each associated Shadow zone. Expires 2010-08-26 [Page 4]
INTERNET-DRAFT 2010-02-26 DNS-SHADOW 3.5. If an Amber zone is signed with DNSSEC, then the signature generation process must be available within the context of the primary master server. Thus, whenever it's necessary to generate or regenerate a Shadow zone, a normal DNSSEC signing procedure will also be done on the resulting Shadow. This requires that the Shadow zones be signed online, with no offline keys or other offline processing. 3.6. Parent zones must be maintained using existing tools, and do not benefit from the new metadata described here. NS RRsets and DS RRsets must be inserted and edited through the normal communication channels used by each parent zone (which could involve action by registries, registrars, and/or registrants, if a TLD or similar shared parent zone is involved). 3.7. No changes are required for recursive nameservers, stub resolvers, or applications. 4. Open Issues 4.1. Using a different default origin and then not touching fully- qualified names is weak. It plays especially poorly with fully dynamic zone content or database back ends. We either need to tail- replace the Amber apex with each Shadow apex, or we need to add new signalling somehow. 4.2. Not allowing updates on shadows is weak. We should probably just outlaw the use of Shadow names within zone content, and do the substitution of Shadow apex by Amber apex. Note that this gets messy if the update came with its own DNSSEC metadata for the new or modified RRsets. 4.3. Doing full Shadow regeneration after each UPDATE is weak. We need to figure out some way to, um, shadow the updates. This gets messy if DNSSEC is involved and if the signer is external to the primary master server (like if there are offline keys). 4.4. The Security Considerations section is empty, which seems wrong. 5. Security Considerations 5.1. Discussion needed. Expires 2010-08-26 [Page 5]
INTERNET-DRAFT 2010-02-26 DNS-SHADOW IANA Considerations IANA would have to allocated an RR type code for SHADOW if this goes forward. Normative References [RFC1035] P. Mockapetris, "Domain Names - Implementation and Specification," RFC 1035, USC/Information Sciences Institute, November 1987. Authors' Addresses Paul Vixie (text) Internet Systems Consortium Redwood City, CA, USA EMail: vixie@isc.org Expires 2010-08-26 [Page 6]