TXT Registry Behavior

The TXT Registry, once configured as per Configuring a Registry, adds extra text records to your DNS providers in order to keep track of DNS record ownership.

The registry concept is based on the external-dns project's registry, as mentioned on Comparison with external dns.

Example Registry Record

A TXT record used for ownership might look like this:

app.brand.tld. 120 IN TXT "heritage=external-dns,external-dns/owner=usc1f-int,external-dns/resource=ingress/brand/app-fe,record-type/A=managed,record-type/AAAA=managed"

The record data would be parsed into a structure like this:

heritage: external-dns
external-dns/owner: usc1f-ext
external-dns/resource: ingress/brand/app-fe
record-type/A: managed
record-type/AAAA: managed

Each field has a meaning:

• heritage marks that the TXT record is used in an external-dns registry fashion. Because TXT records can be used for other purposes, the heritage field works like a signature.
• external-dns/owner identifies the "owner-id" of the installation managing this record. This value should be unique to each DNS sync daemon running in any Kubernetes cluster. I usually include the cloud provider region and also a short identifier for future proofing.
• external-dns/resource identifies the Kubernetes resource that wants this record to exist. If values from multiple Kubernetes resources are being combined, then this field is left out. Useful if you want to locate where a particular record is coming from.
• record-type/* fields provide a list of record types that are being managed by this owner. When this field is present, other record types are allowed to exist at the same DNS name, and the DNS sync daemon owning this TXT record will leave them alone. If the field is missing then it is treated as managing every record type.

Interactions with existing records

When kubernetes-dns-sync wants to manage a DNS record that it doesn't already have ownership over, several things are checked:

1. What other ownership TXTs already exist? For each ownership record we understand:
   1. If the ownership doesn't have any overlapping types (e.g. TXT while we want A), disregard it.
   2. If the ownership overlaps, but it's an owner value that we are willing to adopt, then we will continue with our changes and also rewrite the ownership TXT.
   3. If the ownership overlaps and isn't adoptable, we'll skip management of the FQDN entirely.
2. What DNS records types already exist at the FQDN?
   1. If there's any overlap in types (A exists and we want A), we'll skip management of those types.
   2. If the existing records are all of a different type (e.g. TXT) then we won't skip our management.
3. Do we already manage other types at the FQDN?
   1. We'll happily add new record types to our existing ownership record. This'll happen if you add IPv6 addresses to your existing ingress controller.