CoreDNS - The DNS Server That Doesn't Suck

DNS servers used to be simple. Then containers happened and everything got complicated. CoreDNS replaced kube-dns because kube-dns was a hot mess of three different containers that barely worked together. CoreDNS does the same job with one binary that doesn't randomly break when Kubernetes updates.

Why Everything is a Plugin

BIND is a monolithic beast from the 1980s that does everything and nothing well. CoreDNS said "fuck that" and made everything a plugin. Want DNS serving? Use the file plugin. Need Kubernetes integration? There's the kubernetes plugin. Want caching? Enable cache. The best part? Plugin order matters and if you get it wrong, nothing works and the error messages are about as helpful as a chocolate teapot.

Here's what'll fuck you over: plugins execute in a specific order defined at compile time, not in your config file. So even if you put cache at the end of your Corefile, it might run first. Check the plugin.cfg file to see the actual order, or you'll be debugging DNS issues at 3am wondering why your cache isn't working.

Why Go Actually Matters

CoreDNS is written in Go, which means it's actually good at handling thousands of concurrent connections without shitting itself. The Docker images are tiny compared to BIND's bloated containers.

Performance depends heavily on which plugins you enable and how you configure them. The moment you add too many plugins or misconfigure caching, performance goes to hell just like any other DNS server.

How CoreDNS Fixed Kubernetes DNS

CoreDNS became the default DNS server for Kubernetes in v1.11 because kube-dns was an absolute nightmare to debug. Three separate containers (kubedns, dnsmasq, and sidecar) that had to talk to each other? What genius thought that was a good idea?

CoreDNS fixed this clusterfuck by being one binary with the kubernetes plugin that actually works. It reads from the API server and creates DNS records for your services and pods automatically. The Corefile configuration is way cleaner than whatever kube-dns was using.

But here's where it gets tricky: if you need custom domains or stub zones, you have to edit the CoreDNS ConfigMap in kube-system namespace. And if you screw up the syntax, DNS breaks for your entire cluster. Pro tip: always test your Corefile changes in a dev cluster first, because I learned this the hard way when I took down production DNS for... I think it was around 2 hours? Maybe closer to 3. Time moves slowly when your phone won't stop ringing.

Protocol Support That Actually Works

CoreDNS supports DNS over UDP/TCP (obviously), DNS over TLS, and DNS over gRPC. DNS over HTTPS is trickier - you need to set up an external proxy because CoreDNS doesn't handle HTTPS directly in the current version.

The forward plugin is where CoreDNS shines for upstream queries. It can load balance between multiple upstream servers, health check them, and fail over when one goes down. This actually works pretty well, unlike some DNS servers where failover takes forever or doesn't work at all.

Configuration Simplicity

The Corefile syntax is way simpler than BIND's clusterfuck of a config format. Here's a basic zone:

example.org {
    file db.example.org
    log
    errors
}

This actually makes sense compared to BIND's named.conf which looks like it was designed by someone who hates humans. The best part? Hot reload actually works with kill -SIGUSR1 or the reload plugin, though sometimes you just have to restart the damn thing anyway when configs get complex.

Word of warning: indentation matters in Corefiles, and if you mix tabs and spaces, CoreDNS will silently ignore your config and you'll be wondering why your changes aren't working. Ask me how I know - spent what felt like half my weekend debugging a "working" config that was being completely ignored because of a single fucking tab character somewhere. Pretty sure it was v1.11.1 that had this really fun bug where it would just silently fail on mixed indentation, but honestly all the CoreDNS versions blur together when you're debugging at 2am.

So you want to deploy CoreDNS? Good luck. It's easier than BIND but that's like saying getting punched in the face is better than getting kicked in the nuts. Both suck, but one sucks less.

Installation and Basic Configuration

Download the binary from GitHub or use Docker. The binary works fine for testing, but you'll want containers for production unless you enjoy dependency hell.

Here's a basic Corefile that works on my Ubuntu 22.04 box (your mileage may vary):

.:53 {
    forward . 8.8.8.8 9.9.9.9
    cache 30
    log
    errors
}

