I'm Vitalie Cherpec, the founder of the Luadns project. :)
@relix It's a design choice, Lua code is used only to generate records. Executing user code on each lookup it's just too dangerous.
We wanted fast lookups and security. User code is executed in a restricted Lua environment in background.
If we'll have enough requests we'll add special functions to handle geo-aware DNS load balancing.
"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).
Knowing the path forward includes ipv6/dnssec definitely makes me more willing to signup...
From a post downthread it is clear that the luadns team is well aware of how they will move forward in light of the tinydns feature set.
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.
I have been helping people move off the Dyn platform and encouraging the development of efforts like this (both technically and financially) ever since.
I set up a git/rake/djbdns/curvedns setup in an afternoon with a few VPS's, which has been quite solid for me.
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
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).
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.
Thank you for your suggestions!
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.