Terraform: route 53 changes detected even though there are no changes

Created on 10 Nov 2016  ·  17Comments  ·  Source: hashicorp/terraform

I submitted a similar problem report with the previous version and I think some of it was supposed to be solved, but I am still getting the following differences with the 7.7.10 version.

The environment has just been created with apply and a plan has been run right after. It should be showing no changes, but it shows all the following:

~ module.tst1.aws_route53_record.r53_record
alias.2190465367.evaluate_target_health: "true" => "false"
alias.2190465367.name: "prod-web-1529429951.us-west-2.elb.amazonaws.com" => ""
alias.2190465367.zone_id: "Z1H1FL5HABSF5" => ""
alias.2700809793.evaluate_target_health: "" => "true"
alias.2700809793.name: "" => "PROD-WEB-1529429951.us-west-2.elb.amazonaws.com"
alias.2700809793.zone_id: "" => "Z1H1FL5HABSF5"

~ module.tst1.aws_security_group.admin
ingress.#: "3" => "1"
ingress.1938540428.cidr_blocks.#: "1" => "0"
ingress.1938540428.cidr_blocks.0: "199.58.192.98/32" => ""
ingress.1938540428.from_port: "8091" => "0"
ingress.1938540428.protocol: "tcp" => ""
ingress.1938540428.security_groups.#: "0" => "0"
ingress.1938540428.self: "false" => "false"
ingress.1938540428.to_port: "8091" => "0"
ingress.3897505941.cidr_blocks.#: "3" => "0"
ingress.3897505941.cidr_blocks.0: "199.58.192.98/32" => ""
ingress.3897505941.cidr_blocks.1: "35.160.166.68/32" => ""
ingress.3897505941.cidr_blocks.2: "35.161.227.236/32" => ""
ingress.3897505941.from_port: "22" => "0"
ingress.3897505941.protocol: "tcp" => ""
ingress.3897505941.security_groups.#: "0" => "0"
ingress.3897505941.self: "false" => "false"
ingress.3897505941.to_port: "22" => "0"
ingress.4282511762.cidr_blocks.#: "1" => "1"
ingress.4282511762.cidr_blocks.0: "10.5.101.236/32" => "10.5.101.236/32"
ingress.4282511762.from_port: "22" => "22"
ingress.4282511762.protocol: "tcp" => "tcp"
ingress.4282511762.security_groups.#: "0" => "0"
ingress.4282511762.self: "false" => "false"
ingress.4282511762.to_port: "22" => "22"

~ module.tst1.lb_id.aws_route53_record.r53_record
alias.1412314257.evaluate_target_health: "true" => "false"
alias.1412314257.name: "prod-id-1538439218.us-west-2.elb.amazonaws.com" => ""
alias.1412314257.zone_id: "Z1H1FL5HABSF5" => ""
alias.1713183629.evaluate_target_health: "" => "true"
alias.1713183629.name: "" => "PROD-ID-1538439218.us-west-2.elb.amazonaws.com"
alias.1713183629.zone_id: "" => "Z1H1FL5HABSF5"

~ module.tst1.lb_solr.aws_route53_record.r53_record
alias.1351171064.evaluate_target_health: "" => "true"
alias.1351171064.name: "" => "internal-PROD-SOLR-236462827.us-west-2.elb.amazonaws.com"
alias.1351171064.zone_id: "" => "Z1H1FL5HABSF5"
alias.907506756.evaluate_target_health: "true" => "false"
alias.907506756.name: "internal-prod-solr-236462827.us-west-2.elb.amazonaws.com" => ""
alias.907506756.zone_id: "Z1H1FL5HABSF5" => ""

~ module.tst1.lb_ui.aws_route53_record.r53_record
alias.2037855967.evaluate_target_health: "" => "true"
alias.2037855967.name: "" => "PROD-UI-85055216.us-west-2.elb.amazonaws.com"
alias.2037855967.zone_id: "" => "Z1H1FL5HABSF5"
alias.884876570.evaluate_target_health: "true" => "false"
alias.884876570.name: "prod-ui-85055216.us-west-2.elb.amazonaws.com" => ""
alias.884876570.zone_id: "Z1H1FL5HABSF5" => ""

~ module.tst1.lb_web.aws_route53_record.r53_record
alias.2190465367.evaluate_target_health: "true" => "false"
alias.2190465367.name: "prod-web-1529429951.us-west-2.elb.amazonaws.com" => ""
alias.2190465367.zone_id: "Z1H1FL5HABSF5" => ""
alias.2700809793.evaluate_target_health: "" => "true"
alias.2700809793.name: "" => "PROD-WEB-1529429951.us-west-2.elb.amazonaws.com"
alias.2700809793.zone_id: "" => "Z1H1FL5HABSF5"

bug provideaws

Most helpful comment

Hi @brantburnett

I am working on a solution that will work for all of these - we have a number of issues linked in the Alias

P.

All 17 comments

For me this problem seems to be related to upper and lower case of the DNS name of your record. We had the same issue with route53 and changed to lower case. This worked for us, as a quick work around.

