Какое максимальное количество IP-адресов может иметь DNS-запись?

У меня странная идея - позволить нескольким людям / организациям размещать одно и то же приложение, и чтобы все их узлы были доступны через одно доменное имя. Это для того, чтобы иметь, скажем, действительно распределенную социальную сеть, в которой удобство использования не принесено в жертву (то есть пользователям не нужно запоминать разные URL-адреса провайдеров, а затем, когда один провайдер отключается, переключиться на другого)

Для этого я подумал, что можно использовать запись DNS с несколькими IP-адресами.

Итак, сколько IP-адресов может хранить одна запись DNS A? В этом ответе говорится, что около 30, но сценарий использования другой. Для приведенного выше сценария мне было бы все равно, если данный провайдер кэширует только 30, если другой провайдер кэширует еще 30 и так далее.

Отказ от ответственности: без обид, но это действительно плохая идея. Я не рекомендую никому делать это в реальной жизни.

Но если вы дадите скучающему айтишнику лабораторию, произойдут забавные вещи!

Для этого эксперимента я использовал 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.

• И т.п.

Чтобы ответить на вопрос, как было сказано («сколько IP-адресов может хранить одна запись DNS A?»), Ответ очень прост: одна Aзапись содержит ровно один адрес. Однако может быть несколько Aзаписей для одного и того же имени.

Каждый адрес IPv4 займет 16 байтов в ответе. Каждый адрес IPv6 займет 28 байтов в ответе.

Настоятельно рекомендуется убедиться, что ответ уместится в 512 байт. Это позволило бы использовать около 25 адресов IPv4 и 14 адресов IPv6 (учитывая, что в пакете также нужна другая информация). Точный лимит зависит от длины вашего доменного имени.

Если у вас есть как 25 адресов IPv4, так и 14 адресов IPv6, то вы рассчитываете на клиентов, запрашивающих адреса IPv4 и IPv6 в отдельных запросах. Если клиент запрашивает оба типа адресов в одном запросе (что бывает редко), вам придется пойти ниже.

Если размер ответа превышает 512 байт, он все равно может работать через UDP, если клиент и сервер поддерживают EDNS. Без EDNS клиент получал бы усеченный ответ и должен был бы повторить попытку по TCP. Это увеличивает общение с 1 до 4 туда и обратно. Но что еще хуже, иногда возникают неправильные конфигурации, препятствующие работе DNS через TCP.

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

Ожидание этого таймаута даже один раз может привести к ухудшению работы пользователей. Если клиент должен был пройти через 14 адресов, прежде чем получить ответ, пользователю пришлось бы ждать 13 тайм-аутов.

То, что вы описываете, не особенно новая идея. Как уже упоминалось в других ответах, вы ограничены тем, сколько записей A вы можете иметь в одном ответе, но это ничего не говорит о том, сколько записей A может быть в общей сложности.

Например, вы можете реализовать DNS-сервер, который отвечает на любой запрос записи A со случайным IP-адресом. При достаточном количестве запросов это приведет к созданию 4294967296 уникальных записей A: по одной на каждый адрес IPv4.

Как я уже сказал, это не новая идея. На самом деле, это отчасти то, как работает Akamai (и, вероятно, множество других CDN). Запись A, которую вы получаете для любого домена Akamai, определяется их черными магическими DNS-серверами. Бьюсь об заклад, ответ, который вы получите, зависит от динамической балансировки нагрузки и географических проблем.

Например, я выбрал a338.g.akamaitech.net. Если я сейчас посмотрю на мой компьютер, который использует назначенный DHCP сервер имен из Comcast:

$ host a338.g.akamaitech.net
a338.g.akamaitech.net has address 23.3.98.65
a338.g.akamaitech.net has address 23.3.98.89

Что делать, если я спрашиваю DNS Google?

$ host a338.g.akamaitech.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

a338.g.akamaitech.net has address 23.3.96.152
a338.g.akamaitech.net has address 23.3.96.120

