<html style="direction: ltr;">
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
    <style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;" bidimailui-charset-is-forced="true"
    bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 22/11/16 02:19, Amos Shapira wrote:<br>
    </div>
    <blockquote
cite="mid:CAF9n_WW=V43FgSvvVS34qZhrFHh0m1uYOZON2Rtpsc0wCjJZsg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On 21 November 2016 at 18:20, Shachar
            Shemesh <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:shachar@shemesh.biz" target="_blank">shachar@shemesh.biz</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div bgcolor="#FFFFFF">
                <div class="gmail-m_-7321374812641881217moz-cite-prefix">The
                  DNS resolving <a moz-do-not-send="true"
                    href="http://google.com" target="_blank">google.com</a>
                  guesses your gegraphical location, and gives you an
                  answer that is nearest where you are. If you use
                  another DNS to query the domain, you will get a
                  different IP:<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>It's not always a "guess your geographic location". The
              smarter ones use Anycast to advertise the same IP address
              from multiple locations on the Internet and let BGP do its
              magic to route your packets to the nearest server, taking
              into account any congestion or other transient connection
              speed changes. This is how Google's DNS 8.8.8.8 works, or
              Akamai's CDN. The nice thing about it is that you get
              optimal response even at the host resolution stage. The
              DNS server can then take its knowledge of the DNS query
              source address into account when it decides which IP
              address to resolve to.</div>
            <div><br>
            </div>
            <div>It's pretty neat, personally I find it a fascinating
              trick: <a moz-do-not-send="true"
                href="https://en.wikipedia.org/wiki/Anycast">https://en.wikipedia.org/wiki/Anycast</a></div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    It is, quite fascinating. It is not, unfortunately, as useful as you
    make it out to be. Neither Google nor Akamai use it for web traffic,
    for example.<br>
    <br>
    The reason is twofold. First, anycast is poorly equipted to handle
    TCP connections. There is a (remote) possibility that the handler of
    your IP would change mid-request, which would not play nice with
    your connection.<br>
    <br>
    The second, more pertinent, reason is that , at least for Akamai,
    they would like to be able to control which server you reach when
    you make a request. The would like to be able to re-route your in
    case something bad happens to that server. DNS TTL can be set as low
    as 30 or 60 seconds. BGP routes have much longer settle times.<br>
    <br>
    Shachar<br>
  </body>
</html>