Skip to main content

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

Yes

(Alexey Melnikov)

No Objection

(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Eric Rescorla)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 14 and is now closed.

Warren Kumari
No Objection
Comment (2018-05-04 for -15) Unknown
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. ]
Alexey Melnikov Former IESG member
Yes
Yes (for -14) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (2018-05-08 for -15) Unknown
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.
Alissa Cooper Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2018-05-09 for -15) Unknown
Thanks for a well-written document. My only question is, what is the nature of the experiment?
Benjamin Kaduk Former IESG member
No Objection
No Objection (2018-05-09 for -15) Unknown
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."
Deborah Brungard Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Eric Rescorla Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2018-05-04 for -15) Unknown
I guess this doc could also be informational. Otherwise, what's the experiment or the criteria to move to Proposed Standard?
Spencer Dawkins Former IESG member
No Objection
No Objection (2018-05-09 for -15) Unknown
I wanted to thank the authors for including the design background in Section 1.1. I found that helpful.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -15) Unknown