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.
Related
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.
I am new to AWS and facing this issue for the past few days. So any help will be appreciated :)
I have created an AWS EC2 instance and deployed backend&frontend services on SINGLE INSTANCE that are used in my project.
Backend->Java,Apache tomcat,RDS,Elasti cache
Frontend-> Node
And now created a hosted zone under Route53 to host my Namecheap domain in AWS EC2.
Have checked all configs thrice, and added A type(Value as ec2 IP) and CNAME(Value as domain name e.g. xxyyzz.liv) type variables in the hosted zone including modifying nameservers from hosted zone to the Namecheap DNS settings.
Even after long waiting(of 48 hrs) my domain is not getting live, tried multiple times but no help.
This will be caused by misconfiguration. Perform the following steps to rectify this issue:
Ensure you have not replaced the NS or SOA records in Route 53, these should stay as the values that Route 53 generates. If you have replaced their values, create a new public hosted zone and migrate the records to this (excluding NS or SOA).
Run DIG against your domain for the MX record, either by running DIG NS example.com or by using an online tool such as https://toolbox.googleapps.com/apps/dig/. If you get no results back (returning a SERVFAIL) or incorrect name servers back then you will need to update the name server configuration.
Within your public hosted zone in Route 53 look for the NS record, copy the values (there will be 4 nameservers). Then within namecheap follow these instructions for "Custom DNS". Add each name server from Route 53.
By now running DIG again you should be able to see the records that should have previously been accessible. Depending on the TTL of the previous NS record you might find it takes a few hours/days for the DNS to migrate across, although you can clear the DNS cache on your local network.
I have two public hosted zones in Amazon Route 53 for the same domain name (which has Route 53 as registrar), for the reason that Route 53 automatically created one when I registered the domain name and that the second one was created by Terraform.
As far as I can tell, DNS record sets in the second zone aren't applied, i.e. they're not returned for queries to the domain. Do I have to delete the first zone in order for record sets in the second zone to be active?
As far as I can tell, which hosted zone is active, meaning that its record sets are returned for queries to the domain, depends on the name servers registered with the domain. So, in order to make my second zone active I have to update the domain's name servers, in Route 53, to correspond to those of the desired hosted zone.
Following is an extract from the AWS Route 53 FAQ
Q. Can I create multiple hosted zones for the same domain name?
Yes. Creating multiple hosted zones allows you to verify your DNS setting in a “test” environment, and then replicate those settings on a “production” hosted zone. For example, hosted zone Z1234 might be your test version of example.com, hosted on name servers ns-1, ns-2, ns-3, and ns-4. Similarly, hosted zone Z5678 might be your production version of example.com, hosted on ns-5, ns-6, ns-7, and ns-8. Since each hosted zone has a virtual set of name servers associated with that zone, Route 53 will answer DNS queries for example.com differently depending on which name server you send the DNS query to.
Click here for more details
How is Domain-Name, Namespaces, and Hosted-Zone connected?
Imagine you bought a new name from GoDaddy - example.com. Then you setup your website in your EC2 machine which has IP 100.0.0.10. To point example.com to your webserver, you will need to first choose a DNS resolver. AWS provides one - Route53. A DNS resolver translates names like example.com to IP address like 100.0.0.10.
AWS Route53 has a concept of Hosted Zones. You will need to create a hosted zone for example.com. Route53 will then give you nameservers (bunch of different URLs, AWS gives you 4). You will take these nameservers and go back to GoDaddy and there is a section to put those nameservers. This tells GoDaddy where to send the request to.
Why did we do above ^^^ ?
When you purchased the name from GoDaddy, GoDaddy became your registrator i.e. it registered your name with the DNS authorities. So whenever someone requests example.com to the DNS authorities, they will forward the request to GoDaddy. So GoDaddy needs to know where to send the request to. These nameservers tells GoDaddy that exact information.
After the request reaches AWS Route53, it knows that this domain name example.com needs to go to 100.0.0.10.
What if I create 2 Hosted Zones with the same domain name example.com?
A hosted-zone is nothing but Route53's way to define a set of route rules for a domain.
If you have 2 hosted-zone with the same domain name, you will have 2 sets of namespaces. For AWS, each set has 4 namespace, so total of 8 namespaces).
So now it depends which namespaces you give to GoDaddy. You can give it set A, in which case your second hosted-zone will not receive any traffic. You can give it set B, in which case your first hosted-zone will not receive any traffic. Or, you can give it a mixture of both set A and set B, in which case GoDaddy will send some requests to set A and some to set B, not both though.
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.
I'm using Route 53 for most of my website DNS needs but I have a question I couldn't find a clear answer for on Amazon's (usually very good) support docs.
It states everywhere in support not to change or remove the ns records for a hosted zone. But can I add ns records for a subdomain?
I'm migrating a site to Route 53 that requires ns records to point to a 3rd party for email. The current DNS set up is as follows:
When I come to move the parent domain to Route 53 can I add those records into the parent domain hosted zone as below or would I need to create a new hosted zone just for the sub-domain?
You can change the NS record in Route53 to add other DNS servers in the list or remove existing ones, but this is only required in very specific setups.
From your description, it seems you're simply trying to migrate the existing DNS settings from another provider to Route53. If this is the case, then you'll probably be using the AWS provided name servers exclusively for your domain, so the NS value that you have in Route53 is already what it should be and there's no need to change it.
The only reason why you would change the NS value is if you use other DNS servers (secondary DNS servers), separate from the ones Amazon has assigned to your hosted zone (possibly for redundancy, but the ones that Amazon provides already offer enough redundancy).
UPDATE (based on comments below):
If the subdomain user other name servers (it's delegated), then you'll need to create a new NS record in the hosted zone for that subdomain:
email.primary-domain.com. IN NS other-ns.dns-provider.com.
In this case, you'll need to leave the NS record for the root domain unchanged.