Feature Request: Support Route53 Domains

[hashibot]

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.

[dcousens]

Any progress here?

[dcousens]

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.

[bflad]

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.

[dcousens]

@bflad why not mirror how ACM certificates are handled?

[tdmalone]

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.

[tdmalone]

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:

• importing existing registered domains
• managing nameservers, contacts, auto renew, domain locking etc. on those domains

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!

[ghost]

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?

[tdmalone]

@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!

[ghost]

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...

[tdmalone]

The Go SDK docs - just in case some API functions aren’t implemented. And, taking cues from how existing resources are implemented.

[moosakhalid]

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.

[gazoakley]

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.

[supervacuum]

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.

[rayterrill]

👍

[gtirloni]

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.

[ghost]

@gazoakley May you link us to the branch you're working on?

[virgofx]

Would really love to see this implemented/fixed. It's been many years now and it's still necessary!

[ofirshtrull]

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?

[gazoakley]

@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.

[machbio]

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

[n10000k]

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

[mmachenry]

@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.

[olenm]

@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 ]  )))}   "
  }
}

[b3n-j4m1n]

Has there been any further progress on this or the aws_route53domains_domain resource?

[ghost]

I'm not sure, tbh. I haven't looked at this in a while.

[ughstudios]

this isnt ever going to be added i would assume

[eytanhanig]

this isnt ever going to be added i would assume

Perhaps not by Hashicorp or the official maintainers, however I am unaware of any evidence that suggests they would reject this should a community member choose to do the work themselves. It's a subtle but important difference.

[akerl]

https://github.com/hashicorp/terraform/blob/main/.github/CONTRIBUTING.md Suggests that for the moment, no, they wouldn’t accept a community PR.

[garyp]

@akerl that link is for Terraform Core. Route53 Domains support would be implemented in the Terraform AWS Provider (the repository that contains this issue), not Terraform Core. Here are their contribution guidelines: https://github.com/hashicorp/terraform-provider-aws/tree/main/docs/contributing

[amannm]

Is there some specific reason none of the domain registration services for any of the providers are available via Terraform? Legal or security issues or something? Disappointing to work with this wrinkle... have to do aws route53domains update-domain-nameservers in some weird little interim step in my workflow...

[breathingdust]

Hi all 👋 Just letting you know that this is issue is featured on this quarters roadmap. If a PR exists to close the issue a maintainer will review and either make changes directly, or work with the original author to get the contribution merged. If you have written a PR to resolve the issue please ensure the "Allow edits from maintainers" box is checked. Thanks for your patience and we are looking forward to getting this merged soon!

[github-actions]

This functionality has been released in v4.4.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

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.