Кратко

  • Опция 12 EDNS(0) позволяет добавить заполнитель переменной длины к зашифрованному DNS-сообщению. Она стандартизирует контейнер, а не результат приватности; блоки 128 октетов для запросов и 468 для ответов — экспериментальная политика RFC 8467.
  • Защиту создают совместно: клиент заполняет запрос, сервер выбирает ответ, TLS, HTTP или QUIC формирует внешнюю рамку, а путь ограничивает стоимость и фрагментацию. Время, конечные точки и число обменов остаются видимыми.

Два DoT-резолвера могут заявить «padding включён» и дать противоположный эффект. Первый округляет запросы до кратного 128, ответы — 468. Второй всегда добавляет 16 байтов. Оба создают корректную опцию 12, но второй сохраняет все исходные различия: наблюдателю достаточно вычесть известную константу.

Шифрование транспорта защищает содержание между клиентом и сервером. Длина шифротекста автоматически не исчезает. Некоторые имена, типы RR и наборы ответов дают характерные пары размеров. Имея известные открытые образцы, наблюдатель может сопоставлять их, не расшифровывая имя.

RFC 7830 предлагает намеренно узкий механизм. В псевдозаписи OPT расширения EDNS Padding имеет код 12. Опция встречается не более одного раза в сообщении. Поле длины считает октеты заполнения; ноль допустим, хотя заголовок опции всё равно занимает четыре октета. Отправителю рекомендуется ставить нули, а получатель обязан принять иные значения. Смысла DNS эти байты не несут.

Стандарт не выбирает количество. Общий синтаксис остаётся отдельным от местной политики. RFC 8467 сравнил стратегии и экспериментально рекомендовал блочное заполнение: ближайшее кратное 128 для запроса и 468 для ответа. Несколько исходных размеров попадают в одну видимую группу.

Группа всё ещё сообщает сведения. Если размер блока известен, запрос в 256 октетов ограничивает диапазон исходной длины. Время, интервалы, направление и число сообщений не меняются. Поток может оставаться узнаваемым как DNS. Фоновый трафик или искусственный джиттер воздействовал бы на другие каналы ценой иных ресурсов.

Запрос не даёт неограниченной команды. Если он содержит Padding, сервер должен дополнить ответ, пока не превышен допустимый UDP payload. При объявленной поддержке EDNS сервер может заполнить ответ и без запроса опции, но не может делать это для клиента без EDNS. Разрешение ограничено ёмкостью и не диктует полезную длину.

Путь превращает приватность в задачу доставки. Padding применяется после остальных опций EDNS и занимает остаток. Два октета длины DNS поверх TCP не включают в расчёт, иначе смена UDP на TCP создала бы другую группу только из-за framing. Возле MTU крупные блоки вызывают лишнюю фрагментацию, выше MTU делают её неизбежной для UDP. RFC 7830 запрещает заполнение открытого DNS и предупреждает о риске amplification.

DoH и DoQ переносят точки управления. DoH несёт Padding внутри аутентифицированного HTTPS, но заголовки, cookies, повторное использование соединений и время дают иные связи. DoQ может заполнять сообщение DNS либо, при подходящем QUIC API, выравнивать полный пакет с учётом подтверждений и flow control.

Ни один участник не владеет итогом. Клиент выбирает запрос и резолвер, сервер — ответ, транспортная библиотека — внешнюю форму, сеть — надёжно доставляемый размер. Реестр IANA доказывает общий словарь, но не реализацию, включение или эффект.

Проверка running code — распределение, а не флажок. Нужны размеры до и после, наполнение групп, ответы без padding, добавленные байты, truncation, fragmentation, loss, retry и fallback. Только это показывает рост множества анонимности.