external-dns creates TXT records for CNAMEs, when using Alias in AWS Route 53

[romanlehner]

What happened: When I create a kubernetes service object of type Loadbalancer that creates an AWS NLB, then external-dns creates an A record with an Alias to the NLB DNS, and the respective TXTrecord to reference the A record. But it also creates TXT records for CNAME records.

Example:

AWS hosted zone: mydomain.com

service Annotation: external-dns.alpha.kubernetes.io/hostname: app.mydomain.com

Created records in AWS route 53:	record	type	alias	value
app.mydomain.com	TXT	no	"heritage=external-dns,external-dns/owner=default,external-dns/resource=service/default/app"
app.mydomain.com	A	yes	http://my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com
cname-app.mydomain.com	TXT	no	"heritage=external-dns,external-dns/owner=default,external-dns/resource=service/default/app"

The question is why it is doing so. It is not really degrading any functionality, but is an unexpected behavior.

What you expected to happen: There shouldn't be a TXT record for CNAMES, but only the A record for the Alias:	record	type	alias	value
app.mydomain.com	TXT	no	"heritage=external-dns,external-dns/owner=default,external-dns/resource=service/default/app"
app.mydomain.com	A	yes	http://my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com

How to reproduce it (as minimally and precisely as possible): https://kubernetes-sigs.github.io/external-dns/v0.14.2/tutorials/aws-load-balancer-controller/

Anything else we need to know?:

Environment: dev

• External-DNS version (use external-dns --version): 0.14.2
• DNS provider: AWS route 53
• Others:

external-dns deployment config args:

args:
- --log-level=debug
- --log-format=text
- --interval=10m
- --events
- --source=service
- --source=ingress
- --policy=upsert-only
- --registry=txt
- --domain-filter=mydomain.com
- --provider=aws
- --txt-wildcard-replacement=x

[k8s-triage-robot]

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

This bot triages un-triaged 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:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue 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.

This bot triages un-triaged 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:

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

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

/lifecycle rotten

[nipr-jdoenges]

This seems similar to #3868

[nipr-jdoenges]

/remove-lifecycle rotten