Hello,
We are receiving an error in Virtualmin when trying to set up the new Amazon Route 53 Cloud DNS Provider feature. No matter what access key ID and secret access key we enter, and no matter what AWS region we select, Virtualmin always gives the following error message:
Failed to save cloud DNS provider: AWS credentials are not valid.
We have tried with our AWS root account access key ID and secret access key, along with a custom IAM user we created specifically for Route 53 that was given full access to the Route 53 service. Both sets of credentials produced the same error, even though the root account credentials have been used successfully outside of Virtualmin in the past to access other AWS services.
How can we resolve this issue, or at least determine the specific error in this case? Thank you in advance for any assistance provided.
Comments
Submitted by JamieCameron on Fri, 07/02/2021 - 23:00 Comment #1
I tested this with a couple of my own accounts, but wasn't able to reproduce the problem.
Are you sure there isn't a space or something at the start and end of the credentials? Note that the access key and secret key are different from your AWS console login.
Submitted by JEMEDIACORP on Fri, 07/02/2021 - 23:13 Pro Licensee Comment #2
Hello Jamie,
I have double-checked that there are no spaces in either the access key ID or secret access key. I also tried with the credentials of a friend of mine and I received the same error from Virtualmin as originally mentioned. Is there any way to perhaps view the exact response returned by AWS or to view any debug information so we can determine the exact cause of the issue?
Thanks!
Submitted by JamieCameron on Fri, 07/02/2021 - 23:17 Comment #3
Are you able to use those same credentials to configure Virtualmin to backup to Amazon S3, on the Cloud Storage Providers page?
Submitted by JEMEDIACORP on Fri, 07/02/2021 - 23:47 Pro Licensee Comment #4
I already have backups configured to use Linode's S3-compatible object storage service, and it doesn't look like I can configure a second copy of the S3 backup configuration to use Amazon. Is there another way I can debug the Route 53 credentials issue? Does Virtualmin log the response from AWS? I am using my root user access key ID and secret access key so they should work for any AWS service.
Submitted by JamieCameron on Tue, 07/06/2021 - 16:08 Comment #5
Ah, I think I see the issue - the same setting that controls the endpoint for S3-compatible backups is also used for Route53 calls. I assume that Linode only supports S3?
Submitted by JEMEDIACORP on Tue, 07/06/2021 - 16:11 Pro Licensee Comment #6
Ah, that would seem to explain some things. Linode does have its own hosted DNS service (similar to Route 53), but it must be accessed over Linode's REST API; it doesn't support using access key IDs and secret access keys. I am hoping Virtualmin will implement support for other hosted DNS solutions besides Route 53, like Linode's, but until then is it possible to de-couple the cloud DNS settings in Virtualmin from the cloud backup settings so that this issue can be resolved?
Thanks!
Submitted by JamieCameron on Tue, 07/06/2021 - 19:24 Comment #7
Yes, we do plan to support other DNS hosting APIs, now that we've done the groundwork with route53 support.
Also, the next release of Virtualmin will properly separate the endpoints for S3 and Route53, so that you can have a split config like this.
Submitted by JEMEDIACORP on Tue, 07/06/2021 - 19:25 Pro Licensee Comment #8
Excellent. When is the next release planned to be made available? Is there a workaround available in the meantime? If not, I may switch our backups to Amazon S3 instead of Linode Object Storage.
Submitted by JamieCameron on Wed, 07/07/2021 - 16:19 Comment #9
It will likely be in at least a couple of week..
Submitted by JEMEDIACORP on Wed, 07/07/2021 - 20:23 Pro Licensee Comment #10
OK, that's fine. I'll switch to using Amazon S3 for our backups then rather than Linode S3 Object Storage, we chose that since it was a bit cheaper for how much data we're storing. But I am glad the issue was identified and will be corrected in an upcoming Virtualmin release.
Submitted by JEMEDIACORP on Wed, 07/07/2021 - 22:33 Pro Licensee Comment #11
Good news - I was able to switch our backup configuration to use Amazon S3 and that also allowed me to finally configure Route 53 as a cloud DNS provider without getting any errors. However, I have a few additional questions. Since we already have existing DNS zones hosted by Virtualmin through the local BIND DNS server, is there a way to tell Virtualmin to create these on Route 53 without wiping out our existing DNS records? Of course I could turn off the DNS feature and turn it back on again, and this would probably create the records in Route 53, but I don't want to lose our custom records. I could also create the DNS zone manually on Route 53 and import the records file that Virtualmin gives me, but then how do I tell Virtualmin to access this zone in Route 53 whenever it has to add a new DNS record or edit an existing one?
Finally, does Virtualmin support Route 53's reusable delegation set features? I created a reusable delegation set so that I can continue to use vanity name servers (ns1.mydomain.com, ns2.mydomain.com, etc.) as I do now and just point those custom A records to AWS's DNS servers. In this way, I don't have to change each domain's name servers (at the registrar level) to whatever AWS Route 53 gives me when the DNS zone is created there; i just have all my domains use the same reusable delegation set in Route 53 and thus they can all use my custom name servers.
Submitted by JamieCameron on Sat, 07/10/2021 - 14:12 Comment #12
There's no way yet to move a domain from local hosting to Route 53, but I'm working on it - should be in the next release.
Re-usable delegation sets sounds interesting, but we haven't looked at this at all yet.