[dnsoverhttp] DNS wireformat in JSON draft

[Martin Thomson <[e-mail]>]

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