Subject: [dnsoverhttp] JSON DNS Suggestions

From: Zach Lym <[email-masked]>
Date: Fri, 11 Nov 2016 12:19:27 -0800

My apologies, I'm not very skilled with mailing lists but I wanted to
pickup on the thread Martin started earlier.

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].  I would like to propose the following changes
to bring the spec:

* Lowercase fields (`name`, `ttl`, etc)
* Uppercase text values for `type` ("A", "CNAME", etc)
* Array of RR objects for `question` and `answer` (no alternate "qname"
field)

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.

I'm fairly ignorant of the server side of things, feel free to educate me :
)

Thank you,
-Zach Lym
P.S. Is there a Github repo for the DNS JSON spec?

[0]: https://docs.google.com/spreadsheets/d/1nELiZZEDzUnN--
d7P033ppI_APebXlSFpbIWSmXvj2w/edit#gid=0

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 13 Nov 2016 10:54:34 +0000

On Nov 12, 2016, at 5:19 AM, Zach Lym <[email-masked]> wrote:
> My apologies, I'm not very skilled with mailing lists but I wanted to pickup on the thread Martin started earlier.

No problem, and thanks for the review!

> 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. :-)

>  I would like to propose the following changes to bring the spec:
> 

I painted the bike shed this way to match RFC 1035.

> * Uppercase text values for `type` ("A", "CNAME", etc)

That's already there in section 2.2.

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

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

> I'm fairly ignorant of the server side of things, feel free to educate me : )

There is hopefully nothing server-specifc here!

> 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

---

From: Zach Lym <[email-masked]>
Date: Tue, 15 Nov 2016 13:06:09 -0800

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

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 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 ; )

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

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

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.

> There is hopefully nothing server-specifc here!

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

> Not yet, given that it is not clear what its home will be.

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

Thanks,
-Zach Lym