< draft-andrews-dnsop-update-parent-zones-03.txt		draft-andrews-dnsop-update-parent-zones-04.txt >
	Network Working Group M. Andrews		Network Working Group M. Andrews
	Internet-Draft ISC		Internet-Draft ISC
	Expires: May 9, 2014 November 5, 2013		Expires: May 11, 2014 November 7, 2013
	Updating Parent Zones		Updating Parent Zones
	draft-andrews-dnsop-update-parent-zones-03		draft-andrews-dnsop-update-parent-zones-04
	Abstract		Abstract
	DNS UPDATE was developed to allow DNS zones to be updated.		DNS UPDATE was developed to allow DNS zones to be updated.
	There is a perception that UPDATE cannot be used in conjuction with		There is a perception that UPDATE cannot be used in conjuction with
	the Registry, Registar, Registrant (RRR) model to update a zone.		the Registry, Registar, Registrant (RRR) model to update a zone.
	This document explains how UPDATE can be used in the RRR model.		This document explains how UPDATE can be used in the RRR model.
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 9, 2014.		This Internet-Draft will expire on May 11, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Translation . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Translation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Direct to Registrar . . . . . . . . . . . . . . . . . . . . . . 4		4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Indirect to Registrar . . . . . . . . . . . . . . . . . . . . . 4		5. Direct to Registrar . . . . . . . . . . . . . . . . . . . . . . 4
	6. UPDATE Server Discovery . . . . . . . . . . . . . . . . . . . . 4		6. Indirect to Registrar . . . . . . . . . . . . . . . . . . . . . 4
	7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		7. UPDATE Server Discovery . . . . . . . . . . . . . . . . . . . . 5
	8. Normative References . . . . . . . . . . . . . . . . . . . . . 6		8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
			9. Normative References . . . . . . . . . . . . . . . . . . . . . 6
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	UPDATE [RFC2136] is designed to update any zone in the DNS. This		UPDATE [RFC2136] is designed to update any zone in the DNS. This
	includes updating delegating NS records, glue address records and DS		includes updating delegating NS records, glue address records and DS
	records.		records.
	While UPDATE is primarily designed to UPDATE a zone directly there in		While UPDATE is primarily designed to UPDATE a zone directly there in
	no reason why UPDATE requests cannot be translated to the EPP		no reason why UPDATE requests cannot be translated to the EPP
	requests to perform the changes.		requests to perform the changes.
	This would provide a uniform model to update parent zone regardless		This would provide a uniform model to update parent zone regardless
	of where they are in the DNS hierarchy or whether the zone is signed		of where they are in the DNS hierarchy or whether the zone is signed
	or not.		or not.
	2. Translation		2. Requirements
			This document was written with the following requirements in mind:
			o must be able to authenticate the transaction.
			o must be able to update address records to support automated
			renumbering.
			o must be able to update DS records to support DNSKEY rollover buy
			key management tools.
			o must work for unsigned zones (parent and/or child).
			o must work for signed zones (parent and/or child).
			o must work for RRR managed zones.
			o must work for non RRR managed zones.
			o desirable support updating of NS RRsets so that nameservers can
			ensure delegations delgation data remains consistent.
			3. Translation
	The Registrar would host a server that authenticates UPDATE requests		The Registrar would host a server that authenticates UPDATE requests
	received directly or relayed by the Registry using TSIG [RFC2845],		received directly or relayed by the Registry using TSIG [RFC2845],
	then translate the actions in the UPDATE request into EPP transaction		then translate the actions in the UPDATE request into EPP transaction
	requests. The results of those EPP transactions would be relayed to		requests. The results of those EPP transactions would be relayed to
	the UPDATE client.		the UPDATE client.
	Requests that are not TSIG signed or fail verification must be		Requests that are not TSIG signed or fail verification must be
	rejected.		rejected.
	The translating server would handle a restricted subset of UPDATE		The translating server would handle a restricted subset of UPDATE
	requests, possibly ignoring the prerequiste section. UPDATE requests		requests, possibly ignoring the prerequiste section. UPDATE requests
	would be limited to those supported by EPP.		would be limited to those supported by EPP.
	e.g. Add NS record. Delete all NS records. Add A record. Delete		e.g. Add NS record. Delete all NS records. Add A record. Delete
	AAAA record. Add DS record. Delete DS record.		AAAA record. Add DS record. Delete DS record.
	The translating server may also override/ignore the TTL in the UPDATE		The translating server may also override/ignore the TTL in the UPDATE
	request.		request.
	3. Authentication		4. Authentication
	Authentication would be done using TSIG. TSIG was designed to be		Authentication would be done using TSIG. TSIG was designed to be
	used in a environment where requests are relayed.		used in a environment where requests are relayed.
	Authentication can be done down to the <NAME,TYPE> tuple. There		Authentication can be done down to the <NAME,TYPE> tuple. There
	exist nameservers that already implement access contols down to this		exist nameservers that already implement access contols down to this
	level of granularity based on the presented TSIG.		level of granularity based on the presented TSIG.
	This would allow nameservers to update their own address records as		This would allow nameservers to update their own address records as
	they get renumbered without being able to update anything else.		they get renumbered without being able to update anything else.
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 32 ¶
	without being able to update anything else.		without being able to update anything else.
	As Registrars do all the authentication and generate the signed		As Registrars do all the authentication and generate the signed
	responses there is no need for the Registry to have access to the		responses there is no need for the Registry to have access to the
	private key material used in TSIG.		private key material used in TSIG.
	Registrars already handle shared keys in these numbers with their web		Registrars already handle shared keys in these numbers with their web
	interfaces so it is not unreasonable to expect them to be able to		interfaces so it is not unreasonable to expect them to be able to
	handle a similar number of shared TSIG keys.		handle a similar number of shared TSIG keys.
	4. Direct to Registrar		5. Direct to Registrar
	The hardest part of Direct to Registrar is finding where to send the		The hardest part of Direct to Registrar is finding where to send the
	UPDATE request. This would most probably just be advised to the		UPDATE request. This would most probably just be advised to the
	Registrant.		Registrant.
	5. Indirect to Registrar		6. Indirect to Registrar
	In the indirect model the Registry would host a UPDATE relay server		In the indirect model the Registry would host a UPDATE relay server
	which would examine the first record of the UPDATE section and relay		which would examine the first record of the UPDATE section and relay
	the request to the Registrar of record for the owner name of that		the request to the Registrar of record for the owner name of that
	record. The Registrar would verify the validity if the request based		record. The Registrar would verify the validity if the request based
	on the TSIG then update the registry contents using EPP if		on the TSIG then update the registry contents using EPP if
	appropriate. The response from the Registrar would be relayed back		appropriate. The response from the Registrar would be relayed back
	to the client via the Registry.		to the client via the Registry.
	The Registry takes no action other than to relay the request and		The Registry takes no action other than to relay the request and
	skipping to change at page 4, line 45 ¶		skipping to change at page 5, line 16 ¶
	The relay can use either TCP or UDP when forwarding UPDATE requests		The relay can use either TCP or UDP when forwarding UPDATE requests
	as TSIG supports changes to the DNS id field when a request/response		as TSIG supports changes to the DNS id field when a request/response
	is relayed. Only the Registrar and the client (Registrant) need to		is relayed. Only the Registrar and the client (Registrant) need to
	know the TSIG secret.		know the TSIG secret.
	This is consistent with how tools like nsupdate work out where to		This is consistent with how tools like nsupdate work out where to
	send a UPDATE request if the zone is not explicity set. They look at		send a UPDATE request if the zone is not explicity set. They look at
	the ownername of the first record and use it to discover the		the ownername of the first record and use it to discover the
	containing zone.		containing zone.
	6. UPDATE Server Discovery		7. UPDATE Server Discovery
	UPDATE server discovery is a issue when the RRR model is in use as		UPDATE server discovery is a issue when the RRR model is in use as
	the UPDATE may need to be directed through EPP and/or sent to a		the UPDATE may need to be directed through EPP and/or sent to a
	Registrar. There are a number of way this could be done:		Registrar. There are a number of way this could be done:
	1) Adding a underscore infix labels to the zone which contain SRV		1) Adding a underscore infix labels to the zone which contain SRV
	records at pointing to Registar/Registry servers for each child.		records at pointing to Registar/Registry servers for each child.
	e.g. <child>._update._tcp.<parent> SRV 0 0 53 server.example.tld		e.g. <child>._update._tcp.<parent> SRV 0 0 53 server.example.tld
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 24 ¶
	2) Extend UDPATE to return the update server. Currently the Zone		2) Extend UDPATE to return the update server. Currently the Zone
	section of the UPDATE refers to the zone to be update and is		section of the UPDATE refers to the zone to be update and is
	identified by the <QNAME,SOA,QCLASS> tuple. Replacing SOA with one		identified by the <QNAME,SOA,QCLASS> tuple. Replacing SOA with one
	or more of DS, NS, A and AAAA would allow a nameserver to distingish		or more of DS, NS, A and AAAA would allow a nameserver to distingish
	between a traditional UPDATE request and a request to find the UPDATE		between a traditional UPDATE request and a request to find the UPDATE
	servers. The tuple would contain the resource to be updated and the		servers. The tuple would contain the resource to be updated and the
	reply would contain SRV records pointing to the UPDATE servers. As		reply would contain SRV records pointing to the UPDATE servers. As
	there would possibly more than one parent the owner records would		there would possibly more than one parent the owner records would
	refer to the parent zone being updated.		refer to the parent zone being updated.
	7. Security Considerations		8. Security Considerations
	The UPDATE requests are all TSIG signed. This is a proven method for		The UPDATE requests are all TSIG signed. This is a proven method for
	securing UPDATE requests in the DNS.		securing UPDATE requests in the DNS.
	8. Normative References		9. Normative References
	[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,		[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
	"Dynamic Updates in the Domain Name System (DNS UPDATE)",		"Dynamic Updates in the Domain Name System (DNS UPDATE)",
	RFC 2136, April 1997.		RFC 2136, April 1997.
	[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.		[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
	Wellington, "Secret Key Transaction Authentication for DNS		Wellington, "Secret Key Transaction Authentication for DNS
	(TSIG)", RFC 2845, May 2000.		(TSIG)", RFC 2845, May 2000.
	Author's Address		Author's Address
End of changes. 11 change blocks.
	17 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/