Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I also run my own domain name servers. I use PowerDNS with a MySQL backend; setting up replication between the two MySQL servers wasn't too hard, which gives me redundant name servers in two data centers. I have a few more than 32 zones, but the name services stuff has almost zero impact on server resources.

Updating and querying the name records is a piece of cake thanks to the MySQL database, and if I ever get around to finishing it, I can have my own web-based front-end for it.

Best of all, I can have a nice, short ttl on all of my entries, and PowerDNS is configured to always check the database, so I have a two minute refresh period on any changes made to entries on my name servers -- that alone has been well worth running my own. (Client: "Don't I have to wait like a few hours or a day or something for this to spread over the internet or something?" "Nope. 'Bout two minutes in most cases, little bit more for AT&T's customers.")

I definitely didn't do it right the first time, though. DNS has a few gotchas, like making sure you disable axfr requests, making sure you have an SOA record for appropriate zones, and so on. I'm probably still doing something wrong, but I don't know what it is at this point. Also, the default recommended PowerDNS MySQL setup is needlessly complex, as far as I can tell.



I don't understand why you use short TTLs. Do you care that every visitor has to wait an extra 100ms or so to see the page they came for? I personally want all my DNS records at the ISP.

Sure, Google can get away with a 600 second TTL because there is so much traffic that only one person in a million will have to wait.


I already explained why I use short TTLs. Let me try putting it another way: because it solves more problems than it creates. That's the same yardstick I use for all my infrastructure decisions, because sure 'nuff, no matter what I decide, someone is going to think it was the wrong decision and that I should care about their personal opinion.

Do I care that every visitor has to wait a little bit more every few pages or so? Yes, of course I do. But you fail to understand our business or customers at all when you think that a delay caused by a short ttl in dns is a problem that we need to address right now.

A much bigger problem for our customers is when they call or email and ask for help with some kind of hosting change -- moving onto or off of our servers or changing some service or some such thing -- and they get told that there will be a period of minutes or hours or maybe even a day or two where visitors will see either the new version or the old version and no, we can't say which.

When we tell people that, yes, we can change their mail services for them, and by the way, that change should be instantaneous for most people, they are delighted. And delighting our customers is what's most important to us.

Further, you fail to realize that most of our hosting customers are coming from services like BlueHost or GoDaddy, where their sites have probably been living on overprovisioned servers and so they get better performance with us anyway, which also delights them.

You also don't realize that our average customer, so far, is running a poorly optimized WordPress or Joomla installation, and that either of those systems introduces page delays that are far more severe than a DNS lookup. In other words, our customers are not currently people that are looking for the fastest possible website; they merely want it to be "fast" -- which usually means, "renders in about a second or less on my crappy 1.5Mb DSL" -- but mostly, they want it to always be up and they never want to worry about backups or hackers or phishing or viruses or anything else.

So, yeah, once short ttls start to cause problems -- a la an email from a customer saying, "hey, I just profiled my site, and I noticed it's taking an extra 132 ms to load because of a dns lookup, can you check into that" (a message which we haven't even come close to receiving yet) -- then that'll become a bigger issue and I'll address that instead of whatever else I'm working on at the time.

I know I shouldn't get irritated at comments like yours -- I should simply ignore them -- but they bug the hell out of me because you probably don't even realize what the effect is. You're not sharing helpful information; you're not telling me something about short ttls that I didn't already know; you're not telling me about some bug in PowerDNS caused by ttls less than 194 or that ttls less than 233 can cause issues with MySQL if you have more than pi requests/second. The only thing that comments like this do is further demotivate me from sharing information like this in the future. My thought process before commenting in a thread about server configuration is already something like, "Hey, should I bother to mention how we do this? It was a bit fiddly and there's some bad documentation out there. Someone might ask a question that I could answer. Someone might mention something I don't know about. That could be good. But probably someone's just going to tell me I'm wrong. Am I in the mood for that? Nah, not really."

Sorry for slamming you with a wall-o-text response. I had thought about the last time KeepAlive was mentioned in an HN thread before posting my comment about PowerDNS; you just happened to make me feel like an idiot for not listening to my instincts and deciding to not comment in this thread.


Don't be so sensitive. Even if jcampbell1's question is addressed to you, it's on a public comment thread so it's really aimed at a wider audience. What his question (and your response) does is point out that there's a tradeoff involved here - which of course you know, but not everyone reading might. Think of yourself as a participant in a Socratic dialogue.


I apologize for my comment. I'd have been more civil in person and certainly if I had bothered to look at how open you are in your profile.

I come from a different background. I bootstrapped a SaaS business that now has about 10 employees. I spent a bunch of time thinking about the best DNS solution for us. My conclusion was that we should go with the most expensive provider coupled with long TTLs. The most expensive provider was because of SEO reasons, and long TTLs are best for PPC conversion rates.


It's not so much wrong or right, but you should be aware of the trade-off you're making. It's either the instant gratification of getting your DNS updates propagated swiftly, or the longer term benefit of faster page loads and generating less DNS requests. Whatever your preferences are, objectively there are most certainly going to be much more page loads vs. DNS updates (which should be rare; not counting dynamic IPs which are a special case of course). I realize your users might not understand and just like the quick DNS options, but I think people should have a say over this trade-off, at least as a multiple choice question.


Well, I for one certainly value your comments in here. I think I might just go adjust my TTLs to very low, just for spite.


Great response. Please keep posting.


Please don't refrain yourself of posting things like this because jerks poninted their snarky guns at you, just ignore them.

By doing that you achieve two great things. First, you help people who genuinely need your caring comments on real world experience. Secondly, you don't feed attention whores.

Great post by the way. You saved me weeks of hair pulling by showing that once you achieve the right mindset this problem, like any other, can be realistically managed.

Finally, have happy new year!


I use PowerDNS too, but with BIND flat files as a backend. Setting up replication is even easier than MySQL: I just rsync the flat files from a central server to my 2 DNS servers whenever I make changes. PowerDNS automatically reloads the files based on their mtime.


Yeah, I'd considered that, and there are some serious advantages to flat files. To be honest, relying on MySQL for production anything makes me nervous. But: SQL queries occasionally save my butt when needing to make lots of changes all at once, instead of having to figure out sed again or edit lots of files; and, I wanted something that would sync automatically, since I'm an idiot and sometimes forget to do something like an rsync command after a change.


"and if I ever get around to finishing it, I can have my own web-based front-end for it."

If you finish it let me know. I would be interested in possibly buying the front end from you (even if it's rough wouldn't be customer facing.)


There's several existing MySQL management solutions for powerDNS, including: https://www.poweradmin.org/trac/ https://github.com/averna-syd/PowerdnsTango

PowerDNS Tango is the prettiest looking one.


Looking at the featureset of these frontends, my own implementation pales in comparison. It would need a lot of work before matching the features these offer.


I've rolled my own very basic PHP frontend to my own SQLite-backended self-hosted PowerDNS setup. If there is serious interest, I might just throw it up on Gitorious or Github as I've always intended.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: