Что максимальным количеством дюйм/с является DNS, который может иметь запись?
У меня есть странная идея - позволяют нескольким людям/организациям разместить то же приложение и позволить всем их узлам быть доступными через единственное доменное имя. Это в порядке, чтобы иметь, скажем, действительно распределенную социальную сеть, где удобство использования не принесено в жертву (т.е. пользователи не должны помнить различные URL поставщика и затем когда один поставщик спускается, переключатель к другому),
Для достижения этого я думал запись DNS с несколькими, дюйм/с может использоваться.
Так, сколько дюйм/с может единственный DNS рекордное хранение? В этом ответе говорится, что это - приблизительно 30, но вариант использования, там отличается. Для вышеупомянутого сценария я не заботился бы если данный ISP кэши только 30, пока другой ISP кэши еще 30, и так далее.
Отказ от ответственности: Без обид, но это действительно плохая идея. Я не рекомендую кому-либо делать это в реальной жизни.
Но если вы дадите скучающему IT-специалисту лабораторию, произойдут забавные вещи!
Для этого эксперимента я использовал DNS-сервер Microsoft, работающий на Server 2012 R2. Из-за сложностей с размещением DNS-зоны в Active Directory я создал новую первичную зону под названием test.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 записей хоста под именем test.testing.com., с буквально каждым IPv4 адресом от 1.1.1.1.1 до 1.1.255.255.
Затем я хотел убедиться, что смог бы безошибочно пробить 65536 (2^16 бит) общее количество записей А, и я смог бы, поэтому я предполагаю, что, вероятно, смог бы пройти весь путь до 16581375 (1.1.1.1 до 1.255.255). 255,) но я не хотел сидеть здесь и смотреть, как этот сценарий работает всю ночь.
Так что я думаю, что можно с уверенностью сказать, что нет никакого практического ограничения на количество записей А, которые вы можете добавить в зону для одного и того же имени с различными IP-адресами на вашем сервере.
Но будет ли на самом деле работать с точки зрения клиента?
Вот что я получаю от своего клиента, как видно из Wireshark:
(Откройте изображение в новой закладке браузера для полного размера)
Как видите, когда я использую nslookup или ping от своего клиента, он автоматически выполняет два запроса - один UDP и один TCP. Как Вы уже знаете, больше всего я могу втиснуть в UDP-датаграмму 512 байт, поэтому, как только этот лимит превышен (например, 20-30 IP-адресов), вместо него необходимо использовать TCP. Но даже с TCP, я получаю только очень маленькое подмножество записей A для test.testing.com. По одному TCP-запросу было возвращено 1000 записей. При каждом последующем запросе список записей A корректно поворачивается на 1, точно так же, как вы ожидаете, что круглосуточный DNS будет работать. Для обработки всех этих запросов понадобились бы миллионы запросов.
Не понимаю, как это поможет вам сделать вашу массивно масштабируемую, отказоустойчивую социальную сеть, Но, тем не менее, ваш ответ есть.
Edit: В своем последующем комментарии вы спрашиваете, почему я считаю, что это вообще плохая идея.
Скажем так, я обычный пользователь интернета, и я хотел бы подключиться к вашему сервису. Я набираю www.bozho.biz в своем веб-браузере. DNS-клиент на моем компьютере получает обратно 1000 записей. Ну, не повезло, первые 30 записей в списке не отвечают, потому что список A записей не поддерживается в актуальном состоянии, или, может быть, есть крупномасштабный перебой в работе, влияющий на кусок интернета. Допустим, у моего веб-браузера есть тайм-аут 5 секунд на IP, прежде чем он перейдет к следующему. Так что теперь я сижу здесь и смотрю на вращающиеся песочные часы в течение 2 с половиной минут в ожидании загрузки вашего сайта. Ни у кого нет на это времени. И я просто предполагаю, что мой веб-браузер или любое другое приложение, которое я использую для доступа к вашему сервису, даже будет пытаться больше, чем первые 4 или 5 IP-адресов. Скорее всего, не будет.
Если вы использовали автоматическую проверку и разрешили непроверенные или анонимные обновления в DNS зоне в надежде сохранить список A записей свежим... только представьте, насколько это было бы небезопасно! Даже если вы создали систему, в которой клиентам нужен был клиентский TLS сертификат, который они получили от вас заранее, чтобы обновить зону, один скомпрометированный клиент в любой точке планеты запустит бот-сеть и уничтожит вашу службу. Традиционный DNS и так ненадежен, без краудсорсинга.
Огромное использование полосы пропускания и расточительство. Если каждый DNS-запрос требует 32 килобайта или более полосы пропускания, это не будет хорошо масштабироваться.
DNS-карусель не заменит правильную балансировку нагрузки. Она не обеспечивает способа восстановления с одного узла, который выходит из строя или становится недоступным в середине вещей. Вы собираетесь инструктировать своих пользователей делать ipconfig/flushdns, если узел, к которому они были подключены, выйдет из строя? Эти проблемы уже решены такими вещами, как GSLB и Anycast.
Etc.
Другие упоминали об этом как о детали, но из практического С другой стороны, жестким пределом является ограничение размера пакета UDP в 512 байт. Хотя при обнаружении усечения можно переключиться на TCP, на практике многие / большинство клиентов не будут этого делать (и, возможно, они не должны этого делать; это ухудшит взаимодействие с пользователем для большинства приложений, и я бы ожидал только передачи зон или других специальные поисковые запросы для поддержки TCP). Итак, вы смотрите на ограничение примерно в 30 адресов для IPv4 (записи A) и несколько меньше для IPv6 (AAAA), поскольку они больше. Длина доменного имени сокращается и будет еще больше ограничивать количество.
Как отмечали другие, это ужасная идея для использования в реальном мире.
В реальном мире есть несоответствующие клиенты и распознаватели, у которых есть проблемы с ответами, которые не могут уместиться в единая дейтаграмма UDP, и существуют брандмауэры, которые будут реализовывать определенные, но не соответствующие протоколу идеи об ограничениях на размер сообщений DNS.
И даже если вы можете рассчитывать на ваш огромный ответ в каждом случае (что вы категорически не можете)есть еще одна причина, по которой это очень плохая идея. Чем больше размер вашего ответа DNS, тем более заманчивым он является в качестве полезной нагрузки для атак отражения, потому что вы обеспечиваете огромный коэффициент усиления. В этом типе атаки типа «отказ в обслуживании», который является обычным в DNS, UDP-запрос отправляется на открытый рекурсивный преобразователь. Адрес источника UDP-запросов обычно легко подделать, и злоумышленник устанавливает в качестве источника запроса IP-адрес предполагаемой цели. Достигаются два желательных (для злоумышленника) эффекта: во-первых, относительно небольшие усилия по отправке с их стороны (из небольшого поддельного запроса) приводят к сравнительно большому потоку нежелательного трафика, поступающего к цели (это коэффициент усиления) и второй - действительный источник атаки скрыт от цели; цель знает только адреса рекурсивных преобразователей, используемых в качестве отражателей.
Интересный момент из исторических фактов по этому поводу. В 90-х годах AOL расширила свои записи DNS так, что запрос MX возвращал> 512 байт. Это нарушило RFC, сломало множество SMTP-серверов (в то время популярным был qmail) и доставило системным администраторам много головной боли. Для исправления требовалось либо исправление , либо добавление статических маршрутов.
Я не знаю, какова текущая ситуация, но несколько лет назад, когда я последний раз касался qmail, исправления все еще были на месте.
Краткий ответ: в UDP-пакет помещается около 25 записей A. Кроме того, 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. В CNAME server-f.example.com.
fred.imap.example.com. В CNAME server-f.example.com.
betty.imap.example.com. В CNAME server-r.example.com.
barney.imap.example.com. В CNAME server-r.example.com.
Однако, если вы это сделаете, Я НАСТОЯТЕЛЬНО РЕКОМЕНДУЮ автоматически генерировать записи DNS из базы данных пользователей. Вы хотите убедиться, что при создании и удалении учетных записей записи DNS также создаются и удаляются. В противном случае вы столкнетесь с неразберихой и большой неразберихой.
Я видел, как это делалось в компаниях с буквально тысячами пользователей, и, поскольку все было автоматизировано, это очень хорошо.
Чтобы ответить на вопрос, как было сказано ("сколько 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 таймаутов
.То, что вы описываете, не является особенно новой идеей. Как уже говорилось в других ответах, вы ограничены в том, сколько записей А вы можете иметь в одном ответе, но это ничего не говорит о том, сколько записей А может быть в общей сложности.
Можно, например, реализовать 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
Что, если я спрошу у Google DNS?
$ 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 обслуживает какой-либо конкретный ресурс? Больше двух, я ставлю.
Почему 512 байт являются магическим числом для полезной нагрузки UDP?
Если вы вернетесь (почти) к началу и посмотрите на RFC-791, который является стандартом протокола для IP версии 4 вы найдете этот текст
Все хосты должны быть готовы принимать дейтаграммы размером до 576 октетов независимо от того, приходят ли они целыми или фрагментарными).
Таким образом, 20 байтов для заголовка TCP и 20 байтов для заголовка UDP оставляют 536 байтов для ответа DNS. 12 байтов для заголовка протокола DNS оставляют 524 байта.Затем вам нужно оставить немного места для QNAME и прочего, а 512 байт — хорошее круглое число.
В современном Интернете обычное значение MTU составляет 1500 байт, и почти каждый хост, использующий IPv4, может поддерживать дейтаграмму IP такого размера. Но эти протоколы предшествовали широкому распространению Ethernet (по крайней мере, IP, UDP), и число, от которого вы зависели, было 576 байт в качестве отправной точки.
Механизм расширения EDNS позволяет сообщать DNS-серверу, какой размер ответа готов принять резолвер, поэтому обычно запросы с этой опцией отражают MTU размером 1500 байт. В идеале вы на самом деле не хотите вызывать фрагментацию IP по целому ряду причин, таким образом, довольно консервативный размер пакета ответов с ответами DNS, транспортируемыми UDP.
Так заканчивается сегодняшний урок истории.