AWS NLB in dual-stack does not create AAAA record

[TomBillietKlarrio]

When creating an AWS Network-load-balancer in dual-stack mode, external-dns does not create a AAAA record in route53. It works perfectly fine in the same setup with an ALB

What happened: Only an A record is created

What you expected to happen: an AAAA record to be created

How to reproduce it (as minimally and precisely as possible):
Deploy the following service:

apiVersion: v1
kind: Service
metadata:
  namespace: default
  name: nlb-sample-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    external-dns.alpha.kubernetes.io/hostname: my.host.example.com
    service.beta.kubernetes.io/aws-load-balancer-ip-address-type: dualstack
spec:
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
    - name: https
      port: 443
      targetPort: 80
      protocol: TCP
  type: LoadBalancer
  selector:
    app: nginx

Anything else we need to know?:

Environment:

• External-DNS version (use external-dns --version): 0.13.5
• DNS provider: AWS-route53

[cdobbyn]

@szuecs - Responding to this.

In our case most traffic goes through ingress-nginx controller's load balancer service which defines the annotations:

service.beta.kubernetes.io/aws-load-balancer-type: nlb
service.beta.kubernetes.io/aws-load-balancer-ip-address-type: dualstack

The AWS Load Balancer Controller configures the NLB based on those annotations. I'll dig around and see if I can figure out the golang, but this is all spaghetti to me.

This "should" be covered by the extractLoadBalancerTargets function under service.go but I dunno.

[vaskozl]

We see the same thing for a dual stack NLB where the targets (ingerss-nginx) all listen on IPv6:

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-ip-address-type: dualstack
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: 'false'
    service.beta.kubernetes.io/aws-load-balancer-scheme: internal
    service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: preserve_client_ip.enabled=true
  name: example-service
  namespace: ingress-nginx
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ipFamilyPolicy: SingleStack
  ipFamilies:
    - IPv6
  ports:
    - name: http
   ...

So NLB <-> ingress-nginx is IPv6 only, but everything uses the NLB with IPv4 since the AAAA record doesn't get created. Deleting the TXT/A record does not help as only they are recreated with the corresponding AAAA alias to the NLB.

[james-callahan]

Duplicate of #1877

I'm hoping it might have been fixed with #2461 ?

[TomBillietKlarrio]

Duplicate of #1877

I'm hoping it might have been fixed with #2461 ?

This is a different issue in my opinion. 1877 is about AAAA records not being created if you switch from ipv4-only to dualstack. This is indeed also an issue, but not the one we're seeing.

This issue is about using an NLB. There I never manage to let it create AAAA record. Also not if you create a branch new loadbalancer, which works fine with the ALB.

[johngmyers]

This will be fixed with #3605

[TomBillietKlarrio]

OK, that would be cool. Any idea on the timing?

[johngmyers]

Things are likely to remain stalled around here until September, when I meet a key requirement for becoming an approver.

[TomBillietKlarrio]

Thx. I should be able to defend that timeline internally.

[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