Skip to content
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

CNAMEs and the TXT registry #262

Closed
ryane opened this issue Jul 6, 2017 · 3 comments
Closed

CNAMEs and the TXT registry #262

ryane opened this issue Jul 6, 2017 · 3 comments

Comments

@ryane
Copy link

ryane commented Jul 6, 2017

It appears that the TXT registry is incompatible with some DNS providers when using the Ingress source. For example:

I am using the nginx ingress controller backed by an ELB on AWS. And, I have an ingress that looks like this:

$ kubectl describe ingress nginx
Name:                   nginx
Namespace:              dev
Address:                xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxx.us-east-1.elb.amazonaws.com
Default backend:        default-http-backend:80 (<none>)
Rules:
  Host                          Path    Backends
  ----                          ----    --------
  nginx.test.mydomain.com
                                /       nginx:80 (<none>)
Annotations:
Events: <none>

This works fine with external-dns when using the AWS provider because it creates an ALIAS. However, if I try to use the Google or DigitalOcean providers, I get errors:

$ ./external-dns --source=ingress --provider=google --domain-filter test.mydomain.com. --registry=txt --txt-owner-id=extdns --once --google-project my-project
...
INFO[0001] Add records: nginx.test.mydomain.com. CNAME [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxx.us-east-1.elb.amazonaws.com.]
INFO[0001] Add records: nginx.test.mydomain.com. TXT ["heritage=external-dns,external-dns/owner=extdns"]
FATA[0002] googleapi: Error 400: The resource record set 'entity.change.additions[0]' is invalid because the DNS name 'nginx.test.mydomain.com.' may have either one CNAME resource record set or resource record sets of other types, but not both.
More details:
Reason: cnameResourceRecordSetConflict, Message: The resource record set 'entity.change.additions[0]' is invalid because the DNS name 'nginx.test.mydomain.com.' may have either one CNAME resource record set or resource record sets of other types, but not both.
Reason: cnameResourceRecordSetConflict, Message: The resource record set 'entity.change.additions[1]' is invalid because the DNS name 'nginx.test.mydomain.com.' may have either one CNAME resource record set or resource record sets of other types, but not both.
$ ./external-dns --source=ingress --provider=digitalocean --domain-filter test.mydomain.com. --registry=txt --txt-owner-id=extdns --once
...
INFO[0002] Changing record.                              action=CREATE record=nginx.test.mydomain.com type=CNAME zone=test.mydomain.com
INFO[0003] Changing record.                              action=CREATE record=nginx.test.mydomain.com type=TXT zone=test.mydomain.com
FATA[0003] POST https://api.digitalocean.com/v2/domains/test.mydomain.com/records: 422 records cannot share a name with a CNAME record

According to the RFCs (RFC 1034 section 3.6.2, RFC 1912 section 2.4), it not permissible for a CNAME record to co-exist with any other records, even TXT records. Some of the DNS providers enforce this (cloudflare does not, fwiw) and causes external-dns to break.

Any ideas on how to approach this? Maybe use a simple hash of the name for the corresponding TXT record to avoid this conflict? Other ideas?

@ideahitme
Copy link

Hello,

Yes, CNAME cannot co-exist with other records, therefore we provided --txt-prefix flag which makes sure to create a TXT record with a name = prefix.<CNAME record>. Let me know if this solved your issue.

@ryane
Copy link
Author

ryane commented Jul 6, 2017

yep, I totally missed that. that gets me past the problem. Thanks!

@ryane ryane closed this as completed Jul 6, 2017
lou-lan pushed a commit to lou-lan/external-dns that referenced this issue May 11, 2022
This script tests if a build is installable (as documented in the readme)
from its tarball+yaml file.

I felt like adding this as extra confidence on all the refactoring we're doing,
and I know we have integration tests that cover this. Since installation is
almost like our API, I thought it would be good to test.

Signed-off-by: Ahmet Alp Balkan <ahmetb@google.com>
@rofreytag
Copy link

When using txt-prefix you should include a . to make sure external-dns does correctly handle the root record of your domain.

See: #1416 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants