This is a good description.
Right now, external-dns has not store or such a thing, therefore it doesn't know about former settings.
So we would need something like a "migration option" probably. For example an option like "--migrate-txt-prefix=default" could inform external-dns about an old txt-prefix. But there could be sophisticated cases like turning a txt-prefix to txt-suffix and the other way round.

@jgrumboe Indeed, --txt-prefix has the same behaviour, losing ownership of records when changing this value.
Good idea about the "migration option". However, I think this would be better automated as external-dns could start storing this data, which would cause less confusion/maintenance for end users.

@bartusz01
Sorry, I was mixing up txt-owner with txt-prefix. (Facepalm) But the concept is the same. ;)

I wouldn't go for adding a store. External-dns is perfectly "stateless" (as long as you don't count the TXT records in DNS as storage). Persistent storage is always hard and adds complexity.
Since you (hopefully) don't wanna change txt-owner on an interval basis, it seems to be some kind of one-off task where it's feasible to add an argument and remove it after the job is done.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

@k8s-triage-robot: Closing this issue.

What would you like to be added: When changing --txt-owner-id on an existing external-dns resource, where --registry=txt and --policy=sync, it does not update the existing TXT records it owns, therefore losing ownership. Meaning that we have to manually delete the records in order to have external-dns take ownership again.

I would expect it to also change the ownership of existing records it previously owned in the DNS zone.

Why is this needed: By default --txt-owner-id is set to default, if we change this value, the external-dns resource loses ownership of existing records it managed, because the TXT record is not updated with the new owner id.

To solve this problem, I added the ability to update the original txt-owner by setting -- migrate-txt-owner to overwrite the old txt-owner. Set new txt-owner can cover the old txt-owner directly when using this tag.(--migrate-txt-owner)

#2466

Hopefully my code will help you