You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is not possible to create reverse DNS records using aws_route53_record.
Minimal working example:
resource "aws_route53_zone" "my_private_zone" {
name = "terraform.example.org"
}
resource "aws_route53_record" "reverse_record" {
zone_id = "${aws_route53_zone.my_private_zone.id}"
name = "1.0.168.192.in-addr.arpa"
type = "PTR"
ttl = "300"
records = ["node1.terraform.example.org"]
}
Problem: this results in a DNS record that includes the zone name: 1.0.168.192.in-addr.arpa.terraform.example.org.. Trying to work around this problem by terminating the record entry with a dot doesn't work either:
I'm not sure if this is safe to do. This method was introduced in #1279 which fixes quite a lot of issues regarding updating of DNS records (i.e. #1126, #1264 and #1122). So this might need some more testing.
The text was updated successfully, but these errors were encountered:
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.
ghost
locked and limited conversation to collaborators
Apr 28, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It is not possible to create reverse DNS records using
aws_route53_record
.Minimal working example:
Problem: this results in a DNS record that includes the zone name:
1.0.168.192.in-addr.arpa.terraform.example.org.
. Trying to work around this problem by terminating the record entry with a dot doesn't work either:This is all caused by the method
expandRecordName
in/builtin/providers/aws/resource_aws_route53_record.go
.I think this can be fixed by the following adjustment:
I'm not sure if this is safe to do. This method was introduced in #1279 which fixes quite a lot of issues regarding updating of DNS records (i.e. #1126, #1264 and #1122). So this might need some more testing.
The text was updated successfully, but these errors were encountered: