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

[Paul Hoffman <[e-mail]>]

On Apr 20, 2017, at 1:58 PM, Wiley, Glen <[e-mail]> wrote:
> 
> 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.

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."

>  
> 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?

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, these definitely do occur in the DNS echo system and we need a way to differentiate them from label separators.

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.

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

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

--Paul Hoffman