Чи може сервер імен динамічно вирішувати IP-адреси на основі якоїсь стратегії?

11

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

Наша поточна стратегія вирішення DNS полягає в тому, що на основі різних IP-адрес клієнта сервер імен повертає різні IP-адреси для одного домену. Наприклад, якщо IP-адреса клієнта з Північної Америки, сервер імен поверне IP-адресу, яка є IP-адресою нашого центру даних Північної Америки.

Але клієнтська IP-адреса іноді не є реальною IP-адресою користувачів. Це може бути IP-адреса DNS, яка належить провайдеру або проксі-серверу. З іншого боку, якщо один з наших центрів обробки даних не працює, ми хочемо, щоб наш сервер імен виключав ту IP-адресу, яка належить до системи, що розбився. Тож ми сподіваємось, що ми зможемо отримати більш динамічну стратегію для вирішення проблеми DNS. Чи є для цього рішення?

networking  domain-name-system 
— ііфан
джерело
Це звучить як випадок для anycast.
— Рон Моупін
1
@RonMaupin Слід зазначити, що для виконання будь-якої трансляції необхідно виділити незалежний адресний блок постачальника та важливіше запустити BGP, щоб рекламувати префікси з кожного центру даних. Це абсолютно новий рівень операцій, і не щось, з чим матимуть досвід багато "орієнтовані на контент" компанії. Рішення на основі DNS виглядає набагато простіше.
— IPX
@IPX, я б міг уявити, що компанія, яка має центри обробки даних по всьому світу, як здається в питанні, матиме незалежну від провайдера адресацію та власний номер AS. З цим, anycast є безкоштовним та простим.
— Рон Моупін
1
@RonMaupin, якби компанія ОП насправді працювала з декількома центрами обробки даних по всьому світу, то так, але тоді вони, мабуть, не задаватимуть відносно простого питання. Б'юсь об заклад, що вони просто розміщують власну або найману HW в декількох комерційних датацентрах і насправді не роблять / не цікавлять просунуті операційні мережі. Це те, що я бачив, як багато середніх компаній роблять для надмірності. Якщо так, DNS - це відповідь, а не маршрутизація .
— IPX
@IPX, те, що я отримую від запитання, полягає в тому, що компанія має центри обробки даних по всьому світу, і якщо один центр обробки даних виходить з ладу, трафік повинен спрямовуватися до іншого центру обробки даних (" якщо один з наших центрів обробки даних не працює .. . "). Я просто відповів на запитання, а не намагався вгадати про сторонній хостинг, і ми теж робимо щось з цього, але все ж у нас є власний постачальник послуг незалежної адреси та номер AS, який використовується для підгляду з провайдерами. Це дозволяє узгоджувати договори та змінювати Інтернет-провайдери без порушення мережевого перенаправлення.
— Рон Моупін

Відповіді:

16

Це здається, що ви хочете будь-якийкаст. Це тип речі, який використовують сайти, як Google. У вас є одна адреса (вирішена DNS) для всіх ваших веб-сайтів, і ви дозволяєте протоколу маршрутизації в Інтернеті (BGP) направляти користувачів на найближчий (за протоколом маршрутизації) сайт. Якщо сайт закривається, наступний найближчий сайт автоматично розміщується в таблиці маршрутизації в Інтернеті.

Класичний приклад - 8.8.8.8для DNS. Він вирішує різні місця по всьому світу, і якщо одна локація знизиться, то вона переходить до наступного найближчого місця.

Відповідь - не DNS, а маршрутизація.

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

Вам потрібно саме те , що пропонує послуга DNS Amazon Route53 :

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

Якщо ви не є Facebook або Google, ціноутворення також не повинно бути проблемою, починаючи з 0,40 доларів за мільйон запитів (див. Детальну інформацію про ціни ).

Сподіваюся, що це допомагає :)

— MLu
джерело
Ви коли-небудь використовували для цього будь-які не-амазонські продукти?
— пташенята
@chicks nope У мене немає. Я завжди схильний використовувати найкращий інструмент для роботи, і Route53 відповідає більшості випадків. Однак якщо ви google щось на кшталт "geo dns service", ви отримаєте кілька варіантів. Я швидко переглянув декілька, але вони здаються досить дорогими (близько $ 50 / місяць - набагато більше, ніж ви, мабуть, витратили з AWS Route53).
— MLu
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 не обрав найближчих.

— джошудсон
джерело
— Йіфан
Коментарі не для розширеного обговорення; ця розмова була переміщена до чату .
— Уорд - Відновити Моніку
Я перемістив усі коментарі до чату, але оскільки їх було так багато, а деякі були автоматично переміщені, я не впевнений, чи пізніше в чаті є їх усі. У будь-якому випадку, подальше обговорення дійсності цієї відповіді та того, як працюють маршрутизатори тощо, не повинно залишатися в коментарях, зберігайте її в одній із чатів. Подальші коментарі тут буде видалено.
— Уорд - Відновити Моніку
-2

Що вам потрібно, можна досягти за допомогою комбінації DNS anycast та RFC-7871.

— Едельділ
джерело
1
Більш детально покращить вашу відповідь
— Дейв М
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.