EDNS0

EDNS0 (расширения DNS, версия 0; от англ. Extension Mechanisms for DNS — механизмы расширения DNS) — это протокол, расширяющий возможности системы доменных имён (DNS) за счёт увеличения максимального размера UDP-пакета, поддержки новых типов записей и передачи дополнительных опций. EDNS0 определён в документе RFC 6891 (ранее RFC 2671) и является стандартом де-факто для современных DNS-серверов и резолверов.

История

Протокол DNS, изначально описанный в RFC 1034 и RFC 1035 (1987 год), был спроектирован с ограничением на размер UDP-пакета в 512 байт. Это ограничение было обусловлено техническими возможностями сетей того времени и необходимостью гарантировать доставку пакетов без фрагментации. Однако с ростом интернета и усложнением DNS-инфраструктуры возникла потребность в передаче большего объёма данных: например, для поддержки DNSSEC (DNS Security Extensions), IPv6-адресов (записи AAAA) и других расширенных функций.

В 1999 году инженер Пол Викси (Paul Vixie) предложил механизм EDNS0, который был опубликован как RFC 2671. В 2013 году он был обновлён и заменён на RFC 6891, который уточнил формат и обработку расширений. EDNS0 стал первым и наиболее распространённым расширением DNS, обеспечившим обратную совместимость с существующими реализациями.

Принцип работы

EDNS0 не изменяет базовый протокол DNS, а добавляет к стандартному DNS-запросу или ответу дополнительный блок — OPT-псевдозапись (псевдо-RR, тип 41). Эта запись размещается в дополнительной секции (additional section) сообщения и содержит информацию о возможностях и параметрах отправителя.

Основные характеристики EDNS0

• Увеличение размера UDP-пакета: EDNS0 позволяет клиенту (резолверу) указывать максимальный размер UDP-пакета, который он может принять. По умолчанию это значение может достигать 4096 байт (часто 1232 байта для избежания фрагментации в IPv4/IPv6). Если ответ превышает этот размер, сервер переключается на TCP.
• Поддержка DNSSEC: EDNS0 обязателен для работы DNSSEC, так как подписи и ключи (RRSIG, DNSKEY) занимают больше места, чем 512 байт.
• Передача опций: EDNS0 позволяет передавать произвольные опции (например, EDNS Client Subnet — для геолокации, или NSID — для идентификации сервера).
• Флаги: EDNS0 вводит флаги (например, DO — DNSSEC OK), которые указывают, что клиент поддерживает DNSSEC.

Формат OPT-псевдозаписи

OPT-псевдозапись не хранится в зоне DNS и не кэшируется. Она состоит из следующих полей:

• NAME (0) — всегда равно 0 (корневая зона).
• TYPE (41) — идентификатор OPT.
• CLASS — максимальный размер UDP-пакета, который может принять отправитель (в байтах).
• TTL — содержит флаги и версию EDNS.
• RDLENGTH и RDATA — данные опций (переменной длины).

Классификация и версии

EDNS0 — это единственная официальная версия механизмов расширения DNS. Последующие версии (EDNS1, EDNS2) были предложены, но не получили распространения. В RFC 6891 указано, что версия 0 является единственной рабочей, а все остальные зарезервированы.

Применение

EDNS0 используется практически во всех современных DNS-системах, включая:

• Резолверы (например, Google Public DNS, Cloudflare DNS, Яндекс.DNS) — для поддержки DNSSEC, EDNS Client Subnet и оптимизации трафика.
• Авторитативные DNS-серверы — для передачи больших ответов (например, с множеством записей AAAA или DNSSEC-подписями).
• Клиентские устройства — операционные системы (Windows, Linux, macOS) и DNS-клиенты (BIND, Unbound, PowerDNS) поддерживают EDNS0 по умолчанию.

Примеры использования

• DNSSEC: Без EDNS0 невозможно передать цифровые подписи, что делает DNSSEC неработоспособным.
• EDNS Client Subnet (ECS): Опция, позволяющая резолверу передавать часть IP-адреса клиента авторитативному серверу для геолокационного таргетинга (например, для выдачи ближайшего CDN-узла).
• NSID (Name Server Identifier): Опция, используемая для идентификации конкретного сервера в кластере.

Проблемы и ограничения

• Фрагментация UDP: Увеличение размера пакета может привести к фрагментации на уровне IP, что увеличивает риск потери пакетов и снижает производительность. Для решения этой проблемы часто используется ограничение на 1232 байта (рекомендация RFC 6891 и практика многих операторов).
• Безопасность: EDNS0 не добавляет механизмов аутентификации, поэтому возможны атаки типа «DNS-амплификация» (использование больших ответов для DDoS). Однако EDNS0 сам по себе не является уязвимостью — проблема решается настройкой серверов (например, ограничением размера ответа).
• Несовместимость: Некоторые старые DNS-серверы (до 1999 года) могут игнорировать или неправильно обрабатывать OPT-псевдозаписи. В таких случаях резолверы обычно переключаются на TCP.

Критика

Критика EDNS0 в основном связана с его сложностью и неполной реализацией в некоторых системах. Например, опция EDNS Client Subnet вызывает споры о приватности, так как позволяет провайдерам и третьим лицам отслеживать IP-адреса пользователей. Также отмечается, что EDNS0 не решает проблему масштабирования DNS для больших зон (например, .com), где размер ответов может превышать 4096 байт, и требуется TCP.

Интересные факты

• EDNS0 был разработан в 1999 году, но массовое внедрение началось только в середине 2000-х годов с ростом DNSSEC.
• В 2018 году компания Google (организация признана иноагентом в РФ) предложила расширение EDNS0 для поддержки DNS-over-HTTPS (DoH), но оно не было стандартизировано.
• Некоторые DNS-серверы (например, BIND) поддерживают EDNS0 с версии 9.0 (2000 год).

Источники

• RFC 6891 — Extension Mechanisms for DNS (EDNS(0)).
• RFC 2671 — Extension Mechanisms for DNS (EDNS0) (устаревший).
• RFC 1034, RFC 1035 — Domain Names — Concepts and Facilities, Implementation and Specification.
• Paul Vixie, «DNS Extension Mechanisms», 1999.
• Документация по DNSSEC и EDNS0 от IETF.