CoreDNS, a DNS server that started its life as a fork of the Caddy webserver, chains middleware in a way that each middleware implements some DNS features. It’s the project of Miek Gieben, who also wrote a book on the programming language Go.
The project — CoreDNS-002 was just released — actually began with Gieben’s involvement with SkyDNS, a DNS service that returned location information on services. He says he built SkyDNS version 2 to be a thin DNS layer built on top of the distributed key-value store etcd, and despite its popularity, it became obvious it was reaching its limits. Something had to be done with its internal architecture, but he didn’t know what.
After becoming frustrated with the Automatic Certificate Management Environment (ACME) client in the Linux Foundation’s Let’s Encrypt certificates for his websites, he found Caddy, which he though could be a good approach to building a server.
“Each ‘thing’ it did was contained in a middleware that you could chain together, for instance, zipping a web page was just a matter of calling the zip middleware after you found a page on disk. It’s very Unix-like,” Gieben explained.
“This got me thinking again about SkyDNS2 again. Maybe I could use this middleware approach to make SkyDNS layered as well. So I forked Caddy and basically replaced all occurrences of ‘http’ with ‘dns.’”
Unlike competitors tied to a single back end, CoreDNS can use any back end as long as there is a middleware that lets it connect, Gieben said.
Intel’s Nick Weaver Discusses Orchestration
Listen to all TNS podcasts on Simplecast.
CoreDNS can be used for tasks such as serving from files instead of etcd, proxying requests, rewriting requests, doing health checks on endpoints, and publishing metrics into Prometheus.
Network intelligence vendor Infoblox is helping with Kubernetes integration and he has other individual contributors to what is a side project for Gieben.
In a Kubernetes blog post on supporting standard interfaces, Google’s Brian Grant and former Googler Craig McLuckie mention CoreDNS among cloud-native DNS implementations showing promise.
On the DNS level there is no difference between “cloud” DNS and “regular” DNS, Gieben said.
“It mostly boils down to cloud DNS being more dynamic in nature, meaning a dynamic backend, like a database or key-value store, like etcd where a client can store discovery information that will then be disseminated by CoreDNS. The lifetimes (TTLs) for this info is usually very short, measured in seconds as opposed to regular DNS where these TTL values can be days or weeks,” he explained.
Another thing is that “regular” DNS mostly deals with IP addresses — A (IPv4) and AAAA (IPv6 ) records — and “cloud” DNS uses SRV records that have both an address and port number.
SkyDNS, which is still under development and very stable, remains one of its competitors, as are the likes of Consul, Mesos-DNS and others.
Why would someone use CoreDNS over built-in DNS services, such as a combination of kube-dns and SkyDNS for Kubernetes, for instance (A question poised on a recent Hacker News discussion about CoreDNS).
For one, kube-dns is more complex to deploy and maintain, especially for tasks such as service discovery. That software uses dnsmasq for caching answers because SkyDNS has limited support for caching. CoreDNS, in contrast, simply has caching as a middleware, so you can drop the dnsmasq dependency.
Why not DNS itself, which, for all its faults, has served the Internet for decades.
“There will always be a category of application for which you can’t do this,” Gieben said, by email. “But you’re right. Currently, the DNS is (ab)used for service discovery, and it might be time to think about a better service discovery protocol — maybe with push notifications? Something DNS lacks. On the other hand, by just using something as old as DNS, you are guaranteed that your software stacks support it.”
Gieben said a short-term goal is to be able to replace kube-dns, which is based on SkyDNS2, in Kubernetes. “We are working hard to implement all features needed for that,” he said.
After that he wants to focus on making DNSSEC (Domain Name System Security Extensions), a DNS extension for security, as easy as possible with automatic key rollovers and key uploads to registrars, as well as making it a solid and fast DNS server with DNS firewalling, DNS routing and query mirroring.
“I’m also hoping people will submit entire middlewares that implement cool stuff I hadn’t thought about,” he said.
Feature Image: “Discovery Cove” by Carter Brown, licensed under CC BY-SA 2.0.