Subject: [dnsoverhttp] feedback on draft-hoffman-dns-in-json-11

From: "Wiley, Glen" <[email-masked]>
Date: Thu, 20 Apr 2017 20:58:55 +0000

One of the folks on my team here at Verisign (Karl Henderson) spent some time looking over the draft and had a few comments, I am posting on his behalf since he can’t currently post to the list.

Re: Representing DNS Messages in JSON (draft-hoffman-dns-in-json-11)

it’s not clear from the Abstract if this draft is proposing the SJON format as an out-of-band telemetry transport format for non-dns-resolver consumption (i.e. transposing RFC1035 queries into JSON format for downstream research, monitoring, etc) or if this is intended to be a new DNS query/response format. This should be clarified in the Abstract.

If the intent is the former then this doesn’t raise concerns.

If the intent is the latter, I have a couple of concerns:

-          The JSON format may substantially increase the size of the query/response message

o    In this case, the new format may necessitate TCP vs UDP due to fragmentation

o    This may increase effectiveness of reflector amplification attacks especially if an attacker is able to query using an RFC1035 format but request a response in JSON format.

-          DNS privacy – it just makes it that much easier for an observer with little technical knowledge to view DNS traffic information

Could the same goals (making it easier for applications to examine only parts of a DNS message) be achieved using more terse encoding formats such as ASN.1 or AVRO?

It’s not clear to me in section 1.1 or 2.6 how we differentiate QNAME label separators in ASCII format and literal dots ‘.’ (0x2E) in QNAME labels. Even though this is not a valid label character, these definitely do occur in the DNS echo system and we need a way to differentiate them from label separators.

Section 1.1, bullet 5 says:

“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.”

Yet, section 4 says:

Streaming DNS objects is performed using [RFC7464]

However, section 2, paragraph 2 of RFC7464 says:

“JSON text sequences MUST use UTF-8 encoding”

-- 

Glen Wiley

Principal Engineer

Verisign, Inc. CTO Technical Team

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 22 Apr 2017 16:34:15 +0000

> it’s not clear from the Abstract if this draft is proposing the SJON format as an out-of-band telemetry transport format for non-dns-resolver consumption (i.e. transposing RFC1035 queries into JSON…

It is not intended exclusively for either. That's why the abstract says "This document describes a general format for DNS message data in JSON."

> Could the same goals (making it easier for applications to examine only parts of a DNS message) be achieved using more terse encoding formats such as ASN.1 or AVRO?

Absolutely. For a current example of a binary format for JSON with a specific use case, see draft-ietf-dnsop-dns-capture-format.

> It’s not clear to me in section 1.1 or 2.6 how we differentiate QNAME label separators in ASCII format and literal dots ‘.’ (0x2E) in QNAME labels. Even though this is not a valid label character,…

This is the exact same problem with the display format described in RFC 1035. If that is a concern for the developer, they should use the "HEX" version of names, which only uses the wireformat.

> “JSON text sequences MUST use UTF-8 encoding”

ASCII encoding is a proper subset of UTF-8 encoding, so there is no conflict here.

--Paul Hoffman