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

30

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

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

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

Bozho
источник
2
Вы принимаете про Anycast ?
Ли Райан
4
Некоторое время назад я узнал, что если вам когда-нибудь придется спросить: «Какое максимальное число Х?» Вы, вероятно, используете это неправильно ...
LordOfThePigs
Не обязательно;) А вообще да
Божо

Ответы:

78

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

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

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

TCP-запрос

Как вы можете видеть, когда я использую 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.

  • И т.п.

Райан Райс
источник
15
Медленно .... хлопать ..... сэр.
mfinni
4
Чтобы добавить к этому, если записи A запрашиваются через BIND (что и выполняется на большинстве DNS-серверов), он будет перетасовывать записи A и возвращать определенное количество записей A из этого. Это определенное число определено MAX_SHUFFLEв исходном коде BIND (по умолчанию 32).
ub3rst4r
1
Из любопытства, почему бы вам не порекомендовать это? Это, конечно, очень странная вещь, но кроме того, что вредоносные узлы обслуживают запрос в «хорошем» домене, а неисправные узлы продолжают получать запросы, что еще может пойти не так :-)
Божо
Кроме того, не изменится ли пользовательский опыт? Является ли каждый узел полной копией? Как бы вы обеспечили это, если бы они находились под контролем других людей? Если они разные, то люди получат один сайт сегодня, а другой - завтра. Лично это свело бы меня с ума!
Брэндон
18

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

Хокан Линдквист
источник
10

Каждый адрес 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 тайм-аутов.

kasperd
источник
2
Каждый DNS должен поддерживать EDNS в эти дни. 512-байтовое ограничение для ответов DNS больше не практично из-за DNSSEC.
Бармар
@ Barmar Но если он включен, существует довольно значительный риск того, что ваш сервер будет использоваться для атак с усилением. В прошлый раз, когда я проверял, я обнаружил, что отключение привязки было единственным, что можно было сделать, чтобы смягчить атаки усиления. До тех пор, пока EDNS не будет расширен с полем cookie, и поддержка этого не будет широко развернута, по-прежнему рекомендуется отключать поддержку ответов размером более 512 байт.
kasperd
1
На самом деле я не получаю много результатов в поиске, так как отключение EDNS является лучшей практикой. Цитаты, пожалуйста? Атаки на усиление с использованием рекурсивных серверов будут происходить независимо от того, включена ли EDNS, если ваша сеть не выполняет проверку адреса источника. Даже если мы говорим об авторитетном сервере, он становится релевантным только после того, как вы настроите его так, чтобы он возвращал столько данных в одном ответе, и в этом случае его отключение не поможет.
Андрей B
@ AndrewB Я не помню, где я читал эту рекомендацию. Я прочитал много разных рекомендаций о том, как избежать атак усиления, и все они отстой. Жаль, что EDNS не внедрила cookie-файл, который мог бы стать эффективным решением для усиления атак с использованием DNS. В своем ответе я рекомендую избегать добавления в запрос такого количества записей, что вы полагаетесь на то, что другие включат EDNS, чтобы ответы были эффективными.
kasperd
@AndrewB Если я поместил в зону записи A, превышающие 512 байт, и убедился, что они размещены на официальном DNS-сервере, на котором включен EDNS, это может стать проблемой для пользователей рекурсивных распознавателей, которые не разрешают ответы такого размера. И именно поэтому я рекомендую держать количество записей А ниже. Более того, я объяснил, почему ощутимая выгода от такого количества записей A не так важна.
kasperd
5

То, что вы описываете, не особенно новая идея. Как уже упоминалось в других ответах, вы ограничены тем, сколько записей 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 обслуживает какой-либо конкретный ресурс? Бьюсь об заклад больше двух.

Фил Фрост
источник
Спасибо. Да, я знаю, что CDN работают таким образом, но, на мой взгляд, они имеют ограниченное количество записей на поддомен (2 в вашем примере). Мой другой недавний вопрос касается именно CDN и их реализации DNS :-)
Божо
2

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

Р..
источник
1
Вы совершенно правы, что существует много неправильно работающих клиентов и распознавателей, которые неправильно обрабатывают ответы DNS, которые не вписываются в одну дейтаграмму UDP, но, пожалуйста, откажитесь от идеи, что только зонные передачи или необычные запросы требуют больших размеров ответов. Исходя из вашего ответа, вы явно не используете проверку DNSSEC, но многие люди (да и DNSSEC не единственная причина, по которой требуются более широкие ответы, но это очень важная причина).
Майкл МакНэлли,
@MichaelMcNally: DNSSEC не предназначен (по крайней мере, не для разработчиков, основанных на потоках в списках рассылки glibc, в которых я принимал участие) для использования на конечных точках (приложениях, выполняющих поиск DNS), но на локальном рекурсивном сервере имен, который будет выполнять поиск от имени приложений. Таким образом, даже при настройке DNSSEC нет оснований ожидать, что приложения будут передавать DNS по TCP. UDP работает отлично.
R ..
1

Краткий ответ: около 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. В противном случае вы получите беспорядок и много путаницы.

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

TomOnTime
источник
0

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

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

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

Майкл МакНалли
источник
0

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

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

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

Coops
источник