Отказ от ответственности: без обид, но это действительно плохая идея. Я не рекомендую никому делать это в реальной жизни.
Но если вы дадите скучающему айтишнику лабораторию, произойдут забавные вещи!
Для этого эксперимента я использовал DNS-сервер Microsoft, работающий на 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, прежде чем он включается и пытается следующий. Так что теперь я сижу и смотрю на вращающиеся песочные часы в течение двух с половиной минут, ожидая загрузки вашего сайта. Ни у кого нет времени на это. И я просто предполагаю, что мой веб-браузер или любое другое приложение, которое я использую для доступа к вашему сервису, даже попытается сделать больше, чем первые 4 или 5 IP-адресов. Это, вероятно, не будет.
Если вы использовали автоматическую очистку и разрешаете не подтвержденные или анонимные обновления в зоне DNS в надежде сохранить список записей A свежим ... просто представьте, насколько небезопасным это будет! Даже если вы разработали систему, в которой клиентам был необходим клиентский сертификат TLS, который они получили от вас заранее для обновления зоны, один скомпрометированный клиент в любой точке планеты запустит ботнет и уничтожит ваш сервис. Традиционный DNS опасен как таковой, без использования краудсорсинга.
Огромное использование пропускной способности и трата. Если для каждого DNS-запроса требуется 32 килобайта или более полосы пропускания, это не будет хорошо масштабироваться.
DNS round-robin не заменяет правильную балансировку нагрузки. Он не дает возможности восстановиться после того, как один узел вышел из строя или стал недоступным в середине событий. Собираетесь ли вы поручить своим пользователям делать ipconfig / flushdns, если узел, к которому они были подключены, выходит из строя? Такие проблемы уже решены такими вещами, как GSLB и Anycast.
И т.п.