Система доменных имен

. Почему DNS через UDP имеет ограничение в 512 байт?

Я искал ответ на этот вопрос (тот, что в заголовке), и лучшее, что я нашел, это:

В конструкции протокола DNS размер транспортного блока UDP (размер полезной нагрузки) имеет был ограничен 512 байтами для оптимизации производительности при создании минимальный сетевой трафик.

мой вопрос: как именно это повышает производительность и есть ли другие причины для этого ограничения при использовании UDP?

  • система доменных имен

1

Полезная нагрузка размером 512 байт гарантирует возможность повторной сборки пакетов DNS, если они фрагментированы в пути. Кроме того, вообще говоря, меньше вероятность случайного отбрасывания небольших пакетов.

Стандарт IPv4 указывает, что каждый хост должен иметь возможность собирать пакеты размером 576 байт или меньше. С заголовком IPv4 (20 байт, хотя он может достигать 60 байт с параметрами) и 8-байтовым заголовком UDP пакет DNS с полезной нагрузкой 512 байтов будет меньше 576 байт.

Как говорит @RyanRies: DNS может использовать TCP для больших полезных нагрузок и для передачи зон и DNSSEC. Когда TCP вступает в игру, задержки намного больше, потому что, в отличие от UDP, между клиентом и сервером происходит рукопожатие, прежде чем какие-либо данные начнут передаваться.

8

Современный DNS фактически больше не ограничивается полезной нагрузкой 512 байт для UDP.

При использовании EDNS0 можно указать больший размер полезной нагрузки, что также обычно имеет место для клиентов, поддерживающих DNSSEC.

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

Подробную информацию о EDNS0 см. в rfc2671.

2

операции DNS, например, запросы и операции обслуживания зоны по умолчанию используется порт 53. Из соображений производительности запросы используют UDP протокол с ограничением размера блока в 512 байт. TCP может быть опционально согласование на основе транзакции за транзакцией для операций запроса, но из-за накладных расходов, связанных с TCP, это по существу теоретическая способность. Исторически сложилось так, что превышение Ограничение размера ответа в 512 байт обычно избегали любой ценой, и действительно ограничение в 13 корневых серверов IPv4 было максимальным, которое могло быть возвращается в одной 512-байтовой UDP-транзакции.

Рон Эйчисон — Pro DNS и BIND 10 — 2011

1

TCP предлагает несколько возможностей по сравнению с UDP, таких как повторная передача, чтобы гарантировать получение данных. Большая дейтаграмма UDP может быть фрагментирована на несколько IP-пакетов. Это делается на уровне 3, когда обнаруживается, что, учитывая размер дейтаграммы, пакет будет больше, чем MTU канала.

Поскольку UDP не может обрабатывать повторную передачу, при потере любого фрагмента дейтаграммы вся дейтаграмма UDP теряется. Это довольно неэффективно. Для больших дейтаграмм DNS предпочитает разбивать их на несколько упорядоченных сегментов TCP. Каждый из этих сегментов упаковывается в отдельный пакет и может быть передан повторно, если не получен получателем. Дублированные сегменты также могут быть обнаружены. По сути, TCP гораздо лучше справляется со сбоями, следовательно, более эффективен для больших дейтаграмм.

Протоколы на основе UDP, такие как DNS, ограничивают размер дейтаграммы UDP примерно 512 байтами, потому что этот размер гарантирует, что дейтаграмма не будет фрагментирована, и, следовательно, потеря одного фрагмента приводит к потере всей дейтаграммы. Это около 512, потому что в спецификациях IPv4 хосты должны иметь возможность обрабатывать пакеты размером не менее 576 байт (что обычно намного меньше MTU большинства каналов). Поскольку заголовок IPv4 может иметь размер до 60 байт (20-байтовый заголовок плюс до 40 байтов параметров), 516 байт (576–60) — это максимальный размер полезной нагрузки IP, гарантирующий отсутствие фрагментации.

Это QOS.

Поскольку UDP не имеет состояния, обработка ошибок пакетов невозможна.

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

3

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания, политикой конфиденциальности и политикой использования файлов cookie

.

networking — Каков самый большой размер безопасного пакета UDP в Интернете

Нет ни одного.

Я собираюсь полностью отбросить любые рассуждения о том, что «UDP — это лучший способ», и просто сосредоточусь на «максимальном безопасном размере пакета UDP», который понимается как «достаточно малый, чтобы полностью избежать любой фрагментации где-то на пути».

Для важной информации:

