Luadns, managed DNS with Git and Lua scriptable back-end.

http://www.luadns.com/

by sramov • 14 years ago

53 22 14 years ago

relix• 14 years ago

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.

vitalie7• 14 years ago

Hello,

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.

reginaldo2• 14 years ago

Do wildcard records work?

reginaldo2• 14 years ago

History: (from http://www.luadns.com/about.html)

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.

dsl• 14 years ago

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.

dfc3• 14 years ago

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?

vitalie7• 14 years ago

Thank you for your suggestions!

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).

dfc3• 14 years ago

That's awesome. Do you mention that on your site? I don't remeber seeing it but I might have not looked for ipv6/dnssec after seeing tinydns.

Knowing the path forward includes ipv6/dnssec definitely makes me more willing to signup...

jbarham• 14 years ago

Who can make DNSSEC a requirement? How will it be enforced?

dfc3• 14 years ago

Any customer can make DNSSEC a requirement for adoption. Bob or Alice simply choose a different provider to enforce their requirement.

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.

zdw2• 14 years ago

Will you support DNSCurve? It would be nice to get more people on that particular bandwagon.

I set up a git/rake/djbdns/curvedns setup in an afternoon with a few VPS's, which has been quite solid for me.

sigil• 14 years ago

If you took notes on your setup I'd be very interested.

jevinskie• 14 years ago

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!?

zdw2• 14 years ago

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.

vitalie7• 14 years ago

At this moment we have no plans to adopt DNSCurve, but if we'll see more and more demands we may change our plans accordingly.

chrishas352• 14 years ago

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.

vitalie7• 14 years ago

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.

chrishas352• 14 years ago

Thanks for the reply. I look forward to switching over as soon as you are able to implement AXFR.

Pkeod• 14 years ago

My humble suggestions:

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).

vitalie7• 14 years ago

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.

Thank you for your suggestions!

Luadns, managed DNS with Git and Lua scriptable back-end.

Related Stories