< draft-hoffman-dns-in-json-09.txt		draft-hoffman-dns-in-json-10.txt >
	Network Working Group P. Hoffman		Network Working Group P. Hoffman
	Internet-Draft ICANN		Internet-Draft ICANN
	Intended status: Experimental October 04, 2016		Intended status: Experimental October 31, 2016
	Expires: April 7, 2017		Expires: May 4, 2017
	Representing DNS Messages in JSON		Representing DNS Messages in JSON
	draft-hoffman-dns-in-json-09		draft-hoffman-dns-in-json-10
	Abstract		Abstract
	Some applications use DNS messages, or parts of DNS messages, as		Some applications use DNS messages, or parts of DNS messages, as
	data. For example, a system that captures DNS queries and responses		data. For example, a system that captures DNS queries and responses
	might want to be able to easily search those without having to decode		might want to be able to easily search those without having to decode
	the messages each time. Another example is a system that puts		the messages each time. Another example is a system that puts
	together DNS queries and responses from message parts. This document		together DNS queries and responses from message parts. This document
	describes a standardized format for DNS message data in JSON.		describes a standardized format for DNS message data in JSON.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 April 7, 2017.		This Internet-Draft will expire on May 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 6, line 29 ¶		skipping to change at page 6, line 29 ¶
	o CLASSname - String whose value is "IN", "CH", "HS", or has the		o CLASSname - String whose value is "IN", "CH", "HS", or has the
	format in [RFC3597]		format in [RFC3597]
	o TTL - Integer whose value is 0 to 4294967295		o TTL - Integer whose value is 0 to 4294967295
	o RDLENGTH - Integer whose value is 0 to 65535. Applications using		o RDLENGTH - Integer whose value is 0 to 65535. Applications using
	this format are unlikely to use this value directly, and instead		this format are unlikely to use this value directly, and instead
	calculate the value from the RDATA.		calculate the value from the RDATA.
	o RDATA - String of the octets of the RDATA field of the resource		o RDATAHEX - Hex-encoded string (base16 encoding described in
	record. This will most likely be given as RDATAHEX. The data in		[RFC4648]) of the octets of the RDATA field of the resource
	some common RDATA fields are also described in their own members;		record. The data in some common RDATA fields are also described
	see Section 2.3.		in their own members; see Section 2.3.
	o rrSet - List of objects which have RDLENGTH and RDATA members.		o rrSet - List of objects which have RDLENGTH and RDATA members.
	A Question section can be expressed as a resource record. When doing		A Question section can be expressed as a resource record. When doing
	so, the TTL, RDLENGTH, and RDATA members make no sense.		so, the TTL, RDLENGTH, and RDATA members make no sense.
	2.3. Specific RDATA Field Members		2.3. Specific RDATA Field Members
	The following are common RDATA types and how to specify them as JSON		The following are common RDATA types and how to specify them as JSON
	members. The name of the member contains the name of the RDATA type.		members. The name of the member contains the name of the RDATA type.
	skipping to change at page 7, line 22 ¶		skipping to change at page 7, line 22 ¶
	RFC that defines that RDATA type. It is not expected that every		RFC that defines that RDATA type. It is not expected that every
	receiving application will know how to parse these values.		receiving application will know how to parse these values.
	rdataCDNSKEY, rdataCDS, rdataCSYNC, rdataDNSKEY, rdataHIP,		rdataCDNSKEY, rdataCDS, rdataCSYNC, rdataDNSKEY, rdataHIP,
	rdataIPSECKEY, rdataKEY, rdataMX, rdataNSEC, rdataNSEC3,		rdataIPSECKEY, rdataKEY, rdataMX, rdataNSEC, rdataNSEC3,
	rdataNSEC3PARAM, rdataOPENPGPKEY, rdataRRSIG, rdataSMIMEA, rdataSPF,		rdataNSEC3PARAM, rdataOPENPGPKEY, rdataRRSIG, rdataSMIMEA, rdataSPF,
	rdataSRV, rdataSSHFP, rdataTLSA		rdataSRV, rdataSSHFP, rdataTLSA
	2.4. The Message and Its Parts as Octets		2.4. The Message and Its Parts as Octets
	The following can be members of a message object. These names will		The following can be members of a message object. These members are
	most likely be given as "HEX" to indicate encoding that is not plain		all encoded in base16 encoding described in [RFC4648]. All these
	ASCII. All these items are strings.		items are strings.
	o messageOctets - The octets of the message		o messageOctetsHEX - The octets of the message
	o headerOctets - The first 12 octets of the message (or fewer, if		o headerOctetsHEX - The first 12 octets of the message (or fewer, if
	the message is truncated)		the message is truncated)
	o questionOctets - The octets of the Question section		o questionOctetsHEX - The octets of the Question section
	o answerOctets - The octets of the Answer section		o answerOctetsHEX - The octets of the Answer section
	o authorityOctets - The octets of the Authority section		o authorityOctetsHEX - The octets of the Authority section
	o additionalOctets - The octets of the Additional section		o additionalOctetsHEX - The octets of the Additional section
	The following can be a member of a resource record object.		The following can be a member of a resource record object.
	o rrOctets - The octets of a particular resource record		o rrOctetsHEX - The octets of a particular resource record
	The items in this section are useful in applications to canonically		The items in this section are useful in applications to canonically
	reproduce what appeared on the wire. For example, an application		reproduce what appeared on the wire. For example, an application
	that is converting wire-format requests and responses might do		that is converting wire-format requests and responses might do
	decompression of names, but the system reading the converted data may		decompression of names, but the system reading the converted data may
	want to be sure the decompression was done correctly. Such a system		want to be sure the decompression was done correctly. Such a system
	would need to see the part of the message where the decompressed		would need to see the part of the message where the decompressed
	labels resided, such as in one of the items in this section.		labels resided, such as in one of the items in this section.
	2.5. Additional Message Object Members		2.5. Additional Message Object Members
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 34 ¶
	been removed.		been removed.
	There are two encodings for names:		There are two encodings for names:
	o If the member name does not end in "HEX", the value is a domain		o If the member name does not end in "HEX", the value is a domain
	name encoded as ASCII. Non-ASCII octets in the domain name are		name encoded as ASCII. Non-ASCII octets in the domain name are
	expressed using JSON's escaping rules. Periods indicate		expressed using JSON's escaping rules. Periods indicate
	separation between labels.		separation between labels.
	o If the member name ends in "HEX", the value is the wire format for		o If the member name ends in "HEX", the value is the wire format for
	an entire domain name stored in base16 encoding.		an entire domain name stored in base16 encoding described in
			[RFC4648].
	3. JSON Format for a Paired DNS Query and Response		3. JSON Format for a Paired DNS Query and Response
	A paired DNS query and response is represented as an object. Two		A paired DNS query and response is represented as an object. Two
	optional members of this object are names "queryMessage" and		optional members of this object are names "queryMessage" and
	"responseMessage", and each has a value that is an message object.		"responseMessage", and each has a value that is an message object.
	This design was chosen (as compared to the more obvious array of two		This design was chosen (as compared to the more obvious array of two
	values) so that a paired DNS query and response could be		values) so that a paired DNS query and response could be
	differentiated from a stream of DNS messages whose length happens to		differentiated from a stream of DNS messages whose length happens to
	be two.		be two.
	skipping to change at page 14, line 15 ¶		skipping to change at page 14, line 15 ¶
	10.2. Informative References		10.2. Informative References
	[I-D.daley-dnsxml]		[I-D.daley-dnsxml]
	Daley, J., Morris, S., and J. Dickinson, "dnsxml - A		Daley, J., Morris, S., and J. Dickinson, "dnsxml - A
	standard XML representation of DNS data", draft-daley-		standard XML representation of DNS data", draft-daley-
	dnsxml-00 (work in progress), July 2013.		dnsxml-00 (work in progress), July 2013.
	[I-D.dulaunoy-dnsop-passive-dns-cof]		[I-D.dulaunoy-dnsop-passive-dns-cof]
	Dulaunoy, A., Kaplan, A., Vixie, P., and H. Stern,		Dulaunoy, A., Kaplan, A., Vixie, P., and H. Stern,
	"Passive DNS - Common Output Format", draft-dulaunoy-		"Passive DNS - Common Output Format", draft-dulaunoy-
	dnsop-passive-dns-cof-01 (work in progress), November		dnsop-passive-dns-cof-02 (work in progress), October 2016.
	2015.
	[I-D.mohan-dns-query-xml]		[I-D.mohan-dns-query-xml]
	Parthasarathy, M. and P. Vixie, "Representing DNS messages		Parthasarathy, M. and P. Vixie, "Representing DNS messages
	using XML", draft-mohan-dns-query-xml-00 (work in		using XML", draft-mohan-dns-query-xml-00 (work in
	progress), September 2011.		progress), September 2011.
	[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,		[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
	RFC 20, DOI 10.17487/RFC0020, October 1969,		RFC 20, DOI 10.17487/RFC0020, October 1969,
	<http://www.rfc-editor.org/info/rfc20>.		<http://www.rfc-editor.org/info/rfc20>.
End of changes. 14 change blocks.
	21 lines changed or deleted		21 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/