Відмова: Без образи, але це дуже погана ідея. Я не рекомендую нікому робити цього в реальному житті.
Але якщо ви дасте нудному ІТ-хлопцеві лабораторію, смішні речі трапляться!
Для цього експерименту я використовував сервер Microsoft DNS, що працює на сервері Server 2012 R2. Через ускладнення розміщення зони DNS в Active Directory я створив нову первинну зону з назвою testing.com, яка не інтегрована AD.
Використовуючи цей сценарій:
$Count = 1
for ($x = 1; $x -lt 256; $x++)
{
for ($y = 1; $y -lt 256; $y++)
{
for ($z = 1; $z -lt 256; $z++)
{
Write-Host "1.$x.$y.$z`t( $Count )"
$Count++
dnscmd . /RecordAdd testing.com testing A 1.$x.$y.$z
}
}
}
Я продовжував створювати, без помилок, 65025 записів хостів для імені testing.testing.com., з буквально кожною IPv4 адресою від 1.1.1.1 до 1.1.255.255.
Тоді я хотів переконатися, що я можу пробити 65536 (2 ^ 16 біт) загальну кількість записів A без помилок, і я міг би, тому припускаю, що, ймовірно, міг пройти весь шлях до 16581375 (1.1.1.1 до 1.255 .255.255,), але я не хотів сидіти тут і дивитися, як цей сценарій працює всю ніч.
Тож я вважаю, що можна впевнено сказати, що немає жодної практичної межі кількості записів A, які ви можете додати до зони з однаковою назвою з різними IP-адресами на своєму сервері.
Але чи справді це буде працювати з точки зору клієнта?
Ось що я отримую від свого клієнта, як його переглядає Wireshark:
(Відкрийте зображення на новій вкладці браузера для повного розміру.)
Як бачите, коли я використовую nslookup або ping від свого клієнта, він автоматично видає два запити - один UDP і один TCP. Як ви вже знаєте, найбільше я можу наткнутися на дейтаграму UDP - це 512 байт, тож після перевищення цього ліміту (наприклад, 20-30 IP-адрес), замість цього потрібно використовувати TCP. Але навіть за допомогою TCP я отримую лише дуже невеликий підмножину записів A для testing.testing.com. Було повернуто 1000 записів за запитом TCP. Список записів A обертається на 1 належним чином із кожним наступним запитом, точно так, як ви б очікували, що буде працювати DNS з круглим доступом. Потрібно було б мільйони запитів, щоб обернутись по всім цим.
Я не бачу, як це допоможе вам зробити вашу масштабну масштабну, стійку мережу соціальних медіа, але все ж є ваша відповідь.
Редагувати: У своєму подальшому коментарі ви запитуєте, чому я вважаю, що це взагалі погана ідея.
Скажімо, я середній користувач Інтернету, і я хотів би підключитися до вашої служби. Я набираю www.bozho.biz у свій веб-браузер. Клієнт DNS на моєму комп’ютері отримує 1000 записів. Ну, невдача, перші 30 записів у списку не реагують на те, що список записів A не оновлюється, або, можливо, є масштабне відключення, що впливає на шматок Інтернету. Скажімо, у мого веб-браузера є час очікування 5 секунд на IP, перш ніж він перейде до наступного. Тож зараз я сиджу тут і дивлюся на крутячий пісочний годинник протягом 2 з половиною хвилин, чекаючи завантаження вашого сайту. Ніхто не має на це часу. І я просто припускаю, що мій веб-браузер або будь-яка інша програма, яку я використовую для доступу до вашої послуги, навіть намагатиметься більше ніж перші 4 або 5 IP-адрес. Мабуть, не буде.
Якщо ви використовували автоматичне підмітання та дозволяєте неперевірені або анонімні оновлення зони DNS з надією зберегти список записів A свіжим ... уявіть, наскільки це небезпечно! Навіть якщо ви створили іншу систему, де клієнтам потрібен клієнтський сертифікат TLS, який вони отримали від вас заздалегідь, щоб оновити зону, один компрометований клієнт в будь-якій точці планети збирається запустити ботнет і знищити вашу послугу. Традиційний DNS настільки небезпечний, як він є, без натовпу.
Гуморна використання смуги та відходів. Якщо для кожного запиту DNS потрібно 32 кілобайт або більше смуги пропускання, це зовсім не буде масштабним.
DNS круглий робін не замінює правильне врівноваження навантаження. Це не дає можливості відновитись із одного вузла, що йде вниз або стає недоступним посеред речей. Чи збираєтесь ви доручити своїм користувачам робити ipconfig / flushdns, якщо вузол, до якого вони були підключені, знизиться? Такі питання вже вирішені такими речами, як GSLB та Anycast.
І т.д.