IETF API Standardization

First off, thank you for creating this amazing service, which makes it possible for me and others to update their DNS entries at will. I wish there were more systems supporting such an API.

In fact, why not? Have you ever considered taking a look at standardizing your API (or at least the /api/v1/domains part), say in some IETF Workgroup?

Given that an increasing amount of management APIs are moving to HTTP (see e.g. RFC 7030 for Certificate Management), it sure seems like they might be interested in replacing old solutions like RFC 2136 with an ID like “DNS Management over HTTP”.

Have you spoken to other nameserver operators about whether they would implement such an API? Would you even be open to aligning your API to the feedback by a suitable working group?
There are probably things that a WG will want to handle differently, e.g. keep Authorization out of scope or make it compatible with existing specifications such as OAuth 2.0 Bearer Token Usage.

Thanks for any feedback in advance :slight_smile:

Hi logolive,

Thanks for your message, and welcome to deSEC! :slight_smile:

We feel flattered about your compliments regarding our API. Of course, our API should be the standard API™. :wink:

More seriously, here are some thoughts:

  • I am not sure which WG would be the best for standardizing APIs. The DNSOP charter is a bit vague about whether it would be covered.
  • Our API is so intuitive because it is very simple. Other providers also have DNS APIs, but each of them offers a different set of additional features. As an example, take a look at Cloudflare’s DNS record management interface. While some features perhaps can easily be added with optional endpoints or JSON fields, there may be cases where that is not possible, so that the API itself would need more changes, and become more abstract. In the end, you’d not be standardizing our API, but a generalization of it. I can’t say ahead of time whether that would be neat or a cumbersome thing.
  • Our API is implemented using Django REST Framework (DRF) and thus mainly follows its design patterns, plus some of our own thinking. However, that also means that DRF is what constrains our freedom in making changes. If the WG was to agree on an API design that’s incompatible with it, it would be a huge amount of work to implement it.

Given all that, I don’t see why your idea shouldn’t be attempted. I encourage you to sign up for the DNSOP mailing list and make a proposal there. In case it wouldn’t fit there, people can refer you to what to do instead.

Stay secure,
Peter