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.