Hacker News Reader

Comment by druiid | Hacker News Reader

You'd think that it would be a good idea... until someone decides YOU are going to be the target of a DDoS attack. I speak from experience. I have many (at least 15) years of experience dealing with DNS and hosting of it, yet when a bot-net decided to attempt to use our DNS servers for a reflection attack. Obviously the servers were setup to not allow this, but the sheer volume of the traffic making attempts was still enough to saturate the connection with our provider at the time.

This is only one of many possible scenarios with self-hosted DNS. Essentially there are services out there (generally Anycast are best) that do only DNS and have had very high up-time. I'd suggest if you are anything over a 'small' target to look into these services. Sadly it's one of the few things I basically suggest not self-hosting at this point simply due to the unrealistic requirements to scale it yourself under attack scenarios.

View on HN

To Rhizomes point: Yes, it's relatively easy to re-point them to somewhere else.. and if your business can tolerate the interruption that's fine.

Those changes, though, take time to cache out, and depending on your registrar's procedures and whatnot, you could be looking at hours or a couple of days to get things to stabilize back to normal; not to mention finding a new provider and getting things set up. You'll need ot make sure you have the zone data on hand ready to get set up with a new provider, and so on. You could have a procedure in place to do this, sure, with everything tested and validated, but at that point it's much easier to just have a DNS provider of the proper class who can handle these things for you. And keep in mind, if it's your domain they are trying to shut down, and not your DNS provider specifically, the attack will very likely just follow the change, leaving you in quite a mess.

So the short answer: self-host if it's not revenue impacting. If there is money at stake, spend a little bit for a top-notch provider.

This has been my experience as well. Stupid bots being denied recursive requests. I modified my fail2ban script to autoban them which helped considerably.

Well, fail2ban can help, but that is only going to be generally quick enough to keep up with the initial ramp-up of the attack I'd expect. Once the full attack gets going you're probably going to be seeing requests from thousands of hosts at any given time. I haven't specifically tested under that scenario with fail2ban, but I imagine that it would have trouble keeping up with such a flow.

My experience was that fail2ban mitigated it pretty much completely for my small server (which no doubt was only allocated a small number of bots to be attacked with). It took about an hour to build up a list of about 16,000 machines and then basically things were fine again.

This DDoS argument really is a premature optimization, and it's very simple to implement an external primary/secondary if the problem ever does occur.

Read comment up-stream. I disagree with this standpoint and I'm sure can find you stories out there beyond mine to back up what I'm suggesting. DNS hosting as well is so inexpensive unless you're in the hundreds of millions of queries that really I see no reason to not look to hosted DNS solutions first. Even one of the premier DNS providers out there is only like $29 for a small-business plan.

Essentially, unless your website is not revenue generating (or is below the cost to make this feasible), you really should look at moving from self-hosted DNS.

It is simple, but it has mixed results.

There's about 10% of the internet that's using "parent centric" DNS resolvers. What that means is that when it comes to what name-servers to query for a zone; those resolvers pay more attention to what's in the parent-zone than what the child-zone lists for itself.

For that 10% of the internet; the TTL on the NS record set is out of your control - it's whatever the parent domain's policy is. Although you may have set a TTL of an hour - for nimble re-delegations on your end, you'll have to wait out the time-to-update from your registrar (usually an hour, but sometimes a business day or more, depending on the TLD) and then also update the TTL on their end. For most domains, like com and net, it's two days.

So if you need to add name-servers after a problem starts, expect it to take two+ days to fully roll out to all users.

That said, the progress follows a distribution, and you'll remediate things for many users quite sooner - but still probably not within an an availability target of even three nines per month.

Reply on news.ycombinator.com