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
Related
ex: ec2-203-0-113-25.compute-1.amazonaws.com
ex: url marked in this pic https://i.stack.imgur.com/xKcP1.png
How does the routing takes place in AWS services ?
According to url they seem to use routing according to subdomain but registering a subdomain needs 24 hours to propagate through dns servers , so how aws is handling this ?
A user just asks for a ec2 instance and aws gives those public url (not talking about public ip) instantly, they may be routing all * subdomain queries to a particular server and routes requests from there, am I correct ?
Even is the case is like above how to route further into network ? any software of hardware need to be studied here ?
And aws may be having several levels of subnets for internal network , any tool to manage or need to be studied here ?
How ec2-203-0-113-25.compute-1.amazonaws.com is helping to reach exact server ip ?
DNS change need time because of the premise that layers between you and the DNS caches the DNS response, that can be as long as 24hr or more even. So, when you update the domain name to another IP, It is possible that you need to wait for hours
However, you see at the domain ec2-203-0-113-25.compute-1.amazonaws.com , the part 203-0-113-25 is actually it's public IP address and it does not change. As soon as you change your public IP address, your public DNS is switched to the same pattern also.
Therefore, there is no need to update any public DNS record that can be cached by all the layer inbetween
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.
If I'm in the northeast US and trying to talk to a site on AWS, behind CloudFront, I'm generally getting routed to servers in us-east. For a particular hostname (say, myfico.com), is there any way to force e.g. curl to talk with servers in a different region, presumably by routing my traffic to a different CloudFront edge server?
Since amazon publishes the IP ranges of all their edge servers, I suspect it might be possible to do something like overriding some of my DNS records and forcing it to use an IP prefix from a different region. IT might also be possible to do a more general location spoofing by modifying the edns-client-subnet that's passed along in the DNS request, but I think this might not be possible.
AWS regions are not really related to the CloudFront CDN. Generally speaking AWS region is the region where the server is physically located while the CDN offers a termination point to the client so that it can get a reply from the server quickly. You can possibly hit a CDN node in West US but the request may still be routed to us-east if the website is configured that way.
Our Company local network is connected to a AWS VPC in VPN - see schema below :
view architecture here
Now, we want to configure DNS servers in order to use host name instead of Ip all over the network.
What is the best solution ?
Let Route53 handle DNS for the entire network (even the local one)
Have a DNS server on our local network, and Route53 on Amazon VPC. And if so, how to perform synchronization/replication between local DNS server and Route53 ?
Another solution :)
Thanks !
And have a nice day !
The problem with Route 53 is that it doesn't play with other DNS servers. It is a completely self contained solution. This means that if you used Route 53 your internal servers could only look up through the VNet into Route 53, you couldn't have a secondary Nameserver onsite that took a zone transfer from Route 53 (they don't support them)
You could potentially have caching nameservers internally, and have long expirely times on your host records, so if there was any problem the records wouldn't go stale but this brings its own set of problems.
This leaves you with a couple of solutions.
Use your internal network entirely, set up your internal name servers, internal.example.com and have a secondary name server located inside your Vnet that AWS clients can refer to. This way if there is a problem with the link, both sides still have working DNS.
Alternatively, you could configure internal.example.com in the same way, but then have aws.example.com running on Route 53. (or on a standalone server)
If Route 53 supported Zone Transfers and secondary servers it would be largely irrelevant what you went with but because they don't any solution you build is going to mean rolling some sort of glue to sit in between everything. This is invariably a Very Bad Thing™
We have the same architecture, network wise, and have not found a reasonable way to unify both networks' DNS data into one set of DNS servers.
Here is what works for us.
Assuming you want to use a corporate domain such as example.com, you can get a unified naming scheme where all hosts are under the example.com domain. This is done via Zone Delegation. In this document it states:
Domain Name System (DNS) provides the option of dividing up the
namespace into one or more zones, which can then be stored,
distributed, and replicated to other DNS servers. When you are
deciding whether to divide your DNS namespace to make additional
zones, consider the following reasons to use additional zones:
So in your case:
Use company network DNS for servers/devices on the local network. server1.example.com resolves to the IP# for the local network.
Delegate a subdomain such as 'corp' or 'cloud' to Route 53 for all hosts on AWS. Also known as a subzone, this gives full DNS responsibility to another name server. An instance in EC2 would be referenced as server1.cloud.example.com
This gives you a logical naming scheme, with IP resolution for all hosts on the network.
See Creating a Subdomain That Uses Amazon Route 53 as the DNS Service without Migrating the Parent Domain
There are some 3rd party solutions that add features onto Route 53, easyRoute53, and Route53d. Route53d claims for offer some sup[port for zone transfers (IXFR only).
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.