< draft-sury-dnsop-cname-plus-dname-00.txt		draft-sury-dnsop-cname-plus-dname-01.txt >
	dnsop O. Sury		dnsop O. Sury
	Internet-Draft Internet Systems Consortium		Internet-Draft Internet Systems Consortium
	Updates: 1034 (if approved) July 15, 2018		Updates: 1034 (if approved) July 15, 2018
	Intended status: Standards Track		Intended status: Standards Track
	Expires: January 16, 2019		Expires: January 16, 2019
	CNAME+DNAME Name Redirection		CNAME+DNAME Name Redirection
	draft-sury-dnsop-cname-plus-dname-00		draft-sury-dnsop-cname-plus-dname-01
	Abstract		Abstract
	This document updates RFC1034 to allow coexistence of the CNAME		This document updates RFC1034 to allow coexistence of the CNAME
	Resource Record with DNAME Resource Record at the same owner node,		Resource Record with DNAME Resource Record at the same owner node,
	which provides redirection for a sub-tree of the domain name tree in		which provides redirection for a sub-tree of the domain name tree in
	the DNS system, in a parent zone. By allowing this cooexistence, DNS		the DNS system, in a parent zone. By allowing this cooexistence, DNS
	system will have a way how to create a sub-tree redirection together		system will have a way how to create a sub-tree redirection together
	that includes the Resource Records owner name. This would allow		that includes the Resource Records owner name. This would allow
	parent zones to create full domain aliases.		parent zones to create full domain aliases.
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. CNAME+DNAME Bundle . . . . . . . . . . . . . . . . . . . . . 4		3. CNAME+DNAME Bundle . . . . . . . . . . . . . . . . . . . . . 4
	4. Query processing . . . . . . . . . . . . . . . . . . . . . . 4		4. Query processing . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. Processing by Authoritative Servers . . . . . . . . . . . 4		4.1. Processing by Authoritative Servers . . . . . . . . . . . 4
	4.2. Processing by Recursive Servers . . . . . . . . . . . . . 4		4.2. Processing by Recursive Servers . . . . . . . . . . . . . 4
	5. Implementation Report . . . . . . . . . . . . . . . . . . . . 4		5. Implementation Report . . . . . . . . . . . . . . . . . . . . 4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 4		6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	8.1. Normative References . . . . . . . . . . . . . . . . . . 5		8.1. Normative References . . . . . . . . . . . . . . . . . . 5
	8.2. Informative References . . . . . . . . . . . . . . . . . 5		8.2. Informative References . . . . . . . . . . . . . . . . . 5
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	RFC 1034 [RFC1034] defines CNAME resource record for cases when there		RFC 1034 [RFC1034] defines CNAME resource record for cases when there
	are multiple names for single host. A CNAME resource record		are multiple names for single host. A CNAME resource record
	identifies its owner name as an alias, and specifies the		identifies its owner name as an alias, and specifies the
	corresponding canonical name in the RDATA section of the resource		corresponding canonical name in the RDATA section of the resource
	record. If a CNAME resource record is present at a node, no other		record. If a CNAME resource record is present at a node, no other
	data MUST be present; this ensures that the data for a canonical name		data MUST be present; this ensures that the data for a canonical name
	and its aliases cannot be different. This rule also insures that a		and its aliases cannot be different. This rule also insures that a
	skipping to change at page 4, line 22 ¶		skipping to change at page 4, line 22 ¶
	Existing rules for a DNAME RR and a CNAME RR are still valid with		Existing rules for a DNAME RR and a CNAME RR are still valid with
	following exception: The DNAME and CNAME resource records MAY co-		following exception: The DNAME and CNAME resource records MAY co-
	exist at the same owner name in the parent zone.		exist at the same owner name in the parent zone.
	4.1. Processing by Authoritative Servers		4.1. Processing by Authoritative Servers
	The authoritative server implementations MUST allow CNAME record when		The authoritative server implementations MUST allow CNAME record when
	there is a DNAME record for the same name and vice versa.		there is a DNAME record for the same name and vice versa.
	TODO: Experiment with returning DNAME together with CNAME.		The authoritative server implementations compliant with this
			specification SHOULD add an associated DNAME record into an
			ADDITIONAL (or ANSWER?) section for any non-DNAME query along with
			the CNAME record that would be normally required. This would allow
			recursive DNS server implementation that understand the DNAME record
			to synthetize the answers for the subtree directly without making an
			additional queries to the respective authoritative DNS servers.
	4.2. Processing by Recursive Servers		4.2. Processing by Recursive Servers
	The recursive server implementations MUST NOT deny CNAME record when		The recursive server implementations MUST NOT deny CNAME record when
	there is a DNAME record already present in the cache for the same		there is a DNAME record already present in the cache for the same
	name and vice versa.		name and vice versa.
			The recursive DNS server implementation SHOULD accept the extra DNAME
			resource record that would be returned along with the CNAME record in
			the ADDITIONAL (or ANSWER?) section.
	5. Implementation Report		5. Implementation Report
	The author has implemented a change for BIND 9 authoritative server		The author has implemented a change for BIND 9 authoritative server
	during the IETF Hackathon in Montreal, and the domain with		during the IETF Hackathon in Montreal, and the domain with
	CNAME+DNAME can be tested at www.cname-plus-dname.rocks.		CNAME+DNAME can be tested at www.cname-plus-dname.rocks.
	The conducted experiment confirmed that BIND, Unbound and Google		The conducted experiment confirmed that BIND, Unbound and Google
	Public DNS work fine, Knot Resolver has a bug that makes the DNS		Public DNS work fine, Knot Resolver has a bug that makes the DNS
	answer contain the DNAME records, but with RCODE=SERVFAIL, and		answer contain the DNAME records, but with RCODE=SERVFAIL, and
	PowerDNS returns RCODE=SERVFAIL for any DNAME query. The other		PowerDNS returns RCODE=SERVFAIL for any DNAME query. The other
	public DNS implementations follow the errors of their respective		public DNS implementations follow the errors of their respective
	deployed software.		deployed software.
	6. Security Considerations		6. Security Considerations
	The security is the same as security of the individual CNAME and		In case the recursive DNS server looking for records has enabled DNS
	DNAME records.		Query Name Minimization (RFC 7816 [RFC7816]), the CNAME+DNAME
			specification might make the resolver send one more label than needed
			from the original DNS Query Name to the nameservers authoritative for
			the CNAME+DNAME records unless the authoritative DNS server
			preemptively returns DNAME record along with the CNAME resource
			record for the minimized query, and at the same time the recursive
			DNS server understand the additional data in the answer and utilizes
			it to synthetize the answer.
	7. IANA Considerations		7. IANA Considerations
	This document makes no requests of IANA.		This document makes no requests of IANA.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	skipping to change at page 5, line 40 ¶		skipping to change at page 6, line 12 ¶
	8.2. Informative References		8.2. Informative References
	[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint		[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
	Engineering Team (JET) Guidelines for Internationalized		Engineering Team (JET) Guidelines for Internationalized
	Domain Names (IDN) Registration and Administration for		Domain Names (IDN) Registration and Administration for
	Chinese, Japanese, and Korean", RFC 3743,		Chinese, Japanese, and Korean", RFC 3743,
	DOI 10.17487/RFC3743, April 2004,		DOI 10.17487/RFC3743, April 2004,
	<https://www.rfc-editor.org/info/rfc3743>.		<https://www.rfc-editor.org/info/rfc3743>.
			[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
			Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
			<https://www.rfc-editor.org/info/rfc7816>.
	Author's Address		Author's Address
	Ondrej Sury		Ondrej Sury
	Internet Systems Consortium		Internet Systems Consortium
	CZ		CZ
	Email: ondrej@isc.org		Email: ondrej@isc.org
End of changes. 7 change blocks.
	7 lines changed or deleted		28 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/