DNS split across two hosts, subdomain CNAME confusion - amazon-web-services

Right now our domain name and DNS are still hosted by our old provider until we make the full switch to Amazon AWS.
We run a lot of subdomains i.e. vendor.mydomain.com which were previously setup as websites on our old host. I deleted the subdomain on the oldhost and replaced it with a cname on the mydomain.com level for vendor to point to AWS, all is working well.
Now I need to add some TXT records for mailgun to verify my domain and I'm not sure where / how to do it.
Mailgun is looking for and expecting a CNAME record email.vendor.mydomain.com. I tried creating this on mydomain.com as I did for the vendor CNAME, it lets me create it but it never seems to be detected by mailgun.
I figure I could go with the configuration where I create a subdomain on my original host, but then the nameserver of my old host takes over for vendor.mydomain.com. In this scenario I'm all good with the Mailgun CNAME's etc, but I don't know how to effectively point to AWS for vendor.mydomain.com as the CNAME on the domain level no longer works.
Thoughts / suggestions welcome!

If, on the authoritative server for example.com, you have a CNAME record for subdomain.example.com, no other records on that same server can be valid for, or under, that subdomain, because the CNAME effectively blocks everything at or below itself by saying "stop, look elsewhere... specifically, look here."
Create a hosted zone in Route 53 for example.com. Note the 4 awsdns name servers it assigns to the hosted zone.
For each subdomain you need on Amazon, create 4 NS records for each subdomain on the example.com authoritative servers.
vendor NS ns-xxxx.awsdns-yy.com.
vendor NS ns-xxxx.awsdns-yy.net.
...etc., for the .org and .co.uk domains.
This delegates all lookups for that subdomain (e.g. "vendor") and all of its subdomains to the Route 53 servers, while leaving your existing servers authoritative for the records it still contains.
Then you can create records in the hosted zone in Route 53, including alias and CNAMEs as needed.

Related

How to setup a subdomain in Route 53 when the DNS is hoted in Bluehost

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.

Configure AWS CloudFront to be accessible from GoDaddy domain

I have a domain name configured into GoDaddy domain provider.
I created Angular application accessible using this cloudfront internal web address:
xxxxxxxxx.cloudfront.net
The question is how to configure the domain to redirect properly web requests to this address hosted on AWS. I contacted the GoDaddy support and they gave these instructions:
In order to make changes we need the nameservers and the nameservers will be provided by the host that is aws
Once you have the nameservers, Please open the dns page
You will see 2 nameservers that are for godaddy
Click on change option and then select I will use my own nameservers and then update the nameservers that will be provided.
Where I can see what are the names servers used in AWS Cloudfront?
You need to setup the domain in Route53 first (eg example.com), as part of the setup you get 4 name server addresses. You change the name servers at GoDaddy to your AWS nameservers as their support describe, which authorises Route53 to host your DNS. From then on you manage your DNS from Route53, not GoDaddy (but GoDaddy are still your registrar).
Once your nameservers point to route53 follow the docs on creating an alias in route53
If you want to use your own domain name, use Amazon Route 53 to create
an alias record that points to your CloudFront distribution. An alias
record is a Route 53 extension to DNS. It's similar to a CNAME record,
but you can create an alias record both for the root domain, such as
example.com, and for subdomains, such as www.example.com.
When you change the nameservers on GoDaddy any DNS you setup there will no longer be visible on the internet, only whats in Route53. Transfer any records you have created in GoDaddy to Route53 before changing your nameservers. Ignore any DNS records you didnt create.
If theres a problem you can goto GoDaddy and reset the nameservers back to default and that will restore the previous DNS.
One thing to mention - TTL - time to live. If DNS records have a high TTL (in seconds) it means when you make changes it will take upto that amount of time for everyone to get the update. The TTL will be visible in GoDaddy, or you can search "DNS dig" to find online tools that read DNS. The TTL of the NS records might be high (days, a week etc) - this will effect how long it takes Route53 to fully take over responsibility of your DNS.

Can I use Route53 nameservers in addition to my hostgator nameservers?

My domain(say abc-xyz.com) is registered with hostgator. For DNS as well, I am using hostgator and there are 4 nameserver entries listed.
However, now I wish to add route 53 as my DNS service so that I will be able to craete sub1.abc-xyz.com and sub2.abc-zyz.com.
I created a Hosted zone for abc-xyz.com in Route 53 console and it shows 4 name servers which I suppose I need to copy on my hostgator.
When I copied the 4 entries to hostgator along-with the existing nameserver entries (which means total 8 nameserver entries), my DNS entries stopped working. All DNS resolutions started failing.
Is there a way, for me to use both hostgator and Route53 simultaneously as my DNS service?
If you want to use Route53 as your authorised NS than you need to remove the Hostgator DNS server entries.
However you can use both the Route53 and Hostgator name servers, but I would not recommend it, until and unless you have a very strong use case.
Just make sure in your Route53 zone file you make all record entries which were in hostgator zone.

Lightsail instance works when you hit http://[domain].com, but not www.[domain].com, using Route 53 as DNS

I'm pretty new to DNS and this is the first time trying to connect a domain name to an IP, so I'm not sure what I'm missing here. I tried connecting both the www and non www NS records to the Lightsail name servers but only the non www option seems to be working. When I try to hit www.[domain].com, I get unresolved hostname. I also added an A record in each hosted zone that points directly to the IP and I'm not sure if they actually did anything, but I can only access the site from the IP or from http://[domain].com. I appreciate any help you guys can give me, hoping its something small.
Here is an album containing my hosted zone and each zone's settings
I think you don't need to use two separate hosted zone for www and the apex domain (non-www). You can have a single hosted zone and create resource record set for www and the apex domain using CNAME or Alias records. Since you already have an A-record for example.com, in the same hosted zone you can create a CNAME record for www.example.com and point it to example.com
Regardless, for the domain not found, it could be due to the TTL.
Hope this helps.
More information:
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html#CNAMEFormat
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-basic.html#rrsets-values-basic-ttl

Cant create CNAME Record in AWS

I have a domain (mydomain.com). I use AWS Route 53 to point this comain to a server hosted on EC2.
I was able to add a CNAME record for 'www.mydomain.com' or 'someprefix.mydomain.com'.
Route 53 has SOA and NS record for 'mydomain.com' and does not allow to add a CNAME record for 'mydomain.com'.
I need this record to be able to type the domain with or without the leading 'www' in the browser.
More important, I plan to run a mail server on the machine and I believe mail clients need to resolve the 'mydomain.com' part of my user email addresses (e.g. user#mydomain.com).
How do I do that?
To make it all hang together...
Set up
A mydomain.com # Sets up your main domain
CNAME www.mydomain.com # Sets up your www domain. (you may want to
redirect one to the other to avoid duplicate content
NS ns.whatever.com
ns2.whatever.com
MX mail.mydomain.com
This is assuming your not using ELB
A CNAME cannot point to the root domain. Same DNS services will allow it, but a CNAME should point to a service on the domain. ie - the www service in the above case.