Subject: [dnsoverhttp] DNS wireformat in JSON draft

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Sep 2016 15:56:36 +1000

(Starting a new thread for this stuff)

>> Frankly, I don't think that the JSON spec is anywhere near as ready as
>> your proposed protocol spec, so I'm surprised to hear you want to push
>> it out with an RFC number on it.
>
> As I keep saying, I'm quite open to comments on it. I've gotten plenty from the DNS community over the past few years, but we could have missed stuff you're seeing.

Here you go then:

What draft-hoffman-dns-in-json describes is worse than having to parse
the DNS wire protocol.

This is because it assumes that you have name compression, and all the
crap that the DNS wire protocol includes, PLUS the added complicates
of JSON and base64 (and base16).  If the goal here is to make this
format accessible in a way that DNS never has been, you can't just do
a mechanical translation of the wire format.  That does no one a
service - application developers find the format unusable and the DNS
people want their wire format back.  With what you have, you might as
well go with the binary format and leave people to mess with
ArrayBuffers and the like.  That would be a shame.

On the other hand, if you want to make this usable, then make it
usable. Ditch the name compression.  Translate the contents of the
common RRtypes into usable forms, don't just dump RDATA on people.
Don't use "*" or "!" in your names.  Don't use both base64 and base16.
Don't use \DDD encoding.  Don't use 0/1 for boolean fields.  All of
these things are very hostile to application developers.

Then you can include defaults for fields and look at other usability
improvements.  Then you might have something that an application
developer will want to look at.

In the end, you are making the server do more work to produce a usable
format, but do it right and it's fairly easy.  There are a lot more
producers than consumers in this space and the consumers will thank
you for it.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Sep 2016 14:57:08 +0000

> What draft-hoffman-dns-in-json describes is worse than having to parse

Yes and no. Yes because the receiver has more ways to do things and has to specify to the sender what it wants to receive. No because (1) name compression turns out to have ugly edge cases, (2) escaping, and (3) parsing badly-formated responses is really really hard. The original use case for the JSON format was a receiver who wanted to know just a few common values for a huge amount of traffic.

> crap that the DNS wire protocol includes

Yes, of course.

> , PLUS the added complicates
> of JSON and base64 (and base16).  

True. I am open to getting rid of one of the optional encodings.

> If the goal here is to make this
> a mechanical translation of the wire format.  

That was never my goal, but I hear it is a goal for you and others here.

> That does no one a
> usable. Ditch the name compression.  

... you didn't read the revised draft I put out yesterday...

> Translate the contents of the

Define "common" for you. Seriously, that's easily done. However, for the DNS folks, uncommon is just as important as common.

> Don't use "*" or "!" in your names.  

... you didn't read the revised draft I put out yesterday...

> Don't use both base64 and base16.

Noted; can do.

> Don't use \DDD encoding.  

That requirement means "when encoding from a zone file to this format, you MUST do a conversion". You are just trading unfriendly to the recipient with unfriendly to the sender. It's fine for a profile to say "values with \DDD encoding will be rejected", but I think it is wrong to put that in the protocol itself.

> Don't use 0/1 for boolean fields.  

Noted; can do. (Well, *should* do. This was me being lazy.)

> All of

They are hostile to developers of *receiving* applications. Some of what you ask is hostile to the sending applications.

Having said that, I'm open to making the format less balanced between the two, picking one side over the other, and picking the receiving side. I just want you to be clear that is what you are asking for.

> improvements.  

Quite true.

> Then you might have something that an application

My view was that if there are more producers than consumers, you should make the producers' life easier. I hear that might be inverted.

Other folks: please chime in!

--Paul Hoffman