--- /dev/null
+
+
+
+Domain Name System Operations W. Mekking
+Internet-Draft NLnet Labs
+Intended status: Standards Track June 29, 2010
+Expires: December 31, 2010
+
+
+ Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE
+ draft-mekking-dnsop-auto-cpsync-00
+
+Abstract
+
+ This document proposes a way to synchronise existing trust anchors
+ automatically between a child zone and its parent. The algorithm can
+ be used for other Resource Records that are required to delegate from
+ a parent to a child such as NS and glue records.
+
+Requirements Language
+
+ 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 RFC 2119 [RFC2119].
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ 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."
+
+ This Internet-Draft will expire on December 31, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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
+
+
+
+Mekking Expires December 31, 2010 [Page 1]
+\f
+Internet-Draft Child Parent Synchronization June 2010
+
+
+ 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
+
+ This memo defines a way to synchronise existing trust anchors
+ automatically between a child zone and its parent. The algorithm can
+ be used for other Resource Records that are required to delegate from
+ a parent to a child such as NS and glue records.
+
+ To create a DNSSEC RFC 4035 [RFC4035] chain of trust, child zones
+ must submit their DNSKEYs, or hashes of their DNSKEYs, to their
+ parent zone. The parent zone publishes the hashes of the DNSKEYs in
+ the form of a DS record. The DNSKEY RRset at the child may change
+ over time. In order to keep the chain of trust intact, the DS
+ records at the parent zone also needs to be updated. The rolling of
+ the keys with the SEP bit on is one of the few tasks in DNSSEC that
+ yet has to be fully automated.
+
+ The DNS UPDATE mechanism RFC 2136 [RFC2136] can be used to push zone
+ changes to the parent.
+
+ To bootstrap the direct communication channel, information must be
+ exchanged in order to detect service location and granting update
+ privileges. A new or existing child zone can request a direct
+ communication channel with the parent. If the parent allows for
+ direct communication with child zones, the parent can share the
+ required data to set up the channel to the child zone. Once the
+ child has the required credentials, it can use the direct
+ communication channel with the parent to request zone changes related
+ to its delegation.
+
+ If a third party is involved, the third party can act on behalf of
+ the parent. In this case, the third party will give out the required
+ credentials to set up the communication channel.
+
+ It is RECOMMENDED that the direct communication channel is secured
+ with TSIG [RFC2845] or SIG0 [RFC2931].
+
+2. Access and Update Control
+
+ The DNS UPDATE normally is used for granting update permissions to a
+ machine that is within the boundary of the same organization. This
+ document proposes to grant child zones the same permissions.
+ However, it MUST NOT be possible that a child zone updates
+
+
+
+Mekking Expires December 31, 2010 [Page 2]
+\f
+Internet-Draft Child Parent Synchronization June 2010
+
+
+ information in the parent zone that falls outside the administrative
+ domain of the corresponding delegation. For example, it MUST NOT be
+ possible for a child zone to update the data that the parent is
+ authoritative for, or update a delegation that is pointed to a
+ different child zone. It MUST only be able to update records that
+ match one of the following:
+
+ Or: The owner name is equal the child zone name and RRtype is
+ delegation specific. Currently those are records with RRtype NS
+ or DS.
+
+ Or: The owner name is a subdomain of the child zone name and RRtype
+ is glue specific. Currently those are records with RRtype A or
+ AAAA.
+
+ This list may be expanded in the future, if there is need for more
+ delegation related zone content.
+
+ In case of adding or deleting delegation specific records, the DNSSEC
+ related RRs in the parent zone might need to be updated.
+
+ The service location may be handed out by the registrar during
+ bootstrap If this information is missing, the normal guidelines for
+ sending DNS UPDATE messages SHOULD be followed.
+
+3. Update Mechanism
+
+3.1. Child Duties
+
+ Updating the NS RRset or corresponding glue at the parent, an update
+ can be sent at any time. Updating the DS RRset is part of key
+ rollover, as described in RFC 4641 [RFC4641]. When performing a key
+ rollover that involves updating the RRset at the parent, the child
+ introduces a new DNSKEY in its zone that represents the security
+ entry point for determining the chain of trust. After a while, it
+ will revoke and/or remove the previous security entry point. The
+ timings when to update the DS RRset at the parent are described in
+ draft-dnsop-morris-dnssec-key-timing [keytiming]. When updating the
+ DS RRset at the parent automatically, these timing specifications
+ SHOULD be followed. To determine the propagation delays described in
+ this document, the child should poll the parent zone for a short
+ time, until the DS is visible at all parent name servers.
+
+ To discuss: A child zone might be unable to reach all parent name
+ servers.
+
+ The child notifies the parent of the requested changes by sending a
+ DNS UPDATE message. If it receives a NOERROR reply in return, the
+
+
+
+Mekking Expires December 31, 2010 [Page 3]
+\f
+Internet-Draft Child Parent Synchronization June 2010
+
+
+ update is acknowledged by the parent zone. Otherwise, the child MAY
+ retry transmitting the update. In order to prevent duplicate
+ updates, it SHOULD follow the guidelines described in RFC 2136
+ [RFC2136].
+
+3.2. Parent Duties
+
+ When the master DNS server of the parent receives a DNS UPDATE from
+ one of its children the following must be done:
+
+ Step 1: Check the TSIG/SIG0 credentials. In case of TSIG, the
+ parent should follow the TSIG processing described in section 3.2
+ of RFC 2845. In case of SIG0, the parent should follow the SIG0
+ processing described in section 3.2 of RFC 2931.
+
+ Step 2: Verify that the updates matches the update policy for child
+ zones.
+
+ Step 3: If verified, send back DNS UPDATE OK. Otherwise, send back
+ DNS UPDATE REFUSED.
+
+ Step 4: If verified, apply changes. How that is done is a matter of
+ policy.
+
+3.3. Proxy considerations
+
+ Some environments don't allow for direct communication between parent
+ and child zone. In these case, the parent duties can be performed by
+ a different party (for example, the registar). The third party will
+ forward the update to the parent zone. In what format depends on
+ local policy.
+
+4. Example BIND9 Configuration
+
+ This is how a parent zone can configure a policy to enable a child
+ zone synchronize delegation specific records. The first rule of the
+ update policy grants children to update their DS and NS records in
+ the parent zone, in this case example.com. The second rule of the
+ update policy grants children to update the corresponding glue
+ records.
+
+ key cs.example.com. {
+ algorithm HMAC-MD5;
+ secret "secretforcs";
+ }
+
+ key math.example.com. {
+ algorithm HMAC-MD5;
+
+
+
+Mekking Expires December 31, 2010 [Page 4]
+\f
+Internet-Draft Child Parent Synchronization June 2010
+
+
+ secret "secretformath";
+ }
+
+ ...
+
+ zone "example.com" {
+ type master;
+ file "example.com";
+ update-policy { grant *.example.com. self *.example.com. DS NS; };
+ update-policy { grant *.example.com. selfsub *.example.com. A AAAA;
+ };
+ };
+
+5. Security Considerations
+
+ Automating the synchronization of (DNSSEC) records between the parent
+ and child created a new channel. We have recommended that this
+ channel should be secured with TSIG or SIG0. There is an advantage
+ and a disadvantage of the new security channel. The disadvantage is
+ that you create a new attack window for your DNSSEC credentials. If
+ the automated synchronization is used for updating DS records at the
+ parent, you SHOULD pick a cryptographically an equally strong or
+ stronger TSIG/SIG0 key than the strength of your DNSSEC keys.
+
+ The advantage is that if somehow your DNSSEC keys are compromised,
+ you can still use this channel to perform an emergency key rollover.
+
+6. IANA Considerations
+
+ None.
+
+7. Acknowledgments
+
+ Rickard Bellgrim, Wolfgang Nagele, Wouter Wijngaards and more.
+
+8. References
+
+8.1. Informative References
+
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS
+ UPDATE)", RFC 2136, April 1997.
+
+ [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational
+ Practices", RFC 4641, September 2006.
+
+ [keytiming] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
+ Timing Considerations", March 2010.
+
+
+
+Mekking Expires December 31, 2010 [Page 5]
+\f
+Internet-Draft Child Parent Synchronization June 2010
+
+
+8.2. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+ Wellington, "Secret Key Transaction Authentication for
+ DNS (TSIG)", RFC 2845, May 2000.
+
+ [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
+ SIG(0)s)", RFC 2931, September 2000.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+Author's Address
+
+ Matthijs Mekking
+ NLnet Labs
+ Science Park 140
+ Amsterdam 1098 XG
+ The Netherlands
+
+ EMail: matthijs@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mekking Expires December 31, 2010 [Page 6]
+\f
projects / thirdparty / bind9.git / commitdiff
