External-dns: Ingress TTL annotation ignored on AWS when using ELB (ALIAS records)

[yurrriq]

With an Ingress specified like this:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    external-dns.alpha.kubernetes.io/ttl: "10"

and an external-dns Container like this:

name: external-dns
image: registry.opensource.zalan.do/teapot/external-dns:v0.5.0-alpha.0
args:
- --source=ingress
- --provider=aws
- --aws-zone-type=public
- --registry=txt
- --txt-owner-id=k8s

Route 53 reports TTLs of 300, not 10.

[njuettner]

I think you're pointing to an ELB which means the DNS entry is using ALIAS. Therefore you can't set a TTL.

https://github.com/kubernetes-incubator/external-dns/blob/d68657d9cb42180b356ccfbb1695f615d06e2aee/provider/aws.go#L406-L412

[njuettner]

However if you would use an additional annotation "external-dns.alpha.kubernetes.io/target" with an IPv4 address it would work because then you would not use an ALIAS or by using a hostname it would create a CNAME

[yurrriq]

You’re right. This is ok for us. Thanks.

[yurrriq]

It looks like you want to turn this into a documentation opportunity, so shall I leave the issue open?

[njuettner]

I agree, we need to clean this up.

[dezmodue]

Hi, ran into this today, the TTL annotation is not completely ignored because external-dns keeps trying to set the TTL rather than ignoring it completely:

time="2018-04-27T15:11:31Z" level=info msg="Record in zone mydomain.io. were successfully updated"
time="2018-04-27T15:12:32Z" level=info msg="Desired change: UPSERT external-dns-example-1.mydomain.io A"
time="2018-04-27T15:12:32Z" level=info msg="Desired change: UPSERT external-dns-0-external-dns-example-1.mydomain.io TXT"
time="2018-04-27T15:12:32Z" level=info msg="Record in zone mydomain.io. were successfully updated"
time="2018-04-27T15:13:32Z" level=info msg="Desired change: UPSERT external-dns-example-1.mydomain.io A"
time="2018-04-27T15:13:32Z" level=info msg="Desired change: UPSERT external-dns-0-external-dns-example-1.mydomain.io TXT"
time="2018-04-27T15:13:32Z" level=info msg="Record in zone mydomain.io. were successfully updated"
time="2018-04-27T15:14:33Z" level=info msg="Desired change: UPSERT external-dns-example-1.mydomain.io A"
time="2018-04-27T15:14:33Z" level=info msg="Desired change: UPSERT external-dns-0-external-dns-example-1.mydomain.io TXT"
time="2018-04-27T15:14:33Z" level=info msg="Record in zone mydomain.io. were successfully updated"

I would prefer a clear warning in the logs and no attempts to set the TTL since it is not going to succeed

If this behaviour is ok I could attempt a PR with some guidance

[marandalucas]

@yurrriq Could you write an example please?
I tried with differents annotations but it didn't work, always create recordset with ALIAS and 300 TTL.
It is strange because in the logs, i can see that delete the CNAME with 60 and recreate with ALIAS 300 TTL.

This is my example

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: service1-ingress
  annotations:
    external-dns.alpha.kubernetes.io/hostname: service1.ephemeral.env
    # If I use the following annotation, the behavior is the same.
    # external-dns.alpha.kubernetes.io/target: ad5c63e15f4c111e88a1f0a648167a31-3fa9296110286d50.elb.eu-west-1.amazonaws.com
    external-dns.alpha.kubernetes.io/ttl: "60"
spec:
  rules:
  - host: service1.ephemeral.env
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: 80

time="2018-12-10T14:57:37Z" level=debug msg="Endpoints generated from ingress: kube-system/service1-ingress: [service1.ephemeral.env 60 IN CNAME ad5c63e15f4c111e88a1f0a648167a31-3fa9296110286d50.elb.eu-west-1.amazonaws.com map[] service1.ephemeral.env 60 IN CNAME ad5c63e15f4c111e88a1f0a648167a31-3fa9296110286d50.elb.eu-west-1.amazonaws.com map[]]"
time="2018-12-10T14:57:37Z" level=debug msg="Removing duplicate endpoint service1.ephemeral.env 60 IN CNAME ad5c63e15f4c111e88a1f0a648167a31-3fa9296110286d50.elb.eu-west-1.amazonaws.com map[]"
time="2018-12-10T14:57:37Z" level=debug msg="Considering zone: /hostedzone/ZCGLPOH6572KT (domain: ephemeral.env.)"
time="2018-12-10T14:57:37Z" level=debug msg="Considering zone: /hostedzone/ZCGLPOH6572KT (domain: ephemeral.env.)"
time="2018-12-10T14:57:37Z" level=debug msg="Considering zone: /hostedzone/ZCGLPOH6572KT (domain: ephemeral.env.)"
time="2018-12-10T14:57:37Z" level=debug msg="Adding service1.ephemeral.env. to zone ephemeral.env. [Id: /hostedzone/ZCGLPOH6572KT]"
time="2018-12-10T14:57:37Z" level=debug msg="Adding service1.ephemeral.env. to zone ephemeral.env. [Id: /hostedzone/ZCGLPOH6572KT]"
time="2018-12-10T14:57:37Z" level=info msg="Desired change: UPSERT service1.ephemeral.env A"
time="2018-12-10T14:57:37Z" level=info msg="Desired change: UPSERT service1.ephemeral.env TXT"
time="2018-12-10T14:57:37Z" level=info msg="2 record(s) in zone ephemeral.env. were successfully updated"

[yurrriq]

@marandalucas, I'm not sure what you're looking for. It sounds like we're having the same experience.

[marandalucas]

@yurrriq I'm sorry i had a misunderstanding, i thought that you found a workaround.
have you been able to modify the ttl by default?

@njuettner What is the progress of this issue? Thanks for all

[yurrriq]

No, I gave up, and was satisfied with the explanation that Amazon's ALIAS records assume the TTL of their targets.

[rafaelmagu]

@dezmodue did you end up getting your PR into the codebase? I'm seeing the same log messages on my environments. Removing the TTL annotation from the service prevents newer log messages from appearing.