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.
Further reading
Need help, got feedback?
We listen to your Slack support channel. You can also reach us at support@giantswarm.io. And of course, we welcome your pull requests!