How to override DNS results served by CoreDNS

This document (000020117) is provided subject to the disclaimer at the end of this document.

Situation

Task

By default, DNS requests for pods using CoreDNS will be made directly to the upstream nameservers configured in /etc/resolv.conf on the node.

At times, it may not be possible to easily update records on the upstream nameservers, or specific records for the cluster may be needed. In these cases it's useful to override the results that CoreDNS will serve pods.

Pre-requisites

These steps should work for any cluster running CoreDNS where the coredns ConfigMap is used.

Steps

There are two approaches to achieve this, please read through both to understand which is best for your environment.

Both approaches require editting the coredns ConfigMap, specifically the Corefile key. This can be done in the UI by clicking View/Edit YAML, Edit, or on the command line with kubectl.

Along with these options, both plugins covered provide other features, like adjusting the TTL for records, see the documentation links for more information.

Rewrite

The rewrite plugin will perform a rewritten query to the upstream nameserver, and respond to the query with the results. The outcome would be similar to configuring a CNAME for the domain.

data:
  Corefile: |
    .:53 {
        [...]
        rewrite name archive.ubuntu.com internal-mirror.ubuntu.local
    }

In this example, pods configured with the default Ubuntu mirror are now resolving to the internal mirror without any custom configuration.

The benefit of this approach is that the upstream nameserver remains the source of truth for the results.

Hosts

The hosts plugin provides the ability to define a list of IPs and domains in the form of /etc/hosts to respond as query results.

data:
  Corefile: |
    .:53 {
        [...]
        hosts {
          10.0.0.1 archive.ubuntu.com
          10.0.0.2 testing.com
          fallthrough
        }
    }

A similar example, the internal IPs listed are provided as results.

A downside to this approach is that the ConfigMap becomes a source of truth for these results, if changes in the environment are not reflected these entries could become stale. However, it does provide the most flexibility without needing to depend on any upstream nameserver to serve results.

Persist the changes

In an RKE or Rancher environment, during cluster or addon upgrades, it's possible that changes to the coredns ConfigMap are updated to use the provided version.

To persist the changes made to the ConfigMap, add the changes as a user-defined addon. The steps to do this are documented under How To Update CoreDNS's Resolver Policy article.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.