Единственный размер пакета, на который вы можете рассчитывать, чтобы его можно было транспортировать без фрагментации, составляет 24 байта для IPv4 и 56 байтов для IPv6, так как наименьшие заголовки IP для фрагмента составляют 20/48 байтов (v4/v6), а фрагмент должен иметь не менее 4/48 байтов. 8 байт (v4/v6) полезных данных. Таким образом, транспортная система ниже IP-уровня, которая не может транспортировать по крайней мере пакеты этих размеров, не может использоваться для транспортировки IP-трафика [вообще].

— Ответ на вопрос «как MTU 65507 в UDP…?».

Согласно приведенному выше ответу, это связано с тем, что при такой длине механизм фрагментации IP не может работать — в любом случае он может генерировать только один фрагмент.

… стандарт IP требует, чтобы каждый IP-хост мог получать IP-пакеты с общим размером 576 байт… Обратите внимание, однако, что стандарт не говорит 576 без фрагментации, поэтому даже 576-байтовый IP-пакет может оказывается фрагментированным между двумя хостами [где-то на пути между источником и местом назначения].

Таким образом, все, что больше, чем самый маленький интернет-протокол, может оказаться фрагментированным из-за того, что оно «невидимо» временно инкапсулировано чуть выше предела где-то на пути, даже если вы выбрали минимальную полезную нагрузку UDP, которая быть: 576 — 8 (для заголовка UDP) — 20 (IPv4) или 40 (IPv6) = минимум 528 (если вы не уверены, будет ли использоваться v4 или v6).

Причина, по которой вы, возможно, пытаетесь избежать фрагментации, заключается в том, что она увеличивает вероятность того, что пакет пропадет целиком. Больше пакетов, только из-за более высоких накладных расходов, будет означать большую вероятность отказа, не говоря уже о том, что каждый пакет (даже фрагмент) представляет собой еще один «шанс» быть потерянным. Конечно, если он будет передан какой-то ссылке, которая просто отбросит его из-за того, что он слишком большой…

Реализации TCP на уровне ОС предпринимают действия, чтобы попытаться выбрать самый высокий безопасный MTU на уровне TCP, в том числе иногда имеют дело с его динамическим изменением, поскольку части пути между источником и пунктом назначения могут различаться для каждого пакета.

Для UDP вся эта проблема становится и вашей: И это не так просто, как просто «использовать самый большой, который точно не будет фрагментироваться».

В разделе 5 RFC2460 говорится об этом (о минимальном MTU для IPv6).

IPv6 требует, чтобы каждая ссылка в Интернете имела MTU 1280. октеты или больше. По любой ссылке, которая не может передать 1280-байтовый Пакет должен быть цельным, фрагментация и сборка по конкретному каналу должны предоставляться на уровне ниже IPv6.

Следовательно, фрагментация может также происходить на уровне ниже на уровне IP, когда конкретная связь между двумя хостами на пути решает фрагментировать ее, а затем может передавать фрагменты по параллельным каналам… чтобы собрать их в один пакет на другой конец этой ссылки.

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

Конечно, если аппаратное обеспечение придерживается спецификации IP, оно должно быть в состоянии заметить, что пакеты вышли из строя, проверив часть смещения фрагмента заголовка IP, но большинство протоколов связи просто повторно собирают фрагменты в указанном порядке. получено, не беспокоясь о приеме неупорядоченных пакетов.

Теперь, если это межсоединение «нижнего уровня» само по себе используется как сеть… например, в ядре большого коммутатора, тогда вполне возможно, что при больших нагрузках и множестве параллельных путей такие фрагменты могут получить вышел из строя до сборки.

Это суперзло, но, вероятно, иногда случается, что приводит к тому, что иногда все еще доставленные и все же сильно искаженные пакеты, которые все же проходят простую проверку контрольной суммы на основе xor… Которая оказывается контрольной суммой IP это .

TCP просто устанавливает «не фрагментировать» и работает с ним, но UDP оставляет этот бит пустым… поэтому, если вы используете UDP, вы также должны предположить, что ваш поток байтов может иногда переупорядочиваться даже внутри пакетов … и поэтому вы должны проверить свои данные, используя метод контрольной суммы, который уловит изменение порядка.

Большинство каналов в любом случае будут обрабатывать 1500 MTU, но канальный уровень имеет разные минимальный и максимальный размеры дейтаграмм:

  • Ethernet: от 64 до 1500 (или выше с более высокими возможностями MTU)
  • ATM: 53 байта/датаграмма только
  • Frame Relay: от 46 до 4470 байт (ссылка: фрагментация IP нарушена

К сожалению, сам заголовок UDP имеет размер 8 байт.