Мы зарегистрировали несколько серверов имен для разрешения DNS для нашего веб-сайта, который развернут в нескольких центрах обработки данных.
Наша текущая стратегия разрешения DNS заключается в том, что на основе разных IP-адресов клиентов сервер имен будет возвращать разные IP-адреса для одного и того же домена. Например, если IP-адрес клиента из Северной Америки, сервер имен вернет IP-адрес, который является IP-адресом нашего центра обработки данных в Северной Америке.
Но иногда IP-адрес клиента не является настоящим IP-адресом пользователей. Это может быть IP-адрес DNS, принадлежащего интернет-провайдеру или прокси-серверу. С другой стороны, если один из наших центров обработки данных не работает, мы хотим, чтобы наш сервер имен исключал тот IP-адрес, который принадлежит поврежденному центру обработки данных. Поэтому мы надеемся, что сможем получить более динамичную стратегию разрешения DNS. Есть ли решение для этого?
Похоже, вы хотите любую трансляцию. Это то, что используют такие сайты, как Google. У вас есть единый адрес (разрешаемый DNS) для всех ваших веб-сайтов, и вы позволяете протоколу маршрутизации в Интернете (BGP) направлять пользователей на ближайший (по протоколу маршрутизации) сайт. Если сайт выходит из строя, следующий ближайший сайт автоматически помещается в таблицу маршрутизации Интернета с помощью BGP.
Классический пример: 8.8.8.8 для DNS. Он разрешается в разные места по всему земному шару, и если одно из них выходит из строя, оно переходит в следующее ближайшее.
Ответ не DNS, это маршрутизация.
Вам нужно именно какие Amazon Route53 Служба DNS предложения:
Маршрутизация на основе задержки - Направляйте конечных пользователей в регион AWS, который обеспечивает минимально возможную задержку.
Гео DNS - Направляйте конечных пользователей к определенной конечной точке, которую вы указываете в зависимости от географического положения конечного пользователя.
Проверки работоспособности и отказоустойчивость - Amazon Route 53 может отслеживать состояние и производительность вашего приложения, а также ваших веб-серверов и других ресурсов.
Вы не обязательно разместите свой веб-сайт на AWS, чтобы иметь возможность использовать Route53, он будет без проблем работать с сервисами, развернутыми в частных центрах обработки данных.
Если вы не являетесь пользователем Facebook или Google, цены тоже не должны быть проблемой, начиная с 0,40 доллара США за миллион запросов (см. информация о ценах).
Надеюсь, это поможет :)
У меня возникла эта идея, и я начал ее кодировать, но так и не закончил, потому что сначала испарилась потребность.
DNS-сервер имеет имена хостов и MAC-адреса всех машин в своей локальной сети, а также способ доступа к ним. Когда он получает запрос на машину, которую он знает, он отправляет обратный ARP для IP-адреса, заданного MAC-адресом, и использует ответ для построения ответа DNS.
Это не имеет отношения к тому, что вы пытаетесь сделать, но это иллюстрирует суть. Теоретически DNS-сервер может быть запрограммирован для реализации любой новой схемы преобразования имен в IP-адреса.
Фактический вопрос, по-видимому, заключается в том, как получить IP-адрес клиента, чтобы решить, куда его отправить. Это небольшая проблема XY. На самом деле вам нужен интернет-провайдер клиента для геолокации, и вы можете получить это, сделав это напрямую с IP-адреса, отправляющего запрос, при условии, что это не 8.8.4.4 или какая-либо другая служба перенаправления DNS. На мой взгляд, лучшим решением для перенаправителей DNS является игнорирование проблемы и выполнение относительной геолокации (то есть попытка DNS-сервера определить местонахождение вызывающего IP-адреса) и соответствующего перенаправления. Смотрите здесь, как определить географическое положение: https://stackoverflow.com/questions/2574542/location-detecting-techniques-for-ip-addresses
Вы действительно действительно не хотите здесь ничего, кроме чего-то более разумного. Anycast имеет раздражающее свойство, так как он может перенаправлять пакеты в середине вашего TCP-потока, вызывая массовую путаницу.
Рон Мопин утверждает, что Anycast надежен для маршрутизации TCP. Вот трассировка, показывающая иное:
3 cr1-rhe-a-be153.bb.as11404.net (174.127.183.14) 20.657 ms 20.763 ms 19.660 ms
4 cr1-che-b-be-2.as11404.net (192.175.29.161) 22.550 ms 23.562 ms 23.538 ms
5 * cr1-9greatoaks-hu-0-6-0-20-0.bb.as11404.net (192.175.28.108) 24.409 ms 38.083 ms
6 72.14.222.146 (72.14.222.146) 40.038 ms 39.106 ms 39.125 ms
7 108.170.242.225 (108.170.242.225) 37.930 ms 108.170.243.1 (108.170.243.1) 35.434 ms 108.170.242.225 (108.170.242.225) 33.694 ms
8 209.85.240.249 (209.85.240.249) 33.476 ms 108.170.232.65 (108.170.232.65) 31.683 ms 108.170.234.155 (108.170.234.155) 30.754 ms
9 google-public-dns-b.google.com (8.8.4.4) 30.491 ms 28.644 ms 25.718 ms
Если вы попытаетесь геолоцировать восходящие IP-адреса, очевидным способом получите их оба в Уичито. Это неверно, и достаточно простой демонстрации физики.
Диапазон до 8.8.4.4 измеряется в 30 мс, из которых первые 18 мс - это локальный штраф (переход 3 - это локальный маршрутизатор моего интернет-провайдера). Мое расстояние до Уичито составляет 1297 миль. Таким образом, минимальное время прохождения туда и обратно составляет (1297 * 2 миль / 225 000 километров в секунду (скорость света в стекле)), что составляет 18,55 мс. Поэтому я не должен получать ответ быстрее 28 мс, но я получил ответ через 25 мс.
Пакеты поступают в Google по двум различным маршрутам BGP. BGP не выбирал ближайший.
То, что вам нужно, может быть достигнуто с помощью некоторой комбинации DNS anycast и RFC-7871.