Русская Википедия: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.
Примечания
Ссылки
