Additional Record Type TXT records can not be applied due to length

[koooni]

We have been using external-dns for quite a while, but haven't updated the chart. As we recently did this, we had to realize we need to rollback, because external-dns is not able anymore to create the records. specifically, the problem is that due to the additional TXT record that is added, the domain long gets too long, which then is rejected by the google cloud dns api. (yes, we have quite long dns names, and we don't want to change that logic).
i haven't found any possibility to disable this....so for us this was really a breaking change.

It should be configurable if those additional TXT records are created or not.
For example, currently, the following records are created (we are using Google as Provider)
A Record my-subdomain.mydomain.com
TXT Record my-subdomain.mydomain.com
TXT Record a-my-subdomain.mydomain.com

is there any way to avoid the creation of those additional records? or does this need to be implemented?
thanks

[devops-cafex]

We are hitting similar issues with route53 and have also needed to role back

To add to the case above, external-dns could not delete records that it had previously created

Senario

0.11.1 External dns version adds a record with the A and TXT then upgrade to to 0.12.0 and we try to remove that record and the batch fails as its expecting a cname- additional TXT record which is not present and it blocks further updates

time="2022-06-06T09:45:41Z" level=info msg="Desired change: DELETE cname-dns.example.com TXT [Id: /hostedzone/****]"
time="2022-06-06T09:45:41Z" level=info msg="Desired change: DELETE dns.example.com A [Id: /hostedzone/****]"
time="2022-06-06T09:45:41Z" level=info msg="Desired change: DELETE dns.example.com TXT [Id: /hostedzone/****]"
time="2022-06-06T09:45:41Z" level=error msg="Failure in zone example.com. [Id: /hostedzone/****]"
time="2022-06-06T09:45:41Z" level=error msg="InvalidChangeBatch: [Tried to delete resource record set [name='cname-dns.example.com.', type='TXT'] but it was not found]\n\tstatus code: 400, request id: ****"
time="2022-06-06T09:45:41Z" level=error msg="failed to submit all changes for the following zones: [/hostedzone/****]"

Record changed to annomise prior to posting

[k0da]

We have been using external-dns for quite a while, but haven't updated the chart. As we recently did this, we had to realize we need to rollback, because external-dns is not able anymore to create the records. specifically, the problem is that due to the additional TXT record that is added, the domain long gets too long, which then is rejected by the google cloud dns api. (yes, we have quite long dns names, and we don't want to change that logic). i haven't found any possibility to disable this....so for us this was really a breaking change.

It should be configurable if those additional TXT records are created or not. For example, currently, the following records are created (we are using Google as Provider) A Record my-subdomain.mydomain.com TXT Record my-subdomain.mydomain.com TXT Record a-my-subdomain.mydomain.com

is there any way to avoid the creation of those additional records? or does this need to be implemented? thanks

It is the plan to keep only new format in the future. What is missing though is the record length validation. It shouldn't exceed 63 bytes.

[universam1]

This also presents a breaking change for us, and the length reduction via the cname record is an issue for us

[hobti01]

the batch fails as its expecting a cname- additional TXT record which is not present and it blocks further updates

We are seeing this issue: Updates are blocked in the batch change because external-dns is attempting to delete records that do not exist and failing instead of continuing.

Tried to delete resource record set [name='_externaldns.cname-my-name.example.com.', type='TXT'] but it was not found]

[alebedev87]

@hobti01 : #2811 is intended to address the problem of the deletion of the new format TXT records.

[rriverak]

Hey, we also get this issues with Designated OpenStack and have also needed to role back from v0.12.2 to v0.12.0.

It looks like a migration to the new TXT records is being attempted...

"Creating records: a-test.xxx.net./TXT: \"heritage=external-dns,external-dns/designate-original-records=XXX.XX.XXX.XX,external-dns/designate-record-id=5c14ec74-1f2b-4274-809b-7db726a1ff2a,external-dns/designate-recordset-id=0b523ea5-6377-4842-9862-ac1d99c28b00,external-dns/owner=default,external-dns/resource=ingress/development/test-817-route\""

But it fails also on the maxLength condition here...

"Bad request with: [POST https://designate.XXX.net:9001/v2/zones/5c14ec74-1f2b-4274-809b-7db726a1ff2a/recordsets], error message: {\"code\": 400, \"type\": \"invalid_object\", \"errors\": {\"errors\": [{\"path\": [\"records\", 0, \"txt_data\"], \"message\": \"u'\\\"heritage=external-dns,external-dns/designate-original-records=XXX.XX.XXX.XX,external-dns/designate-record-id=5c14ec74-1f2b-4274-809b-7db726a1ff2a,external-dns/designate-recordset-id=0b523ea5-6377-4842-9862-ac1d99c28b00,external-dns/owner=default,external-dns/resource=ingress/development/test-817-route\\\"' is too long\", \"validator\": \"maxLength\", \"validator_value\": 255}]}, \"request_id\": \"req-be6947f3-0d5a-462d-b2d2-b92be34507aa\"}"

should that be covered in #2811 or is this an other issue?

[migueleliasweb]

I'm hitting similar issues when deploying v0.12.2 whilst having lots of records previously created with older versions.

{"level":"error","msg":"InvalidChangeBatch: [The request contains an invalid set of changes for a resource record set [...]

I thought this would have been fixed with #2913 .

[k8s-triage-robot]

The Kubernetes project currently lacks enough 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:

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

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

/lifecycle stale

[k8s-triage-robot]

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:

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

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

/lifecycle rotten

[addisonj]

Just ran into this issue.

Would it make sense to add a flag to not try and create the new records? This is a bit of an edge case... but it is pretty impactful, as with AWS provider and using batch record sets, no new records are applied so it effectively breaks DNS updates

[jessebye]

We just encountered this as well. Hadn't updated in a while, update to the latest version and it fails due to batch length. The only fix we could figure out is to roll back 😬

[k8s-triage-robot]

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

This bot triages issues 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 with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages issues 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 with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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.

[jessebye]

/reopen

[k8s-ci-robot]

@jessebye: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

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.