Show HN: GitHub-based DNS Hosting(dns-api.com)
dns-api.com
Show HN: GitHub-based DNS Hosting
https://dns-api.com/
12 comments
As a pre-emptive note for other HN'ers:
1) I'm not annoyed that Steve's built a competing product. That would be like the developers of Squid being annoyed that Varnish exists, or lighttpd and Nginx, or.... you get the picture. Competition in the free market and especially amongst software providers is good and healthy, and saying otherwise is tantamount to saying that software is sacred. That way lies patent madness. Besides, LuaDNS and I'm sure others have similar products. I was actually really excited about this, as it validates our market, theoretically - until I recognized the name and visited the site.
2) I'm furious that Steve blogged about us, mailed us directly - so he damn sure knows about us and our product - and then directly lifted our copy and messaging, and is now presenting this as an original concept on a Show HN post. That's where this all falls apart. Just - not cool, buddy. Not. Cool.
1) I'm not annoyed that Steve's built a competing product. That would be like the developers of Squid being annoyed that Varnish exists, or lighttpd and Nginx, or.... you get the picture. Competition in the free market and especially amongst software providers is good and healthy, and saying otherwise is tantamount to saying that software is sacred. That way lies patent madness. Besides, LuaDNS and I'm sure others have similar products. I was actually really excited about this, as it validates our market, theoretically - until I recognized the name and visited the site.
2) I'm furious that Steve blogged about us, mailed us directly - so he damn sure knows about us and our product - and then directly lifted our copy and messaging, and is now presenting this as an original concept on a Show HN post. That's where this all falls apart. Just - not cool, buddy. Not. Cool.
1. Good :)
2. What you call "lifting our copy" I call "Making the obvious comparison" - given the implementation. If it were a whole page, rather than one identical sentence, I'd be more apologetic.
That said I am genuinely sorry that this has caused annoyance, and I didn't mean to imply this was a genuinely new idea - just a new implementation of a good idea.
Hopefully this is .. better?
That
2. What you call "lifting our copy" I call "Making the obvious comparison" - given the implementation. If it were a whole page, rather than one identical sentence, I'd be more apologetic.
That said I am genuinely sorry that this has caused annoyance, and I didn't mean to imply this was a genuinely new idea - just a new implementation of a good idea.
Hopefully this is .. better?
That
[deleted]
I'm not sure if refuting point by point will be seen as a sign of good faith, or getting bogged down in the details.
As you say multiple people have had similar ideas, including people such as LuaDNS.
That said:
1. If you check back you'll see my blog posts mention you, and LuaDNS, and others. But yes I've heard of you. e.g. The post previous to the one you link to says, in short "People will pay for Git + DNS" - http://blog.steve.org.uk/some_things_on_dns_and_caching.html - Which clearly gives the motivation, and before I saw you.
2. I guess we'll never know how that could have changed things.
3. Genuinely not intended to be anything other than the obvious thing that popped into my mind - I will absolutely get that changed in the next while.
As for the server falling over, it's a little heavyweight on the front-end, using some Perl CGIs, so the fact it died when having only 512Mb of RAM isn't a surprise.
You'll see that I've just setup both dns-api.org, and dhcp.io, both of which are handling decent amounts of traffic - and both of which are free. I hope that I'm capable of doing DNS stuff.
I'm glad your service exists, I'm glad you implement all the records, but .. apart from the word-collision I'm not sure that I'm doing anything particularly bad here.
As you say multiple people have had similar ideas, including people such as LuaDNS.
That said:
1. If you check back you'll see my blog posts mention you, and LuaDNS, and others. But yes I've heard of you. e.g. The post previous to the one you link to says, in short "People will pay for Git + DNS" - http://blog.steve.org.uk/some_things_on_dns_and_caching.html - Which clearly gives the motivation, and before I saw you.
2. I guess we'll never know how that could have changed things.
3. Genuinely not intended to be anything other than the obvious thing that popped into my mind - I will absolutely get that changed in the next while.
As for the server falling over, it's a little heavyweight on the front-end, using some Perl CGIs, so the fact it died when having only 512Mb of RAM isn't a surprise.
You'll see that I've just setup both dns-api.org, and dhcp.io, both of which are handling decent amounts of traffic - and both of which are free. I hope that I'm capable of doing DNS stuff.
I'm glad your service exists, I'm glad you implement all the records, but .. apart from the word-collision I'm not sure that I'm doing anything particularly bad here.
Having recently started to explore the Amazon Route53 API I can see a lot of value in using it:
* Anycast DNS handling located in multiple regions.
* Good API for accessing it.
But the barrier to entry is high for many, and the volume-based pricing might put people off.
On that basis I thought a middle-layer of glue might be useful, so I created https://dns-api.com/
Using Github webhooks you can trigger updates of your DNS in a simple manner, allowing near instant updates.
* Anycast DNS handling located in multiple regions.
* Good API for accessing it.
But the barrier to entry is high for many, and the volume-based pricing might put people off.
On that basis I thought a middle-layer of glue might be useful, so I created https://dns-api.com/
Using Github webhooks you can trigger updates of your DNS in a simple manner, allowing near instant updates.
I'd want this backed by CloudFlare's dns, not R53 so that I could take advantage of CF's network as a proxy in front of my servers. https://www.cloudflare.com/docs/client-api.html
Interesting comment, thanks.
It's not impossible we could allow a per-zone destination to be setup, and upload to Google, Amazon, CloudFlare, or somebody else.
It's not impossible we could allow a per-zone destination to be setup, and upload to Google, Amazon, CloudFlare, or somebody else.
To expand... the issue I have with CloudFlare's dns is that it isn't under version control. I suspect plenty of other people have this issue too.
I have a tool that syncs my DNS records to CloudFlare using flat files that I keep under version control. I just extracted it from my personal tool set:
https://github.com/dnerdy/namesync
This flat file format seems to work well, and the tool could potentially be updated to support other DNS providers.
https://github.com/dnerdy/namesync
This flat file format seems to work well, and the tool could potentially be updated to support other DNS providers.
That is much more useful to me than the OP service. Thanks.
Using 6 as a prefix for ipv6 might be a bad idea.
The DNS Specification (RFC2181[1]) states:
>The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, __any binary string whatever can be used as the label of any resource record.__
>Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs.
As an example these are all valid domains
[1]: http://tools.ietf.org/rfc/rfc2181
The DNS Specification (RFC2181[1]) states:
>The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, __any binary string whatever can be used as the label of any resource record.__
>Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs.
As an example these are all valid domains
6.4424.cn, 6www.4424.cn, 6662.cn
[1]: http://tools.ietf.org/rfc/rfc2181
The record format is the same one that is used for DJBDNS, which by default does not support IPv6 addresses. There is a patch that adds IPv6 support, records start with 6 for IPv6 records.
If you want to create a record named:
Here is more information about the DJBDNS data format: http://cr.yp.to/djbdns/tinydns-data.html
If you want to create a record named:
6www.whatever.com
66www.whatever.com
Here is more information about the DJBDNS data format: http://cr.yp.to/djbdns/tinydns-data.html
it might not cause problems, but is not very concise
adding syntax to support new features always causes problems (python .. ^cough^)
adding syntax to support new features always causes problems (python .. ^cough^)
This reminds me of my favorite host, LuaDNS.com. Always willing to extend their services, and have never had a problem with them.
Also more expensive than LuaDNS, and the configuration is far more terse than what is provided. I'm not from LuaDNS, but I'll admit I'm a huge fan.
Also more expensive than LuaDNS, and the configuration is far more terse than what is provided. I'm not from LuaDNS, but I'll admit I'm a huge fan.
[deleted]
I'm a fan of Lua, and I like the LuaDNS implementation too.
I almost didn't build this, but I think there is room for more. Certainly Amazons DNS service is hard to beat..
I almost didn't build this, but I think there is room for more. Certainly Amazons DNS service is hard to beat..
I actually created something similar to this long ago (Jan 2013).
https://github.com/silasb/luvdns
That holds the Lua program to parse my domains [1] and also holds a Sinatra application that gets a post commit hook from GH and then it was as simple as updating the database that PowerDNS looked at. I don't think I ever ended up fully using it.
[1]: https://github.com/silasb/domains
https://github.com/silasb/luvdns
That holds the Lua program to parse my domains [1] and also holds a Sinatra application that gets a post commit hook from GH and then it was as simple as updating the database that PowerDNS looked at. I don't think I ever ended up fully using it.
[1]: https://github.com/silasb/domains
I currently have a Git-based DNS setup and can highly recommend the workflow. Having a history, review and team-visibility goes a surprisingly long way.
It's a little more duct-taped together than this (a Jenkins job that rsyncs to https://www.bytemark.co.uk/support/technical_documents/dnsc)
It's a little more duct-taped together than this (a Jenkins job that rsyncs to https://www.bytemark.co.uk/support/technical_documents/dnsc)
You might imagine I'm familiar with the Bytemark system.
My own records hosted there are also under revision control.
My own records hosted there are also under revision control.
I don't see a way to add txt records, which are important for many things. Nor do I see srv records or others.
The documentation also doesn't make it clear because it links TinyDNS format, but says you're using a simplified version without mentioning any real details.
Are there any plans to support / document these other record types?
The documentation also doesn't make it clear because it links TinyDNS format, but says you're using a simplified version without mentioning any real details.
Are there any plans to support / document these other record types?
By simplified I mean that we don't support TXT, SRV, NS, or SOA records.
The missing record-types are highlighted as a concern, and it should be possible for me to add them quickly.
I've launched now mostly to see if there is a demand for this middle-ware - rather than having people jump-ship immediately to Amazon. (Plus I find the idea of Git being used neat.)
So, in conclusion yes missing SRV, missing TXT, and they will come.
The missing record-types are highlighted as a concern, and it should be possible for me to add them quickly.
I've launched now mostly to see if there is a demand for this middle-ware - rather than having people jump-ship immediately to Amazon. (Plus I find the idea of Git being used neat.)
So, in conclusion yes missing SRV, missing TXT, and they will come.
TXT records are now supported, FWIW.
The traffic killed the server - I'm rebuilding it now with decent RAM, back in 20 minutes..
I have to admit I giggled
http://i.imgur.com/H9dBG09.png
Hope the rebuild goes well.
http://i.imgur.com/H9dBG09.png
Hope the rebuild goes well.
Out of curiosity, what are the specs of the server, and how much RAM is "decent"?
Previously it was running a reasonably heavyweight Perl/CGI front-end on 512Mb RAM.
It's now setting with 4Gb of RAM, and a load of ~40.
The single biggest issue is that the front-page either shows "marketing" or "your details", so it is dynamic and being generated on-demand.
I'll update to cache.
It's now setting with 4Gb of RAM, and a load of ~40.
The single biggest issue is that the front-page either shows "marketing" or "your details", so it is dynamic and being generated on-demand.
I'll update to cache.
Perl/CGI is never a good thing.
You might get better response with using perl in fastcgi mode, and using nginx rather than apache.
You might get better response with using perl in fastcgi mode, and using nginx rather than apache.
Why not just slap Varnish in front of that and be done?
That would be the end goal - but since all users get cookies there's not obvious "I'm anonymous" vs "I'm a signed-in-user" differentiator I can use to control whether to cache or serve live.
It'll happen, shortly, but the fastest solution was to re-deploy on a scaling platform.
It'll happen, shortly, but the fastest solution was to re-deploy on a scaling platform.
This requires putting your whole zone file in public, right? Seems like that might not always be a good thing for some but maybe better for others.
Any plans to support something other than Github. Trying to move away from there.
Any plans to support something other than Github. Trying to move away from there.
I'm happy to support anything that will allow a WebHook to be invoked on a push event. I'm certainly intending to look at GitBucket, and similar.
Handling private repositories is a pain (at least with GitHub) because my key would need to be added to allow a clone/update. If there's a way round that, perhaps via applying patches on demand, I've not come across it.
As you say hosting DNS records publicly might be a concern for some. I don't really see a way round it, and I'd guess that by and large people consider DNS-data public, by definition ..
Handling private repositories is a pain (at least with GitHub) because my key would need to be added to allow a clone/update. If there's a way round that, perhaps via applying patches on demand, I've not come across it.
As you say hosting DNS records publicly might be a concern for some. I don't really see a way round it, and I'd guess that by and large people consider DNS-data public, by definition ..
You could also just use https://api.luadns.com/ which at least offers a free tier.
1) On April 19th, Steve wrote this blog post mentioning us, Namecast: http://blog.steve.org.uk/i_was_beaten_to_the_punch__but_felt...
2) At around the same time Steve sent me a personal email doing market research on the concept of Git-backed DNS. I didn't respond because, well, it was a bit of a clunky first way to ping someone. Still no problem, though - who hasn't sent a random stranger an awkward email before, right?
3) He then decided to build a competing product - and steal our messaging?! Seriously, go to http://www.namecast.net right now, check out our above the fold copy, and then check out dns-api.com. "Imagine if updating your DNS records was as easy as running "git push"." Really, Steve? Really?
This is where things go in my mind from "hey, two DNS guys had the same idea about Git and DNS, neat!" to "this dude can't create his own ideas so has decided to steal our copy and cargo cult copy our product."
Luckily Steve isn't very good at DNS or handling traffic, so his servers have fallen down and people are complaining about his feature set, so instead of complaining too hard:
For those of you who want a provider who's site won't fall over after a tiny crush of HN traffic, check out http://www.namecast.net.
We've also got working SRV, TXT and alias records - some of you have noticed dns-api.com doesn't - as well as geoIP and native IPv6 amongst other things, and as good members of the open source community, we're contributors to the open source geodns project (written in Go by Ask Bjorn Hansen, it powers the global NTP pool - so if you've got software that talks to pool.ntp.org, like say, ntpdate, it's talking to a server running geodns.)
mic drop
--afsheenb