Subject: [dnsoverhttp] Updated draft-hoffman-dns-in-json

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Sep 2016 20:47:43 +0000

Greetings. Based on the recent discussion on the DNSOP mailing list (noting again that this is not a WG work item!), I have updated draft-hoffman-dns-in-json. I still plan to send this to the ISE for Experimental in about two weeks, and am happy to make more changes before then (or after, based on the ISE review).

--Paul Hoffman

> A new version of I-D, draft-hoffman-dns-in-json-08.txt
> has been successfully submitted by Paul Hoffman and posted to the
> IETF repository.
> 
> Name:		draft-hoffman-dns-in-json
> Revision:	08
> Title:		Representing DNS Messages in JSON
> Document date:	2016-09-21
> Group:		Individual Submission
> Pages:		13
> URL:            https://www.ietf.org/internet-drafts/draft-hoffman-dns-in-json-08.txt
> Status:         https://datatracker.ietf.org/doc/draft-hoffman-dns-in-json/
> Htmlized:       https://tools.ietf.org/html/draft-hoffman-dns-in-json-08
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-in-json-08
> 
> 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 standardized format for DNS message data in JSON.

---

From: George Michaelson <[email-masked]>
Date: Thu, 22 Sep 2016 08:15:37 +1000

I really like this document. I particularly like that it explicitly
addresses how the JSON format it uses can represent *malformed* DNS
state, as seen on the wire. This is very important, because some
canonicalize-and-map-the-DNS efforts I've seen have focussed on
well-formed packets, and this one stands out as saying "no, we have to
be able to represent incorrect state, because that exists on the wire,
and we need to show it sometimes"

It has multiple encoding possibilities for the DNS RR. I'm a little
confused what difference it makes, that you'd want 'all the things'
here. If the argument is 'long crypto hashes are better done as
base64' then why do we have the hex at all? Is that to preserve
bit-field legibility for instance? Or, to encode unintelligible
off-the-wire sequences which present as a valid RR but you can't
decompose into their constituents? Maybe its just a little guidance
when you saw the hex being used? rather than B64.

Do you need to be explicit that transform through this JSON would
permit re-emission of the wire content onto a network, and have the
packets function? Is that even a goal? The streaming reference sort-of
made me think this might be a goal, but it wasn't explicit to me in a
cursory reading.

I think this is a good document. I think its close to baked for me.

George

On Thu, Sep 22, 2016 at 6:47 AM, Paul Hoffman <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Sep 2016 22:49:16 +0000

On Sep 21, 2016, at 3:15 PM, George Michaelson <[email-masked]> wrote:
> base64' then why do we have the hex at all?

Hex is easier to type for short blobs.

> Is that to preserve

Really, it's just there because some people prefer one way over the other for some fields.

> packets function? Is that even a goal?

Not a goal. (Particularly for badly-formed DNS responses :-) )

> The streaming reference sort-of

Thanks! And thanks to the many folks who have suggested (and will hopefully continue to suggest) changes. It's way better than the -00.

--Paul Hoffman