Механизмы расширения DNS
Механизмы расширения для DNS ( EDNS ) — это спецификация для расширения размера нескольких параметров протокола системы доменных имен (DNS), который имел ограничения по размеру, которые сообщество инженеров Интернета сочло слишком ограниченными для увеличения функциональности протокола. Первый набор расширений был опубликован в 1999 году Инженерной группой Интернета под названием RFC 2671 , также известный как EDNS0. [1] который был обновлен RFC 6891 в 2013 году немного изменил аббревиатуру на EDNS(0) . [2]
Мотивация
[ редактировать ]Система доменных имен была впервые разработана в начале 1980-х годов. С тех пор он постепенно расширялся новыми функциями, сохраняя при этом совместимость с более ранними версиями протокола.
Ограничения на размер нескольких полей флагов, кодов возврата и типов меток, доступных в базовом протоколе DNS, не позволили реализовать поддержку некоторых желательных функций. Более того, сообщения DNS, передаваемые по UDP, были ограничены 512 байтами, без учета интернет-протокола (IP) и заголовков транспортного уровня . [3] Использование по виртуальному каналу транспорта с использованием протокола управления передачей (TCP) значительно увеличило бы накладные расходы. Это стало серьезным препятствием для добавления новых функций в DNS. В 1999 году Пол Викси предложил расширить DNS, чтобы обеспечить возможность использования новых флагов и кодов ответов, а также обеспечить поддержку более длинных ответов в рамках, обратно совместимой с предыдущими реализациями.
Механизм
[ редактировать ]Поскольку в заголовок DNS нельзя добавить новые флаги, EDNS добавляет информацию к сообщениям DNS в форме ( записей псевдоресурсов «псевдо-RR»), включенных в раздел «дополнительные данные» сообщения DNS. Обратите внимание, что этот раздел существует как в запросах, так и в ответах.
EDNS вводит один тип псевдо-RR: OPT.
Как псевдо-RR, записи типа OPT никогда не появляются ни в одном файле зоны; они существуют только в сообщениях, сфабрикованных участниками DNS.
Механизм обратно совместим , поскольку старые ответчики DNS игнорируют любые RR неизвестного типа OPT в запросе, а новый ответчик DNS никогда не включает OPT в ответ, если только он не был в запросе. Наличие OPT в запросе означает, что запрашивающая сторона знает, что делать с OPT в ответе.
Псевдозапись OPT предоставляет место для 16 флагов и расширяет пространство для кода ответа. Общий размер пакета UDP и номер версии (в настоящее время 0) содержатся в записи OPT. Поле данных переменной длины позволяет регистрировать дополнительную информацию в будущих версиях протокола. Исходный протокол DNS предусматривал два типа меток, которые определяются первыми двумя битами октета длины метки (RFC 1035): 00 (стандартная метка) и 11 (сжатая метка). EDNS представляет тип метки 01 как расширенную метку . Младшие 6 бит первого байта могут использоваться для определения до 63 новых расширенных меток.
Пример
[ редактировать ]Пример псевдозаписи OPT, отображаемый командой dig :
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096
Результат «EDNS: версия: 0» указывает на полное соответствие EDNS0. [4] Результат «flags: do» указывает, что установлен «DNSSEC OK». [5]
Приложения
[ редактировать ]DNSSEC
[ редактировать ]EDNS необходим для реализации расширений безопасности DNS ( DNSSEC ). [6]
Заполнение EDNS
[ редактировать ]Существуют стандарты использования EDNS для установки размера заполнения вокруг сообщения DNS. [7] [8] Заполнение необходимо при шифровании DNS, поскольку без заполнения можно определить запрашиваемое доменное имя по зашифрованному размеру запроса.
Поддержка активности EDNS
[ редактировать ]EDNS используется для указания того, как долго TCP-соединение должно поддерживаться. [9]
Подсеть клиента EDNS (ECS)
[ редактировать ]EDNS также используется для отправки общей информации от преобразователей на серверы имен о географическом местоположении клиентов в форме опции «Клиентская подсеть EDNS» (ECS). [10]
Проблемы
[ редактировать ]На практике могут возникнуть трудности при использовании межсетевых экранов EDNS, поскольку некоторые межсетевые экраны предполагают максимальную длину DNS-сообщения 512 байт и блокируют более длинные DNS-пакеты.
Внедрение EDNS сделало возможным атаку DNS-амплификации , тип отраженной атаки типа «отказ в обслуживании» , поскольку EDNS обеспечивает передачу очень больших пакетов ответов по сравнению с относительно небольшими пакетами запросов.
Рабочая группа IETF DNS Extensions (dnsext) завершила работу над уточнением EDNS0, которое было опубликовано как RFC 6891.
Ссылки
[ редактировать ]- ^ RFC 2671 , Механизмы расширения DNS (EDNS0) , П. Викси, The Internet Society (август 1999 г.)
- ^ RFC 6891 , Механизмы расширения DNS (EDNS(0)) , Дж. Дамас, М. Графф, П. Викси (апрель 2013 г.)
- ^ RFC 1035, Доменные имена – реализация и спецификация , П. Мокапетрис (ноябрь 1987 г.)
- ^ Сетевая рабочая группа IETF, август 1999 г., RFC 2671: Механизмы расширения DNS (EDNS0), страница 3, Полное соответствие данной спецификации обозначается версией «0».
- ^ Сетевая рабочая группа IETF, декабрь 2001 г., RFC 3225: указание поддержки DNSSEC со стороны резольвера. страница 3, Механизм, выбранный для явного уведомления о способности клиента принимать (если не понимать) записи безопасности DNSSEC, использует старший бит поля Z в заголовке OPT EDNS0 в запросе. Этот бит называется битом «DNSSEC OK» (DO).
- ^ RFC 4035, Модификации протокола для расширений безопасности DNS , Р. Арендс, Telematica Instituut, 2005. Раздел 4.1 Поддержка EDNS.
- ^ Майрхофер, Александр (май 2016 г.). «RFC 7830: опция заполнения EDNS(0)» . www.tools.ietf.org . Проверено 2 февраля 2018 г.
- ^ Майрхофер, Александр (октябрь 2018 г.). «RFC 8467: Политики заполнения для механизмов расширения DNS (EDNS(0))» . www.tools.ietf.org . Проверено 1 октября 2018 г.
- ^ Воутерс, Пол (апрель 2016 г.). «RFC 7828: Опция edns-tcp-keepalive EDNS0» . www.tools.ietf.org . Проверено 2 февраля 2018 г.
- ^ Контавалли, Карло (май 2016 г.). «RFC 7871: Клиентская подсеть в DNS-запросах» . www.tools.ietf.org . Проверено 2 февраля 2018 г.