Created a wildcard record even there is no * host record in ingress rules

[yukccy]

What happened:
I used External-DNS to create DNS records on Route53 for my dynamic environments. It works fine to create the records I need, however, it also creates A and TXT records for *.example.com.

What you expected to happen:
Only the records specified in Ingress rule are being created.

For example, in my Ingress rules, there is only one record abc.example.com. I expect only A and TXT record for abc.example.com would be created. However, there are 6 records in total, 3 for abc.example.com and 3 for *.example.com.

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}]'
    alb.ingress.kubernetes.io/load-balancer-name: ingress-test
spec:
  ingressClassName: alb
    tls:
    - hosts:
      - "*.example.com"
  rules:
  - host: abc.example.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: abc
            port: 
              number: 80

Anything else we need to know?:
values.yaml for Helm:

sources:
  - ingress
policy: sync
registry: txt
txtOwnerId: external-dns
domainFilters:
  - example.com

Log

time="2024-03-28T17:59:36Z" level=info msg="Desired change: CREATE *.example.com A [Id: /hostedzone/123]"
time="2024-03-28T17:59:36Z" level=info msg="Desired change: CREATE *.example.com TXT [Id: /hostedzone/123]"
time="2024-03-28T17:59:36Z" level=info msg="Desired change: CREATE abc.example.com A [Id: /hostedzone/123]"
time="2024-03-28T17:59:36Z" level=info msg="Desired change: CREATE abc.example.com TXT [Id: /hostedzone/123]"
time="2024-03-28T17:59:36Z" level=info msg="Desired change: CREATE cname-*.example.com TXT [Id: /hostedzone/123]"
time="2024-03-28T17:59:123" level=info msg="Desired change: CREATE cname-abc.example.com TXT [Id: /hostedzone/123]"
time="2024-03-28T17:59:37Z" level=info msg="6 record(s) in zone example.com. [Id: /hostedzone/123] were successfully updated"

Environment:

• External-DNS version (use external-dns --version): v0.14.0, Chart version v1.14.3
• DNS provider: aws
• Others:

[yukccy]

The wildcard record will not create anymore once removed the tls section under spec. I was using the Certificate Discovery feature by tls field. Now I use the Discover vis Ingress host rule method.

Reference: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.2/guide/ingress/cert_discovery/

However, I doubt a wildcard record should be created just because of using Discover vis Ingress tls method, as this is just a way of attaching TLS certificate instead of a route. Not sure if this case has been discussed before.

This is my updated ingress.yaml,

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}]'
    alb.ingress.kubernetes.io/load-balancer-name: ingress-test
spec:
  ingressClassName: alb
  rules:
  - host: abc.example.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: abc
            port: 
              number: 80

[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

[yukccy]

/remove-lifecycle stale

[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

[TomyLobo]

/remove-lifecycle stale
/remove-bot k8s-triage-robot

[TomyLobo]

In the RFC2136 provider, this actually causes errors instead of just inconveniences:

time="2024-10-29T01:03:09Z" level=info msg="error in dns.Client.Exchange: unexpected acceptor flag is not set: expecting a token from the acceptor, not in the initiator"
time="2024-10-29T01:03:09Z" level=error msg="RFC2136 create record failed: unexpected acceptor flag is not set: expecting a token from the acceptor, not in the initiator"
time="2024-10-29T01:03:09Z" level=fatal msg="Failed to do run once: RFC2136 had errors in one or more of its batches: [unexpected acceptor flag is not set: expecting a token from the acceptor, not in the initiator]"

external-dns crashes after that.

[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

[yukccy]

/remove-lifecycle rotten