The Lua-code doesn't appear to be executed once for each lookup - as I first imagined how it would work. So sadly, one cannot point different region users to the closest server IP.
After reading the title I was a little surprised when I skimmed the documentation. It seems like a better title would be:
"Luadns, managed DNS with Git and Lua scriptable front-end"
It seems like tinydns is your back-end. Which in my opinion is nothing to be ashamed of. When I thought the service was a new dns server written in Lua I was less intrigued. There are a ton of pitfalls when writing your own dns daemon, tinydns is a good choice.
What are you going to do when dnssec becomes a requirement?
We are trying to avoid reinventing the wheel. :) TinyDNS served me well more than 10 years, I like the design of this piece of software ( although it needs 2 pairs of glasses to read it :) ), so it was a natural choice.
To provide IPv6 and DNSSEC support we'll provide another set of name servers with NSD/PowerDNS as we designed Luadns with flexibility in mind (it's already 100% compatible with PowerDNS).
I was a happy user of a free DNS hosting service for many years, when this service was acquired by a competitor in august 2011, I was forced to move somewhere else.
While migrating my zone files I realized that I don't like Bind syntax files neither administering tens of domains through a web interface. I've started to experiment on how it should look a perfect DNS service for me. I've realized that I would love to store my configuration files in a Git repository and I would need some configuration language for templating (Lua).
This is how Luadns was born on October, 2011.
I don't know if this is an after the fact explanation, but either way it's a very good story about scratching your own itch.
By the way, they had me at I would love to store my configuration files in a Git repository. As soon as I have a use for this in a new project, I'll be their user. The examples are pretty cool too.
The dates line up. August 2011 was when Dyn bought EveryDNS and fucked everyone.
I have been helping people move off the Dyn platform and encouraging the development of efforts like this (both technically and financially) ever since.
How has curvedns been for you? I need DNSCurve for a research project of mine but I'm very frightened to see that curvedns is the only forwarding implementation and gdnsd is the only authoritative implementation. Speaking of implementations, what the heck do you use for a client/resolver!?
That's the chicken/egg problem. The only real clients I've seen right now are the python testing implementation, OpenDNS's servers, and the DNSCrypt implementation that OpenDNS released: http://www.opendns.com/technology/dnscrypt/
Looking at one of my CurveDNS logs for the last few days and doing some very basic math:
$ grep "query too small to be DNSCurve packet" *.s | wc -l
27539
$ grep "DNSCurve shared secret" *.s | wc -l
2282
2282/29821 = .07652
So about 7.6% of all DNS queries are being answered via DNSCurve. Doing reverse IP lookups on the querying servers, nearly all of these requests are coming from OpenDNS.
btw, gdnsd dropped DNSCurve support in recent builds, so it's only curvedns now.
Your pricing page "Sign Up" buttons should go to a sign up screen not a sign in screen.
On sign up you should collect credit card information. You will get less sign ups but more revenue, and you won't have to shut off free people if they go over their query quota. Auto upgrade if they do? Send an e-mail saying they are close to meeting their query quota and that they will be auto upgraded if they do?
After sign up you should display a message saying for them to open their e-mail client and click the confirm e-mail - not just a login screen.
Kill the $39 price point. Just have $9, $27, $69 and then below those three have the free option, and explain if they go over their quota they will be upgraded (thus requiring cc information on their account).
Indeed, free users are notified to upgrade their account upon hitting quota.
We are not collecting CC information as we chose Avangate to process our orders. Dealing with CC it's a big hassle, we wanted to allocate more time for the service itself, maybe in the future it will make more sense.
Any chance of you guys allowing AXFR transfers? I really like the ideas behind the service, however, I have reservations about moving production DNS given your relatively young age. Being able to have secondary DNS elsewhere eliminates the risk of switching over but maintains all the upside of your excellent interface.
AXFR support it's on our priority list, we'll release an update soon. Please, subscribe to our Twitter feed or Blog's RSS feed and we'll make an announcement when it's ready.
Yes, it's a young service, we have launched on February 10 (in production since December 15) and we are aware of great responsibility involved by this service.
We took many measures to ensure quality of this service. All servers and services are monitored with Nagios and we are notified by email and SMS. We are adepts of test-driven development, so everything it's tested before released in production.