Как сделать, региональный DNS как CDN делает?

Проблема с CDNs состоит в том, что они не направляют Вас на основе Вашего собственного IP-адреса - они направляют Вас на основе IP-адреса Вашего сервера DNS... Это могло быть абсолютно неправильно. И действительно прочитайте статью ACM Paul Vixie, это, барабанят в деньги.

Во всяком случае, если Вы уже добрались region.example.com настроенный и выполнение, Вы могли рассмотреть выполнение перенаправления HTTP от example.com к соответствующему веб-серверу, на основе IP-адреса клиента.

Это в значительной степени, что делает Google, это - как я заканчиваю в google.co.uk введя google.com.

Действительно также удостоверьтесь, хотя это Вы предоставляете средство клиентам добраться до других изменений. Клиентам не нравится он, когда они вынуждены к конкретному сайту, ли ошибками в базах данных Geo или просто потому что они на самом деле должны обратиться на сайт от другого региона.

Существует много способов обработать это, но они все сводятся к выяснению, где IP-адрес, и указание на него соответственно. Например, Вы могли бы указать диапазон дюйм/с для Северной Америки и один для Европы. Если IP, запрашивающий информацию (от DNS, Вашего веб-сервера, Вашего сервера содержания, и т.д.) падения европейского диапазона, то Ваши европейские серверы должны получить запросы.

Вы могли установить основную страницу по умолчанию по example.com. В первый раз, когда кто-то посещает, они выбирают, к какому региону они хотят быть направленными. Это - тот же способ, которым работает www.ups.com.

Пользователь может установить флажок для совершения этого его выбора по умолчанию от той точки на, таким образом храня выбор в cookie.

Это дает Вам преимуществу использования DNS таким образом, это было разработано для по словам Paul Vixie, позволяя Вашему пользователю сделать самый точный decsion, на котором дата-центре они должны быть направлены к.

Новые CDN (Cloudflare, MaxCDN, fast.ly) используют anycast для обоих DNS и фактические контент-серверы. Это несколько лучше, чем пытаться использовать исходный IP-адрес DNS-запроса и постоянно меняющуюся базу данных сопоставления.

Теоретически использование anycast как для DNS, так и для серверов содержимого позволяет самой сети находить «ближайшие» серверы к клиенту. . На практике это в основном верно, но возникают некоторые странные случаи, когда люди в Сингапуре попадают в пограничные серверы в Калифорнии, а не в Гонконге из-за постоянно меняющихся отношений пиринга между интернет-провайдерами.

Anycast трудно преуспеть .

Старые CDN, такие как Akamai и Limelight, обычно используют anycast, чтобы добраться до ближайшего DNS-сервера, но затем используют подход, основанный на предположениях на основе IP-адреса источника. По моему опыту, это не работает, особенно если клиент использует DNS-серверы, которых нет поблизости с точки зрения топологии сети. Тем не менее, у огромного установленного CDN, такого как Akamai, есть сотни местоположений серверов контента, поэтому ответ «достаточно близко» обеспечивает достойный пользовательский опыт. Очевидно, что иметь сотни сайтов очень дорого, поэтому ни одна из сетей CDN с универсальным доступом не выбрала этот маршрут. Следовательно, они также не взимают столько же за почти эквивалентную услугу.

Если у вас есть веб-сайт, размещенный в нескольких регионах, то вам не нужно ничего делать на уровне DNS. Вы можете использовать API, например http://ipinfo.io, чтобы получить страну посетителя, а затем перенаправить его на соответствующий URL.

Если речь идет не о веб-сайте или каком-либо протоколе, который обрабатывает перенаправление, то есть несколько вариантов на уровне DNS. Можно выполнить поиск одной и той же IP страны и затем вернуть запись, соответствующую региону (DNS на основе геолокации), или иметь карту задержек между различными сетями, и вернуть запись, которая представляет собой наименьшую задержку для пользователя (DNS на основе задержек). Служба DNS Route53 компании Amazon предлагает и то, и другое.