Может ли сервер имен разрешать IP-адреса динамически на основе какой-либо стратегии?

11

Мы зарегистрировали несколько серверов имен для разрешения DNS для нашего веб-сайта, который развернут в нескольких центрах обработки данных.

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

Но IP-адрес клиента иногда не является реальным IP-адресом пользователей. Это может быть IP-адрес DNS, который принадлежит провайдеру или прокси-серверу. С другой стороны, если один из наших центров обработки данных не работает, мы хотим, чтобы наш сервер имен исключал тот IP-адрес, который принадлежит к поврежденному центру обработки данных. Поэтому мы надеемся, что сможем получить более динамичную стратегию для решения DNS. Есть ли решение для этого?

networking  domain-name-system 
— Ифань
источник
Это звучит как случай для anycast.
— Рон Мопин
1
@RonMaupin Следует отметить, что для выполнения anycast необходимо иметь независимое от поставщика выделение блоков адресов и, что более важно, запустить BGP для объявления префиксов из каждого центра обработки данных. Это совершенно новый уровень деятельности, и не так уж много «контент-ориентированных» компаний имеют опыт. Решение на основе DNS выглядит намного проще.
— IPX
@IPX, я полагаю, что компания с центрами обработки данных по всему миру, как кажется в этом вопросе, будет иметь независимую от поставщика адресацию и свой собственный номер AS. С этим anycast свободен и легок.
— Рон Мопин
1
@RonMaupin , если компания в OP была на самом деле работает несколько центров обработки данных по всему миру , то да, но тогда они , вероятно, не спрашивая относительно простой вопрос здесь. Могу поспорить, что они просто размещают свои собственные или нанятые HW в нескольких коммерческих центрах обработки данных и на самом деле не заботятся о продвинутых сетевых операциях. Это то, что я видел, что многие средние компании делают для резервирования. В этом случае DNS является ответом, а не маршрутизацией .
— IPX
@IPX, что я понял из вопроса, что у компании есть центры обработки данных по всему миру, и если один центр обработки данных дает сбой, направляемый трафик следует направлять в другой центр обработки данных (« если один из наших центров обработки данных не работает ..» . "). Я просто ответил на вопрос, как задано, вместо того, чтобы пытаться угадать сторонний хостинг, и мы тоже кое-что делаем, но у нас все еще есть собственная независимая от провайдера адресация и номер AS, используемый для взаимодействия с ISP. Это позволяет согласовывать контракты и менять интернет-провайдеров без прерывания переадресации в сети.
— Рон Мопин

Ответы:

16

Похоже, вы хотите anycast. Именно такие вещи используют такие сайты, как Google. У вас есть один адрес (разрешенный DNS) для всех ваших веб-сайтов, и вы позволяете протоколу интернет-маршрутизации (BGP) направлять пользователей на ближайший (по протоколу маршрутизации) сайт. Если сайт выходит из строя, следующий ближайший сайт автоматически помещается в таблицу маршрутизации Интернета с помощью BGP.

Классический пример 8.8.8.8для DNS. Он разрешается в разных местах по всему земному шару, и если одно место падает, то оно переходит в следующее ближайшее место.

Ответ не DNS, это маршрутизация.

— Рон Мопин
источник
2
Anycast обычно бесполезен для протоколов на основе TCP, поскольку пакеты, принадлежащие одному и тому же соединению, могут отправляться на разные серверы.
— Paŭlo Ebermann
2
@ PaŭloEbermann, это не проблема, когда вы делаете это с маршрутизацией BGP, так как маршруты обычно не меняются, когда объявляется (только незначительные изменения)
— Ferrybig
2
@ PaŭloEbermann Вы можете выполнить anycast для балансировщиков нагрузки на основе DSR, если все ваши балансировщики нагрузки согласуются с выбором внутренних интерфейсов.
— kasperd
3
@ PaŭloEbermann, это заблуждение. Весь трафик с одного хоста пойдет на один сервер, если этот сервер не выйдет из строя, тогда трафик будет направлен на другой сервер. Да, это приведет к разрыву TCP-соединения, но так будет, если сервер, к которому вы подключены, выходит из строя. Anycast - это не круглая вещь. Маршрутизация является детерминированной, поэтому anycast является детерминированной.
— Рон Мопин
2
@RonMaupin Anycast маршрутизация не так стабильна, как вы предполагаете. И Google не использует anycast, как вы говорите. Если вы хотите узнать, как на самом деле это делает Google, взгляните на страницу 227 в книге по надежности сайта, опубликованной Google. Короче говоря, уровень балансировки нагрузки за маршрутизацией anycast компенсирует неизбежные изменения в маршрутизации, которые в противном случае разорвали бы соединения TCP.
— Касперд
9

Что вам нужно, так это то, что предлагает сервис DNS Amazon Route53 :

Вам не нужно размещать свой веб-сайт на AWS, чтобы использовать Route53, он с радостью будет работать со службами, развернутыми в частных центрах обработки данных.

Если вы не являетесь Facebook или Google, цены не должны быть проблемой, начиная с $ 0,40 за миллион запросов (см. Информацию о ценах ).

Надеюсь, это поможет :)

