I have a sub-domain setup on Route53 that points at an ALB. If I hit the ALB DNS name directly, the application responds right away. If I hit any of the nodes in the ECS cluster that the ALB fronts, again, response is immediate. But from time to time, if I hit the sub-domain, it'll take a long time to resolve. Also, if I do
host http://<my route53 sub-domain>
I sometimes get
Host <my route53 sub-domain> not found: 3(NXDOMAIN)
I have about a dozen sub-domains setup just like this (pointing at different ALBs) and haven't had this issue before, except for this most recent micro service.
Question: Where should I look to figure out what could be going on?
I would carefully check the name server configuration. If one is somehow misconfgured, it can cause intermittent issues where some DNS lookups on a single name server fail while others are ok.
Also try a DNS propagation test, to see if your DNS is being propagated properly across the internet. See https://dnsmap.io/ or https://www.whatsmydns.net/
Some problems can be traced that way.
To exclude any issues with your ISPs DNS, try to use a DNS lookups gateway like kloth.net and see if repeated lookups there show the same issue. See http://www.kloth.net/services/nslookup.php
Always use a general DNS checker like https://mxtoolbox.com/dnscheck.aspx to do a complete test of the DNS setup for your domain.
Related
Not sure what I am doing wrong here. My zone is public and I have simple routing for the A records pointing to the EB alias. I even tried a CNAME to no avail.
Browser error in Chrome -- The site can't be reached. DNS address could not be found. Diagnosing the problem. DNS_PROBE_POSSIBLE
I even did a test response within the console. Everything checks out but there is something funny happening between the Route53 -> EB handshake. The EB alias works just fine by itself.
I would love some pointers. Perhaps I need to configure something within Django settings?
It turned out to be an issue with the resolvers on the AWS side even though I didn't transfer the domain. They provisioned the wrong resolvers and I had to manually change them out to a different set. I only discovered this fact after creating a support case.
I am using a public API hosted behind CloudFront. I want to get the least possible latency.
I have done the following things so far:
Hosted my code on EC2 in the same region as the API origin server. (I have a clue as to which region the origin server could be hosted in based on ping times)
Tried pinging the API domain name from various availability zones within that region and identified the zone with least ping time.
However during my testing, I came across instances where ping time from my desktop was smaller than the ping time from my EC2 instance. So I had a look at what the CNAME & IP, the original API domain name was getting resolved to in each case. I found them to be different.
Is there something I can do to ensure that DNS resolution of CloudFront leads me to the lowest latency link.
I can use the CNAME or IP that I found to be the fastest during my testing. But that CNAME/IP may change so that's not a proper solution.
I think the answer could lie in a smart DNS client which pings all the servers in DNS file periodically and resolves DNS requests to the the fastest IP. However I don't know if any such client exists and how to use it if it does.
I would like to hear your ideas.
Is there something I can do to ensure that DNS resolution of CloudFront leads me to the lowest latency link.
If you have your own domain name, you could try using Route53's latency record or Geoproximity routing
I recently created a new domain on GoDaddy to which I want to move my current website.
I decided to move the hosting to AWS and create an EC2 Instance there.
Everything was going fine until I purchased the new domain I want to move my website to and started configuring Route 53.
I ended up following a tutorial that said to move the GoDaddy records to Route53 where I had created a hosted zone, so i started doing exactly that. However, the A record pointed to "parked", the 'www' cname record pointed to # and a '_domainconnect' cname record pointed to _domainconnect.gd.domaincontrol.com'
When creating the new records on Route 53, I changed the 'www' cname record by making it point to my domain 'example.com' so that the www.example.com points to example.com.
I changed the A record so that it points to the IPv4 address on my instance.
Finally, I did not copy the "_domainconnect' record because I thought this was something that had to do with GoDaddy specifically and probably shouldn't be copied (I also did not see it in any tutorial).
Now, there was no problem accessing the website through the www.example.com or example.com domains but after reading multiple tutorials and watching multiple videos, there are 2 things I want to make sure I am doing right:
1- Somebody mentioned the server serving www.example.com and example.com twice and them being 2 separate versions when the previous process is done... I didn't understand what they meant and if this was a problem or not. If someone could clarify this, that would be awesome.
2- Somebody also mentioned using Elastic IPs for Route53 because the instance IPv4 might change? Is that something I should be worrying about if I will be running a website on the instance?
Sorry for the long explanation, I am trying to be as descriptive as possible.
This is the Route 53 Configuration:
To better understand point one, if you could attach the route 53 configuration the could hep us giving a better answer.
For the second point, two recommendations.
it is better if you create an Elastic IP and attach to a network interface, then attach the network interface to the instance. In this way the IP would stay forever (or as long as you want). Otherwise, as soon as you restart the instance, and this can definitively happen, you will loose the IP, therefore your DNS needs to be propagated again.
leave everything as it is, but as a further step learn what an AWS VPC is, it will give you much benefit rather than exposing your instance directly to the internet.
I have set up a custom domain on API Gateway, it is a subdomain. api.example.com. The gateway endpoints are pointing to lambda functions. When making a GET request to the subdomain, I am occasionally (and often) getting the error "server DNS address could not be found". It seems like it could be related to the Lambda cold start, but I can't be sure. If it was related to the cold start, wouldn't the request just timeout or hang, instead of sending back, in particular, a DNS error? The DNS error makes me think the cold starting Lambda isn't the issue.
Also, I need to hit the request 5-10 times before it begins returning successful responses.I do this manually right now, so there are brief pauses between each request.
The error seems to be domain specific too. If in one browser tab I make the request 5+ times, it begins to return successfully, but from another server, on a domain somewhere, I have to hit it 5+ times to get a successful response even though it is currently returning successfully from another domain or server. To me, this rules out lambda cold start being the issue, no?
The domain is registered in route 53. I have a hosted zone for example.com, and in that hosted zone I have an A record for api.example.com. The A record target is set to the CloudFront public DNS setup by API Gateway when I added the custom domain.
One of my questions is: Is this configuration incorrect? Should the subdomain be in its own hosted zone, with a new NS record for api.example.com created in the parent domain pointed to the subdomain's hosted zone? Could this configuration be my issue?
I don't think that is related to Lambda's cold start.
It seems like you are having issues with DNS records. The DNS record will take up to 48 hours to propagate across. If you still see this issue, I encourage you to contact Route53 support. They should be able to help you on DNS issue.
I've setup a couple of EC2 instances in different regions and have configured A record sets in my hosted zone. All is working correctly, but I want to be able to check were a certain request is going. So if a request is done through webpagetest.org from Europe, is there a way I can check that Route 53 is routing it correctly to my EC2 instance in Ireland (assuming that it has the lowest latency)?
That site doesnt tell you what ip address is resolved in the request. You should try something like pingdom to see if the request is resolving to the correct ip address from different points around the world.