Механизмы расширения для DNS - Extension Mechanisms for DNS
Механизмы расширения для DNS ( EDNS ) - это спецификация для увеличения размера нескольких параметров протокола системы доменных имен (DNS), которые имели ограничения по размеру, которые инженерное сообщество Интернета сочло слишком ограниченными для увеличения функциональности протокола. Первый набор расширений был опубликован в 1999 г. Инженерной группой Интернета как RFC 2671 , также известный как EDNS0, который был обновлен RFC 6891 в 2013 г. с незначительным изменением аббревиатуры на EDNS (0) .
Мотивация
Система доменных имен была впервые разработана в начале 1980-х годов. С тех пор он был постепенно расширен новыми функциями, сохраняя при этом совместимость с более ранними версиями протокола.
Ограничения на размер нескольких полей флагов, кодов возврата и типов меток, доступных в основном протоколе DNS, препятствовали поддержке некоторых желательных функций. Более того, DNS-сообщения, передаваемые по UDP, были ограничены 512 байтами, без учета Интернет-протокола (IP) и заголовков транспортного уровня . Использование виртуального транспортного канала с использованием протокола управления передачей (TCP) значительно увеличило бы накладные расходы. Это стало серьезным препятствием для добавления новых функций в DNS. В 1999 году Пол Викси предложил расширить DNS, чтобы учесть новые флаги и коды ответов, а также обеспечить поддержку более длинных ответов в структуре, которая обратно совместима с предыдущими реализациями.
Механизм
Поскольку никакие новые флаги не могут быть добавлены в заголовке DNS, EDNS добавляет информацию к DNS - сообщений в виде псевдо- записей ресурсов ( «псевдо-RR» s) включены в раздел «Дополнительные данные» в сообщении DNS. Обратите внимание, что этот раздел существует как в запросах, так и в ответах.
EDNS представляет один тип псевдо-RR: OPT.
Как псевдо-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, отображаемой командой dig :
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096
Результат «EDNS: version: 0» указывает на полное соответствие EDNS0. Результат «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.