external-dns/docs/tutorials/coredns.md

CoreDNS

• Documentation

Multi cluster support options

The CoreDNS provider allows records from different CoreDNS providers to be separated in a single etcd by activating the setting --coredns-strictly-owned flag and set txt-owner-id. It will prevent any override (update/create/delete) of records by a different owner and prevent loading of records by a different owner.

Flow:

graph TD
  subgraph ETCD
    store--> E(services from Cluster A)
    store--> F(services from Cluster B)
    store--> G(services from someone else)
  end
  subgraph Cluster A
  A(external-dns with stictly-owned)
  end
  A --> E
  subgraph Cluster B
  B(external-dns with stictly-owned)
  end
  B --> F
  store --> CoreDNS

This features works directly without any change to CoreDNS. CoreDNS will ignore this field inside the etcd record.

Other entries inside etcd

Service entries in etcd without an owner field will be filtered out by the provider if strictly-owned is activated. Warning: If you activate strictly-owned afterwards, these entries will be ignored as the owner field is empty.

Ways to migrate to a multi cluster setup

Ways:

1. Add the correct owner to all services inside etcd by adding the field owner to the JSON.
2. Remove all services and allow them to be required again after restarting the provider. (Possible downtime.)

Specific service annotation options

Groups

Groups can be used to group set of services together. The main use of this is to limit recursion, i.e. don't return all records, but only a subset. Let's say we have a configuration like this:

[[% include 'tutorials/coredns/coredns-groups.yaml' %]]

And we want domain.local to return (127.0.0.1 and 127.0.0.2) and subdom.domain.local to return (127.0.0.3 and 127.0.0.4). For this the two domains, need to be in different groups. What those groups are does not matter, as long as a and b belong to the same group which is different from the group c and d belong to. If a service is found without a group it is always included.