

Ask HN: What do you look for in a DNS provider? - stevekemp

I&#x27;ve been becoming increasingly interested in DNS hosting, and DNS-providers.<p>Specifically I think that it would be interesting to provide an API to interface with DNS.  I&#x27;ve been thinking of accepting POSTed JSON which would ultimately end up inside a git history.<p>Your client would make requests, these would be applied, and if you wanted you could clone the git repository to see your history.<p>Alternatively I could imagine git pushes triggering DNS updates.<p>But beyond these rough ideas I&#x27;d wonder what features others might enjoy, desire, or need?
======
mattbee
Greetings from Bytemark, we are contemplating much the same thing right now.

We have our old content DNS system
([http://www.bytemark.co.uk/support/technical_documents/dnsc](http://www.bytemark.co.uk/support/technical_documents/dnsc))
which just lets you upload tinydns data via rsync (since 2003). Based on
tinydns, so it's been completely rock-solid stable but missing more and more
features as time went on (IPv6 is in, but DNSSSEC is a long way off).

Our challenge is to add / augment this to allow sane control panel access for
people that want t ouse it and not proliferate databases or logins. We have a
rough idea of what to do, as maybe you do too, though we will likely have to
make people choose between "old" and new type logins

But the idea will remain the same -upload a nice simple text file of records,
becomes live straight away. tinydns syntax can certainly be transformed from
other formats pretty easily...

What're you working on then?

~~~
stevekemp
I suspect you could solve your problem ("provide web-interface to DNS")
reasonably easily without moving away from tinydns. If you used a sneaky
second access mechanism (HTTP, say) to get the hosted/live records from your
upload-host you could wrap that into a form with fields and select-boxes for
record-types (since tinydns is so trivial to parse).

(If you were to just expose the actual tinydns file then the whole thing is
trivial of course, but user-error is more likely.)

Once you have some user-interface then applying changes goes in the same
direction, process the form submission, then put back the modified records to
the central location, and trigger a rebuild of the binary records.

\--

My current prototype allows a complete zone-file to be POSTed to a HTTP
service, and then written out to a tinydns file _or_ uploaded to Amazon's
route53 service.

Similarly you can query a zone and retrieve back an array of records. Each
record has an ID, a type ("A", "NS", "AAAA", "MX") along with the associated
data.

The point where I've started to take a step back and think things over is the
case of adding/editing a single record. Because each record has an ID you can
trivially say /zone/example.com/delete/$id or POST to apply an update.

But allowing operations to be applied to a single record complicates things
somewhat, and that was the point where I started considering using git as the
storage back-end. That would allow historical tracking, and interesting things
to be done - especially if you exposed the actual store too.

