Новости 
25.01.2019
Что нужно знать о DNS flag day
Что нужно знать о DNS flag day
В СМИ и соцсетях появились публикации о возможных проблемах, в связи с развитием сервиса доменных имен DNS. С первого февраля стартует новый протокол сервиса EDNS, и владельцы DNS-серверов, соответственно, должны обновить программное обеспечение.
UZINFOCOM, администрирующий семь корневых серверов доменной зоны UZ, на постоянной основе обновляет программное обеспечение и отслеживает возможные риски. Также, все наши хостинг сервера, использующие DNS сервисы, ранее уже были обновлены до расширения, поддерживающего протокол EDNS.
Для внесения большей ясности по данной проблеме, предлагаем список частых вопросов и ответов на них:
1. С 1 февраля произойдет глобальное обновление протокола системы доменных имен. Насколько это критично?
Ничего критичного не произойдет. Более того, такая формулировка скорее сбивает людей с толку. Протоколы системы доменных имен останутся теми же самыми, поменяется только версия программного обеспечения, которое используется на DNS-серверах.
2. Для чего это нужно?
Много лет назад, когда система DNS только появилась, никто еще не представлял, во что превратится современный интернет, каким большим он будет, и как много разных функций будет на него возложено. Старая версия системы доменных имен просто не была для этого предназначена, и потребовалось вводить целый набор расширений, которые отвечали бы за безопасность, масштабируемость, шифрование трафика и т.д. Для этого была разработана следующая версия протокола, EDNS (extended DNS), которая как раз позволяла бы все эти расширения внедрять. Сейчас система работает так: наш провайдер запрашивает DNS-сервера для того, чтобы узнать для нас IP-адрес по имеющемуся домену. Он по умолчанию отправляет запрос в новом формате, и в том случае если сервер вдруг не отвечает, переспрашивает в старом формате. Это по идее должно было обеспечить работоспособность в том случае, если владелец сервера еще не обновил программное обеспечение. После первого февраля провайдеры перестанут переспрашивать сервера в том случае, если им не пришел ответ сразу. По мнению некоторых экспертов это потенциально может обернуться тем, что перестанут работать некоторые домены, которые обслуживаются на серверах со старыми версиями.
3. Почему именно сейчас?
Сложно сказать, почему это делают именно сейчас. Мы придерживаемся версии, что сейчас серверов со старой версией ПО осталось так мало, что такой переход не повлияет на общую работоспособность сети.
4. Это коснется только компаний или обычных пользователей тоже?
Система DNS обслуживает абсолютно все ресурсы, которые можно открыть при помощи доменного имени, а также все системы электронной почты, большинство мобильных приложений и некоторые мессенджеры, так что теоретически вопрос касается всего интернета.
5. В Интернете пишут, что может лечь много сайтов. Преувеличение? Или все серьезно? Если проблема в обновлении ПО, почему его просто не обновить?
Мы смотрим на вещи гораздо более оптимистично. Исследования, проведенные крупнейшими мировыми инфраструктурными операторами показывают, что количество серверов со старой версией программного обеспечения исчезающе мало. Например, некоторые цифры можно посмотреть в документе компании ISC.
Описание для технических специалистов
Речь идёт о согласованном прекращении поддержки резолверами "обходных механизмов", позволяющих сейчас работать с DNS-серверами, которые не отвечают на запросы с EDNS. Согласованность состоит в том, что разработчики самых распространённых резолверов (BIND, PowerDNS, Knot, Unbound) договорились синхронизировать выпуск новых версий, в которых "обходные механизмы" отключены. Дата: 1 февраля 2019 года.
Так как DNS независимо от объявления flag days, всё равно обновления происходят медленно, и каких-то внезапных массовых "отключений сайтов" в связи с данным нововведением не ожидается. Локальные проблемы - возможны, но их можно упредить.
EDNS - это набор расширений для оригинального протокола DNS, позволяющий дополнить его рядом полезных функций, например: увеличение размера ответа; передача списков опций, поддерживаемых сервером или клиентом - резолвером и так далее. Среди ключевых моментов, на которые, например, ссылается ISC (в контексте BIND), возможность использования в EDNS сигналов DNS-cookie. Эти сигналы могут применяться для противодействия DDoS-атакам. Кроме того, поддержка EDNS необходима для работы DNSSEC.
Изменения, о которых идёт речь, коснутся только ситуации, когда резолвер не получает никакого ответа на запрос, отправленный с EDNS. Такое возможно в следующих случаях:
1) авторитативный сервер игнорирует запросы, не укладывающиеся в "классический" формат (встречается весьма редко, обычно, в "самодельных" системах, так как все распространённые программные пакеты DNS-серверов - EDNS поддерживают). В этом случае считается, что авторитативный сервер настроен некорректно, так как он должен прислать тот или иной ответ, например, сообщение об ошибке.
2) запросы или ответы фильтруются промежуточными узлами. Обычно, это разнообразные межсетевые экраны. Фильтроваться могут либо запросы/ответы, превышающие определённую длину (типовые для UDP 512 байтов), либо запросы/ответы, которые содержат дополнительные флаги. Первый вариант, с ограничением по длине, напрямую к EDNS не относится, но, тем не менее, работе протокола препятствует. Второй вариант - непосредственно связан с EDNS, так как работает "по DNS-заголовкам", однако на практике этот вариант вряд ли встречается. Фильтрация DNS-пакетов может использоваться в составе мер противодействия DDoS-атакам. Основная особенность здесь в том, что корректно работающий резолвер и корректно работающий авторитативный сервер - всё равно не могут провести обмен данными в рамках протокола, так как им мешает промежуточный фильтр.
Ранее резолверы использовали дополнительные "обходные механизмы", позволявшие преодолеть сбой и "договориться" с неверно настроенным или недоступным по EDNS авторитативным сервером. Эти механизмы сводятся к повтору DNS-запросов, но с другими сочетаниями параметров, в том числе, без EDNS. После наступления "переломного дня" (01.02.2019) новые версии резолверов перестанут пытаться "договориться", а станут считать авторитативный сервер, от которого не был получен ответ на запрос с EDNS, нерабочим, соответственно, перестанут к нему обращаться. В этом и состоит "переломный момент" DNS flag day.
Такое поведение подразумевает, что каждый авторитативный сервер должен быть доступен для корректных DNS-запросов, отправляемых с EDNS, и сервер должен отвечать на такие запросы. Из этого не следует, что сервер должен полностью поддерживать EDNS: если сервер отвечает корректным пакетом с кодом DNS-ошибки ("Ошибка формата"), то, в этом случае, резолвер всё же попробует повторить запрос без EDNS. В частности, такое поведение заявлено для Unbound и BIND. То есть, ужесточается только обработка отсутствия какого-либо ответа - в таком случае резолвер не пытается отправить запрос без EDNS. Но с практической точки зрения - ситуация эквивалентна повсеместному внедрению EDNS, так как устранение "особенностей" обработки EDNS-пакетов там, где эти "особенности" внедрены преднамеренно, проще всего реализовать, внедрив данную технологию в полной мере.
Что нужно сделать
Нововведение не является критическим в масштабах Узнета. Во-первых, проблемы с потерями и блокированием EDNS довольно редки. Во-вторых, на проблемных направлениях ещё должны обновиться резолверы. Что касается авторитативных серверов, то большинство (по числу зон) уже так или иначе поддерживает работу с EDNS-пакетами, поэтому здесь массовой недоступности узлов для конечных пользователей ожидать не следует. Если где-то и остались несовместимые "самодельные" решения, либо старые версии типового ПО, то им следует доработать программный код или обновить пакеты.
Особенность данной ситуации в том, что существенную роль играет сетевой транспорт и его настройка. То есть, факторы, которые к DNS относятся косвенно, и исправить их обновлением ПО DNS нельзя. Здесь, в теории, возможна ситуация, когда крупный провайдер доступа обновит резолверы, но не поменяет настройки прохождения пакетов, соответственно, его конечные клиенты останутся без службы DNS (ситуация теоретическая, потому что такой провайдер уже должен был бы отмечать дефекты в работе DNS на своих сетях). Поэтому, для исключения возможных аварий, требуется участие провайдеров доступа, служб NOC, обеспечивающих прохождение пакетов DNS "в обе стороны" - и на стороне клиентов (рекурсивных резолверов), и на стороне автортитативных серверов. Такое участие состоит в проверке правил межсетевых экранов и подобного программно-аппаратного обеспечения: пакеты EDNS, при штатной работе сети, не должны блокироваться (если тотальное блокирование всё же необходимо, то следует отправлять на адрес источника пакета сообщение DNS о неверном запросе).
Отдельная благодарность Координационному центру домеров .RU/.РФ за cодействие в предоставлении информации.
