Re: Why are there no GeoDNS solutions anywhere in sight?

2013-04-14 Thread Eric Adler
If this is for http and similar user-accessed (not machine accessed)
traffic, you could do what some large manufacturers and shipping companies
do: Provide a (relatively) low-bandwidth Select where you are in the
world global landing page which then redirects to a different
domain/subdomain for each region.  This also lets them direct relatively
localized content easily. For example, panasonic.com can list items sold
mass-market for the US, panasonic.nl for the Netherlands, and
panasonic.com.au for Australia.  Yes, you may well run into times that a
user in the US goes to the .au site because s/he wants to research an .au
product that isn't detailed on the US page but this is not the bulk of your
traffic (and, if through stats, you find it becomes so, you can work on
your design so that it isn't).

- Eric


On Wed, Mar 20, 2013 at 11:28 PM, Constantine A. Murenin muren...@gmail.com
 wrote:

 Dear NANOG@,

 Not every operator has the ability to setup their own anycast.

 Not every operator is big enough to be paying 25 USD/month for a
 managed GeoDNS solution, just to get their hands on GeoDNS.  (Hey, for
 25$/mo, I might as well have an extra POP or two!)

 Why so many years after the concept has been introduced and has been
 found useful, can one not setup GeoDNS in under 5 minutes on one's own
 infrastructure, or use GeoDNS from any of the plentiful free or
 complementary DNS solutions that are offered by providers like he.net,
 xname.org, linode.com and others?

 I'm an NSD3 user and have a POP in Europe and NA, and, frankly, the
 easiest (and only) solution I see right now is, on both servers,
 running two copies of `nsd` on distinct sockets, and redirecting
 incoming DNS traffic through a firewall based on IPv4 /8 address
 allocation (RIPE and AfriNIC -- to an `nsd` instance with zone files
 with an `A` record of a POP in Europe; ARIN, APNIC, LACNIC and the
 rest of /8 allocations -- an `A` record for NA), with zone replication
 managed through git.  Yeap, it's rough, and quite ugly, and
 unmaintainable, and will give optimal results only in 80 to 95 per
 cent of actual cases, and will not benefit from the extra webapp
 redundancy one otherwise might have had, but what other alternatives
 could be configured in 5 or 15 minutes?

 Any plans to make DNS itself GeoDNS-friendly?

 When editing a zone file in `emacs`, why can one not say that one has
 3 web servers -- Europe, NA, Asia -- and have the dns infrastructure
 and/or the web-browser figure out the rest?

 Why even stop there:  all modern browsers usually know the exact
 location of the user, often with street-level accuracy.  It should be
 possible to say that you have a server in Fremont, CA and Toronto, ON
 or Beauharnois, QC, and automatically have all East Coast users go to
 Toronto, and West Coast to Fremont.  Why is there no way to do any of
 this?

 Cheers,
 Constantine.




Re: Why are there no GeoDNS solutions anywhere in sight?

2013-04-14 Thread Jimmy Hess
On 3/21/13, Constantine A. Murenin muren...@gmail.com wrote:
 Does it sound too complicated and pointy?  Yes, it's not exactly
 trivial, and not as good as BGP, but better than having 300ms latency
 from a simple round-robin.

It sounds like you are asking about Geolocation, when what you really
want is latency-based selection.  Latency is more complicated, and
influenced by factors other than purely Geographic location.
Furthermore,  distance  doesn't work all that well as a measure of
latency:  it only defines the latency, in the best case scenario for a
link between the geo locations.

Why not just have the browser send a SYN packet to every IP  in the
A/   RRSET?

Whichever webserver's response to the connection handshake is received
first wins (lowest RTT latency);  the other two or three connections
are  just dropped,  so there is some minor waste,  in exchange  for
picking the lowest RTT destination.



Now another alternative would be for the local network operator to
offer some sort of  latency lookup service;

Based on implementing packet inspection,  and gathering statistical
information RTT and average throughput and retransmit rates
experienced during  network users' TCP handshakes to remote prefixes,
aggregated at an AS level.

So the browser could query  the latency lookup service  for the
hostname,   and receive a DNS reply  annotated  with an estimated
historical average latency, drop rate, throughput for  the IP prefix
inquired about.

Or in fact... have the lookup service re-order or filter the query
result,  so the responses with higher than a certain cutoff latency
are placed last in the response,  or filtered/deleted from the
response,  when there are at least 3 better choices.


 C.
--
-JH



Contact for BGP at nic.mil (AS721 AS27064)

2013-04-14 Thread Bernhard Schmidt
Hello,

if someone from nic.mil (AS721 and/or AS27064) is present please contact
me off-list. I have a persistent routing issue from your network to one
of my prefixes at AS29259 that I can't get cleared, even by bouncing the
prefix. whois-contact (hostmas...@nic.mil) did not answer.

Thanks,
Bernhard