Representing DNS Messages in JSON
draft-hoffman-dns-in-json-16

[Ballot comment]
For the "compressedFOO" elements, are we confident that the "length
in the message" text is sufficiently unambiguous?

It sounds like fields whose value is an integer but whose value can
be greater than 2**16 (e.g., TTL) can use the full flexibility of
JSON numeric encoding, including exponent and fractional part.  Just
double checking that that's the intent, as it does not seem to be
explicitly stated anywhere.

In Section 6, I think there may be a singular/plural mismatch in
"For example, private DNS systems such as those described in
[I-D.dulaunoy-dnsop-passive-dns-cof] covers just DNS responses."

[Ballot comment]
Thanks for taking the time to make this document easy to read. I have a handful
of comments. The first two are conflicts between this document and existing
documents, and really need to be resolved prior to publication. The remaining
comments are simple clarifications and/or nits.

---------------------------------------------------------------------------

§1.1:

>  o  The encoding for the DNS object is ASCII as described in
>    [RFC0020].  This is done to prevent an attempt to use a different
>    encoding such as UTF-8 for octets in names or data.

RFC 8259 §8.1:

>  JSON text exchanged between systems that are not part of a closed
>  ecosystem MUST be encoded using UTF-8 [RFC3629].

I believe what you mean to say here is that the JSON representation of the
objects described in this document is limited to the UTF-8 codepoints from
U+0000 to U+007F. This has an impact in §2.6 as well.


---------------------------------------------------------------------------

§2.2:

>  o  TTL - Integer whose value is 0 to 4294967295

RFC 1035 §2.3.4:

> TTL            positive values of a signed 32 bit number.
                                      ^^^^^^

RFC 1035 §3.2.1:

> TTL            a 32 bit signed integer that specifies the time interval
                          ^^^^^^

If the intention is to replicate the format defined by RFC 1035, then
this document should define a range of -2147483648 to 2147483647.

---------------------------------------------------------------------------

§2.3:

>  o  rdataAAAA - IPv6 address, such as "fe80::a65e:60ff:fed6:8aaf"

For avoidance of doubt regarding encoding, I would recommend that this
document cite and require the use of the format described in RFC 5952.

---------------------------------------------------------------------------

§2.6:

>  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
>    expressed using JSON's escaping rules.  Periods indicate
>    separation between labels.

For avoidance of doubt, this should probably indicate that the values greater
than U+007F represent literal on-the-wire bytes, rather than allowing any
implication that U-labels are allowed.

---------------------------------------------------------------------------

§10:

>  Many
>  people on the dnsoverhttp mailing list also contributed very useful
>  ideas (even though this list is not a WG and this work might not even
>  be used by the eventual DNS-over-HTTPS work).

I'm just flagging this as it appears to be somewhat dated. Feel free to update
if you are so inclined.

[Ballot comment]
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3056

  "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
      expressed using JSON's escaping rules.  Periods indicate
      separation between labels."

How does this deal with labels that contain periods?
This is sadly common in "attack" or "hand-rolled" queries and is something that people might really want to log/use this for.

I could see:
A: MUST use HEX for names which have embedded periods
B: some discussion on escaping these
C: something else!


[ Note: First time using Mozilla's Phabricator system for review - still learning its tagging, etc system. ]

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-hoffman-dns-in-json-13. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the application registry on the Media Type registry page located at:

https://www.iana.org/assignments/media-types/

a single, new media type is to be registered as follows:

Name: dns+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-04-20):

From: The IESG
To: IETF-Announce
CC: linuxwolf+ietf@outer-planes.net, alexey.melnikov@isode.com, draft-hoffman-dns-in-json@ietf.org, Matthew Miller
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Representing DNS Messages in JSON) to Experimental RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'Representing DNS Messages in JSON'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-04-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Some applications use DNS messages, or parts of DNS messages, as
  data.  For example, a system that captures DNS queries and responses
  might want to be able to easily search those without having to decode
  the messages each time.  Another example is a system that puts
  together DNS queries and responses from message parts.  This document
  describes a general format for DNS message data in JSON.  Specific
  profiles of this document can be described in other documents for
  specific applications and usage scenarios.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-hoffman-dns-in-json/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-hoffman-dns-in-json/ballot/


No IPR declarations have been submitted directly on this I-D.

# SUMMARY

The document shepherd is Matthew Miller.  The responsible Area Director is Alexey Melnikov.

This document defines a mapping of DNS messages into JSON; it allows for conversion to and from the DNS binary message format.  It defines the expected JSON syntax for the common properties within a DNS message, a mechanism for encoding binary data without representation, and a common mechanism to specify a query/response pair.  The data format allows for future extensibility, such as additional type-specific values.

# REVIEW AND CONSENSUS

This document received reviews from those versed in the DNS and applications with little controversy.  There have been some comments made on its generic nature; the document explicitly states it provides a mapping without opinions, and applications of this data format are allowed and encouraged to constrain it for their needs.

## REFERENCES

The reference to RFC 7159 is now obsoleted by RFC 8259, but there are no issues with updating this reference.

This document contains a number of references to expired internet-drafts.  Such references are purely informational, and provide some additional context and insights into the development of this document.

## IANA REGISTRY ACTIONS

This document registers a new media type of "application/dns+json"; it is clear and meets the requirements from RFC 6838.  As this document is only expressing already existing DNS parameters into a new format, no other actions by IANA are necessary.

## INTELLECTUAL PROPERTY

The author has confirmed their adherence to BCP 78/79; there are no IPR disclosures currently on this document, and the author has indicated they are not aware of any such claims that can be made.