In a setup with EC2 instances, and a properly configured zone file, I've found that AWS periodically changes their DNS servers. This means one has to go all the way back to the initial ISP setup and update those DNS records every time they change.
This ISP (and most every ISP) actually allows you to set up private DNS nameservers, but this only works if the DNS servers (addresses) are consistent. Otherwise the site will become completely unreachable when AWS randomly changes their zone files/DNS servers. Is there any way around this?
The IP addresses of Route 53's name servers assigned to your hosted zones should not change. I would post to the Route 53 forums explaining what you are seeing.
Related
I want to connect my domain (in AWS Registered Domains) to the IP address of my Ec2 instance in my AWS account; so that I can type www.my-domain.com in any browser and open my website.
I transferred a domain name from my old AWS account to a new one. Usually AWS creates a hosted zone for the domain automatically, but it didn't.
So I created my own hosted zone and and added and two A records (www.a.com and a.com) with value connected to the IP address of my Ec2 instance but the browsers didn't recognize the domain.
So I tried:
Updating the Name servers of the hosted zone to be the same as the domain name NS But same result
Updating the Name servers of the domain name to be the same as the hosted zone NS But same result
What can I do?
Thanks.
As long as the domain registrar is AWS (you can validate this by running whois against your domain) the setup should be quite simple.
Firstly it might be worth creating a new hosted zone if you've modified the NS records for it. It is important that these values are the original domains that AWS entered against the values. Also ensure the hosted zone is a public hosted zone.
Copy each of the nameserver values from your public hosted zone (there should be 4 in total). Then on your registered domain in the Route 53 console, edit the nameservers replacing the values with the values that were taken from your hosted zone. Once you have done this the new public hosted zone will be used by your domain.
Depending on any TTL caching you might find it can take a little time for clients to use this nameserver but you can test it by using a DIG command to find the NS value using an external server or the web service offered by google.
I don't know if this could count as and answer but this is what I did to fix the problem:
I created and Application Load Balancer
With Security Group with Inbound rules: HTTP TCP 80 0.0.0.0/0, ::/0
And Target Group TCP 80 Set to Ec2 instance.
Connect the A record to the ALB
This fixed my problem
I've set up my application on AWS Elastic Beanstalk. I added a load balancer and pointed a CNAME for 'www' to it. But now I need to get root pointed there too. I can't use Route53 and use AWS nameservers because the client wants to use theirs. How can I get root to my app? Can I redirect the traffic? The tech lead I'm working with suggested setting up a server to do the redirect?
Since AWS ELB's only offer DNS Record (Instead of IPs) you need to use a CNAME mapping. However with DNS, CNAMEs do not allow root domain to point to it. To overcome this AWS has provided Alias Records (Custom implementation to AWS) to point root domain to ELBs.
If your client want to use their nameservers still you can use, AWS Route53 in between to solve this with following steps.
First create a Public Hosted Zone in Route53 for your domain.
Then create a record set inside the Hosted Zone for the root domain to point to the ELB with Type = A - IPv4 Address, Alias = Yes with ELB CNAME as for the Alias value.
In the external domain management service, create a NS record to point the root domain to Route53 nameservers.
Then when the DNS resolution happens, the root DNS query will first go to external nameservers(Managed outside of Route53) and then it will be forwarded to route53 where it will resolve the ELBs IP address and sent back.
You can set up a machine with a single static IP address that does nothing but redirect requests to the www host. Then you can put an A record on the bare domain at the apex of the DNS zone pointing to that machine.
There is at least one service, http://wwwizer.com/naked-domain-redirect, that will do this for you. (I'm not affiliated with this service, but it appears to do what it claims and will serve your purpose. There are probably others like it.)
Ideally, though, you'd persuade your client to change the authoritative nameservers to point to a Route 53 hosted zone that you create for them. They are still the registrant and "owner" of their domain, and can take control back from you by simply changing the nameservers to something else.
I generally persuade clients with the explanation that our load balancer infrastructure is integrated with the DNS servers so that if a balancer node fails, or we need to add or scale up capacity, or experience a traffic surge or DDoS event, the load balancer system will automatically update the DNS records for their domain to try to mitigate the issue and keep the site up. To do otherwise is to do things in such a way that removes those layers of redundancy.
Ideally, you can set up a apache server with a static IP, and install a free SSL certificate on that web server at first.
Second you need to redirect your root domain name request to AWS ELB.
Then go to your DNS management and set up your apex point to the server you created.
It is now possible to setup a Network Load Balancer and allocate one or more Elastic IP Addresses to it (one per Availability Zone). The Network Load Balancer can have an Application Load Balancer as a target. The Application Load Balancer would target the Elastic Beanstalk. An A record can then be created in the external DNS for each Elastic IP Address of the Network Load Balancer.
If you don't need the functionality that the Application Load Balancer provides, you may be able to target Elastic Beanstalk or whatever application directly from the Network Load Balancer.
Since AWS ELB's only offer DNS Record (Instead of IPs) you need to use a CNAME mapping. However with DNS, CNAMEs do not allow root domain to point to it. To overcome this AWS has provided Alias Records (Custom implementation to AWS) to point root domain to ELBs.
If your client want to use their nameservers still you can use, AWS Route53 in between to solve this with following steps.
First create a Public Hosted Zone in Route53 for your domain.
Then create a record set inside the Hosted Zone for the root domain to point to the ELB with Type = A - IPv4 Address, Alias = Yes with ELB CNAME as for the Alias value.
Recently I started looking at AWS Route53.
I am able to create a Hosted Zone for any domain. What prevents someone to create a Hosted Zone for a domain which they don't own? This way it should be possible to redirect traffic.
You can even create two (or more) hosted zones for the exact same domain within a single AWS account, and it still won't matter. Only one will be live on the Internet.
The reason is because Route 53 has at least 2,048 DNS server names and IP addresses allocated... but each hosted zone assigned to -- and is valid on -- exactly 4 of them. None of the others will respond to queries for your domain's data. These are shown in the console and automatically added as NS records in the hosted zone. Editing the NS records breaks your zone but doesn't actually change the 4 assigned server IP addresses.
Create a second hosted zone for the same domain, and it will be assigned to 4 different Route 53 nameserver IP addresses.
When you configure your authoritative name servers with your registrar, you provide the 4 nameserver addresses assigned by Route 53 to the hosted zone that you want to be live, and that's where the resolvers on the Internet will send queries for your domain... not any of the others. So, if someone does create a hosted zone for your domain, it doesn't matter -- their hosted zone will be on 4 different nameservers, none of which will actually by queried by any system trying to resolve your domain.
Note that there are 4 nameserver addresses assigned to your hosted zone, but that does not mean there are only 4 actual nameservers. The IP addresses assigned to the Route 53 name servers are anycast addresses. Multiple servers around the globe respond to the same set of 4 IP addresses.
If, for some reason, you still see this as a potential problem, consider the fact that this is no different than configuring a zone file for a domain you do not own, on a set of DNS servers that you control, located anywhere on the Internet. It won't impact the domain operationally, because nobody will ever query your servers -- they are not authoritative for the domain.
Quick Help Please....
I recently migrated my DSN from Godaddy to AWS Route 53. When doing the process I had checked "automatically import....". So I thought everything would propagate automatically.
Now after 7+ days when Godaddy finally released me, nothing is working. I am not an expert on DNS. And Site is down. Priority now is getting "www.example.com" to point to my ip address.
I have attached screen shot. What else needs to be done?
I should also add this was launched into a VPC.
Update I have attached an image of my Named Servers.
You shouldn't be using an IP address for S3. You need to change the record type to CNAME, and point it to the domain name S3 tells you to use. Honestly that's how it should have been set up on GoDaddy as well.
Here are the instructions: http://docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html
You don't need to be an "expert on DNS" to set this stuff up. You just need to follow the instructions.
Also, when you say "this was launched into a VPC" what do you mean by that? Route53 offers public and private DNS zones. Public zones are similar to your previous GoDaddy DNS and are what you need to use for a public website. Private DNS zones are for DNS records you only want to resolve from within your VPC.
One of the biggest shortcomings of AWS Elastic Load Balancer is the inability to assign a static IP to it. To get around this I have to use Amazon Route 53 DNS, which I can then set an A Record for the root/sub domain to point to the load balancer.
Let's say my Route 53 domain is:
domain1.com
I've create an elastic load balancer and pointed the following to it via A Record:
sub.domain1.com
I'm wondering, if I create a CNAME for another domain (such as sub.domain2.com) and point it to sub.domain1.com if this is OK?
Why do I need to do this?
We run promotional pages for clients websites by setting up static websites on subdomains of their sites. We currently give them a static IP for an EC2 instance which they then create an A Record for, but we're looking to do a load balanced cluster for high availability and scaling.
Has anyone tried this or know if this is OK to do? I know this concept is somewhat similar to S3 CNAME's but I just don't know if this bad or not :)
One of the biggest shortcomings of AWS Elastic Load Balancer is the inability to assign a static IP to it.
That's not a design limitation, it's more of an indication that you're trying to use the ELB incorrectly.
I'm wondering, if I create a CNAME for another domain (such as sub.domain2.com) and point it to sub.domain1.com if this is OK?
Yes, just make sure you set the TTL on CNAME low enough that if/when the IP addresses on the ELB change that your users aren't looking at stale records for too long. Route53 uses 60 second TTLs.
We run promotional pages for clients websites by setting up static websites on subdomains of their sites. We currently give them a static IP for an EC2 instance which they then create an A Record for, but we're looking to do a load balanced cluster for high availability and scaling.
If these are actually static websites, you'd be better off hosting them directly out of a S3 bucket. Nothing important should ever be run on a single EC2 instance.