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.