— мМЕ
источник
Вы когда-нибудь использовали для этого продукты не-Amazon?
— птенцы
@ цыплят Нет, у меня нет. Я всегда стремлюсь использовать лучший инструмент для работы, и Route53 отвечает всем требованиям в большинстве случаев. Однако, если вы воспользуетесь чем-то вроде «geo dns service», вы получите несколько вариантов. Я быстро посмотрел на несколько, но они кажутся довольно дорогими (около 50 долларов в месяц - гораздо больше, чем вы, вероятно, потратили бы на AWS Route53).
— МЛ
2
Я бы немного расширил свою точку зрения, прежде чем вызывать первый инструмент, который я нашел лучшим в большинстве случаев. Route53 может быть лучшим для всех, но как бы вы узнали, если бы вы ничего не пробовали?
— птенцы
-1

У меня была эта идея, и я начал ее кодировать, но так и не закончил, так как потребность исчезла первой.

DNS-сервер имеет имена хостов и MAC-адреса всех машин в своей локальной сети и способ их достижения. Когда он получает запрос для машины, которую он знает, он отправляет обратный ARP для IP-адреса с заданным MAC-адресом и использует ответ для построения ответа DNS.

Это не имеет ничего общего с тем, что вы пытаетесь сделать, но это иллюстрирует суть. DNS-сервер теоретически может быть закодирован для выполнения любой новой схемы, в которой вы хотите преобразовать имена в IP-адреса.

Похоже, что реальный вопрос заключается в том, как получить IP-адрес клиента, чтобы решить, куда его отправлять. Это небольшая проблема XY. То, что вы действительно хотите, - это определение местоположения интернет-провайдера клиента, и вы можете получить это, выполнив это непосредственно с IP-адреса, отправляющего запрос, предполагая, что это не 8.8.4.4 или какая-либо другая служба перенаправления DNS. На мой взгляд, лучшим решением для перенаправителей DNS является игнорирование проблемы и самостоятельная геолокация (то есть с DNS-сервера попытайтесь найти вызывающий IP-адрес) и перенаправление соответствующим образом. Смотрите здесь, чтобы узнать, как геолокации: /programming/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 не выбрал ближайший.

— joshudson
источник
— Ифань
Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
— Опека - Восстановите Монику
Я переместил все комментарии в чат, но поскольку их было так много, а некоторые были автоматически перемещены, я не уверен, что в последнем чате они есть. В любом случае, дальнейшее обсуждение действительности этого ответа и того, как работают маршрутизаторы и т. Д., Не должно быть в комментариях, храните его в одной из комнат чата. Любые дальнейшие комментарии здесь будут удалены.
— Опека - Восстановите Монику
-2

То, что вам нужно, может быть достигнуто с помощью некоторой комбинации DNS anycast и RFC-7871.

— Edheldil
источник
1
Более подробно бы улучшил ваш ответ
— Дейв М
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.