This issue came up as a result of SEO concerns, but having done some further research, it seems Google feels that IP/hosting location are now a weak signal for ranking, at best. So now I'm just curious, as I'm only familiar with networking on a basic level.
I have several sites hosted in the europe-west-1 region. Each site is on a compute engine instance with an external static IP assigned. I can ping the domains/IPs and then have my colleague in the UK ping the same and based on response time it's clear that the IP is ultimately resolving in Europe (probably Dublin, Ireland where it should be). But a DNS lookup of the same domain/IP lists the IP in Mountain View, CA? It always comes out like this: xxx.xxx.xxx.xxx.bc.googleusercontent.com. Is this Google acting like an ISP, and then the routing to Europe is behind the scenes? Why do none of the IPs show as resolving in the data center where the instances are hosted?
It sounds like you are conflating three concepts:
The domain registration for the googleusercontent.com reverse DNS
The SWIP record for the subnet
The routing decision to reach an IP
All three are independent. All GCE instance IP addresses have a reverse DNS entry that maps to xxx.xxx.xxx.xxx.bc.googleusercontent.com. This domain is under Google's control and therefore registered to the HQ in Mountain View.
The SWIP record / WHOIS entry denotes the administrative ownership of an IP address resp. its subnet. It's therefore also registered to the HQ in Mountain View.
Both of these do not reflect anything about physical location of the machine answering packets to an IP address nor the decisions on how packets are routed to the destination.
Google has a global network. Packets to a GCE instance will cross over to Google's network relatively close to the client. Since Google maintains a lot of peerings with ISPs worldwide, most of the time your packets will end up on Google's network directly from your ISP.
If you run a traceroute to your instance, you might see hops with airport codes in their reverse DNS names, especially when traversing peering points. The hops internal to Google usually do not hint any further at geographical location.
And finally, when the "proximity" or location of an IP address is discussed, most of the time the relevant metric is the latency or network distance to the host - not the geographical distance. (Although geographical distance sets a lower bound for latency as packets cannot go faster than the speed of light)
Related
My understanding is that when querying a domain's DNS records, the response can vary depending on the client's IP address. Is there a simple way to obtain all DNS records for all possible IP addresses?
You can not.
The response can vary on many factors.
You can not from remote discover the business policies of a nameserver, or in fact any server. It can decide to reply 192.0.2.1 for odd hours and 192.0.2.11 for even ones, or any other non trivial business rule.
A more realistic one: there can be a service on 3 IP addresses. A nameserver may be programmed to reply with the IP address of the box being currently less loaded. Hence you will never be able to see those details remotely.
I am curious, I am analyzing the DNS section for the website imgur.com. My doubt is that when I run "dig imgur.com" dig only returns an IP address, if I run again the same command dig returns another IP address or sometimes the same.
Another question:
By using dig www.imgur.com get a CNAME to another domain, is this normal?, Can someone explain to me?
Thanks
You should check Round-robin DNS.
Round Robin DNS is a technique of load distribution, load balancing,
or fault-tolerance provisioning multiple, redundant Internet Protocol
service hosts, e.g., Web server, FTP servers, by managing the Domain
Name System's (DNS) responses to address requests from client
computers according to an appropriate statistical model.
In its simplest implementation, Round-robin DNS works by responding to
DNS requests not only with a single potential IP address, but with one
out of a list of potential IP addresses corresponding to several
servers that host identical services. The order in which IP addresses
from the list are returned is the basis for the term round robin. With
each DNS response, the IP address sequence in the list is permuted.
Usually, basic IP clients attempt connections with the first address
returned from a DNS query, so that on different connection attempts,
clients would receive service from different providers, thus
distributing the overall load among servers.
I've only recently begun scratching the surface of hosting my own DNS, but I'm looking to do so in the hopes that I can facilitate my own reverse lookups.
My idea being that if I can manage my own DNS, I can give it tables I've complied about IP / FQDN relations so I can do a reverse lookups on dynamic ips (of which I know the FQDN of) without my ISP's support; I'd pair the return of something like an nslookup somewhere within my own hosted DNS then have that DNS server facilitate reverse DNS lookups for some programs that require the function (like for a CFEngine Hub)
Near as I can tell, the 'PRT' record is what I want to spoof; Right?
I'm wondering if there are better resources out in the wild to use. This and this are the best I've found about hosting DNS in this manner.
Any pitfalls I'm not seeing about trying to pursue this convoluted solution?
Reverse lookup requires the IP address owner to delegate reverse lookup DNS to you. Note that the owner here is not the DHCP recipient, but whoever assigns the IP address.
For a completely internal network, it would be possible to configure your own PTR records since you control the IP addresses being assigned.
On third party networks, the third party (who assigns IP addresses to you) would need to delegate reverse lookup for those IPs to you. In a dynamic IP situation, this delegation is unlikely because your IP comes out of a pool that is used for assigning IP addresses to many customers, not just you. Some ISPs allow allow programmatic access to configure reverse lookups, but this again seems unlikely for dynamic DNS for the same reason as delegation -- the addresses are part of pool assigned to any customer using it, not just you.
It might be possible to hack ("shadow"?) it by requiring your users / clients to use your DNS server and populating "fake" (since you don't actually have ownership of the IPs) PTR records.
Article on reverse lookup sequence and info.
http://www.dnsstuff.com/reverse-dns-faq
A way around this might be to create your own tool for looking through your forward lookup table for a specific IP address. However, this would be a custom tool separate from the usual DNS lookup tools like nslookup and dig.
I have a webapplication in multiple Regions in the Azure Cloud and i'm using the Traffic Manager in Performance mode zu redirect the user to the closest Region.
What's concerning me is the following:
With this site https://www.whatsmydns.net i checked my Webapplication to see, which Datacenter is selected.
The funny thing is, that people from California gets redirected to the server in Westeurope but there is a Server in US Central too.
So from the site of the traffic manager the ping to the europe server is faster then to US central.
But i believe, that the difference between these too can not be high...
Now i have the fear, that it can happen that a user jumps between US Central and Europe all the time because he is in such a zone where the latencies to the available servers are nearly identical.
I also store files in a Azure Storage account in each region. If the user now jumps, i would have to transfer these files between the regions all the time...
So i was wondering if there is a possibility to redirect the user by his GEOIp to a specific region than by latency?
One of the benefit of the traffic manager is in my eyes that i can use one domain for all regions...
the only solution for my problem i can think of is a own cloudservice which replaces the traffic manager and redirects the user to the different regions by their IP like us-center.DOMAIN.com, we-eu.DOMAIN.com etc...
Are there any other solutions?
Thanks for your help!
Br,
metabolic
If you believe Traffic Manager is routing queries incorrectly, that should be raised with Azure Support.
Traffic Manager 'Performance' mode routing is based on an internal 'IP address to Azure data center latency map. The source IP of the DNS query (which is typically the IP of your DNS server) is looked up in the map to determine which Azure location will offer the best performance. There is an implicit assumption that the IP address of the DNS server is a good proxy for the location of the end user.
The 'Performance' mode in Azure Traffic Manager is deterministic. Identical queries from the same address will be routed consistently. The only exception is that routing may change during occasional map updates, which affect only a small %age of the IP address space.
A more common cause of routing changes is customers moving from place to place. For example, during travel, or simply by picking up a Wifi network that uses a DNS service in a different location, with a different IP address.
A Geo-IP based routing is not currently supported by Traffic Manager. However, please note that it would work in the same way as the 'performance' routing, just that it would use a different map. Users could still be routed to different locations as a result of map updates or changing DNS servers.
As you describe, if your application requires a strong, un-violable association between a user and a region, one option is re-direct users at the application level (e.g. via HTTP 302).
I'm testing Google Cloud DNS.
I have 3 A NAMES in my test zone that all resolve to the same DNS name.
The servers are in Australia, Northwest US, and India.
I am located in Northwest US.
When I do a tracert on my DNS name, it goes to the IP in the Australian data center.
From me to the Northwest US data center has much lower latency.
Why does it pick Australia? I thought latency based routing was "built-in" to an anycast network.
thanks in advance
Google Cloud DNS does not do latency based routing.
The Cloud DNS nameservers are on anycast network, so your DNS queries will be routed to the "nearest" nameserver. See https://cloud.google.com/dns/what-is-cloud-dns#performance_and_timing. Your servers' ip addresses, however, are not on that network.
To my knowledge Google Cloud DNS doesn't do lowest latency routing. AWS has regions in the places you mentioned, so it might be worth checking out Route 53. I primarily use GCE for compute resources, but generally use Route 53 for DNS. http://aws.amazon.com/blogs/aws/latency-based-multi-region-routing-now-available-for-aws/
http://aws.amazon.com/route53/faqs/#Route_53_anycast
If you have 3 A records on the same domain. The nameserver will ALWAYS return all 3 IPs.
Then your computer just pick one of them to ping/traceroute. Same for browsers(browsers will try another if the current one is down).
If you want the nameserver return the nearest server, use AWS Route 53's latency/geo based function. Google Cloud DNS don't have such function so far.
However if you have all your servers at Google, you may want to try their Load Balancer + CDN. The overall latency and performance is amazing, just like the speed your credit card is burning. lol