- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
This is definitely a case where engaging the support team is the right answer. Because the resource is owned by another account there's nothing that you can (directly) do here.
One thing I can think of is that the subdomain definition in the domain's hosted zone is still pointing to the former employee's Route 53, where he set up a hosted zone to control the subdomain. If that is the case, you should create your own hosted zone for that subdomain and then change the NS records for the subdomain in the hosted zone of the domain to NS records define in the subdomain's hosted zone. Then you can add the Aliased A records to the subdomain's hosted zone. Something like this:
Current Company Hosted Zone (company.com):
sub.company.com NS - NS1, NS2, NS3
Current Ex-Employee's Hosted Zone:
sub.company.com NS - NS1, NS2, NS3
sub.company.com A (alias) - Employee CloudFront Distribution
To fix this:
New Company Hosted Zone (sub.company.com)
sub.company.com NS - NS4, NS5, NS6
sub.company.com A (alias) - Company CloudFront Distribution
Modified Company Hosted zone (company.com)
sub.company.com NS - NS4, NS5, NS6
The setup we found is close to what you have mentioned in your answer. We did remove all DNS records pointing to the hosted subzone and created a new hosted zone in the appropriate sub account. We also created a completely new bucket, Cloudfront distribution and a
Route53 A Alias
record to point towards the new distribution. Unfortunately, no matter what you point to -- it always opens the old Cloudfront distribution. We suspect it might be related to the TLS certificates which were probably also created under the personal account.Any other ideas we can try?
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html You must own the domain name, or have authorization to use it, which you verify by adding an SSL/TLS certificate.
As a troubleshooting step, I would change the value of the subdomain to a known value, like 1.1.1.1. Then run a 'dig' against the subdomain to verify that you truly have control of the subdomain. If it does not return 1.1.1.1, you know something is still not correct with the DNS setup. You can also do a 'dig NS subdomain' to verify that the NS records.
Though the TLS certificate won't affect the routing, I would create a new one on ACM and use that in your CloudFront distribution.
Yes, we have tried troubleshooting the hosted zone the same way you suggested. The DNS records are indeed updated properly and point to the IP we define (i.e.
1.1.1.1
).$ dig +noall +answer +multiline dev.local.domain A dev.local.domain. 30 IN A 1.1.1.1
But the moment we change it back to an
A Alias
record pointing to the new distribution id we end up in the same situation as previously mentioned.Of course we are also assigning the newly generated ACM certificates as well. Any further ideas?
Thank you for your suggestions!
Contenuto pertinente
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 9 mesi fa
- AWS UFFICIALEAggiornata un anno fa
We have reached out to suppor and it does indeed seem like the only viable option in our case. Thank you for your help!