Re: [dnsoverhttp] JSON DNS Suggestions

[Zach Lym <[e-mail]>]

>
> > While at EasyDNS, I created a library to translate between popular REST
> DNS APIs.  The syntax suggested by the current proposal is very different
> from what I found in the wild[0].
>
> This list shows that lots of developers have lots of preferences. :-)
>

The best standards tend to codify existing norms (WHAT-WG) or were formed
as the result of a competition (AES, SHA, etc).  A list of public APIs that
represent DNS records in JSON is the best proxy I can come up with.

Granted, being popular doesn't equate to being the "best" choice, but it's
more than just a pile of preferences.

>  I would like to propose the following changes to bring the spec:
> >
> > * Lowercase fields (`name`, `ttl`, etc)
>
> I painted the bike shed this way to match RFC 1035.
>

None of the APIs in the aforementioned list uppercase the field names ...
uppercase keywords died out with B&W terminals.

Dismiss this as bike shedding if you like, but I'm not going to let you
paint that bike shed neon pink ; )

> * Uppercase text values for `type` ("A", "CNAME", etc)
>
> That's already there in section 2.2.
>

I was advocating for the string representation by default, you have TYPE as
an integer and TYPEname as a string.  Going back to that list, the only
provider that accepts integers at all is Google and even they support both
strings and ints.

> * Array of RR objects for `question` and `answer` (no alternate "qname"
> field)
>
> One of the design goals for this format was the ability to specify invalid
> queries and responses so that it can be used to encapsulate some of the
> crap we see on the wire.
>

Ahh, I was confused and I misspoke!  Why should have both
qname/qtype/qclass in the message body AND a question array?

I'm not against getting rid of the question array, but I don't understand
why we are doing both....

> I'm also a bit concerned about parsing the "Specific RDATA Field Members"
> (`rdataA` and friends).  The proliferation of record types has led most
> APIs to stuffing everything (pref, prio, weight, port, etc) into the rdata
> field.  I think it would be best to require a space delimited rdata field
> and *optional* record-specific fields.  I can write a polygot library to
> split out such fields for client side developers.
>
> This sounds reasonable, but I added that in at the request of others on
> this mailing list.
>

Yes and while I agree with the reasoning, the implementation is problematic.

The current scheme requires a different rdata field for every record type.
Yet for most records, you keep the space delimited text form.  When you
look at real-world implementations, most just use space delimited rdata
values.  The two that do split fields from rdata tend to do so for MX and
SRV records.

Having a single representation for rdata lets one use a generic algorithm
for all records.  Making record-specific fields optional allows
applications to make use of them when it suites them.

> I'm fairly ignorant of the server side of things, feel free to educate me
> : )
>
> There is hopefully nothing server-specifc here!
>

For example, I generally don't care about stuff like the HEX representation.

> P.S. Is there a Github repo for the DNS JSON spec?
>
> Not yet, given that it is not clear what its home will be.
>
> --Paul Hoffman


If I created one, would you use it?  I prefer to break issues down into
single tickets instead of marathon emails.

Thanks,
-Zach Lym