I had 2 EC2 instances - one connected to mydomain.com and another connected to dev.mydomain.com
When mydomain.com instance went down because of some reason I changed the record set of mydomain.com to the public IP of second EC2 instance. The change was immediately reflected and mydomain.com started working fine.
After a few hours after fixing issues with the first EC2 server I reverted the IP address in the record set of mydomain.com. But this does not work. mydomain.com still points to the 2nd EC2 machine.
Can anybody suggest possible solutions?
DNS changes take time to propagate. Also, computers cache DNS responses, so checking changes can be difficult. The best advice is to wait, or to check it via a different computer.
You might want to use a service like https://cachecheck.opendns.com/ to check the resolution, or clear your cache before checking (in Windows, use ipconfig /flushdns).
DNS records have a ttl or Time To Live. This means records are not refreshed from the central server until that TTL has expired.
You should look at using failover records in R53 :)
Related
So the ubuntu server I'm using for a webserver is acting fine when I try to ssh or view the page using it's public IP. However when I try to use the record I just created in GoDaddy it wont work. I am trying to set up a subdomain and it won't work at all. I just had the exact same setup working on Amazon's OS but I saw too many negative reviews of the distro. So I spun up some instances running ubuntu and immediately they aren't working.
I have the record set to type:'A' and the name and value are definitely set correctly.
What else should I check? I'm not sure where the error is here because the godaddy setup is so simple. I feel like it has to be in my setup of the EC2 instance or some other aws settings.
If you can access the site via public IP and you are sure that the A record config is fine, I think the dns is still being propagated. Dns propogation may take longer.
If that's the case, Give it some time.
You can check which part of world knows about your new cname on https://dnschecker.org/. There are many other sites as well.
Old database endpoint : old.cy336nc8sq5l.us-east-1.rds.amazonaws.com
New database endpoint : new.cy336nc8sq5l.us-east-1.rds.amazonaws.com
Above endpoints are automatically created by AWS, at the time of creation of RDS instance
I have tried setting up CNAME for old.cy336nc8sq5l.us-east-1.rds.amazonaws.com with value new.cy336nc8sq5l.us-east-1.rds.amazonaws.com but it did not worked.For this I have to create a new Hosted zone in route53 name cy336nc8sq5l.us-east-1.rds.amazonaws.com
However, If a setup a CNAME in other hosted zone for any url like abc.example.com with value new.cy336nc8sq5l.us-east-1.rds.amazonaws.com works like a charm. The old rds url has been used in multiple application I cannot take a risk to completely abandon, the best way is to use some kind of redirection.
In addition to it, any CNAME under the cy336nc8sq5l.us-east-1.rds.amazonaws.com Hosted zone is not working.
How can I fix this? Please also suggest what is the best practice for redirection rds traffic? I knew for the new DB endpoint, I will create a new custom CNAME and will use that going forward rather that just using the default one. All suggestions are welcome :)
You can't add any records for the domain cy336nc8sq5l.us-east-1.rds.amazonaws.com, because you don't control it, Generally you will be able to create any hosted zones like google.com etc but it won't get reflect unless you change the NS record and SOA records from the original DNS provider to point yours, you can't it with aws rds domains. you can confirm it by doing
dig +short -t ns cy336nc8sq5l.us-east-1.rds.amazonaws.com
If above results returns your NS records then you control that domain.
To have this kind of flexibility in future, i would suggest a way create a private zone like mydb.com and have A record like master.mydb.com with value old.cy336nc8sq5l.us-east-1.rds.amazonaws.com and when you want to switch to another endpoint just switch it in route53, after TTL expires the connections will start coming to new endpoint, since you are making a change, its better to start using this way.
Also for your case, after you switch to new endpoint, you can check the connections count in the old DB to know if its being referred somewhere and by running show processlist;, you will be able to know which IP, its being used.
The bottom line is that you are going to have to update all 30 applications to use the new DB endpoint. If you are going to be deleting databases & recreating them like this regularly, then configure your databases to use a name in a zone you control, and create a CNAME to whatever database endpoint is current.
You may be able to create a temporary solution by adding an entry to /etc/hosts (assuming your clients are running linux - I believe this is also possible on Windows, but it has been a long time) that maps the current IP for the new database to the old hostname. But this is probably just as much work as updating the application to use the new database. It will also fail if you are running a multi-AZ database and have a failover event.
Change your DB identifier can help in some way.
Select your cluster -> Modify -> change DB cluster identifier
You will keep your old database with difference endpoint, then change new DB to new endpoint.
But I love /etc/hosts solution as simple and safe.
Long story short here, I restarted my EC2 instance unwittingly which (without an EIP) changed the pubic facing IP address. Ok fair enough, but after I changed the DNS records on Hover.com for my domain now when I type in www.mydomain.com it points back to the old instance IP that doesn't work.
I verified this with host www.mydomain.com on my Linux command line.
I looked at the DNS records and they are clearly changed to the new IP for the A records (for * and #).
The only thing I can come up with is that perhaps the DNS servers listed are the problem. Here are the name servers I'm using
My attempted solution has been trying to find a way to update these servers, but I am not finding any help on that. Any recommendations to solve this issue?
Check the TTL (Time To Live = cache duration) on your DNS server, be sure to use the smallest duration allowed (0 if possible). This will tell DNS relays and clients to cache the resolution for a short period of time (or not at all if you set it to 0)
However, some clients do not honor the TLS proposed by the DNS and your only solution is to wait for their cache to expire.
The dig command will show you the TTL sent by your DNS server, as in the example below : 60 secs.
$ dig www.stormacq.com +noall +answer
; <<>> DiG 9.10.6 <<>> www.stormacq.com +noall +answer
;; global options: +cmd
www.stormacq.com. 60 IN A 54.192.29.54
www.stormacq.com. 60 IN A 54.192.29.133
www.stormacq.com. 60 IN A 54.192.29.136
www.stormacq.com. 60 IN A 54.192.29.234
I would suggest you to use an Elastic IP Address, these are provided without charges as long as it is attached to a running EC2 instance. (see https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html for more details)
I solved this by using Hover's DNS servers instead of using Amazon's. I contacted Hover and they recommended changing to their name servers and removing Amazon's. Apparently Amazon's DNS servers were taking a long time to update records (if they were trying to at all).
Record #1 ns1.hover.com
Record #2 ns2.hover.com
Record #3 blank
Record #4 blank
*edit: Thumbs down but no comment explaining why? This answer worked for me
I am new to all this. I have setup a Nginx server http://52.x.x.x I am testing it. I bought domain name from namecheap. I want domain name routed to the ip. What setting I should configure for this.
First, make sure your instance is associated with an Elastic IP (EIP). If you do not do that, your instance's public IP address will change each time you reboot. Here are the instructions from AWS on how to setup and assign an EIP:
http://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/getting-started-assign-eip.html
Note that if you don't associate that EIP to a running instance you will be charged. You can reference EIP pricing here:
https://aws.amazon.com/ec2/pricing/
Next, as mbaird mentioned setup an A record in your DNS management at Namecheap.com. All you have to do is add an A record and enter the public EIP address that you received in the step above. As a start set your TTL (Time to Live) to 60 seconds. Here are the instructions on how to do that from Namecheap:
https://www.namecheap.com/support/knowledgebase/article.aspx/434/78/how-do-i-set-up-host-records-for-a-domain
You can use www.whatsmydns.net to help troubleshoot any DNS propagation. (i.e. It takes a while for all of the world-wide root DNS servers to know that your domain name points to 54.x.x.x)
And finally - just as a suggestion - don't post your IP address in a forum like this unless you absolutely have to. Instead write something like, 54.x.x.x.
I hope this helps!
i've registered a .com domain name. At the Amazon Web Services account i own, I have already set up the DNS zone,i've changed the nameservers at my registrar's panel and i've created an A-record in my AWS DNS zone,too. I think i've done all the preparation needed. But my website is not opening!
This is not a DNS propagation time-requiring issue,by the time i did all the above stuff about 5 days ago (DNS had enough time to be refreshed globally in any ISP). Also via ipduh.com i can see that all the nameservers are correctly configured and recognised, as well as the *.mydomain.com A record which points at my AWS instance's IP.
What possibly would be wrong guys? :/ i've done anything i know and i've followed also the directions i've found in SO and i had no luck till now :/
Any suggestion and help would be highly appreciated :D
Thank you in advance guys!
I'm going to assume that the DNS is set up properly, and that the A record is pointing at the IP address assigned to your instance.
If this is a new AWS account, you're probably running in a VPC. Did you make sure that you allocated a public IP address to the instance? If your IP is 10.something, that's the internal, private IP address and you won't be able to use that. You'll need to allocate an Elastic IP and associate it with your instance, then update your DNS settings.
Next, make sure that the web server is up & running? If you log into the instance, what happens if you wget localhost? You might not get the page you're expecting if you're running multiple name-based virtualhosts, but you should get the index page for the default web site.
OK, so how you're sure the web server is running. Next thing to do is check the security rules. When you created your instance, you had give it the name of a security group. The default is, strangely enough, called "defaut". Take a look and see if port 80 is open. If not, open it up to the world (0.0.0.0) and see if you can access the web site now.
None of this helps? Reboot your instance and see if it starts working when it comes back up - it's possible that you're on a bad host, and rebooting will bring it up on different hardware.