External-dns: External DNS always uses ALIAS for AWS ELBs, not CNAME (only A records are created in Route53)

Created on 21 May 2018 · 17Comments · Source: kubernetes-sigs/external-dns

I have deployed external-dns in aws, it can able to create records in route53 based on annotations used in ingress. But it is creating only A records with ALIAS. Is it possible to create CNAME instead of A records.

Ingress yaml:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    external-dns.alpha.kubernetes.io/hostname: svs.test1.example.com
    external-dns.alpha.kubernetes.io/target: internal-example-N71XM6QP6II4-4567345678.us-west-2.elb.amazonaws.com
    kubernetes.io/ingress.class: nginx-internal
  name: test-ing
  namespace: default
spec:
  rules:
  - host: svs.test1.example.com
    http:
      paths:
      - backend:
          serviceName: test-ing
          servicePort: 9411
        path: /

lifecyclrotten provideaws

Source

sujithvs74

👍8

Most helpful comment

Need a capability to create CNAME record pointing straight forward to ELB without using ALIAS. All this in terms of Service with type: LoadBalancer.

martynova1 on 11 Apr 2019

👍3

All 17 comments

Why would you want to use CNAME (extra DNS hop) instead of using Route53's ALIAS feature?

hjacobs on 22 May 2018

In case of ALIAS if we do nslookup with domain name, it will return only IPs of ELB. So it is always difficult to locate ELB in aws console to which domain is pointing. If we configure it with CNAME it will return exact ELB CNAME, which is more helpful.

sujithvs74 on 23 May 2018

@sujithvs74 you can easily find the ELB name via kubectl get ingress -o wide --- I suppose it's better to not leak the ELB information to external users/customers just for easier debugging.

UPDATE: sorry, I did not see that you use the target annotation, i.e. kubectl get ingress -o wide will not show the ELB name in your case.

hjacobs on 23 May 2018

It's currently not possible to force using CNAME when ALIAS would also work as our expectations was that most people will want to use ALIAS in that case.

The logic is: when a target looks like an ELB/ALB => use ALIAS, see: https://github.com/kubernetes-incubator/external-dns/blob/master/provider/aws.go#L461

PRs welcome: we could add a --aws-prefer-alias which defaults to true. If it's false it should make isAWSLoadBalancer to always return false or by changing the above line to something like:

// if target is a DNS name and not an IP...
if ep.RecordType == endpoint.RecordTypeCNAME {
  // ...and if looks like an ALB/ELB and we prefer ALIAS, return true
  return preferALIAS && canonicalHostedZone(ep.Targets[0]) != ""
}

linki on 23 May 2018

👍3

Why is it difficult to locate the ELB in AWS console? If you are in the console you can just take a look at Route53, the ELB name is listed in the overview.

Another problem is that CNAMEs can't be used on root domains.

We should be careful with the argument about leaking information, dig TXT leaks a lot more information than I am willing to give out.

joekohlsdorf on 23 May 2018

Our logic for selecting ALIAS records by default for ELBs (which IMHO makes absolutely sense!) causes some confusion for people who want to set TTLs, see #534

hjacobs on 29 Jun 2018

Need a capability to create CNAME record pointing straight forward to ELB without using ALIAS. All this in terms of Service with type: LoadBalancer.

martynova1 on 11 Apr 2019

👍3

Considering using Infoblox External DNS provider with AWS cloud. Will we be able to create the required CNAME entry in Infoblox? I'm assuming the AWS ALIAS feature won't be supported.

GaryAult on 3 Jun 2019

Would be awesome if you could also support record sets of typeCNAME without Alias

dbluxo on 9 Jul 2019

Is there any chance for this feature?

Some background information: Our hosted zones records are synchronized with our enterprise DNS. The record type ALIAS is an AWS proprietary record type and AWS allows you to set a DNS record directly on AWS resources. Since this is not a DNS RfC standard and therefore can not be transferred and created in our enterprise DNS (our DNS team said). So I need to force CNAME creation instead.

dbluxo on 16 Jul 2019

@dbluxo you could give https://github.com/kubernetes-incubator/external-dns/pull/1103 a try. It adds a global flag that makes ExternalDNS prefer CNAME over ALIAS.

linki on 17 Jul 2019

👍2

@linki Yes, yes, yes, it works! :confetti_ball: Thank you :heart:

dbluxo on 17 Jul 2019

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-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot on 15 Oct 2019

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

fejta-bot on 14 Nov 2019

It would be nice have it overridable via annotation. So for example one services can use CNAME and others by default ALIAS.

zdmytriv on 14 Nov 2019

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

fejta-bot on 14 Dec 2019

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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.