Бьюсь об заклад, если вы попробуете это, держу пари, вы получите другой ответ. Сколько пограничных серверов у Akamai обслуживает какой-либо конкретный ресурс? Бьюсь об заклад больше двух.

Другие упоминали об этом как о деталях, но с практической точки зрения жестким ограничением является ограничение размера пакета UDP в 512 байт. Хотя возможно переключиться на TCP при обнаружении усечения, на практике многие / большинство клиентов этого не сделают (и, возможно, этого не следует делать; это дало бы плохой пользовательский опыт для большинства приложений, и я ожидал бы только зонную передачу или другое поиск специального назначения для поддержки TCP). Итак, вы смотрите на ограничение где-то около 30 адресов для IPv4 (записи A) и несколько меньше для IPv6 (AAAA), поскольку они больше. Длина доменного имени врезается в это и будет ограничивать число далее.

Краткий ответ: около 25 А записей помещаются в пакет UDP. Кроме того, DNS переключится на TCP, и это будет не так быстро. У вас также будут проблемы с клиентами, которые не используют DNS-распознаватели, способные выбирать «ближайший» IP-адрес. Кроме того, с Wi-Fi и мобильным телефоном «ближайший» часто не будет подходящим сервером.

Более длинный ответ:

Не делай этого. Лучшим способом было бы настроить отдельные записи CNAME для каждого пользователя, которые указывают на соответствующий сервер. Допустим, у вас есть два сервера, server-fи server-rиспользуется для IMAP. Настройте IMAP-клиент каждого человека, указав имя сервера USERNAME.imap.example.com, где вместо имени пользователя USERNAME будет указано имя пользователя электронной почты. Теперь вы можете перемещать людей между серверами без необходимости перенастраивать их почтовый клиент.

server-f.example.com. IN A 10.10.10.10 server-r.example.com. IN A 10.20.20.20 wilma.imap.example.com. IN CNAME server-f.example.com. fred.imap.example.com. IN CNAME server-f.example.com. betty.imap.example.com. IN CNAME server-r.example.com. barney.imap.example.com. IN CNAME server-r.example.com.

Однако, если вы сделаете это, я НАСТОЯТЕЛЬНО РЕКОМЕНДУЮ, чтобы вы автоматически генерировали записи DNS из базы данных пользователей. Вы хотите убедиться, что при создании и удалении учетных записей создаются и удаляются записи DNS. В противном случае вы получите беспорядок и много путаницы.

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

Как уже отмечали другие, это ужасная идея для реального использования.

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

И даже если бы вы могли рассчитывать на то, что ваш огромный ответ получен в каждом случае (чего вы категорически не можете), есть еще одна причина, по которой это очень плохая идея. Чем больше размер ответа DNS, тем более заманчиво это в качестве полезной нагрузки для атак отражения, потому что вы предоставляете огромный коэффициент усиления. В этом типе атаки типа «отказ в обслуживании», распространенной в DNS, UDP-запрос отправляется открытому рекурсивному преобразователю. Адрес источника UDP-запросов обычно легко подделывается, и злоумышленник устанавливает источник запроса в соответствии с IP-адресом предполагаемой цели. Достигнуты два желательных (для атакующего) эффекта: во-первых, относительно небольшое усилие по отправке с их стороны (из-за небольшого поддельного запроса) приводит к сравнительно большому потоку нежелательного трафика, прибывающего в цель (это коэффициент усиления), и второе - фактический источник атаки скрыт от цели; цель знает только адреса рекурсивных распознавателей, используемых в качестве отражателей.

Интересный момент исторической мелочи на эту тему. В 90-х годах AOL расширили свои записи DNS, так что запрос MX вернул бы> 512 байт. Это нарушало RFC, нарушало работу многих SMTP-серверов (в то время популярным был qmail) и вызывало у системных администраторов много головной боли. Исправление требовало либо исправления , либо добавления статических маршрутов.

Я не знаю, какова текущая ситуация, но несколько лет назад, когда я в последний раз коснулся qmail, патчи все еще были на месте.

http://www.gossamer-threads.com/lists/qmail/users/30503