-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional Record Type TXT records can not be applied due to length #2790
Comments
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 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 |
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. |
This also presents a breaking change for us, and the length reduction via the |
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.
|
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? |
I'm hitting similar issues when deploying v0.12.2 whilst having lots of records previously created with older versions.
I thought this would have been fixed with #2913 . |
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
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 |
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 😬 |
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
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. |
/reopen |
@jessebye: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
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. |
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
The text was updated successfully, but these errors were encountered: