EDNS (EDNS)

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

Причины появления

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

Ограничения в размере нескольких полей флагов, кодов возврата и типов меток, доступных в базовом протоколе DNS, препятствовали поддержке некоторых желаемых функций. Кроме того, сообщения DNS, передаваемые по протоколу UDP, были ограничены 512 байтами, не считая IP-протокола и заголовков транспортного уровня^[1]. Использование виртуальной транспортной сети с использованием протокола управления передачей (TCP) значительно увеличило бы издержки. Это стало серьезным препятствием для добавления новых функций в DNS. В 1999 году Пол Викси предложил расширить DNS, чтобы включить новые флаги и коды ответов, а также обеспечить поддержку более длинных ответов в рамках, обратно совместимых с предыдущими реализациями.

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

Поскольку никакие новые флаги не могут быть добавлены в заголовке DNS, EDNS добавляет информацию к DNS — сообщений в виде псевдо-записей ресурсов («псевдо-RR»), включенных в раздел «Дополнительные данные» в сообщении DNS. Обратите внимание, что этот раздел существует как в запросах, так и в ответах.

EDNS представляет один тип псевдо-RR: OPT.

Как псевдо-RR, RR типа OPT никогда не появляются ни в одном файле зоны; они существуют только в сообщениях, изготовленных участниками DNS.

Механизм обратно совместим, поскольку более старые респонденты DNS игнорируют любые RR неизвестного типа OPT в запросе, и более новый респондент DNS никогда не включает OPT в ответ, если в запросе его не было. Наличие OPT в запросе означает, что более новый запросчик знает, что делать с OPT в ответе.

Псевдозапись OPT обеспечивает пространство до 16 флагов и расширяет пространство для кода ответа. Общий размер пакета UDP и номер версии (в настоящее время 0) содержатся в записи OPT. Поле данных переменной длины позволяет регистрировать дополнительную информацию в будущих версиях протокола. Исходный протокол DNS предусматривал два типа меток, которые определяются первыми двумя битами в пакетах DNS (RFC 1035): 00 (стандартная метка) и 11 (сжатая метка). EDNS вводит метку типа 01 как расширенную метку . Младшие 6 битов первого байта могут использоваться для определения до 63 новых расширенных меток.

Пример

Пример псевдозаписи OPT, отображаемой утилитой Domain Information Groper (dig):

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; UDP: 4096

Результат «EDNS: версия: 0» указывает на полное соответствие EDNS0^[2]. Результат «flags: do» указывает, что «DNSSEC OK» установлен.

Приложения

EDNS имеет важное значение для реализации расширений безопасности DNS (DNSSEC). EDNS также используется для отправки общей информации от распознавателей на серверы имен о географическом местоположении клиентов в виде опции EDNS Client Subnet (ECS).

Существуют предложения по использованию EDNS для задания того, сколько отступов должно быть вокруг сообщения DNS, и для указания того, как долго TCP-соединение должно поддерживаться в рабочем состоянии.

Проблемы

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

Введение EDNS сделало возможной атаку с усилением DNS , тип отраженной атаки отказа в обслуживании, поскольку EDNS обеспечивает очень большие ответные пакеты по сравнению с относительно небольшими пакетами запросов.

Рабочая группа IETF DNS Extensions (dnsext) завершила работу над уточнением EDNS0, которое было опубликовано как RFC 6891.

Примечания

↑ P. V. Mockapetris. Domain names - implementation and specification (англ.). tools.ietf.org. Дата обращения: 4 февраля 2019. Архивировано 3 апреля 2019 года.
↑ P. Vixie. Extension Mechanisms for DNS (EDNS0). — RFC Editor, 1999-08. — С. 3.

Ссылки

С 01.02.2019 серверы имён, не поддерживающие EDNS, станут недоступны (рус.). www.linux.org.ru. Дата обращения: 4 февраля 2019.
«Сломается» ли интернет 1 февраля? (рус.) Рамблер/новости. Дата обращения: 4 февраля 2019.
С 1 февраля 2019 года многие сайты в интернете станут недоступными (рус.). www.securitylab.ru. Дата обращения: 4 февраля 2019.

[1] P. V. Mockapetris. Domain names - implementation and specification (англ.). tools.ietf.org. Дата обращения: 4 февраля 2019. Архивировано 3 апреля 2019 года.

[2] P. Vixie. Extension Mechanisms for DNS (EDNS0). — RFC Editor, 1999-08. — С. 3.

[1]

[2]