It seems like terraform accepts upper case DNS records but transform them into lower case DNS records , but does not reflect this in the tf.state file.

Cheers
Ole

Thanks – this workaround works!

Tom Stachura

From: ole-flaregames [mailto:[email protected]]
Sent: Monday, November 14, 2016 06:45
To: hashicorp/terraform [email protected]
Cc: Tom Stachura [email protected]; Author [email protected]
Subject: Re: [hashicorp/terraform] route 53 changes detected even though there are no changes (#10007)

For me this problem seems to be related to upper and lower case of the DNS name of your record. We had the same issue with route53 and changed to lower case. This worked for us, as a quick work around.

It seems like terraform accepts upper case DNS records but transform them into lower case DNS records , but does not reflect this in the tf.state file.

Cheers
Ole


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/hashicorp/terraform/issues/10007#issuecomment-260352937 , or mute the thread https://github.com/notifications/unsubscribe-auth/ACJzodcZTKm61bjfJPqYuVUsRvyUrn-7ks5q-HPngaJpZM4KuLfU . https://github.com/notifications/beacon/ACJzoSGHtwudTmUI8N5M6cBkMdQ7A04yks5q-HPngaJpZM4KuLfU.gif

So - in our case, we're seeing the exact same thing, but the upper->lower conversion is happening because we're using a reference to an ELB's dns_name attribute, which, based on what I see in the PLAN, has uppercase letters, that then get converted to lower within Route53. If that's going to be the case, instead of requiring that everyone use ${lower(aws_elb.my_elb.dns_name)} - can terraform just do that?

Correction: even with the lower() I'm still getting the churn on the records. I just don't know what's causing it now.

~ aws_route53_record.MY_RECORD
    alias.1663593623.evaluate_target_health: "" => "true"
    alias.1663593623.name:                   "" => "my-record-123456789.us-east-1.elb.amazonaws.com"
    alias.1663593623.zone_id:                "" => "Z3DZXE0Q79N41H"
    alias.568395318.evaluate_target_health:  "true" => "false"
    alias.568395318.name:                    "my-record-123456789.us-east-1.elb.amazonaws.com." => ""
    alias.568395318.zone_id:                 "Z35SXDOTRQ7X7K" => ""

Hi,

I used lower() as follows and it fixed my problem:

resource "aws_route53_record" "r53_record" {
zone_id = "${var.hosted_zone_id}"
name = "${lower(var.domain_prefix)}${lower(var.name)}"
type = "A"
set_identifier = "${lower(var.name)}.${var.hosted_zone}-NA"
geolocation_routing_policy {
continent = "NA"
}
alias {
name = "${var.dns_name}"
zone_id = "${var.zone_id}"
evaluate_target_health = true
}
}

Tom Stachura

From: Brice Ruth [mailto:[email protected]]
Sent: Thursday, November 17, 2016 07:27
To: hashicorp/terraform [email protected]
Cc: Tom Stachura [email protected]; Author [email protected]
Subject: Re: [hashicorp/terraform] route 53 changes detected even though there are no changes (#10007)

Correction: even with the lower() I'm still getting the churn on the records. I just don't know what's causing it now.

~ aws_route53_record.MY_RECORD
alias.1663593623.evaluate_target_health: "" => "true"
alias.1663593623.name: "" => "my-record-123456789.us-east-1.elb.amazonaws.com"
alias.1663593623.zone_id: "" => "Z3DZXE0Q79N41H"
alias.568395318.evaluate_target_health: "true" => "false"
alias.568395318.name: "my-record-123456789.us-east-1.elb.amazonaws.com." => ""
alias.568395318.zone_id: "Z35SXDOTRQ7X7K" => ""


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/hashicorp/terraform/issues/10007#issuecomment-261276796 , or mute the thread https://github.com/notifications/unsubscribe-auth/ACJzoflUAviKHK4J_PUGLNXR3SeheyaHks5q_HJZgaJpZM4KuLfU . https://github.com/notifications/beacon/ACJzofz9ML3iLZlKZNOnIHgbej6BbT_iks5q_HJZgaJpZM4KuLfU.gif

I'm having this same issue, and none of my records are capitalized. What it looks like it's trying to change is the associated zone_id?

My terraform code

resource "aws_route53_record" "my_record" {
zone_id = "${aws_route53_zone.myorg.zone_id}"
name = "myrecord.myorg.com"
type = "A"
alias {
name = "${aws_elb.app-elb.dns_name}"
zone_id = "${aws_elb.app-elb.zone_id}"
evaluate_target_health = false
}
}

and every time I run terraform it wants to change the zone id

~ aws_route53_record.myrecord
alias.1749073404.evaluate_target_health: "" => "false"
alias.1749073404.name: "" => "myelb-123456789.us-west-2.elb.amazonaws.com"
alias.1749073404.zone_id: "" => "Z33MTJ483KN6FU"
alias.2112022487.evaluate_target_health: "false" => "false"
alias.2112022487.name: "myelb-123456789.us-west-2.elb.amazonaws.com." => ""
alias.2112022487.zone_id: "Z1H1FL5HABSF5" => ""

I can report the same behavior with no mixed-case records. At first I thought it had something to do with "evaluate_target_health", since it seems to be attempting to switch it to "false" no matter what.

alias.568395318.evaluate_target_health: "true" => "false"

@kendrickm I had the same problem, try this instead:

resource "aws_route53_record" "my_record" {
  zone_id = "${aws_route53_zone.myorg.zone_id}"
  name = "myrecord.myorg.com"
  type = "A"
  alias {
    name = "${lower(aws_elb.app-elb.dns_name)}"
    zone_id = "${aws_elb.app-elb.zone_id}"
    evaluate_target_health = false
  }
}

My issue was that the name of the ELB had caps, so it was confusing the alias portion when AWS converted to lowercase.

Brant

Hi @brantburnett

I am working on a solution that will work for all of these - we have a number of issues linked in the Alias

P.

@stack72 any update on this?

BTW, we have the same issue in eu-west-1. I can see this other bug that might be related: https://github.com/aws/aws-cli/issues/1761

Specially interesting is the comment about the migration of zones in aws: https://github.com/aws/aws-cli/issues/1761#issuecomment-191729971

I actually make it work by hardcoding the zone_id for in our case (reported by the update all the time) and adding a "dot" . at the end of the domain provided by the elb.

Edit: At the beginning I though that adding a dot was also required, but it is not the case.

I think the problem of the dot in the domain can be solved in the provider, but not sure about the zone_id issue. It the comment in https://github.com/aws/aws-cli/issues/1761#issuecomment-191729971 is right, maybe the problem is in AWS itself for some regions and the AWS support has something to say :-m.

BTW, my diff to make it work (eu-west-1, Terraform v0.8.5):

diff --git a/terraform/cloudfoundry/dns-records.tf b/terraform/cloudfoundry/dns-records.tf
index 68a7db9..21d0ba4 100644
--- a/terraform/cloudfoundry/dns-records.tf
+++ b/terraform/cloudfoundry/dns-records.tf
@@ -60,8 +60,8 @@ resource "aws_route53_record" "apps_apex" {
   type    = "A"

   alias {
-    name                   = "${aws_elb.cf_router.dns_name}"
-    zone_id                = "${aws_elb.cf_router.zone_id}"
+    name                   = "${aws_elb.cf_router.dns_name}."
+    zone_id                = "Z32O12XQLNTSW2"
     evaluate_target_health = true
   }
 }

I want to also highlight that this issue is not happening for our dev environments, which we destroy frequently. It happens in CI, staging and Prod, which we did not reprovision as often (or ever at all). I say this because maybe the zone_id being reported back by the AWS API for the ELBs is different if the ELB was created recently or not.

I have the theory that there was some kind of migration in AWS, and they changed the zone_id of the ELBs to be used in the route53 alias, but the elbs created before keep reporting the old zone_id, meanwhile the route53 does automatically translate to the new one.

I created a example case: https://gist.github.com/keymon/ebf576110399fcb5790670623f16a71c

@stack72 If I am not wrong the solution can be have two values for the alias.zone_id in the route53 record in https://github.com/hashicorp/terraform/blob/7d6b3b80b94ecbab6a6c277ad6131038bf9180c0/builtin/providers/aws/resource_aws_route53_record.go#L92-L96 .

One to keep track the value provided by the user, and that would be used to create/update if the value changes. And then other Computed: true to keep track of the value returned by the API. If the user does not change the value and the value returned by the AWS is the same, there is no need to update.

What do you think?

@keymon I have an Route53 A record pointing to an ELB. Hard-coding the zone_id and adding a . to the name fixed the dirty thrashing for me. Thanks.

Terraform version: v0.8.7
AWS Region: us-east-1

The mentioned fixes don't help me. The only weird looking thing is that for the outgoing resource it is keeping evaluate_target_health set to false.

~ aws_route53_record.chef_oh-pub
    alias.3043200995.evaluate_target_health: "" => "false"
    alias.3043200995.name:                   "" => "internal-chef-oh-aws-enova-com-2043497653.us-east-2.elb.amazonaws.com."
    alias.3043200995.zone_id:                "" => "Z3AADJGX6KTTL2"
    alias.488908475.evaluate_target_health:  "false" => "false"
    alias.488908475.name:                    "internal-chef-oh-aws-enova-com-2043497653.us-east-2.elb.amazonaws.com." => ""
    alias.488908475.zone_id:                 "Z3AADJGX6KTTL2" => ""

@grimm26 I had a diff very similar to that. Like in your diff, the zone ID matched and ELB name matched (in case and number of dots). terraform apply wouldn't fix it.

I had the "dualstack" subdomain of the ELB name in my config. Removing the "dualstack." prefix and using the exact same ELB name that appeared in the diff made terraform plan clean again. I guess the name canonicalisation isn't totally consistent somewhere.

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

carl-youngblood picture carl-youngblood  ·  3Comments

ronnix picture ronnix  ·  3Comments

ketzacoatl picture ketzacoatl  ·  3Comments

shanmugakarna picture shanmugakarna  ·  3Comments

rjinski picture rjinski  ·  3Comments