_This issue was originally opened by @garyp as hashicorp/terraform#5368. It was migrated here as part of the provider split. The original body of the issue is below._
It'd be really useful if Terraform could automatically update the whois nameserver records for a domain registered through AWS Route 53 when that domain's zone is being managed via Route 53.
That is, the current aws_route53_zone
resource defines a name_servers
attribute for getting the list of nameservers that AWS assigned to the zone. For domains that are registered via Route 53 (http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html), I'd like Terraform to use the UpdateDomainNameservers API to update the domain's nameservers using the aws_route53_zone.name_servers
attribute.
It would probably make sense to model a new aws_route53_domain
resource that supports the registered domain API: https://docs.aws.amazon.com/Route53/latest/APIReference/actions-on-domain-registrations.html.
Any progress here?
trying to think ahead a bit just to make sure we get the model of aws_route53_domain as future-proof as possible.. that would presumably mean we use the following operations:
Why not provide a data
source first?
For me, that would cover off on quite a few use cases to start.
I imagine a potential issue here is testing (either a resource or data source) as most of the current provider testing relies on managing actual infrastructure. In this case, it would require real, public domain registration. Maybe its fine with domain name randomization. Another option is relying on the SDK mocking framework, which is less than ideal in many ways: https://docs.aws.amazon.com/sdk-for-go/api/service/route53domains/route53domainsiface/
For what its worth, testing the data source essentially implies implementing the Terraform resource first, since you're already implementing the create and delete functionality to a certain degree.
@bflad why not mirror how ACM certificates are handled?
From the above referenced issue, which has been consolidated here:
Unfortunately the testing is going to be a pain with this service (real public domains == $$) and will likely require usage of the
route53domainsiface
SDK package, which is something we don't do anywhere else in the project at the moment.
@bflad That's fair enough. I don't know how many domains need to be purchased for testing but I'm happy to be a part of it if it helps.
I know that this issue was renamed to support Route53 domains as a whole, but I wonder whether the cost of registration for testing is holding this back?
If so, would it be feasible to support, to start with:
The documentation could have a note that 'creation' (and deletion, if desired) of the resource is not yet supported - much like the notices on the documentation for various default resources, like aws_default_vpc
.
I'm about to move a portfolio of close to 100 domains to Route53, and being able to write a module to ensure the nameservers and contacts are managed across them, along with the DNS zones, would be absolutely fantastic!
Was this feature added?
I'm not quite clear on that.
I added a Route53 zone, for which Amazon is the Registrar, but the registered domain details, show incorrect nameservers.
I just edited them manually.
Can this be done with Terraform?
@hullsean No, this feature hasn't been added.
It probably needs someone to work on it, and then there's also the cost of testing that was pointed out above.
I have barely touched Go before, but if no-one else picks this up and I get some brain space, maybe I will try to get my feet wet with it, because I'd really love to see it!
I could help with testing.
As far as coding it, hmmm... I wouldn't know where to begin. I'm good at python, but haven't done much with Go other than go get/install packages. How does one even get started? I guess the AWS Route53 API docs...
The Go SDK docs - just in case some API functions aren鈥檛 implemented. And, taking cues from how existing resources are implemented.
Hey guys I'm new to terraform and coding :) . In learning stages at this time and hit the same issue of having to update NS's against Registered AWS domain manually when playing with Terraform. Any progress on this? If there's been work done on this already can someone provide links to the code? Would be really nice to have "aws_route53_domain" resource in aws provider module for TF.
I've been playing around with adding support and now have a branch locally with the ability to:
It doesn't look like anyone above has asked for domain registration as a use case. Is that important? It doesn't fit as well with the normal Terraform resource model since there's no way to delete domains through the API and only limited support for doing that through the console (depending on TLD).
If we want to support registration, I'd suggest:
disable_auto_renew_on_delete
- this is the closest we can get to deletionMaybe the above can be a second round of people want it.
As for testing, if we automatically read existing domains in the same manner as e.g. aws_default_security_group
we could just leave a domain for testing in the account used for integration tests. That said I agree we probably need to use mocks for these tests.
I've been playing around with adding support and now have a branch locally with the ability to:
* Enable/disable auto renewal * Enable/disable transfer locks * Enable/disable contact privacy * Update tags * Retrieve existing nameservers (I plan to allow updates) * Retrieve existing contacts
It doesn't look like anyone above has asked for domain registration as a use case. Is that important? It doesn't fit as well with the normal Terraform resource model since there's no way to delete domains through the API and only limited support for doing that through the console (depending on TLD).
If we want to support registration, I'd suggest:
* Add an attribute of something like `disable_auto_renew_on_delete` - this is the closest we can get to deletion * If the domain already exists in the account during creation just automatically read it. We need to specify the initial registration period so that also needs to be an attribute
Maybe the above can be a second round of people want it.
As for testing, if we automatically read existing domains in the same manner as e.g.
aws_default_security_group
we could just leave a domain for testing in the account used for integration tests. That said I agree we probably need to use mocks for these tests.
I see the "update name servers" use case the most useful of them all.
馃憤
Exactly. Updating name servers is our first use case. If we could have just a data source, that would be enough for most use cases. Updating domain details like contacts would come second.
Registering domains is not a priority here because it involves billing and that is still done in an oldfashioned way.
@gazoakley May you link us to the branch you're working on?
Would really love to see this implemented/fixed. It's been many years now and it's still necessary!
btw need to see if you buy a domain and then delete it via terraform destroy (some might have envs that they bring up and down on a monthly basis) if we pay per day/min or you buy it per year?
@ofirshtrull You're immediately charged for domain registration up front - if you have a credit card on file AWS will charge that immediately rather than wait until the end of the month.
resource "aws_route53_zone" "domain" {
name = var.domains["name"]
}
resource "null_resource" "updatens-domain" {
provisioner "local-exec" {
command = "aws route53domains update-domain-nameservers --region us-east-1 --domain-name ${var.domains["name"]} --nameservers Name=${aws_route53_zone.domain.name_servers.0} Name=${aws_route53_zone.domain.name_servers.1} Name=${aws_route53_zone.domain.name_servers.2} Name=${aws_route53_zone.domain.name_servers.3}"
environment = {
AWS_ACCESS_KEY_ID = var.aws_access_key
AWS_SECRET_ACCESS_KEY = var.aws_secret_key
}
}
}
This was my solution - not foolproof - but it works until terrafrom aws provider for updating name server is ready
I agree with @gtirloni my priority is I do a update or deploy a route53 change, it returns name servers.. however.. I have to update them manually.. if there was a domains option we can use that instead of constantly swapping 4 ns records out. This is needed <3
@machbio That's a great help, thank you. I'm looking forward to being able to have Terraform manage the name servers of my registered domain without such a hack, that this is definitely nice to have.
@machbio using this but updated to TF12 loop logic + trigger support => seems to get the job done in a way. After testing things it does seem to take some additional time to update; some items require email validation or web-ui confirmation - so its understandable why this remains at-large.
Hope this helps:
locals {
domain_name = "domain.com"
use_failback = false
failback_list = [
"aws-dns-1",
"aws-dns-2",
"aws-dns-3",
"aws-dns-4",
]
}
resource "null_resource" "aws_domain_com_nameservers" {
triggers = {
nameservers = join(", ",sort( local.use_failback == false ? aws_route53_zone.domain_com.name_servers : [ for ns in local.failback_list: ns ] ))
}
provisioner "local-exec" {
command = "aws route53domains update-domain-nameservers --domain-name ${local.domain_name} --nameservers ${join(" ",formatlist(" Name=%s",sort( local.use_failback == false ? aws_route53_zone.domain_com.name_servers : [ for ns in local.failback_list: ns ] )))} "
}
}
Most helpful comment
I've been playing around with adding support and now have a branch locally with the ability to:
It doesn't look like anyone above has asked for domain registration as a use case. Is that important? It doesn't fit as well with the normal Terraform resource model since there's no way to delete domains through the API and only limited support for doing that through the console (depending on TLD).
If we want to support registration, I'd suggest:
disable_auto_renew_on_delete
- this is the closest we can get to deletionMaybe the above can be a second round of people want it.
As for testing, if we automatically read existing domains in the same manner as e.g.
aws_default_security_group
we could just leave a domain for testing in the account used for integration tests. That said I agree we probably need to use mocks for these tests.