CoreDNS: DNS service discovery for the cloud | Hacker News Reader

CoreDNS: DNS service discovery for the cloud

coredns.io

58 pointspjf21 comments

CoreDNS is very cool. You can try it without any downloads or configuration using a Katacoda interactive scenario at https://katacoda.com/courses/coredns/dns-responder

I don't know why they don't mention this on the site, but this has been merged back in as a module for Caddy (available at download time).

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?

Cool.

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.

Go to HashiCorp's documentation for fantastic examples of comparing software to others in the same space. Here is their "Vs" section for Consul:

https://www.consul.io/intro/vs/index.html

Is this related to DNS service discovery (DNS-SD, RFC6763), or is it just a very poor choice of words?

DND-SD is, and I'm a DNS guy, just a overly broad name for a RFC. They laid claim to all use of DNS for service discovery with that name.

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!

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?

Does it support rate limiting? This is needed in order not to be used as a DDoS amplifier.

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.

You haven't convinced me that rate limiting is pointless.

It does nothing to stop real attacks.

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.

The new middleware "firewall" in under development.

What's the basic difference between coredns and classic bind based dns??

In a cloud world, moving host resolution into the app makes the most sense and isn't that hard.

Why use dns at all?

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?

This is really cool! It's easy to develop new middleware.

Reply on news.ycombinator.com