CRD unable to create DNSEndpoint of record types other than A or CNAME

[mikelorant]

What happened:

Applied the following DNSEndpoint resource:

apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSEndpoint
metadata:
  name: examplednsrecord
spec:
  endpoints:
  - dnsName: foo.bar.com
    recordTTL: 180
    recordType: TXT
    targets:
    - "test"

This results in no resource created. Even in debug mode, there is no object even mentioned.

As soon as I kubectl edit dnsendpoint examplednsrecord to change it from TXT to CNAME I see the following output.

{"level":"debug","msg":"Adding foo.bar.com. to zone ffxblue.io. [Id: /hostedzone/...]","time":"2020-06-25T08:40:24Z"}
{"level":"debug","msg":"Adding foo-txt.bar.com. to zone ffxblue.io. [Id: /hostedzone/...]","time":"2020-06-25T08:40:24Z"}
{"level":"info","msg":"Desired change: CREATE foo.bar.com CNAME [Id: /hostedzone/...]","time":"2020-06-25T08:40:24Z"}
{"level":"info","msg":"Desired change: CREATE foo-txt.bar.com TXT [Id: /hostedzone/..]","time":"2020-06-25T08:40:24Z"}

What you expected to happen:

It is expected that the DNSEndpoint should be able to create all record types. The comments in the source code specifically list SRV and TXT records. My initially attempts were a MX record which also failed.

Attempting to use the providerSpecific options to create the exact record also did not work.

How to reproduce it (as minimally and precisely as possible):

Apply the YAML I provided at the start of this issue and change the dnsName to be a valid zone that external-dns is managing.

All my tests have been using AWS. Uncertain if this is an issue with other providers.

Anything else we need to know?:

Environment:

• External-DNS version (use external-dns --version): 0.7.2
• DNS provider: AWS
• Others:
  • The option preferCNAME enabled.
  • Policy set to sync.
  • Using the Bitnami Helm chart.

[ytsarev]

I can confirm this behavior, have seen it before for TXT.

[ytsarev]

/assign @ytsarev

[Raffo]

@ytsarev are you able to take a look at that given that you are assigned?

[ytsarev]

@Raffo yes, i have it in the pipeline

[AlbinoDrought]

(Possibly reopen? I think the Partially fixes #... in #1813 may have triggered an early close here)

[seanmalloy]

/reopen

[k8s-ci-robot]

@seanmalloy: Reopened this issue.

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.

[AmitBenAmi]

Is there any update regarding this issue?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[danopia]

Since this valid-looking ticket is going stale I'll link some relevant context here..

It was written down that external-dns was originally supposed to be specifically for A and CNAME: #1923 (comment)

The #1813 PR that accidentally closed this issue actually broke people on upgrade because of conflict with existing NS records. It became clear that external-dns isn't ready for diverse-recordtype ownership. That's what started the project scope discussion above.

From my point of view, either the CRD source needs new documentation stating the allowed Record Types, OR external-dns needs to grow support for more record-types somehow. The latter seems to be a bit tricky 😄 Currently, the example CRD in this repository implies it can manage any record:

                    recordType:
                      description: RecordType type of record, e.g. CNAME, A, SRV, TXT etc

(I personally wanted A/AAAA, MX, TXT, SSHFP, etc and ended up writing/running my own external-dns-like controller [1] to do everything I originally wanted from external-dns. I know this isn't reasonable for many, so seeing a conclusion here would still be 💯 )

[seanmalloy]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

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

[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:

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

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

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

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:

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

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

/close

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.