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

[sj-williams]

Also observe this behaviour and interested in the reason for it happening.

Currently working our way through external-dns upgrade from 0.13.4 to 0.15.1 and in doing so tackling the constant UPSERT issue (looking to update our txtPrefix pattern as suggested by @aidan-mundy-simplisafe here)

Our external-dns is managing many thousands of records in over 100 hosted zones and it seems we may have a bit of a manual clean up of 'old' external-dns managed TXT records post-upgrade.

[aidan-mundy-simplisafe]

@romanlehner There are two TXT records created because there are two TXT heritage record formats. The old record format does not contain the record type. The new record format prefixes the domain with %{record_type}-. If you would like to only have one TXT heritage record created, you must specify a --txt-prefix containing %{record_type}. When you provide a --txt-prefix containing %{record_type}, the old format heritage record wont be created at all:

external-dns/registry/txt.go

Line 217 in 850b973

if !im.txtEncryptEnabled && !im.mapper.recordTypeInAffix() && r.RecordType != endpoint.RecordTypeAAAA {

I recommend a --txt-prefix containing %{record_type} and ending with ., so that the TXT record is at a subdomain. Otherwise, external-dns has trouble handling apex records. See my comment on #3977 that @sj-williams linked for more details (#3977 (comment)).

However, AFAIK the new-format record is always created, and the %{record_type} of alias records always evaluates to cname.

@sj-williams This behavior is intentional, though this comment on #3868 (#3868 (comment)) mentions there are noncosmetic effects so maybe it is an issue that could be resolved (though I think the leftover heritage records they mention might happen any time you change between record types, not just between A and A-Alias, so it may be an expected behavior).

The reason for Alias records being denoted as CNAME records in the TXT heritage records looks to be a backwards compatibility decision, since Alias records used to be handled internally to external-dns as CNAME records. When the internal record representation for Alias records changed to be A record in #3910, the decision was made that %{record_type} for Alias records should remain as cname for backwards compatibility (see #3910 (comment)) so that new format TXT heritage records would not break.

---

I think the question in the OP is answered

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

@nipr-jdoenges I'd suggest closing this as a duplicate and tracking this issue in #3868

[nipr-jdoenges]

@nipr-jdoenges I'd suggest closing this as a duplicate and tracking this issue in #3868

I would tend to agree, there appear to be several issues about this same behavior that should be consolidated, although I'm neither the reporter of any of the issues nor a contributor to the project.