<< Back to article

Article - DNS - coredns

CoreDNS is a robust, CNCF-certified DNS server primarily recognized for its integral role within Kubernetes clusters. However, its versatility extends beyond container orchestration, allowing it to operate efficiently in standalone mode outside of a cluster environment. It is highly configurable, making it an excellent choice for dynamic DNS operations and complex networking requirements.

If you have already read the guide on Article - DNS, you will be familiar with the fundamental roles and architectural arrangements of DNS infrastructure. This foundational understanding will prove beneficial as we delve into CoreDNS's specific capabilities and configurations.

Configuring CoreDNS for Various Roles

To fully leverage CoreDNS, understanding its configuration for different operational roles is key.

Installation and Service Management

TODO: Add a short installation script. This section should cover obtaining the CoreDNS binary, setting up a dedicated user, and configuring a service file for Systemd, to ensure CoreDNS runs reliably as a background service.

Download latest coredns single binary https://github.com/coredns/coredns/releases/latest.

Run coredns using systemd

Create necessary directories:

mkdir -p /opt/coredns/zones

Create service user for coredns:

useradd --system --shell /usr/sbin/nologin --no-create-home coredns

Define systemctl service file at /etc/systemd/system/coredns.service with content:

[Unit]
Description=coredns          
After=network.target

[Service]
ExecStart=/opt/coredns/coredns -conf /opt/coredns/Corefile
Restart=on-failure
RestartSec=5s
WorkingDirectory=/opt/coredns

[Install]
WantedBy=multi-user.target

At this point configure coredns for the desired role shown below.

After you done all further role specific configuration reload and start the service:

systemctl daemon-reload
systemctl start --now coredns

Let's see the logs of coredns:

journalctl -f -u coredns

Resolver (DNS Forwarder)

If your primary requirement is simply to forward all DNS queries to an external DNS server, dnsmasq is often a more lightweight and straightforward choice (refer to my article on Article - DNS - dnsmasq for more details).

However, if you wish to utilize CoreDNS for this role-perhaps due to existing infrastructure, future expansion plans, or a preference for a unified DNS solution- here is how you would configure it:

/opt/coredns/Corefile

# /opt/coredns/Corefile
. {
    # Serve authoritative zone from a BIND file
    # Include external forwarding rules
    forward . /etc/resolv.conf
      forward . 1.1.1.1
      forward . 8.8.8.8

    # Basic logging and health checks
  # log
    errors
  # prometheus :9153
    ready
      reload 3s 1s
}

Serving Static Zones and Forwarding Others

This common configuration allows CoreDNS to act as an authoritative server for specific internal domains (static zones) while forwarding all other queries to an upstream DNS server. This is ideal for managing internal network resources while still providing full internet name resolution.

# /opt/coredns/Corefile

intra.net {
    auto . {
        directory /opt/coredns/zones/ (.*) {1}
        reload 3s 1s
    }

    forward lxe.intra.net 192.168.20.10
    forward dev.intra.net 10.70.0.10:54
}

. {
    # Serve authoritative zone from a BIND file
    # Include external forwarding rules
    forward . /etc/resolv.conf
      forward . 1.1.1.1
      forward . 8.8.8.8

    # Basic logging and health checks
    #   log
      errors
    #   prometheus :9153
    ready
      reload 3s 1s
}

And here is an example zone configuration for intra.net. Keep files semantic layout so it is placed to /opt/coredns/zones/intra.net

$ORIGIN intra.net.
$TTL 3600
@   IN  SOA ns1.lxe.intra.net. admin.lxe.intra.net. (
        16578 ; serial
        3600       ; refresh
        1800       ; retry
        1209600    ; expire
        3600 )     ; minimum

;; routed vpn access to production server in dmz
prod.vpn.dmz IN A 10.255.0.1
;; k8s worker in dmz
k8s.dmz IN A 192.168.255.2
;; server in home network segment
home IN A 192.168.10.2
;; web server to download on guest network
guest IN A 192.168.0.2

Note: reload 3s 1s means CoreDNS check every 3 secounds for file change. If you change zone record it will be only reloaded if serial is changed 16578 ; serial. So refresh every time you done any change in zone file.

Docker Dynamic Zones for Service Discovery

CoreDNS can be powerfully integrated with Docker to provide dynamic DNS resolution for containers. This enables service discovery within a Docker environment, allowing containers to resolve each other's hostnames without manual configuration.

TODO: Write a Dockerfile and an entrypoint shell script demonstrating how to deploy CoreDNS within Docker and configure it to dynamically resolve container names.

Check and debug

TODO if dns resolution is working and which pard TODO dig @dns_ip record

Implementing Adblocking by Extracting DNS Zones from Pi-hole

Leveraging CoreDNS's flexible plugin architecture, it's possible to replicate or integrate adblocking functionalities similar to Pi-hole. This involves extracting ad-blocking DNS zones (blacklists) and configuring CoreDNS to deny resolution for those domains.

TODO: Detail the process of extracting DNS zones from a Pi-hole installation or similar adblock lists and implementing them within CoreDNS to provide network-wide adblocking.