- If you don't have a very well defined need for a short DNS time to live, set your time to live to a large value, perhaps a day. Then, as long as someone can get at least one DNS request through, they can reach your site all day. (Ycombinator.com, why do you have a TTL of 12 seconds?.)
- Get multiple DNS services now. Not just two. Get four or five, some of which are not widely used.
Those two things will probably get you through future DNS attacks.
You either meant to say 60 seconds, or forgot to factor your local caching DNS resolver in. Here:
$ dig +short soa ycombinator.com
ns-225.awsdns-28.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
$ dig a ycombinator.com @ns-225.awsdns-28.com. | grep -A3 'ANSWER SECTION'
;; ANSWER SECTION:
ycombinator.com. 60 IN A 54.240.184.14
ycombinator.com. 60 IN A 54.240.184.154
ycombinator.com. 60 IN A 54.240.184.206
No they don't. CDNs with the exception of AWS Cloudfront don't run on a cloud provider. Things aren't quickly spun up and down with any kind of velocity. CDNs manage all of their own infrastructure, POPs, hardware etc. There is usually a maximal hardware lifecycle since the CDN business is so CapEx heavy.
Cache-Control TTLs and DNS SOA record TTLs have nothing to do with each other. They are separate layer 7 concerns. The former is used by your browser and the latter by your system's resolver library.
I have never heard of anybody using SOA TTLs records to purge a cache. How would that even work?
CDNs generally give you decent tools to purge your objects.
Source: I worked for a CDN.
Why is this not a default feature by DNS providers themselves?
I always assumed they act as slave copies for each other to avoid this kind of situations
The only problem is this seems be a tough one to get right config-wise and I just haven't had time to figure it out.
Anybody know of any good tutorials for this specific use case? I've googled it a few times and they never seem too easy.
While it's not exactly what you're looking for, you could use dnsmasq, you could use the "--min-cache-ttl" option to increase the TTL: but only up to an hour. You can patch the source to increase this time to suit your needs.
To exactly match your use-case dsnmasq would need to have a regular cache that respects upstream TTLs and a last-resort cache that doesn't.
If you set a long DNS TTL, then you will not be able to move your IP addresses quick enough. In the DDoS world, you may need to nullroute an HTTP server IP. If you do that, you assume you can point the DNS to another, not-nulled IP. For this reason, keeping the DNS TTL to low values will make you more resilient.
Multiple DNS providers is probably a good advice, although hard to do in practice. The api's of different vendors don't always match. (cname flattening? geo-routing?). Also a real big attack will just likely take down all your providers. Using multiple providers may well _decrease_ the stability of the internet at large.
DDoS against DNS is not trivial problem. As sad as it may be, I'd say we must just assume DNS infrastructure in the world works. If it stops, then, many users will be affected.
Is this as simple as setting up the same records on multiple providers and updating your nameservers to point to the different providers? Or is there more involved?
Are there any providers which will replicate records from your 'master' provider, or is this going to be manual?
But I guess this excludes many of the popular DNS services that are used today.
You just need a primary DNS vendor which supports AXFR, such as DNS Park (https://www.dnspark.com/).
IIRC, bind has multiple built-in methods of keeping zone files synchronised between boxes.
- Put up a caching DNS server on your local network to keep your regular sites functioning.