1 февраля ряд DNS-сервисов и производителей DNS-серверов решили (https://www.isc.org/blogs/dns-flag-day/) провести день (https://dnsflagday.net/) корректной обработки запросов EDNS (DNS flag day). В этот же день организация ISC планирует выпустить новый значительный релиз DNS-сервера BIND 9.14, в который будут внесены изменения, нарушающие совместимость резолвера с некоторыми DNS-серверами, на которых используется старое ПО с некорректно реализованной обработкой запросов с расширенными флагами EDNS.
EDNS определяет механизм расширения размера некоторых параметров DNS и позволяет добавлять в протокол новые флаги. Расширенные флаги кодируются в специальных RR-записях, что позволят сохранить обратную совместимость с классическим протоколом DNS (не поддерживающий EDNS сервер может ответить на запрос без учёта дополнительных флагов).
EDNS был стандартизирован в 1999 году в форме RFC 2671 (https://tools.ietf.org/html/rfc2671), а в 2013 году было выпущено обновление спецификации RFC 6891 (https://tools.ietf.org/html/rfc6891).
Так как до 1999 года расширения EDNS не были стандартизированы, DNS-серверы того времени по разному обрабатывали ситуацию, когда поступали запросы с применением не поддерживаемых на этих серверах расширений EDNS. Утверждённая спецификация предписывает в случае отсутствия поддержки определённых EDNS-флагов отправлять соответствующий DNS-ответ в старом формате, просто отбрасывая флаги EDNS. Некоторые серверы поступали иначе и игнорировали не поддерживаемые запросы, вообще не отправляя ответный пакет.
Около 20 лет назад в DNS-сервере BIND был реализован обходной манёвр ("грязный хак"), позволяющий корректно взаимодействовать с подобными серверами, который впоследствии был воплощён и в других DNS-резолверах. Суть метода в том, что в качестве признака отсутствия поддержки флагов EDNS использовался таймаут - если после отправки запроса через определённый промежуток времени не поступал ответ, DNS-сервер считал, что расширенные флаги не поддерживаются и отправлял повторный запрос без флагов EDNS.
Применение обходного манёвра позволяло сохранить взаимодействие с проблемными серверами, но приводило к увеличению задержек из-за повторной отправки пакетов, повышению нагрузки на сеть и неоднозначности при отсутствии ответа из-за сетевых сбоев, а также мешало внедрению основанных на EDNS возможностей, таких как применение DNS Cookies (https://tools.ietf.org/html/rfc7873) для защиты от DDoS-атак. Добавление обходного манёвра также привело к тому, что некоторые DNS-серверы не уделяли должного внимания соблюдению стандарта и до недавнего времени практиковали игнорирование пакетов с не поддерживаемыми флагами EDNS.
В частности,
в резолвере PowerDNS все замечания в области поддержки спецификации будут устранены только в готовящемся выпуске 4.2. При этом в подготовленной в 2017 году версии PowerDNS 4.1 (https://www.opennet.ru/opennews/art.shtml?num=47673) авторитотивный сервер уже полностью соответствовал спецификации EDNS, а ветке 4.0 всплывали лишь отдельные несовместимости, возникающие при определённом стечении обстоятельств и в общем виде не мешающие нормальной работе.
Теперь разработчики DNS-серверов договрились удалить из реализаций DNS-резолверов поддержку упомянутого обходного метода проверки и более не откатываться на старый вариант протокола в случае наступления таймаута. Изменение планируется произвести в выпусках BIND 9.14 (намечен на 1 февраля), Unbound 1.8.4/1.9.0 и PowerDNS Recursor 4.2.0. В Knot Resolver изначально не применялся рассматриваемый обходной метод. К инициативе также подключились компании CloudFlare, Quad 9, Cisco (OpenDNS) и Google, которые планируют удалить поддержку обходного метода проверки на своих публичных DNS-серверах (1.1.1.1, 8.8.8.8).
Изменение не повлияет на штатное поведение резолверов - запросы с использованием старого протокола DNS и корректно отбрасываемые не поддерживаемые запросы с EDNS будут обрабатываться как и прежде. Иными словами, DNS теперь должны корректно реагировать на не поддерживаемые запросы EDNS, а не молча игнорировать их. По сути, авторитативные серверы лишь принуждают к соответствию стандарту, принятому 20 лет назад, при этом серверы как и раньше не обязаны поддерживать EDNS и могут ограничиваться старым классическим протоколом.
С практической стороны прекращение поддержки обходной проверки может привести к проблемам при взаимодействии с DNS-серверами, использующими очень старые выпуски PowerDNS. Для тестирования корректности реагирования на запросы с EDNS запущены специальные online-сервисы dnsflagday.net (https://dnsflagday.net/) и EDNS Compliance Tester (https://ednscomp.isc.org/ednscomp). Тем не менее, так как каждый домен обслуживает как минимум 2 разных DNS-сервера, а переход на новые выпуски Unbound и BIND будет выполняться постепенно, со временем всё больше и больше DNS-резолверов не сможет взаимодействовать с DNS-серверами, некорректно отвечающими на EDNS-запросы.
Проблемы после отмены обходной проверки также могут возникнуть из-за блокирования расширенных DNS-запросов на стороне межсетевых экранов- блокировка DNS-пакетов размером больше 512 байт иногда применяется для противодействия DDoS-атакам, использующим поля EDNS для усиления трафика. Поэтому администраторам межсетевых экранов также следует обратить внимание на корректность пропускания DNS-трафика с флагами EDNS.
URL: https://news.ycombinator.com/item?id=18930798
Новость: https://www.opennet.ru/opennews/art.shtml?num=49999
