< draft-ietf-dane-srv-07.txt		draft-ietf-dane-srv-08.txt >
	DNS-Based Authentication of Named Entities (DANE) T. Finch		DNS-Based Authentication of Named Entities (DANE) T. Finch
	Internet-Draft University of Cambridge		Internet-Draft University of Cambridge
	Intended status: Standards Track M. Miller		Intended status: Standards Track M. Miller
	Expires: January 24, 2015 Cisco Systems, Inc.		Expires: April 24, 2015 Cisco Systems, Inc.
	P. Saint-Andre		P. Saint-Andre
	&yet		&yet
	July 23, 2014		October 21, 2014
	Using DNS-Based Authentication of Named Entities (DANE) TLSA Records		Using DNS-Based Authentication of Named Entities (DANE) TLSA Records
	with SRV Records		with SRV Records
	draft-ietf-dane-srv-07		draft-ietf-dane-srv-08
	Abstract		Abstract
	The DANE specification (RFC 6698) describes how to use TLSA resource		The DANE specification (RFC 6698) describes how to use TLSA resource
	records in the DNS to associate a server's host name with its TLS		records in the DNS to associate a server's host name with its TLS
	certificate, where the association is secured with DNSSEC. However,		certificate, where the association is secured with DNSSEC. However,
	application protocols that use SRV records (RFC 2782) to indirectly		application protocols that use SRV records (RFC 2782) to indirectly
	name the target server host names for a service domain cannot apply		name the target server host names for a service domain cannot apply
	the rules from RFC 6698. Therefore this document provides guidelines		the rules from RFC 6698. Therefore this document provides guidelines
	that enable such protocols to locate and use TLSA records.		that enable such protocols to locate and use TLSA records.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 January 24, 2015.		This Internet-Draft will expire on April 24, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. DNS Checks . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. DNS Checks . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. SRV Query . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. SRV Query . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.2. Address Queries . . . . . . . . . . . . . . . . . . . . . 4		3.2. Address Queries . . . . . . . . . . . . . . . . . . . . . 4
	3.3. TLSA Queries . . . . . . . . . . . . . . . . . . . . . . 5		3.3. TLSA Queries . . . . . . . . . . . . . . . . . . . . . . 4
	3.4. Impact on TLS Usage . . . . . . . . . . . . . . . . . . . 5		3.4. Impact on TLS Usage . . . . . . . . . . . . . . . . . . . 5
	4. TLS Checks . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. TLS Checks . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. SRV Records Only . . . . . . . . . . . . . . . . . . . . 5		4.1. SRV Records Only . . . . . . . . . . . . . . . . . . . . 5
	4.2. TLSA Records . . . . . . . . . . . . . . . . . . . . . . 6		4.2. TLSA Records . . . . . . . . . . . . . . . . . . . . . . 6
	5. Guidance for Application Protocols . . . . . . . . . . . . . 7		5. Guidance for Protocol Authors . . . . . . . . . . . . . . . . 6
	6. Guidance for Server Operators . . . . . . . . . . . . . . . . 7		6. Guidance for Server Operators . . . . . . . . . . . . . . . . 7
	7. Internationalization Considerations . . . . . . . . . . . . . 8		7. Guidance for Application Developers . . . . . . . . . . . . . 8
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		8. Internationalization Considerations . . . . . . . . . . . . . 8
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 8		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Mixed Security Status . . . . . . . . . . . . . . . . . . 8		10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	9.2. A Service Domain Trusts its Servers . . . . . . . . . . . 8		10.1. Mixed Security Status . . . . . . . . . . . . . . . . . 8
	9.3. Certificate Subject Name Matching . . . . . . . . . . . . 9		10.2. A Service Domain Trusts its Servers . . . . . . . . . . 8
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		10.3. Certificate Subject Name Matching . . . . . . . . . . . 9
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	11.1. Normative References . . . . . . . . . . . . . . . . . . 9		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	11.2. Informative References . . . . . . . . . . . . . . . . . 10		12.1. Normative References . . . . . . . . . . . . . . . . . . 9
			12.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
	A.1. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . 11		A.1. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	A.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 11		A.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Appendix B. Rationale . . . . . . . . . . . . . . . . . . . . . 12		Appendix B. Rationale . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The base DANE specification [RFC6698] describes how to use TLSA		The base DANE specification [RFC6698] describes how to use TLSA
	resource records in the DNS to associate a server's host name with		resource records in the DNS to associate a server's host name with
	skipping to change at page 3, line 44 ¶		skipping to change at page 3, line 47 ¶
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this memo are to be interpreted as described in		"OPTIONAL" in this memo are to be interpreted as described in
	[RFC2119].		[RFC2119].
	This draft uses the definitions for "secure", "insecure", "bogus",		This draft uses the definitions for "secure", "insecure", "bogus",
	and "indeterminate" from [RFC4035]. This draft uses the acronyms		and "indeterminate" from [RFC4035]. This draft uses the acronyms
	from [RFC7218] for the values of TLSA fields where appropriate.		from [RFC7218] for the values of TLSA fields where appropriate.
	3. DNS Checks		3. DNS Checks
	To expedite connection to the intended service, where possible the
	queries described in the following sections SHOULD be performed in
	parallel (this is similar to the "happy eyeballs" approach for IPv4
	and IPv6 connections described in [RFC6555]).
	3.1. SRV Query		3.1. SRV Query
	When the client makes an SRV query, a successful result will		When the client makes an SRV query, a successful result will
	typically be a list of one or more SRV records (or possibly a chain		typically be a list of one or more SRV records (or possibly a chain
	of CNAME / DNAME aliases leading to such a list).		of CNAME / DNAME aliases leading to such a list). Implementers need
			to be aware that unsuccessful results can occur because of various
			DNS-related errors; a helpful summary can be found in section 2.1 of
			[I-D.ietf-dane-smtp-with-dane].
	For this specification to apply, the entire DNS RRset that is		For this specification to apply, the entire DNS RRset that is
	returned MUST be "secure" according to DNSSSEC validation ([RFC4033]		returned MUST be "secure" according to DNSSSEC validation ([RFC4033]
	section 5). In the case of aliases, the whole chain of CNAME and		section 5). In the case of aliases, the whole chain of CNAME and
	DNAME RRsets MUST be secure as well. This corresponds to the AD bit		DNAME RRsets MUST be secure as well. This corresponds to the AD bit
	being set in the response(s); see [RFC4035] section 3.2.3.		being set in the response(s); see [RFC4035] section 3.2.3.
	If the the entire RRset is "insecure" or "indeterminate", this		If the the entire RRset is "insecure", this protocol has not been
	protocol has not been correctly deployed. The client SHOULD fall		correctly deployed. The client SHOULD fall back to its non-DNSSEC,
	back to its non-DNSSEC, non-DANE behavior (this corresponds to the AD		non-DANE behavior (this corresponds to the AD bit being unset). If
	bit being unset). If the entire RRset is "bogus", the client MUST		the entire RRset is "bogus", the client MUST abort the attempt.
	abort the attempt.
	In the successful case, the client now has an authentic list of		In the successful case, the client now has an authentic list of
	target server host names with weight and priority values. It		target server host names with weight and priority values. It
	performs server ordering and selection using the weight and priority		performs server ordering and selection using the weight and priority
	values without regard to the presence or absence of DNSSEC or TLSA		values without regard to the presence or absence of DNSSEC or TLSA
	records. It also takes note of the DNSSEC validation status of the		records. It also takes note of the DNSSEC validation status of the
	SRV response for use when checking certificate names (see Section 4).		SRV response for use when checking certificate names (see Section 4).
	The client can now proceed to making address queries on the target		The client can now proceed to making address queries on the target
	server host names as described in the next section.		server host names as described in the next section.
	3.2. Address Queries		3.2. Address Queries
	For each SRV target server host name, the client makes A / AAAA		For each SRV target server host name, the client makes A and AAAA
	queries, performs DNSSEC validation on the address (A, AAAA)		queries, performs DNSSEC validation on the address (A or AAAA)
	response, and continues as follows based on the results:		response, and continues as follows based on the results:
	o If the response is "secure" and usable, the client MUST perform a		o If the response is "secure" and usable, the client MUST perform a
	TLSA query for that target server host name as described in the		TLSA query for that target server host name as described in the
	next section.		next section.
	o If the response is "insecure", the client MUST NOT perform a TLSA		o If the response is "insecure", the client MUST NOT perform a TLSA
	query for that target server host name; the TLSA query will most		query for that target server host name; the TLSA query will most
	likely fail.		likely fail.
	skipping to change at page 7, line 5 ¶		skipping to change at page 6, line 42 ¶
	[RFC6698].		[RFC6698].
	If the TLS server's certificate -- or the public key of the server's		If the TLS server's certificate -- or the public key of the server's
	certificate -- matches a usable TLSA record with Certificate Usage		certificate -- matches a usable TLSA record with Certificate Usage
	"DANE-EE", the client MUST consider the server to be authenticated.		"DANE-EE", the client MUST consider the server to be authenticated.
	Because the information in such a TLSA record supersedes the non-key		Because the information in such a TLSA record supersedes the non-key
	information in the certificate, all other [RFC5280] and [RFC6125]		information in the certificate, all other [RFC5280] and [RFC6125]
	authentication checks (e.g., reference identifier, key usage,		authentication checks (e.g., reference identifier, key usage,
	expiration, issuance) MUST be ignored or omitted.		expiration, issuance) MUST be ignored or omitted.
	5. Guidance for Application Protocols		5. Guidance for Protocol Authors
	This document describes how to use DANE with application protocols in		This document describes how to use DANE with application protocols in
	which target servers are discovered via SRV records. Although this		which target servers are discovered via SRV records. Although this
	document attempts to provide generic guidance applying to all such		document attempts to provide generic guidance applying to all such
	protocols, additional documents for particular application protocols		protocols, additional documents for particular application protocols
	could cover related topics, such as:		could cover related topics, such as:
	o Fallback logic in the event that a client is unable to connect		o Fallback logic in the event that a client is unable to connect
	securely to a target server by following the procedures defined in		securely to a target server by following the procedures defined in
	this document.		this document.
	o How clients ought to behave if they do not support SRV lookups, or		o How clients ought to behave if they do not support SRV lookups, or
	if clients that support SRV lookups encounter service domains that		if clients that support SRV lookups encounter service domains that
	do not offer SRV records.		do not offer SRV records.
	o Whether the application protocol has a functional equivalent for		o Whether the application protocol has a functional equivalent for
	TLS SNI that is preferred within that protocol.		TLS SNI that is preferred within that protocol.
			o Use of SRV records with additional discovery technologies, such as
			the use of both SRV records and NAPTR records [RFC3403] for
			transport selection in the Session Initiation Protocol (SIP).
	For example, [I-D.ietf-xmpp-dna] covers such topics for the		For example, [I-D.ietf-xmpp-dna] covers such topics for the
	Extensible Messaging and Presence Protocol (XMPP).		Extensible Messaging and Presence Protocol (XMPP).
	6. Guidance for Server Operators		6. Guidance for Server Operators
	To conform to this specification, the published SRV records and		To conform to this specification, the published SRV records and
	subsequent address (A, AAAA) records MUST be secured with DNSSEC.		subsequent address (A and AAAA) records MUST be secured with DNSSEC.
	There SHOULD also be at least one TLSA record published that		There SHOULD also be at least one TLSA record published that
	authenticates the server's certificate.		authenticates the server's certificate.
	When using TLSA records with Certificate Usage "DANE-EE", it is not		When using TLSA records with Certificate Usage "DANE-EE", it is not
	necessary for the deployed certificate to contain an identifier for		necessary for the deployed certificate to contain an identifier for
	either the source domain or target server host name. However,		either the source domain or target server host name. However,
	servers that rely solely on validation using Certificate Usage "DANE-		operators need to be aware that servers relying solely on validation
	EE" TLSA records might prevent clients that do not support this		using Certificate Usage "DANE-EE" TLSA records might prevent clients
	specification from successfully connecting with TLS.		that do not support this specification from successfully connecting
			with TLS.
	For TLSA records with Certificate Usage types other than "DANE-EE",		For TLSA records with Certificate Usage types other than "DANE-EE",
	the certificate(s) MUST contain an identifier that matches:		the certificate(s) MUST contain an identifier that matches:
	o the service domain name (the "source domain" in [RFC6125] terms,		o the service domain name (the "source domain" in [RFC6125] terms,
	which is the SRV query domain); and/or		which is the SRV query domain); and/or
	o the target server host name (the "derived domain" in [RFC6125]		o the target server host name (the "derived domain" in [RFC6125]
	terms, which is the SRV target).		terms, which is the SRV target).
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 5 ¶
	"multi-tenanted environments") can implement the Transport Layer		"multi-tenanted environments") can implement the Transport Layer
	Security Server Name Indication (TLS SNI) [RFC6066] or its functional		Security Server Name Indication (TLS SNI) [RFC6066] or its functional
	equivalent to determine which certificate to offer. Clients that do		equivalent to determine which certificate to offer. Clients that do
	not support this specification will indicate a preference for the		not support this specification will indicate a preference for the
	service domain name, while clients that support this specification		service domain name, while clients that support this specification
	will indicate the target server host name. However, the server		will indicate the target server host name. However, the server
	determines what certificate to present in the TLS handshake; e.g.,		determines what certificate to present in the TLS handshake; e.g.,
	the presented certificate might only authenticate the target server		the presented certificate might only authenticate the target server
	host name.		host name.
	7. Internationalization Considerations		7. Guidance for Application Developers
			Developers of application clients that depend on DANE-SRV often would
			like to prepare as quickly as possible for making a connection to the
			intended service, thus reducing the wait time for end users. To make
			this optimization possible, a DNS library might perform the SRV
			queries, address queries, and TLSA queries in parallel (because a
			TLSA record can be ignored if it turns out that the address record on
			which it depends is not secure, performing the TLSA queries in
			parallel with the SRV queries and address queries is not harmful from
			a security perspective and can yield some operational benefits).
			8. Internationalization Considerations
	If any of the DNS queries are for an internationalized domain name,		If any of the DNS queries are for an internationalized domain name,
	then they need to use the A-label form [RFC5890].		then they need to use the A-label form [RFC5890].
	8. IANA Considerations		9. IANA Considerations
	No IANA action is required.		No IANA action is required.
	9. Security Considerations		10. Security Considerations
	9.1. Mixed Security Status		10.1. Mixed Security Status
	We do not specify that clients checking all of a service domain's		We do not specify that clients checking all of a service domain's
	target server host names are consistent in whether they have or do		target server host names are consistent in whether they have or do
	not have TLSA records. This is so that partial or incremental		not have TLSA records. This is so that partial or incremental
	deployment does not break the service. Different levels of		deployment does not break the service. Different levels of
	deployment are likely if a service domain has a third-party fallback		deployment are likely if a service domain has a third-party fallback
	server, for example.		server, for example.
	The SRV sorting rules are unchanged; in particular they have not been		The SRV sorting rules are unchanged; in particular they have not been
	altered in order to prioritize secure servers over insecure servers.		altered in order to prioritize secure servers over insecure servers.
	If a site wants to be secure it needs to deploy this protocol		If a site wants to be secure it needs to deploy this protocol
	completely; a partial deployment is not secure and we make no special		completely; a partial deployment is not secure and we make no special
	effort to support it.		effort to support it.
	9.2. A Service Domain Trusts its Servers		10.2. A Service Domain Trusts its Servers
	By signing their zone with DNSSEC, service domain operators		By signing their zone with DNSSEC, service domain operators
	implicitly instruct their clients to check their server TLSA records.		implicitly instruct their clients to check their server TLSA records.
	This implies another point in the trust relationship between service		This implies another point in the trust relationship between service
	domain holders and their server operators. Most of the setup		domain holders and their server operators. Most of the setup
	requirements for this protocol fall on the server operator:		requirements for this protocol fall on the server operator:
	installing a TLS certificate with the correct name (where necessary),		installing a TLS certificate with the correct name (where necessary),
	and publishing a TLSA record for that certificate. If these are not		and publishing a TLSA record for that certificate. If these are not
	correct then connections from TLSA-aware clients might fail.		correct then connections from TLSA-aware clients might fail.
	9.3. Certificate Subject Name Matching		10.3. Certificate Subject Name Matching
	Section 4 of the TLSA specification [RFC6698] leaves the details of		Section 4 of the TLSA specification [RFC6698] leaves the details of
	checking names in certificates to higher level application protocols,		checking names in certificates to higher level application protocols,
	though it suggests the use of [RFC6125].		though it suggests the use of [RFC6125].
	Name checks are not necessary if the matching TLSA record is of		Name checks are not necessary if the matching TLSA record is of
	Certificate Usage "DANE-EE". Because such a record identifies the		Certificate Usage "DANE-EE". Because such a record identifies the
	specific certificate (or public key of the certificate), additional		specific certificate (or public key of the certificate), additional
	checks are superfluous and potentially conflicting.		checks are superfluous and potentially conflicting.
	Otherwise, while DNSSEC provides a secure binding between the server		Otherwise, while DNSSEC provides a secure binding between the server
	name and the TLSA record, and the TLSA record provides a binding to a		name and the TLSA record, and the TLSA record provides a binding to a
	certificate, this latter step can be indirect via a chain of		certificate, this latter step can be indirect via a chain of
	certificates. For example, a Certificate Usage "PKIX-TA" TLSA record		certificates. For example, a Certificate Usage "PKIX-TA" TLSA record
	only authenticates the CA that issued the certificate, and third		only authenticates the CA that issued the certificate, and third
	parties can obtain certificates from the same CA. Therefore, clients		parties can obtain certificates from the same CA. Therefore, clients
	need to check whether the server's certificate matches one of the		need to check whether the server's certificate matches one of the
	expected reference identifiers to ensure that the certificate was		expected reference identifiers to ensure that the certificate was
	issued by the CA to the server the client expects.		issued by the CA to the server the client expects.
	10. Acknowledgements		11. Acknowledgements
	Thanks to Mark Andrews for arguing that authenticating the target		Thanks to Mark Andrews for arguing that authenticating the target
	server host name is the right thing, and that we ought to rely on		server host name is the right thing, and that we ought to rely on
	DNSSEC to secure the SRV lookup. Thanks to James Cloos, Viktor		DNSSEC to secure the SRV lookup. Thanks to James Cloos, Viktor
	Dukhovni, Ned Freed, Olafur Gudmundsson, Paul Hoffman, Phil Pennock,		Dukhovni, Ned Freed, Olafur Gudmundsson, Paul Hoffman, Phil Pennock,
	Hector Santos, Jonas Schneider, and Alessandro Vesely for helpful		Hector Santos, Jonas Schneider, and Alessandro Vesely for helpful
	suggestions.		suggestions.
	11. References		12. References
	11.1. Normative References		12.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	February 2000.		February 2000.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements", RFC		Rose, "DNS Security Introduction and Requirements", RFC
	skipping to change at page 10, line 40 ¶		skipping to change at page 10, line 40 ¶
	Submission/Access Services", RFC 6186, March 2011.		Submission/Access Services", RFC 6186, March 2011.
	[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication		[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
	of Named Entities (DANE) Transport Layer Security (TLS)		of Named Entities (DANE) Transport Layer Security (TLS)
	Protocol: TLSA", RFC 6698, August 2012.		Protocol: TLSA", RFC 6698, August 2012.
	[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify		[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
	Conversations about DNS-Based Authentication of Named		Conversations about DNS-Based Authentication of Named
	Entities (DANE)", RFC 7218, April 2014.		Entities (DANE)", RFC 7218, April 2014.
	11.2. Informative References		12.2. Informative References
	[I-D.ietf-dane-smtp-with-dane]		[I-D.ietf-dane-smtp-with-dane]
	Dukhovni, V. and W. Hardaker, "SMTP security via		Dukhovni, V. and W. Hardaker, "SMTP security via
	opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-05		opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-05
	(work in progress), February 2014.		(work in progress), February 2014.
	[I-D.ietf-xmpp-dna]		[I-D.ietf-xmpp-dna]
	Saint-Andre, P. and M. Miller, "Domain Name Associations		Saint-Andre, P. and M. Miller, "Domain Name Associations
	(DNA) in the Extensible Messaging and Presence Protocol		(DNA) in the Extensible Messaging and Presence Protocol
	(XMPP)", draft-ietf-xmpp-dna-05 (work in progress),		(XMPP)", draft-ietf-xmpp-dna-05 (work in progress),
	February 2014.		February 2014.
	[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with		[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
	Dual-Stack Hosts", RFC 6555, April 2012.		Part Three: The Domain Name System (DNS) Database", RFC
			3403, October 2002.
	Appendix A. Examples		Appendix A. Examples
	In the following, most of the DNS resource data is elided for		In the following, most of the DNS resource data is elided for
	simplicity.		simplicity.
	A.1. IMAP		A.1. IMAP
	; mail domain		; mail domain
	_imap._tcp.example.com. SRV 10 0 9143 imap.example.net.		_imap._tcp.example.com. SRV 10 0 9143 imap.example.net.
	skipping to change at page 13, line 40 ¶		skipping to change at page 13, line 40 ¶
	Matthew Miller		Matthew Miller
	Cisco Systems, Inc.		Cisco Systems, Inc.
	1899 Wynkoop Street, Suite 600		1899 Wynkoop Street, Suite 600
	Denver, CO 80202		Denver, CO 80202
	USA		USA
	Email: mamille2@cisco.com		Email: mamille2@cisco.com
	Peter Saint-Andre		Peter Saint-Andre
	&yet		&yet
	P.O. Box 787
	Parker, CO 80134
	USA
	Email: peter@andyet.com		Email: peter@andyet.com
			URI: https://andyet.com/
End of changes. 29 change blocks.
	50 lines changed or deleted		63 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/