Last modified September 2, 2025

Advanced CoreDNS configuration

Your Giant Swarm clusters come with a default configuration for the CoreDNS add-on. CoreDNS is installed as default application in your clusters using a HelmRelease. This guide explains how you can customize the CoreDNS configuration in your clusters.

Where to store the user configuration

Given the cluster you are trying to configure is called: 123ab you can create or extend the <CLUSTER>-user-values ConfigMap of the organization namespace on the management cluster. Inside the ConfigMap, the Helm values are passed as the field called values which lets you define a

data:
  values: |
    global:
      apps:
          coreDns:
              values:
                  ...    
kind: ConfigMap
metadata:
  name: 123ab-userconfig
  namespace: org-my-org

More information about cluster configuration.

Configuration Reference

Cache settings

By default we set the cache TTL for CoreDNS to 30 seconds. You can customize the cache settings of CoreDNS by setting the value of the cache field in the user ConfigMap like this:

data:
  values: |
    configmap:
      cache: "60"

Above setting increases the TTL to 60 seconds.

The cache plugin also supports much more detailed configuration which is documented in the upstream documentation.

Logs

By default, we set the log level for CoreDNS to denial and error. You can tune these settings by adding a property log in the user ConfigMap like this:

data:
  values: |
    configmap:
      log: |
        all

To learn more about the exact details of each log level log plugin, please read the upstream documentation.

Resource limits

We set resource limits for the CoreDNS deployment. For larger clusters these may need to be increased. This can be done in the user ConfigMap like this:

data:
  values: |
    resources:
      limits:
        memory: 512Mi
      requests:
        cpu: 250m
        memory: 512Mi

Additional forwards (formerly known as proxy)

The default forward entry we set in CoreDNS is

forward . /etc/resolv.conf

You can add additional forward entries by adding each as a line to the forward field of the user values ConfigMap. They will be selected in random order.

You can use a simple line or multiple lines to define the upstreams of the default server block.

Simple line:

data:
  values: |
    configmap:
      forward: . 1.1.1.1 /etc/resolv.conf

Multiple lines:

data:
  values: |
    forward: |
      .
      1.1.1.1
      8.8.8.8
      /etc/resolv.conf

Warning: The number of forward upstreams is limited to 15.

The example above results in the following additional forward entries in the CoreDNS configuration:

forward . 1.1.1.1 /etc/resolv.conf

forward . 1.1.1.1 8.8.8.8 /etc/resolv.conf

This setting would forward all requests to 1.1.1.1 which is Cloudflare’s DNS. If the first upstream fails the second IP (8.8.8.8) will be used as resolver. In case it fails too, all requests will be resolved by the default DNS provider set for your cluster.

The forward plugin also supports much more detailed configuration which is documented in the upstream documentation.

Note: For releases using the CoreDNS chart in versions 1.1.3 and below, the upstreams must not include . and /etc/resolv.conf as they are rendered by the chart. They can be configured using simple or multiple lines:

Simple lines:

data:
  values: |
    configmap:
      forward: 1.1.1.1 8.8.8.8

Multiple lines:

data:
  values: |
    configmap:
      forward: |
        1.1.1.1
        8.8.8.8

Advanced configuration

In case you need to have a finer granularity you can define custom server blocks with all desired configurations. They will be parsed after the catch-all block in the Corefile. As an example, let’s define a block for a example.com with a custom configuration:

data:
  values: |
    configmap:
      custom: |
        example.com:1053 {
          forward . 9.9.9.9
          cache 2000
        }

This custom configuration allows CoreDNS to resolve all example.com requests to a different upstream DNS resolver (9.9.9.9) than the generic one. At the same time we use a different cache TTL(2000) setting.

Warning: By default our clusters come with Pod Security Standards and Network Policies for managed components. This means the CoreDNS container doesn’t use a privileged port and listens to 1053 instead. Please make sure you test the final Corefile carefully. We do not take responsibility for incorrect custom configuration that could break workload communication.

Giant Swarm Offerings