Механизмы расширения для 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» 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, отображаемой служебным инструментом Domain Information Groper (dig):
;; ОПТИЧЕСКАЯ ПСЕВДОЗЕКЦИЯ:; EDNS: версия: 0, флаги: делать; UDP: 4096
Результат «EDNS: version: 0» указывает на полное соответствие EDNS0. [4] Результат «flags: do» указывает, что установлен «DNSSEC OK». [5]
Приложения [ править ]
EDNS необходим для реализации расширений безопасности DNS ( DNSSEC ). [6] EDNS также используется для отправки общей информации от преобразователей на серверы имен о географическом местоположении клиентов в форме опции EDNS Client Subnet (ECS). [7]
Есть предложения по использованию EDNS, чтобы установить, сколько заполнения должно быть вокруг сообщения DNS [8], и для указания, как долго TCP-соединение должно оставаться активным. [9]
Проблемы [ править ]
На практике могут возникнуть трудности при использовании брандмауэров с обходом 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 в заголовке EDNS0 OPT в запросе. Этот бит называется битом «DNSSEC OK» (DO).
- ^ RFC 4035, Модификации протокола для расширений безопасности DNS , Р. Арендс, Telematica Instituut, 2005. Раздел 4.1 Поддержка EDNS.
- ^ Contavalli, Карло. «RFC 7871: подсеть клиента в запросах DNS» . tools.ietf.org . Проверено 2 февраля 2018 .
- ^ Майрхофер, Александр. «RFC 7830: параметр заполнения EDNS (0)» . tools.ietf.org . Проверено 2 февраля 2018 .
- ^ Воутерс, Пол. «RFC 7828: опция edns-tcp-keepalive EDNS0» . tools.ietf.org . Проверено 2 февраля 2018 .
См. Также [ править ]
- Клиентская подсеть EDNS
- День флага DNS - 2019
