I'd like to move our DNS management from DO to AWS.
I've updated the DNS on the DO to point to AWS Route 53 nameservers and added the records on route 53 in preparation.
After setting the NS records for the domain, it seems like it hasn't yet propagated. My experience has been that DNS changes typically take a couple of minutes, unless I've made a mistake somewhere (albeit often it's said that it can take between 24-48 hours).
After running some dig commands, it seems like the NS records are still pointing to digital ocean.
Should I have made additional changes to get this to work?
Where is your domain "registered"? You'll probably want to change the NS records in Route53 (as it seems like you've done already), but you'll also need to change them with your domain registrar who ultimately defines your name servers. So, if it's registered in Route53, then you'll need to go in to Route53 -> Registered domains and you'll see "Name servers" in there - they'll be pointing to your old name servers I suspect. If it's not Route53 where you've got your domain registered, it'll be a similar process whether your domain is registered with Gandi, GoDaddy, 1&1, eNom or wherever.
Related
I am having trouble generating a HTTPS certificate from the AWS Certificate Manager, which is stuck in Pending Validation for more than 24 hours. I found this tutorial by AWS that gives some potential clues on how to solve the problem: https://www.youtube.com/watch?v=MBGo8m6UET8
One of the steps suggests running dig on the domain and comparing against the name servers in my hosted zone. When I run dig NS <my_domain> I get:
;; ANSWER SECTION:
<my_domain>. 0 IN NS ns-1144.awsdns-15.org.
<my_domain>. 0 IN NS ns-68.awsdns-08.com.
<my_domain>. 0 IN NS ns-1885.awsdns-43.co.uk.
<my_domain>. 0 IN NS ns-718.awsdns-25.net.
In my Route53 I have a hosted zone for <my_domain> with a NS record, which was created automatically, that points to:
ns-1309.awsdns-35.org.
ns-381.awsdns-47.com.
ns-1859.awsdns-40.co.uk.
ns-722.awsdns-26.net.
As far as I understood the name servers should match in both places, so I don't know why they don't. Should I be concerned? How should I fix this?
EDIT: I found the fix to my problem. The name servers that appear on the Hosted Zone:
need to be set as name servers on the domain here:
The values returned by dig are taken direct from DNS. As the NS (name server) records dont match your zone in Route53, that isnt the zone hosting your domain. There is a Route53 zone setup somewhere in AWS that hosts <my_domain> but thats not it. Do you have multiple zones in Route53, or multiple accounts perhaps - maybe your using the wrong one? Otherwise look to anyone previously involved with <my_domain>'s hosting - its probably in their aws account.
Yes you should be concerned, you do not have access to your own DNS, and some other account owns that zone in Route53. You need to resolve this issue to use domain validation in ACM or otherwise make changes to <my_domain>.
The NS values seen in dig come from the company you registered the domain name (the "registrar") - they will have a web portal. Somewhere in there will be an option for "custom name servers" or similar for your domain. They will currently be set to the values seen in dig. You need to set those to your Route53 zones name servers instead if you want to manage the DNS for the domain with that Route53 zone.
WARNING - changing name servers will effectively remove all DNS records provided by the current Route53 zone that dont already exist in your Route53 zone (once the TTL expires). This could break stuff - websites, email, 3rd party integrations etc. You should ideally get the current owner to export the zone file and then you can import it to avoid loosing any records.
If thats not possible and depending on how complicated <my_domain> is you might be able to dig DNS and retrieve enough info to setup your own route53. You need to ensure all A, CNAME, TXT, MX, etc records that exist in dns exist in your zone for the apex (<my_domain>) and any subdomains (eg www.<my_domain>). This approach is very risky and probably wont get all the records - this could break anything related to <my_domain> or any of its subdomains. This is a last resort, not a good idea ;-)
I am confused on the process of how to point a subdomain of an EC2 instance which is being run behind an ALB. The Target Group has port 80 which will then Redirect traffic to 443 and then a second Target Group which has the SSL certificate for 443. I have read online that I would need to create a hosted zone in Route 53 of the subdomain (e.g. apples.ilovefruits.org) and setup an ALIAS of the ALB. My domain and subdomains are hosted on Bluehost. The error I receive on the website to enter is a "403 Forbidden":
Would appreciate any help on this to get this to work.
UPDATE:
Should I replace the NS records of Route 53 with Bluehosts NS records?
I have read online that I would need to create a hosted zone in Route 53 of the subdomain (e.g. apples.ilovefruits.org) and setup an ALIAS of the ALB.
That's not true. You can delegate a subdomain and create an ALIAS record in Route 53, or you can create a CNAME record within your current dns provider.
An ALIAS record is an A record that will automatically resolve to an IP for the ALB without an intermediate CNAME lookup. This is great, but by no means necessary. An ALIAS record is a Route53-specific integration to other AWS resources.
Delegating a subdomain to route53 - at the cost of $0.50 a month plus a few cents per millions of requests - makes it more convenient to create with AWS dns records within that subdomain. It's especially useful if you're creating a lot of dns records that point to things in AWS. Creating records in your current DNS provider by hand is often an adequate solution until you're creating more than a few.
A route53 subdomain is also convenient if you're going to use ACM, amazon's cert issuing service. These certs are free, secure, and - if you use DNS validation - can renew automatically. If the domain of the certificate is in route53, the aws console for ACM will have a button to automatically add the validation record - convenient, right? But you can create the same record in any DNS provider, so again, until you're doing it a few times a week, the manual approach isn't so bad.
If you were to create a CNAME, do so in your current dns provider. Create a CNAME record whose name is your desired DNS name, and the value value is the ALB's dns name provided in the ALB details in the web console. This functions fine.
If you did want to delegate the domain, start by choosing the subdomain and creating its zone in Route 53. Take note of the 4 nameservers under the NS record there. These servers are ready to respond to requests for the subdomain, but nobody's going to ask them until you add these servers to your current dns provider as NS records for the subdomain. Then, public queries for the subdomain will be referred (or "delegated") to the amazon servers.
UPDATE: Should I replace the NS records of Route 53 with Bluehosts NS records?
No, The NS records for the zone in Route 53 are ready to serve queries for your zone, but that record is not what points any queries to those servers. The record that delegates the subdomain is in the parent zone (eg ilovefruits.org). Changing that NS record essentially does nothing. Above, we're *adding new * NS records for the subdomain, not changing anything that already exists for the parent domain.
If you're curious, the same is true of ilovefruits.org itself. In that case, the domain registrar also provides NS records for ilovefruits within the .org domain. As the domain registrant, you get to choose which servers these are. You could migrate your dns to amazon by changing these settings with your registrar. But strange as it may seem, even then, the NS records for the domain within that zone aren't being consulted for most dns lookups. DNS happens from the top level out, so .org is the domain that points to ilovefruits.org; it cannot, of course, point to itself!
Don't change the NS records of the root of your dns zone unless you're sure you know what you're doing. They aren't part of normal dns lookups and will be set appropriately by the dns provider, even if your domain hasn't delegated any dns queries to them.
The error I receive on the website to enter is a "403 Forbidden":
This has nothing to do with DNS and you should diagnose it separately.
We purchased a domain from GoDaddy, for example, say mycompany.com.
My colleague then moved it to Wix.com to publish our marketing site, which will be available at the mycompany.com url. I need to add a subdomain in AWS, pointing to a Cloudfront CDN endpoint.
To shed more light into the current situation, here is a little more info:
When I check GoDaddy, it shows Nameservers, referencing the Wix servers. For DNS, it says We can't display your DNS information because your Nameservers aren't managed by us.
When I check Wix.com, I see that Managed by Third Party, Connected by DNS and still provides the option to transfer to Wix.
Both Godaddy and Wix provide the option to add a subdomain.
I'd rather do that in AWS.
What is my best option here? Should I transfer the domain to AWS and manage it there? If so, how do I then route traffic from mycompany.com to the marketing site?
Is there a way to keep it as is, but still add a subdomain on the AWS side for example.mycompany.com?
I really regret not registering this domain via AWS in the first place, but lesson learned. Any help would be much appreciated.
I am assuming that your DNS is being hosted via wix.com.
If you want to migrate to Route 53 its not actually too hard. Start by setting up a public hosted zone within Route 53 with the domain name you setup.
Next you would want to perform a zone lookup for all your DNS records, you can use Googles DIG Tool with the ANY option or do this via cli by running dig example.com ANY.
Now that you have all the records you will need to create them within your public hosted zone, follow this tutorial if you need any assistance. Do not add the SOA or NS records.
Now that all records have been migrated get the values from the NS record in your public hosted zone and replace the nameservers within GoDaddy to point at these values.
Your DNS will migrate over whichever period the TTL of your previous NS record is set as. Once this has migrated and it working you can add your CNAME record as you originally wanted to add.
I've followed these instructions 'Creating a Subdomain That Uses Amazon Route 53 as the DNS Service without Migrating the Parent Domain' many times over without success. I configured a domain a couple of weeks ago and let it sit, I'm revisiting today and it's still not working.
My parent domain haynesandcompany.com is hosted with arvixe.com.
Here's my steps I took to implement as per the instructions;
Created a hosted zone 'helloamazon.haynesandcompany.com' on Route53.
Created a subdomain on my host arvixe.com for 'helloamazon.haynesandcompany.com', removed the NS records and replaced them with the NS records reported by Route53.
At this point the DNS config on arvixe for the subdomain contains 4 NS records only, nothing else.
Back on Route53 I created a TXT record to validate my work with the value "bensayshello" and also created an A record pointing to my Elastic Load Balancer instance ALIAS. My config on route 53 looks like this;
helloamazon.haynesandcompany.com A ALIAS dualstack.awseb-e-q-awsebloa-14c3yer0oht29-329340065.us-east-1.elb.amazonaws.com. Routing Policy: Simple, Evaluate Target Health: No
helloamazon.haynesandcompany.com NS ns-1845.awsdns-38.co.uk, ns-906.awsdns-49.net, ns-1063.awsdns-04.org, ns-461.awsdns-57.com
helloamazon.haynesandcompany.com SOA ns-1845.awsdns-38.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
helloamazon.haynesandcompany.com TXT "bensayshello"
www.helloamazon.haynesandcompany.com A ALIAS dualstack.awseb-e-q-awsebloa-14c3yer0oht29-329340065.us-east-1.elb.amazonaws.com. Routing Policy: Simple, Evaluate Target Health: No
Based on my understanding, navigating to helloamazon.haynesandcompany.com now should work but it fails. dnsstuff.com DNS report serves up a bunch of warnings and errors and running a propagation test on whatsmydns.com shows every 2nd server OK, the rest return a fail. Mind you, it's been weeks since I set this all up so I don't think it's just a matter of giving it more time.
I think I see your mistake.
Created a subdomain on my host ... removed the NS records
If you did this correctly, there would not be any NS records for you to "remove." Based on that, don't create a separate subdomain as its own entity at the other DNS provider. There's going to be nothing to tie that back to the parent domain.
Inside the existing parent domain, at the other DNS provider, just create records of type NS for the host "helloamazon" using the name servers assigned to the hosted zone in Route 53.
That should be all you need.
We are migrating to AWS, and so far we are quite pleased with the performance and ease of use the AWS console provides, especially the Route53 UX. However we ran into an issue.
We have 3 subnets (datacenters), and our old DNS provider we had it set-up like this:
example.us
www
sn1.example.us (local datacenter)
gateway (CNAME)
demo1
feature1
sn2.example.us (old datacenter)
gateway (A record for static ip)
app-a-1
service-a-1
sn3.example.us (aws vpc)
gateway (A record for elastic ip)
app-a-1
service-a-1
So when we migrated to Route53, I maintained the same structure, in that I created a separate "hosted zone" for each subdomain, as it makes each zone easier to administer.
The problem I am seeing is that gateway.sn1 and gateway.sn3 are not resolving, however gateway.sn2 is resolving. With respect to Route53, is it ok to maintain this structure, or should I just have one hosted zone for example.us, and put everything in there?
Update #1
When I created each separate zone, they each were defaulted to differing nameserver records, so I went in and updated all the other zones NS records to match sn2.example.us (as it was the only one working).
Update #2
Bad idea trying to share nameservers across the various hosted zones, when testing behavior, I was getting REFUSED responses. So it does look like I have to move all entries from subdomains (in other hosted zones) up into the parent zone, so I can use the parent's zone nameservers when updating registrar's nameserver information for the domain example.us
You can definitely do this in Route 53... just not the specific way you tried to do it.
Create 4 hosted zones, example.com, sn1.example.com, sn2.example.com, and sn3.example.com.
Don't change the NS entries. You can't. (You technically can, but it doesn't work, if you try.)
Give the assigned nameservers for example.com to the registrar.
Then, in the example.com hosted zone, create one NS entry with hostname sn1, and paste the 4 automatically assigned nameservers for sn1 (as assigned by Route 53 to the hosted zone for sn1.example.com) in the box. Repeat the process for sn2 and sn3 using the correct NS records originally assigned by Route 53 in each case.
The way you tried to implement this can't work, because changing the NS in a hosted zone doesn't change which actual Route 53 servers will respond to requests. That can't be changed.