This forwards DNS queries to Google and Quad9 with 30-second caching. The errors plugin logs failures while log plugin shows you what's hitting your server. Start simple or you'll be debugging plugin interactions until you hate your life choices.

Pro tip: Always enable the errors plugin first. CoreDNS failing silently is worse than getting spammed with error logs.

Kubernetes Production Deployment

In Kubernetes, CoreDNS runs as a Deployment in kube-system namespace. The default setup has 2 replicas, which is fine until one of them crashes and your cluster's DNS becomes slow as hell. AWS EKS, Azure AKS, and Google GKE all manage CoreDNS for you, which is great until you need to customize something and discover their defaults are garbage.

Custom Corefile configurations enable advanced features like stub domains for on-premises integration:

.:53 {
    errors
    health {
        lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

company.internal:53 {
    forward . 10.0.1.10 10.0.1.11
    cache 300
}

This config deals with both internal cluster DNS and forwards company.internal queries to your on-premises DNS servers with longer caching because corporate DNS changes about as often as the CEO's golf schedule.

Plugin Combinations That Actually Work

The real magic happens when you combine plugins. The rewrite plugin lets you manipulate DNS requests, which is handy for gradual service migrations:

.:53 {
    rewrite name old-service.example.com new-service.example.com
    kubernetes cluster.local in-addr.arpa ip6.arpa
    forward . 8.8.8.8
    cache 30
}

For debugging, enable the log plugin, metrics plugin, and trace plugin if you want to see what the hell is happening. The metrics plugin dumps Prometheus data at /metrics so you can at least pretend to monitor things properly. Fair warning: trace plugin generates a shitload of logs, so don't leave it on in production unless you enjoy paying for log storage.

Security and Performance Optimization

If you're running CoreDNS in production, you probably want to lock it down so random assholes can't query your DNS. The acl plugin can help:

.:53 {
    acl {
        allow net 10.0.0.0/8
        allow net 192.168.0.0/16
        block net 0.0.0.0/0
    }
    kubernetes cluster.local in-addr.arpa ip6.arpa
    forward . 8.8.8.8
}

Want encrypted DNS? DNS over TLS works out of the box. DNS over HTTPS is more complicated - you need a separate proxy because CoreDNS doesn't handle HTTPS directly, which is annoying.

Performance tuning is mostly about getting the cache plugin right. Mess up the TTLs or cache size and CoreDNS will either eat all your memory like a fucking hungry hippo or perform like shit. Also, Go's GOMAXPROCS matters - I learned this on an AWS m5.4xlarge where CoreDNS was only using 2 cores out of 16 because the container runtime didn't set GOMAXPROCS correctly. Took me way too long to figure that one out.

Monitoring and Troubleshooting

Monitoring CoreDNS is critical because when DNS breaks, everything breaks and people will blame you. Key metrics to watch: query rates, cache hit ratios, and error rates. The ready plugin gives you health check endpoints that actually work (unlike some other plugins).

Common debugging scenarios that will ruin your day:

• Plugin ordering issues (check plugin.cfg for the real order)
• Cache not working because you misconfigured TTLs
• Upstream DNS servers timing out and CoreDNS not failing over properly
• The debug plugin crashes CoreDNS when you need it most

Pro tip: Set up proper logging and metrics before you go to production, because debugging CoreDNS without them is like trying to fix a car with your eyes closed.

Migration Strategies

If you're migrating from BIND, don't do it all at once unless you enjoy career-limiting moves. Start with non-critical zones and keep BIND running for the important stuff. The secondary plugin can sync zones from BIND masters, which works until it doesn't.

For Kubernetes migrations from kube-dns to CoreDNS, it usually just works. But if you had custom kube-dns configs with stub domains or weird upstream shit, you're gonna have to figure out how to translate that to Corefile format. Good luck deciphering what your old kube-dns settings actually did - the docs were garbage and whoever set it up probably left the company two years ago without documenting anything. I'm still trying to figure out what some of the ConfigMaps in my current cluster actually do.