8.03 Prerequisite: CoreDNS

Abstract

CoreDNS is a flexible DNS server commonly used in Kubernetes for cluster DNS and service discovery.

In this prerequisite, we configure CoreDNS as a basic DNS server using /etc/hosts, then forward unknown queries to another resolver.

Why CoreDNS Is Used

In small environments, hostname mappings can be stored locally in:

/etc/hosts

But in larger environments, managing host entries on every machine becomes difficult.

A DNS server centralizes name resolution.

Note

CoreDNS can act as a DNS server and resolve hostnames using plugins.

What is CoreDNS?

CoreDNS is a plugin-based DNS server.

It can:

resolve hostnames
forward DNS queries
cache DNS responses
log DNS requests
integrate with Kubernetes
serve DNS records using plugins

Success

CoreDNS is the default DNS solution used in many Kubernetes clusters.

Install CoreDNS

Download the CoreDNS binary from GitHub releases.

curl -LO https://github.com/coredns/coredns/releases/download/v1.12.4/coredns_1.12.4_linux_amd64.tgz

Extract it:

tar -zxf coredns_1.12.4_linux_amd64.tgz

You should now have the CoreDNS executable:

./coredns

Tip

CoreDNS can also be run as a container image, but using the binary is useful for understanding how it works.

Run CoreDNS

Start CoreDNS:

./coredns

By default, DNS listens on port:

Note

Port 53 is the default port used by DNS servers.

CoreDNS Configuration File

CoreDNS reads configuration from a file named:

Corefile

A Corefile defines:

what port CoreDNS listens on
which plugins are enabled
how DNS queries are handled
where unmatched queries are forwarded

Example Corefile

.:53 {
    # Use /etc/hosts to resolve hostname
    hosts /etc/hosts {
        reload 1m
        fallthrough
    }

    # Forward unmatched queries to the host's resolver
    forward . /etc/resolv.conf {
        max_concurrent 1000
    }

    cache 30
    log
    errors
}

Example

This Corefile tells CoreDNS to first resolve names using /etc/hosts, then forward unmatched queries to the resolver configured in /etc/resolv.conf.

Corefile Breakdown

Directive	Purpose
`.:53`	Listen for DNS queries on port 53
`hosts /etc/hosts`	Resolve records from `/etc/hosts`
`reload 1m`	Reload host entries every 1 minute
`fallthrough`	Continue to next plugin if no match is found
`forward . /etc/resolv.conf`	Forward unmatched queries to upstream DNS
`max_concurrent 1000`	Limit concurrent forwarded queries
`cache 30`	Cache responses for 30 seconds
`log`	Log DNS queries
`errors`	Log DNS errors

How Query Resolution Works

With the above Corefile:

Client sends DNS query to CoreDNS
CoreDNS checks /etc/hosts
If record exists, CoreDNS returns the IP
If record does not exist, fallthrough allows the query to continue
CoreDNS forwards the query using /etc/resolv.conf
Response is cached for 30 seconds

Client
  ↓
CoreDNS
  ↓
hosts plugin
  ↓
forward plugin
  ↓
Upstream DNS

Tip

The fallthrough option is important when CoreDNS should continue searching other plugins after /etc/hosts.

Configure Host Entries

Add DNS records to the DNS server’s /etc/hosts file.

cat >> /etc/hosts
192.168.1.11 db
192.168.1.12 web
192.168.1.13 nfs

CoreDNS can now resolve:

db
web
nfs

Warning

/etc/hosts based DNS is simple, but it is not ideal for large dynamic environments.

Configure Clients to Use CoreDNS

On client machines, configure /etc/resolv.conf:

nameserver 192.168.1.100

Where 192.168.1.100 is the CoreDNS server IP.

Test:

ping db

or:

nslookup db

Forwarding Unknown Queries

If CoreDNS does not find a record locally, it can forward the query.

Example:

forward . /etc/resolv.conf

This forwards unknown DNS queries to the resolver configured on the DNS server.

Success

Forwarding allows CoreDNS to resolve both internal names and external names.

Caching DNS Responses

The cache plugin improves performance.

cache 30

This caches DNS responses for 30 seconds.

Benefits:

reduces repeated DNS lookups
improves response time
reduces load on upstream DNS servers

Tip

In production, tune cache duration based on how frequently DNS records change.

Logging and Errors

CoreDNS can log DNS requests and errors.

log
errors

These are useful for debugging.

Note

In production, enable logging carefully because high DNS query volume can generate large logs.

CoreDNS Plugins

CoreDNS is plugin-based.

Common plugins:

Plugin	Purpose
`hosts`	Serve records from hosts file
`forward`	Forward queries to upstream DNS
`cache`	Cache DNS responses
`log`	Log DNS queries
`errors`	Log DNS errors
`kubernetes`	Serve Kubernetes cluster DNS records

Example

Kubernetes uses the kubernetes plugin to resolve Services and Pods inside the cluster.

CoreDNS in Kubernetes

In Kubernetes, CoreDNS provides internal DNS resolution for:

Services
Pods
namespaces
cluster domain names

Example Kubernetes DNS name:

service-name.namespace.svc.cluster.local

Note

The Kubernetes-specific CoreDNS plugin is covered separately when learning Kubernetes DNS.

Production Best Practices

Recommended

Run CoreDNS with high availability
Use reliable upstream DNS resolvers
Enable caching
Monitor DNS latency and error rates
Use proper resource requests and limits
Avoid excessive DNS logging in high-traffic clusters
Keep CoreDNS configuration version-controlled
Test DNS changes before applying to production

Do's

Use CoreDNS for centralized DNS resolution
Use forwarding for external DNS queries
Enable caching for performance
Monitor CoreDNS logs and metrics
Use the Kubernetes plugin inside clusters
Keep DNS records clean and documented

Don'ts

Don't manage large environments only with /etc/hosts
Don't expose internal DNS publicly
Don't disable caching without reason
Don't make DNS changes without testing
Don't ignore DNS latency in production
Don't run a single DNS instance for critical systems

Danger

DNS failure can break service discovery and application communication across the environment.

Troubleshooting Checklist

When CoreDNS resolution fails, check:

Is CoreDNS running?
Is CoreDNS listening on port 53?
Is the Corefile valid?
Are records present in /etc/hosts?
Is fallthrough configured correctly?
Is /etc/resolv.conf pointing to the correct upstream resolver?
Can clients reach the CoreDNS server?
Are logs showing DNS errors?

Quick Commands

Check CoreDNS binary:

./coredns -version

Run CoreDNS:

./coredns

Check DNS server configuration:

cat Corefile

Check host records:

cat /etc/hosts

Check resolver:

cat /etc/resolv.conf

Test DNS:

nslookup db
dig db

Summary

Quote

CoreDNS is a plugin-based DNS server
It can resolve records from /etc/hosts
Unknown queries can be forwarded to upstream DNS
cache, log, and errors help performance and troubleshooting
Kubernetes uses CoreDNS for service discovery