Last modified December 7, 2022

Advanced CoreDNS configuration

Your Giant Swarm installation comes with a default configuration for the CoreDNS addon

You can override these defaults in a ConfigMap named coredns-user-values in the management cluster.

Note: In Cluster API, CoreDNS is part of default apps <provider> chart (example Cluster API for Openstack. In order to extend the app, you need to patch the App Custom Resource to use coredns-user-values configmap. Check out this example.

Where is the user values ConfigMap

Given the cluster you are trying to configure has id: 123ab then you will find the coredns-user-values ConfigMap in the management cluster in the 123ab namespace:

$ kubectl -n 123ab get cm coredns-user-values --context=control-plane
NAME                                   DATA      AGE
coredns-user-values                    0         11m

Warning:

Please do not edit any other CoreDNS related ConfigMaps.

Only the user values ConfigMap is safe to edit.

How to set configuration options using the user values ConfigMap

On the management cluster, create or edit a ConfigMap named coredns-user-values in the workload cluster namespace as described above:

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: coredns
  name: coredns-user-values
  namespace: abc12
data:
  values: |
    configmap:
      cache: "60"

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.

Notes: 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 Policies 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.