Reload CoreDNS Config Automatically Without Restart (2026)

CoreDNS can reload its configuration without a full restart by sending a SIGHUP signal to its process.

Here’s how you can observe it in action:

Let’s say you have a CoreDNS instance running, and its configuration file is at /etc/coredns/Corefile.

Initial State:

You can check the current configuration by querying a specific record that might be defined in your Corefile. For instance, if you have a local zone example.com configured:

dig @127.0.0.1 example.com A +short

If the record is not yet configured or has a default value, you’ll get a specific response.

Modifying the Configuration:

Now, let’s say you want to add a new record or change an existing one. You’d edit your /etc/coredns/Corefile.

Suppose your Corefile initially looks like this:

.:53 {
    cache 30
    forward . /etc/resolv.conf
    reload
    log
    errors
    health {
       lameduck 5s
    }
    prometheus :9153
}

And you want to add a specific A record for app.example.com. You’d modify the Corefile to include a hosts plugin for this local zone:

.:53 {
    hosts {
        192.168.1.100 app.example.com
        fallthrough
    }
    cache 30
    forward . /etc/resolv.conf
    reload
    log
    errors
    health {
       lameduck 5s
    }
    prometheus :9153
}

Triggering the Reload:

Instead of stopping and starting the coredns service, you can send a SIGHUP signal to the CoreDNS process. First, you need to find the Process ID (PID) of your running CoreDNS instance.

pgrep coredns

Let’s assume the output is 12345. You would then execute:

kill -SIGHUP 12345

Verifying the Reload:

Immediately after sending the SIGHUP signal, you can query the same record again:

dig @127.0.0.1 app.example.com A +short

This time, you should see the new record you added: 192.168.1.100. The change is effective without any interruption to DNS resolution for other queries.

The reload plugin in CoreDNS watches the configured Corefile for changes. When it detects a modification (typically based on inode or timestamp), it signals the CoreDNS process to re-read the configuration. The SIGHUP signal is the standard Unix way to tell a process to re-initialize itself, which includes re-reading its configuration files. This mechanism allows for dynamic updates to DNS records, server directives, and plugin configurations without dropping existing connections or interrupting service.

The reload plugin is often enabled by default in many CoreDNS deployments, especially within Kubernetes. If it’s not explicitly present in your Corefile, you can add it. The reload plugin itself monitors the Corefile. When it detects a change, it internally triggers the reload process. The SIGHUP signal is often used by the system’s init system (like systemd) when you run systemctl reload coredns, which then tells the reload plugin (or CoreDNS directly) to re-read. However, sending SIGHUP directly to the CoreDNS PID is the manual way to achieve the same effect, irrespective of the reload plugin’s internal watching. The reload plugin is designed to work in conjunction with the SIGHUP signal, ensuring that changes are applied promptly.

One aspect that often trips people up is that the reload plugin itself also monitors the Corefile for changes. This means you can often modify the Corefile and CoreDNS will pick it up automatically without even sending a SIGHUP. The SIGHUP is more of a guaranteed, immediate trigger if the plugin’s watch mechanism isn’t fast enough or if you’ve disabled the automatic watch. However, relying solely on the reload plugin’s watch can sometimes lead to slight delays or missed updates if the filesystem events are not perfectly delivered or if the Corefile is being modified very rapidly.

The next step is understanding how to manage different configurations for various zones or how to implement more advanced DNS features like DNSSEC.