Site being cloned or deploy to domain I don't own - ruby-on-rails

I'm deploying a Rails app to EC2 using Elastic Beanstalk. I just found out, while doing a search in google that whenever I deploy to my domain, my site seems to also get deployed to a domain I don't own. I use Route 53 for my DNS as well.
Has anyone ever run into this situation or have any idea what might be happening here?

It could be a simple DNS issue. Someone's DNS A record is pointing to the ip address of your EC2 instance
Amazon recycles ip addresses. It is possible that your current ip address was allocated to someone else earlier, and they have not deleted their DNS entry when releasing the ip address.
you can run ping command to confirm both domain names resolve to same ip address
ping domain1.com
ping domain2.com

Related

Changing ISP traefik doesn't work anymore

I just moved my server from one place to another and while everything is working on my reverse proxy. (Traefik generates ACME Certificate, docker containers are up and healthy)
I can't seem to access traefik from my domain name, whereas I can access it with the static IP (WAN) or even local IP (LAN). I changed the A record in my registrar's DNS (porkbun) to the new static IP and can ping through it, even access ssh, but I can't reach traefik. Logs (level DEBUG) don't even show an attempt to connect, so I don't know what's happening.
If you have any idea what could go wrong, or what I could be missing. Everything worked before.
Thanks.

AWS Load Balancer EC2 health check request timed out failure

I'm trying to get down and dirty with DevOps and I'm running into a health check request timed out failure. The problem is my Elastic Load Balancer sends a health check to my EC2 instance and gets a network timeout. I'm not sure what I did wrong. I am following this tutorial and I have completed all the steps up to and including "Using a Elastic Load Balancer". My EC2 instance seems to be working fine and I am able to successfully curl localhost on port 9292 from within the EC2 instance.
EC2 instance security group setup:
Elastic Load Balancer setup:
My target group for the ELB routing has port 9292 open via HTTP and here's a screenshot of the target in my target group that is unhealthy.
Health check config:
I have a VPC that my EC2 instance is a part of and my ELB is connected to the same VPC. I do not have Apache installed and I do not have nginx installed. To my understanding, I do not need these. I have a Rails Puma server running and I can send successful curl requests to the server.
My hunch is that my ELB is not allowed to reach my EC2 instance, resulting in a network timeout and a failed health check. I'm unable to find the cause for this. Any ideas? This SO post didn't help much. Are my security groups misconfigured? What else could potentially block a routing request from ELB to my EC2 instance?
Also, is there a way to view network requests / logs for my EC2 instance? I keep seeing VPC flow logging but I feel like there are simpler alternatives.
Here's something I posted in the AWS forums but to no avail.
UPDATE: I can curl the private IP of target just fine from within an EC2 instance. I don't think it's the target instance, I think it's something to do with the security group setup. I am unable to identify why though because I have basically allowed all traffic from the Load Balancer to the EC2 instance.
I made my mistake during the "Setup your VPC" step. I finished creating a subnet for an RDS instance. I proceeded to start an instance and the default subnet that AWS chose when I switched to my VPC was the subnet I made for my RDS, which was NOT a public subnet. Therefore, any attempts, from any EC2 instance or my load balancer, would not be able to reach it because I had only set up my public subnet to take requests.
The solution was to create a new instance and this time, pick the correct public subnet. My original EC2 instance was associated with a private subnet while the load balancer was pointing to the public subnet.
Here's a link to a hand drawn image that helped me pin point my problem, hopefully can help anyone else who's having trouble setting up. I didn't put image here directly because it's bigger than 2MB.
Glad to answer any further questions too!

AWS Certificate Manager - SSL says in use but HTTPS does not work

So here is my issue. I have a Rails 5 Application that is being deployed to AWS using Elastic Beanstalk. I purchased the domain name (eightysixpad.me) from Bluehost.com and updated the DNS records to point to the IP address of the EC2 instance that was created.
I used AWS's Certificate Manager to create an SSL certificate for the domain eightysixpad.me and www.eightysixpad.me. I have verified both of them through email. I created a Load Balancer under the Elastic Beanstalk environment and applied the SSL certificate to it. The AWS Certificate Manager console says the SSL certificate is in use; however, when I go to https://eightysixpad.me, it says Site Cannot be reached. http://eightysixpad.me works fine but says it is unsecure.
I am not sure what I am doing wrong! Any help would be greatly appreciate and I would be more than happy to provide more information if necessary!
Thank you all in advance!
Update the DNS entry to a CNAME and make it point to the DNS endpoint of the ELB , to which you have added the EC2 instance(s).
For example create new CNAME entry to ELB Dns endpoint "name-of-elb-unique-.ap-southeast-1.elb.amazonaws.com"
ELBs in AWS do not have an IP address (always dns names) as IP address keep changing

How dns servers work know the ip address of website?

My question is that suppose my website is "xyz.com"
I can access it anywhere in the world, but I'm curious to know how does all the dns servers know the ip address of my website..?
I'm little bit confused..
The main process that resolves an IP Address through DNS is referrals. A DNS Server will go through a process to find the Authorative Nameserver for your domain. The Authorative Nameserver is the server that is configured to answer queries for that domain. i.e. the godaddy DNS Servers, if you have purchased, and configured a domain name through them.
If you go to www.example.com from your PC, it will send a query to your configured DNS server, asking for www.example.com
If your configured DNS Server knows that answer already, i.e. it has been asked the same question recently, it will return the answer from cache (as long as it hasn't expired)
If your configured DNS Server doesn't know, then it will find out. In order to find out what server knows the answer, it needs to look up the name server for example.com first.
So the first query the nameserver makes is to the root domain "." (All DNS Servers should have these configured) to find out the nameservers for the .com domain.
When it has an address for the .com domain's nameservers, it will send a query asking for the nameserver for example.com
when it has the address for example.com's nameservers, it will send the original query, for www.example.com, to that server, and return the answer to you (and put a copy in its cache incase anyone else asks)
Note: If you were looking for www.test.example.com then it would have asked example.com for the nameservers for test.example.com instead.
URL resolution in DNS happens from right to left.
DNS comprises of Root Servers, Top Level Domain(TLD) and Authoritative Servers
For the example www.example.com :
Root Server queries the TLD for '.com' extension
TLD searches the DNS cache for the domain, if not it queries the corresponding authoritative server for the domain 'example.com' to finally get the IP address for the host www.example.com, then return that IP address to your computer.
That's why there are DNS Root Servers.
At the top of the DNS system are DNS root servers. There are
approximately 500 root servers distributed around the planet,
addressed via 13 IP addresses. These root servers are the only ones
that contain the entire list of all domain names and IP addresses. So
eventually, a DNS request might make it all the way to the DNS root
servers if no other DNS server has the answer. If there is still no
answer at the root level, then the DNS request fails, and your browser
returns an error. Source

Can't Access Rails Server on EC2 Instance from Public IP

I have rails running on an Amazon EC2 instance but I'm having trouble accessing my rails server (port 3000) from public IPs. This was working as recently as last week but today when I started up my rails server I was unable to get a response from an outside IP. Even when I created a brand new rails project I was not able to access the server once I had started it.
Despite this I can access the Apache server by going through port 80. Moreover SSL continues to work.
I have already
ensured that the port 3000 is open on my security group in the Amazon EC2 console
checked my iptables on the Amazon instance. There are no rules and the default for the INPUT chain is to accept packets.
banged my head against a wall.
Does anyone have any ideas?
Did you verify the port 3000 is opened for every IPs addresses and not only for your workplace's IP?
Also, your Amazon EC2 virtual machine's IP could have changed.

Resources