Назад | Перейти на главную страницу

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

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

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

Итак, сколько IP-адресов может содержать одна запись DNS A? Этот ответ говорит, что это около 30, но вариант использования другой. Для вышеприведенного сценария меня бы не волновало, кэширует ли данный ISP только 30, пока другой ISP кеширует еще 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. По запросу TCP было возвращено 1000 записей. Список 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.

  • И т.п.

Чтобы ответить на поставленный вопрос («сколько IP-адресов может содержать одна запись A DNS?»), Ответ очень прост: один 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-адреса.

Как я уже сказал, это не новая идея. Фактически, это частично как работает Акамай (и, вероятно, множество других 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), поскольку они больше. Длина доменного имени сокращается и еще больше ограничивает количество.

Краткий ответ: в UDP-пакет помещается около 25 А записей. Кроме того, 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