< draft-dkg-dprive-demux-dns-http-00.txt		draft-dkg-dprive-demux-dns-http-01.txt >
	dprive D. Gillmor		dprive D. Gillmor
	Internet-Draft ACLU		Internet-Draft ACLU
	Intended status: Informational April 24, 2017		Updates: 1035, 7230, 7540 (if approved) May 03, 2017
	Expires: October 26, 2017		Intended status: Informational
			Expires: November 4, 2017
	Demultiplexing Streamed DNS from HTTP		Demultiplexing Streamed DNS from HTTP
	draft-dkg-dprive-demux-dns-http-00		draft-dkg-dprive-demux-dns-http-01
	Abstract		Abstract
	DNS over TCP and traditional HTTP are both stream-oriented, client-		DNS over TCP and traditional HTTP are both stream-oriented, client-
	speaks-first protocols. They can both be run over a stream-based		speaks-first protocols. They can both be run over a stream-based
	security protocol like TLS. A server accepting a stream-based client		security protocol like TLS. A server accepting a stream-based client
	can distinguish between a valid stream of DNS queries and valid		can distinguish between a valid stream of DNS queries and valid
	stream of HTTP requests by simple observation of the first few octets		stream of HTTP requests by simple observation of the first few octets
	sent by the client. This can be done without any external		sent by the client. This can be done without any external
	demultiplexing mechanism like TCP port number or ALPN.		demultiplexing mechanism like TCP port number or ALPN.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 41 ¶
	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 October 26, 2017.		This Internet-Draft will expire on November 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 27 ¶		skipping to change at page 2, line 28 ¶
	3.1. DNS stream initial octets . . . . . . . . . . . . . . . . 4		3.1. DNS stream initial octets . . . . . . . . . . . . . . . . 4
	3.2. HTTP initial octets . . . . . . . . . . . . . . . . . . . 5		3.2. HTTP initial octets . . . . . . . . . . . . . . . . . . . 5
	3.2.1. HTTP/0.9 . . . . . . . . . . . . . . . . . . . . . . 6		3.2.1. HTTP/0.9 . . . . . . . . . . . . . . . . . . . . . . 6
	3.2.2. HTTP/1.0 and HTTP/1.1 . . . . . . . . . . . . . . . . 6		3.2.2. HTTP/1.0 and HTTP/1.1 . . . . . . . . . . . . . . . . 6
	3.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 7		3.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Specific octets . . . . . . . . . . . . . . . . . . . . . . . 8		4. Specific octets . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. octets 0 and 1 . . . . . . . . . . . . . . . . . . . . . 8		4.1. octets 0 and 1 . . . . . . . . . . . . . . . . . . . . . 8
	4.2. octets 2 and 3 . . . . . . . . . . . . . . . . . . . . . 8		4.2. octets 2 and 3 . . . . . . . . . . . . . . . . . . . . . 8
	4.3. octet 4 . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.3. octet 4 . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.4. octet 5 . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.4. octet 5 . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.5. octets 6 and 7 . . . . . . . . . . . . . . . . . . . . . 9		4.5. octets 6 and 7 . . . . . . . . . . . . . . . . . . . . . 10
	4.6. octets 8 through 11 . . . . . . . . . . . . . . . . . . . 9		4.6. octets 8 through 11 . . . . . . . . . . . . . . . . . . . 10
	4.7. octets 12 and 13 . . . . . . . . . . . . . . . . . . . . 10		4.7. octets 12 and 13 . . . . . . . . . . . . . . . . . . . . 10
	5. Combinations of octets . . . . . . . . . . . . . . . . . . . 10		5. Combinations of octets . . . . . . . . . . . . . . . . . . . 10
	5.1. Proof: a valid DNS message cannot be an HTTP query . . . 10		5.1. Proof: a valid DNS message cannot be an HTTP query . . . 11
	6. Guidance for Demultiplexing Servers . . . . . . . . . . . . . 11		6. Guidance for Demultiplexing Servers . . . . . . . . . . . . . 12
	6.1. Without supporting HTTP/0.9 . . . . . . . . . . . . . . . 11		6.1. Without supporting HTTP/0.9 . . . . . . . . . . . . . . . 12
	6.2. Supporting archaic HTTP/0.9 clients . . . . . . . . . . . 11		6.2. Supporting archaic HTTP/0.9 clients . . . . . . . . . . . 12
	6.3. Signaling demultiplexing capacity . . . . . . . . . . . . 12		6.3. Signaling demultiplexing capacity . . . . . . . . . . . . 13
	7. Guidance for DNS clients . . . . . . . . . . . . . . . . . . 12		7. Guidance for DNS clients . . . . . . . . . . . . . . . . . . 13
	7.1. Interpreting failure . . . . . . . . . . . . . . . . . . 13		7.1. Interpreting failure . . . . . . . . . . . . . . . . . . 14
	8. Guidance for HTTP clients . . . . . . . . . . . . . . . . . . 14		8. Guidance for HTTP clients . . . . . . . . . . . . . . . . . . 15
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 14		9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14		10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	12. Document Considerations . . . . . . . . . . . . . . . . . . . 15		12. Document Considerations . . . . . . . . . . . . . . . . . . . 16
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	13.1. Normative References . . . . . . . . . . . . . . . . . . 15		13.1. Normative References . . . . . . . . . . . . . . . . . . 16
	13.2. Informative References . . . . . . . . . . . . . . . . . 15		13.2. Informative References . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	DNS and HTTP are both client-speaks-first protocols capable of		DNS and HTTP are both client-speaks-first protocols capable of
	running over stream-based transport like TCP, or as the payload of a		running over stream-based transport like TCP, or as the payload of a
	typical TLS [RFC5246] session.		typical TLS [RFC5246] session.
	There are some contexts where it is useful for a server to be able to		There are some contexts where it is useful for a server to be able to
	decide what protocol is used by an incoming TCP stream, to choose		decide what protocol is used by an incoming TCP stream, to choose
	dynamically between DNS and HTTP on the basis of the stream itself		dynamically between DNS and HTTP on the basis of the stream itself
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	3.1. DNS stream initial octets		3.1. DNS stream initial octets
	[RFC1035] section 4.2.2 ("TCP Usage") shows that every stream-based		[RFC1035] section 4.2.2 ("TCP Usage") shows that every stream-based
	DNS connection starts with a DNS message, preceded with a 2-octet		DNS connection starts with a DNS message, preceded with a 2-octet
	message length field:		message length field:
	The message is prefixed with a two byte length field which gives		The message is prefixed with a two byte length field which gives
	the message length, excluding the two byte length field.		the message length, excluding the two byte length field.
	[RFC1035] section 4.1.1 represents the DNS message header section,		[RFC6895] section 2 represents the DNS message header section, which
	which is the first part of the DNS message on the wire (after the		is the first part of the DNS message on the wire (after the message
	message length).		length).
	1 1 1 1 1 1		1 1 1 1 1 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| ID |		| ID |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	|QR| Opcode |AA|TC|RD|RA| Z | RCODE |		|QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| QDCOUNT |		| QDCOUNT/ZOCOUNT |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| ANCOUNT |		| ANCOUNT/PRCOUNT |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| NSCOUNT |		| NSCOUNT/UPCOUNT |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	| ARCOUNT |		| ARCOUNT |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	So in a DNS over TCP stream, the interpretation of the initial 14		So in a DNS over TCP stream, the interpretation of the initial 14
	octets are fixed based on information about the first query sent on		octets are fixed based on information about the first query sent on
	the stream:		the stream:
	o 0,1: length of initial DNS message		o 0,1: length of initial DNS message
	o 2,3: DNS Transaction ID		o 2,3: DNS Transaction ID
	o 4,5: DNS opcode, flags, and response code		o 4,5: DNS opcode, flags, and response code
	o 6,7: Question count		o 6,7: Question count (or Zone count in UPDATE)
	o 8,9: Answer count		o 8,9: Answer count (or Prerequisite count in UPDATE)
	o 10,11: Authority count		o 10,11: Authority count (or Update count in UPDATE)
	o 12,13: Additional RR count		o 12,13: Additional RR count
	All DNS streams sent over TCP start with at least these 14 octets.		All DNS streams sent over TCP start with at least these 14 octets.
	3.2. HTTP initial octets		3.2. HTTP initial octets
	In an HTTP stream, the first octets sent from the client are either		In an HTTP stream, the first octets sent from the client are either
	the so-called "Simple-Request" (for HTTP/0.9), the "Request-Line"		the so-called "Simple-Request" (for HTTP/0.9), the "Request-Line"
	(for HTTP/1.0 and HTTP/1.1), which has variable characteristics, or		(for HTTP/1.0 and HTTP/1.1), which has variable characteristics, or
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 26 ¶
	"request-target" itself cannot contain 0x20 (SP) or any CTL		"request-target" itself cannot contain 0x20 (SP) or any CTL
	characters, or any characters above the US-ASCII range (> 0x7F).		characters, or any characters above the US-ASCII range (> 0x7F).
	And the "HTTP-version" token is either the literal string "HTTP/1.0"		And the "HTTP-version" token is either the literal string "HTTP/1.0"
	or the literal string "HTTP/1.1", both of which are constrained to		or the literal string "HTTP/1.1", both of which are constrained to
	the same printable-ASCII range.		the same printable-ASCII range.
	The ASCIIbetically-lowest shortest possible HTTP/1.0 or HTTP/1.1		The ASCIIbetically-lowest shortest possible HTTP/1.0 or HTTP/1.1
	request is:		request is:
	char: ! SP / H T T P / 1 . 0 CR LF CR LF		char: ! SP / SP H T T P / 1 . 0 CR LF CR LF
	index: 0 1 2 3 4 5 6 7 8 9 0 a b c d		index: 0 1 2 3 4 5 6 7 8 9 0 a b c d e
	In any case, no HTTP/1.0 or HTTP/1.1 request line can include any		In any case, no HTTP/1.0 or HTTP/1.1 request line can include any
	values lower than 0x0A (LF) or greater than 0x7F (DEL) in the first		values lower than 0x0A (LF) or greater than 0x7F (DEL) in the first
	14 octets.		15 octets.
	However, [RFC7230] section 3.1.1 also says:		However, [RFC7230] section 3.1.1 also says:
	In the interest of robustness, a server that is expecting to receive		In the interest of robustness, a server that is expecting to receive
	and parse a request-line SHOULD ignore at least one empty line (CRLF)		and parse a request-line SHOULD ignore at least one empty line (CRLF)
	received prior to the request-line.		received prior to the request-line.
	So we should also consider accepting an arbitrary number of repeated		So we should also consider accepting an arbitrary number of repeated
	CRLF sequences before the request-line as a potentially-valid HTTP		CRLF sequences before the request-line as a potentially-valid HTTP
	client behavior.		client behavior.
	skipping to change at page 9, line 27 ¶		skipping to change at page 9, line 27 ¶
	+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+
	|QR| Opcode |AA|TC|RD|		|QR| Opcode |AA|TC|RD|
	+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+
	In a standard DNS query sent over a streaming interface, QR, Opcode,		In a standard DNS query sent over a streaming interface, QR, Opcode,
	AA, and TC are all set to 0. The least-significant bit (RD -		AA, and TC are all set to 0. The least-significant bit (RD -
	Recursion Desired) is set when a packet is sent from a stub to a		Recursion Desired) is set when a packet is sent from a stub to a
	recursive resolver. The value of such an octet is 0x01. This value		recursive resolver. The value of such an octet is 0x01. This value
	never occurs in octet 4 of a legitimate HTTP client.		never occurs in octet 4 of a legitimate HTTP client.
			But under DNS UPDATE ([RFC2136], Opcode is set to 5 and all the
			option bits are cleared, which means this value would have 0x40
			(ASCII '@'), which could legitimately occur in some HTTP requests at
			this position..
	4.4. octet 5		4.4. octet 5
	In a DNS stream, octet 5 also combines several fields:		In a DNS stream, octet 5 also combines several fields:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+
	|RA| Z | RCODE |		|RA| Z|AD|CD| RCODE |
	+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+
	In a standard DNS message sent from a client, all these bits are 0.		In some DNS messages sent from a client, all these bits are 0.
	No legitimate HTTP client ever sends a value of 0x00 in octet 5.		However, section 5.7 of [RFC6840] suggests that queries may wish to
			set the AD bit to indicate a desire to learn from a validating
			resolver whether the resolver considers the contents to be Authentic
			Data.
			[RFC6840] also suggests that:
			validating resolvers SHOULD set the CD bit on every upstream query.
			So many queries, particularly from DNSSEC-validating DNS clients, are
			likely to set bits 2 and 3, resulting in a value 0x30 (ASCII '0').
			This is usually a legitimate value for octet 5 in an HTTP request.
	4.5. octets 6 and 7		4.5. octets 6 and 7
	In DNS, octets 6 and 7 represent the query count. Most DNS clients		In DNS, octets 6 and 7 represent the query count. Most DNS clients
	will send one query at a time, which makes this value 0x0001. As		will send one query at a time, which makes this value 0x0001. As
	long as the number of initial queries does not exceed 0x0A0A (2570),		long as the number of initial queries does not exceed 0x0A0A (2570),
	then at least one of these octets will have a value less than 0x0A.		then at least one of these octets will have a value less than 0x0A.
	No HTTP client sends an octet less than 0x0A in positions 6 or 7.		No HTTP client sends an octet less than 0x0A in positions 6 or 7.
			In DNS UPDATE, octets 6 and 7 represent the zone count. Entries in
			the Zone section of the DNS UPDATE message are structured identically
			to entries in the Query section of a standard DNS message.
	4.6. octets 8 through 11		4.6. octets 8 through 11
	In streaming DNS, octets 8 through 11 represent answer counts and		In streaming DNS, octets 8 through 11 represent answer counts and
	authority counts. Standard DNS queries will set them both 0. No		authority counts in normal DNS queries, or Prerequisite and Update
	HTTP client sends a zero-valued octet in these positions.		counts in DNS UPDATE. Standard DNS queries will set them both 0.
			DNS UPDATE queries are likely to include some records in these
			sections, so they won't be all zero, but as long as no more than 2570
			Prerequisite records and no more than 2570 Update records are sent,
			at least one octet will have value less than 0x0A. But No HTTP
			client sends an octet less tan 0x0A in these positions.
	4.7. octets 12 and 13		4.7. octets 12 and 13
	In streaming DNS, octets 12 and 13 represent the number of Additional		In streaming DNS, octets 12 and 13 represent the number of Additional
	RRs. When a DNS query is sent with EDNS(0), the OPT RR is accounted		RRs. When a DNS query is sent with EDNS(0), the OPT RR is accounted
	for here. So this is often either 0x0000 or 0x0001. No HTTP client		for here. So this is often either 0x0000 or 0x0001. In a Secure DNS
	will send these values at these positions.		UPDATE [RFC3007], the SIG(0) or TSIG record is also found in this
			section, which could increase the values of these octets to 0x0002.
			No HTTP client will send octets with these low values at these
			positions.
	5. Combinations of octets		5. Combinations of octets
	In a DNS message, each Question in the Question section is at least 5		In a DNS message, each Question in the Question section (or Zone in
	octets (1 octet for zero-length QNAME + 2 octets for QTYPE + 2 octets		the Zone section for DNS UPDATE) is at least 5 octets (1 octet for
	for QCLASS), and each RR (in the Answer, Authority, and Additional		zero-length QNAME + 2 octets for QTYPE + 2 octets for QCLASS), and
	sections) is at least 11 octets. And the header itself is 12 octets.		each RR (in the Answer, Authority, and Additional sections for normal
			DNS queries; or in the Prerequisite, Update, and Additional sections
			for DNS UPDATE) is at least 11 octets. And the header itself is 12
			octets.
	So we know that for a valid DNS stream, the first message has a size		So we know that for a valid DNS stream, the first message has a size
	of at least:		of at least:
	min_first_msg_size = 12 + 5 * (256*o[6] + o[7]) +		min_first_msg_size = 12 + 5 * (256*o[6] + o[7]) +
	11 * (256*(o[8] + o[10] + o[12]) +		11 * (256*(o[8] + o[10] + o[12]) +
	o[9] + o[11] + o[13])		o[9] + o[11] + o[13])
	It's possible to compare this value with the expected first query		It's possible to compare this value with the expected first query
	size:		size:
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 50 ¶
	or responses be padded, aggregated, or delayed given that streams are		or responses be padded, aggregated, or delayed given that streams are
	multiplexed?		multiplexed?
	FIXME: any other privacy considerations?		FIXME: any other privacy considerations?
	11. IANA Considerations		11. IANA Considerations
	This document does not ask IANA to make any changes to existing		This document does not ask IANA to make any changes to existing
	registries.		registries.
			However, it does update the DNS and HTTP specifications, to reflect
			the fact that services using this demultiplexing technique may be
			constrained in adoption of future versions of either DNS or HTTP if
			those future versions modify either protocol in a way that breaks
			with the distinctions documented here.
			Future revisions of or extensions to stream-based DNS or HTTP should
			take this demultiplexing technique into consideration.
	12. Document Considerations		12. Document Considerations
	[ RFC Editor: please remove this section before publication ]		[ RFC Editor: please remove this section before publication ]
	This document is currently edited as markdown. Minor editorial		This document is currently edited as markdown. Minor editorial
	changes can be suggested via merge requests at		changes can be suggested via merge requests at
	https://gitlab.com/dkg/hddemux or by e-mail to the author. Please		https://gitlab.com/dkg/hddemux or by e-mail to the author. Please
	direct all significant commentary to the public IETF DNS Privacy		direct all significant commentary to the public IETF DNS Privacy
	mailing list: dns-privacy@ietf.org		mailing list: dns-privacy@ietf.org or to the IETF HTTP WG mailing
			list: ietf-http-wg@w3.org
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <http://www.rfc-editor.org/info/rfc1035>.		November 1987, <http://www.rfc-editor.org/info/rfc1035>.
	[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext		[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
	Transfer Protocol -- HTTP/1.0", RFC 1945,		Transfer Protocol -- HTTP/1.0", RFC 1945,
	DOI 10.17487/RFC1945, May 1996,		DOI 10.17487/RFC1945, May 1996,
	<http://www.rfc-editor.org/info/rfc1945>.		<http://www.rfc-editor.org/info/rfc1945>.
			[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
			"Dynamic Updates in the Domain Name System (DNS UPDATE)",
			RFC 2136, DOI 10.17487/RFC2136, April 1997,
			<http://www.rfc-editor.org/info/rfc2136>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.		<http://www.rfc-editor.org/info/rfc5234>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<http://www.rfc-editor.org/info/rfc7230>.		<http://www.rfc-editor.org/info/rfc7230>.
	skipping to change at page 16, line 5 ¶		skipping to change at page 17, line 17 ¶
	DOI 10.17487/RFC7540, May 2015,		DOI 10.17487/RFC7540, May 2015,
	<http://www.rfc-editor.org/info/rfc7540>.		<http://www.rfc-editor.org/info/rfc7540>.
	13.2. Informative References		13.2. Informative References
	[I-D.ietf-dnsop-dns-wireformat-http]		[I-D.ietf-dnsop-dns-wireformat-http]
	Song, L., Vixie, P., Kerr, S., and R. Wan, "DNS wire-		Song, L., Vixie, P., Kerr, S., and R. Wan, "DNS wire-
	format over HTTP", draft-ietf-dnsop-dns-wireformat-http-01		format over HTTP", draft-ietf-dnsop-dns-wireformat-http-01
	(work in progress), March 2017.		(work in progress), March 2017.
			[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
			Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
			<http://www.rfc-editor.org/info/rfc3007>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<http://www.rfc-editor.org/info/rfc5246>.		<http://www.rfc-editor.org/info/rfc5246>.
			[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
			Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
			DOI 10.17487/RFC6840, February 2013,
			<http://www.rfc-editor.org/info/rfc6840>.
			[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
			Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
			April 2013, <http://www.rfc-editor.org/info/rfc6895>.
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,		Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
	July 2014, <http://www.rfc-editor.org/info/rfc7301>.		July 2014, <http://www.rfc-editor.org/info/rfc7301>.
	[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,		[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
	DOI 10.17487/RFC7830, May 2016,		DOI 10.17487/RFC7830, May 2016,
	<http://www.rfc-editor.org/info/rfc7830>.		<http://www.rfc-editor.org/info/rfc7830>.
	[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,		[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
End of changes. 28 change blocks.
	49 lines changed or deleted		109 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/