Rate limiting is relatively pointless. Attacks are just spread out over enough DNS servers so the rate limit isn't exceeded on any of them.
Even without rate limiting attackers will spread it out because too much traffic coming from one DNS server can be easily blocked at the network level.
DNS RRL is massively effective, what makes you think it isn't?
Many DDoS attacks will send a significant number of queries through any given DNS server to get a decent amplification. While normal clients will send 1 per TTL period. Yes, you can add servers at will, bit if everyone has RRL, your amplification factor is nearing zero.
No it's not. You're fundamentally misunderstanding amplification attacks if you think RRL brings down the amplification factor.
The amplification factor is the ratio of the response size to a single packet. Not the number of packets you can send to a server.
The only thing the RRL helps with is forcing the attacker to spread packets over more DNS servers, but, as I pointed out, a good amplification attack already does this because it makes it harder for the victim to block DNS servers by IP.
The attacker isn't going to run out of DNS servers because there are hundreds of thousands authoritative ones, let alone open resolvers.
It would be great if the site explained why it is different to the alternatives. If I was using Kubernetes for instances, why would I swap out the default service discovery mechanism for this one?
Indeed! It's a delicate balance between being informative and talking down the competition, but I wish more projects did this.
K8S uses SkyDNS and CoreDNS says it's a full replacement for sky just with more features. From quick eyeballing of the site, these new features include: serving from files instead of etcd, proxying requests, rewriting requests, doing healthchecks on endpoints, and publishing metrics into Prometheus.
This looks very interesting. Does anyone know if it supports a split horizon DNS setup?
I can't find anything specific in the site nor in the docs, but maybe some of the mentioned features can achieve this?
I assume this uses the crypto libs in the Go standard lib to do the SEC part of DNSSEC. It used to be that the Go authors urged caution when using those libs because they were relatively new and unaudited. Has that changed? Are they recommended for use in production for security critical apps?
Same could be said for any number of protocols. DNS itself laid claim to all use of a system for doing things with domain names. TCP laid claim to all use of a protocol to control transmissions of any sort. ND laid claim to all protocols that could be used to discover your neighbours. And don't even get me started on ICMP!
Maybe because when the host resolution is built into the app it needs to be externally provisioned less it becomes out of date as services come and go. So if you're going to need some centralized mechanism to provision apps, why deal with that overhead and just bake it into DNS directly?
21 comments
[ 2.7 ms ] story [ 53.8 ms ] threadEven without rate limiting attackers will spread it out because too much traffic coming from one DNS server can be easily blocked at the network level.
Many DDoS attacks will send a significant number of queries through any given DNS server to get a decent amplification. While normal clients will send 1 per TTL period. Yes, you can add servers at will, bit if everyone has RRL, your amplification factor is nearing zero.
The amplification factor is the ratio of the response size to a single packet. Not the number of packets you can send to a server.
The only thing the RRL helps with is forcing the attacker to spread packets over more DNS servers, but, as I pointed out, a good amplification attack already does this because it makes it harder for the victim to block DNS servers by IP.
The attacker isn't going to run out of DNS servers because there are hundreds of thousands authoritative ones, let alone open resolvers.
It would be great if the site explained why it is different to the alternatives. If I was using Kubernetes for instances, why would I swap out the default service discovery mechanism for this one?
K8S uses SkyDNS and CoreDNS says it's a full replacement for sky just with more features. From quick eyeballing of the site, these new features include: serving from files instead of etcd, proxying requests, rewriting requests, doing healthchecks on endpoints, and publishing metrics into Prometheus.
https://www.consul.io/intro/vs/index.html
Why use dns at all?