We want external-dns to provision alias records for domains that may have existing txt records. We added the txt-prefix argument and found that while it would create new txt records using the prefix, it would not create domains when a txt record existed on the exact domain (without prefix).
The use case we have is that some of our domains require txt records for mail providers
Configure external-dns with the following arguments:
Create a txt record for world.domain with value "google-site-verification=abc"
Deploy ingress that requests two domains:
hello.domainworld.domain2 aliases and 2 new txt are created:
hello.domain is created with correct txt record:
However, world.domain is ignored because the existing but prefix-less txt record does not contain the matching owner. Example log message:
level=debug msg="Skipping endpoint world.domain 60 IN TXT "google-site-verification=abc" because owner id does not match, found: "", required: "acme""
We have the same problem with our domains and mail providers (SPF records and the like) so it would be nice for external-dns to support this use case.
While I'm not deeply into the topic, I would see this as a bug. Someone wants to contribute a patch?
I have the same problem, and was planning on spending some time fixing this problem.
I've poked around with the code a little bit.
TXT registry only considers the first Target of every TXT record. It literally takes the first element in the array, and ignores the rest.
If I change the code so that all the Targets are converted to Endpoints, now weird things happen such as Google CloudDNS returning preconditionFailed, or InMemoryProvider failing with ErrRecordAlreadyExists. This is probably because the rest of the code assumes that there is only one target for a single TXT record.
Would fixing this depend on multiple endpoints?
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-testing, kubernetes/test-infra and/or fejta.
/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-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Most helpful comment
We have the same problem with our domains and mail providers (SPF records and the like) so it would be nice for external-dns to support this use case.