Что-что случится 1 февраля?
Не то что бы, конечно, это было первое обсуждение вопроса на Хабре. Однако до сего момента в основном обсуждались последствия, в то время как, на наш взгляд, куда интереснее первопричины.
Итак, на 1 февраля запланирован DNS Flag Day. Эффекты этого события будут наступать постепенно, однако всё же быстрее, чем некоторые компании сумеют к нему адаптироваться.
Что это такое? Говоря простым языком, это манифест основных мировых разработчиков DNS-серверов: компаний CZ.NIC, ISC, NLnet Labs и PowerDNS.
Производители программного обеспечения DNS уже давно столкнулись с проблемой: развитие системы доменных имён, добавление в неё новых функций, требующихся клиентам, решение вопросов безопасности — все эти процессы радикально замедляются ввиду кооперативной структуры системы DNS и необходимости поддерживать архаичные серверы, реализующие устаревшие версии протоколов (и даже это зачастую делающие с ошибками).
Согласно каталогу стандартов протокола DNS, текущая спецификация содержит, по состоянию на 21 января 2018 года, 3248 страниц. Они включают в себя все релевантные RFC в статусах «internet standard», «proposed standard» (что на сегодняшний день, по сути, то же самое), «best current practice» и «informational». Для сравнения: протокол HTTP, обеспечивающий доставку контента для всех веб-сайтов в Интернете, описан суммарно на 672 страницах.
Необходимость реализовывать обработку всех описанных на 3 тысячах страниц функций и исключительных ситуаций — тяжёлая работа и сама по себе, а вдобавок целый ряд DNS-серверов реализует ту или иную функциональность неправильно, что приводит к необходимости дополнительно обрабатывать ещё и нестандартное поведение. В некоторых из вышеупомянутых RFC отчаяние, обуревающее работающих с протоколом людей, выплёскивается даже в название.
По мнению ключевых разработчиков DNS, ситуация со сложностью программного кода уже достаточно серьёзная, чтобы принимать радикальные меры. 1 февраля в рамках скоординированной акции будут выпущены обновлённые версии всех основных DNS-серверов, в которых поддержка определённого некорректного поведения будет прекращена отныне и навсегда.
А подробнее?
Чтобы пояснить, что именно перестанет поддерживаться, приведу аналогию. Представьте, будто до 1999 года людей не пускали на самолёт с багажом, а в 1999 году официальным решением контролирующего органа пассажирам разрешили брать на борт сумки (определённого веса и габаритов). Достаточно удобно, правда? Можно перевезти массу полезных вещей.
Вот только представьте теперь, что в 2019 году до сих пор существуют самолёты, на которые с сумками нельзя, и вплоть до посадки на борт у вас нет возможности узнать, можно ли брать с собой багаж.
Примерно так обстоят дела с расширением EDNS, отсутствие поддержки которого с 1 февраля приведёт к недоступности ряда веб-сайтов. Грубо говоря, самолёты, не умеющие брать багаж на борт (хотя бы минимальный), в феврале в связи с двадцатилетним юбилеем первого стандарта EDNS перестанут пускать в целый ряд аэропортов.
Объявление об этом было выпущено достаточно заблаговременно: в марте-мае 2018 года основные организаторы DNS Flag Day проинформировали общественность на ряде популярных отраслевых конференций. Кроме того, сам по себе выпуск обновлённых версий DNS-серверов не приведёт к проблемам моментально, поскольку операторам ещё предстоит на эти версии перейти, а это занимает время. Но, что более существенно, целый ряд облачных провайдеров DNS-услуг также присоединился к DNS Flag Day. В их числе такие гиганты, как Google (и их знаменитый DNS-сервер с IP-адресом 8.8.8.8), Cloudflare, Facebook и Cisco.
В результате сайты, пользующиеся DNS-серверами без поддержки EDNS (то есть «самолётами», не умеющими «брать на борт багаж») уже с 1 февраля перестанут работать для всех, кто пользуется открытыми DNS-серверами 8.8.8.8, 9.9.9.9, 1.1.1.1 и рядом других. По мере обновления DNS-серверов у провайдеров связи список будет расти.
Особенность функционирования DNS-сервера в корпоративной инфраструктуре — в том, что есть он обычно не просит, работает себе и работает, поэтому его зачастую никто и никогда не обновляет. Системные администраторы старой закалки даже любят гордиться многолетним аптаймом таких машин. Проблема в том, что, когда возникает необходимость обновиться, выясняется, что для этого нужно, например, также переехать с FreeBSD 5 на FreeBSD 10 (реальный случай), для чего, в числе прочих бед, потребуется перезагрузка, а из перезагрузки старый сервер уже может просто-напросто не выйти.
Самое неприятное, что решение проблемы в общем случае не сводится к простому обновлению DNS-серверов. Некоторые организации используют файрволлы (как программные, так и программно-аппаратные), которые принудительно сбрасывают все DNS-пакеты с функцией EDNS. В числе прочего этим занимались старые модели Juniper SRX, но ими дело отнюдь не ограничивается. В принципе, если говорить про файрволлы и DPI-решения в целом, то давно известен достаточно невысокий уровень качества разработки ряда таких решений. Все эти годы от объективно вызванных ими проблем страдали разработчики протокола DNS, а теперь они решили нанести ответный удар.
Вот только обновление подобных решений может занять существенное время, а в каких-то случаев, вероятно, потребуется выбросить некогда дорогостоящее оборудование на помойку и приобрести новое, что вызовет множество сложностей, например, в рамках российского бюджетного цикла (особенно если выбрасываемая аппаратура была произведена за рубежом, а больше возможности покупать зарубежное у организации по тем или иным причинам — финансовым, политическим, идеологическим — нет).
Так что тем, у кого наблюдается эта проблема, самое время начать её решать. Заметим, что незамедлительного решения требуют только те проблемы, которые соответствующий инструмент проверки отображает с красными знаками «STOP» или «SLOW». Восклицательный знак в жёлтом треугольнике пока является лишь предупреждением и 1 февраля проблем не вызовет (хотя в долгосрочной перспективе и эту проблему нужно исправить).
А дальше что?
Во-первых, каких-то значимых катаклизмов DNS Flag Day уже спровоцировать не должен.
В разнообразных обсуждениях можно услышать критику оригинального поста Алексея Лукацкого на Хабре: мол, автор взял излишне алармистский тон. Тем не менее, нельзя не заметить, что как раз Алексей — тот человек, который очень хорошо в курсе, как порой устроена и на какую аппаратуру завязана сетевая инфраструктура крупных российских организаций и государственных учреждений. Согласно исследованию, результаты которого, по всей видимости, имеются в распоряжении Координационного центра доменов .RU и .РФ, проблема, которая до поста Лукацкого регистрировалась у целого ряда известных сайтов, сегодня уже проявляется в следовых количествах, то есть запись в блоге Cisco (и последующие заметки, скажем, в блоге Роскомсвободы) возымели должный эффект.
Однако успешность DNS Flag Day очевидным образом приведёт к последствиям, главное из которых состоит в том, что такие акции будут проводиться и в дальнейшем. В системе DNS ещё осталось много мест, которые разработчикам хотелось бы расшить как можно оперативнее; кроме того, DNS вообще не единственный такой протокол, в котором есть что разобрать. Пример с BGP-атрибутом 0xFF, о котором мы расскажем в следующей статье, наглядно показывает: порой Интернету полезна прививка.
Что, на сегодняшний день, оставляет системных администраторов перед достаточно однозначной дилеммой:
- Либо администратор DNS-сервера должен следить за жизнью Интернет-сообщества, в частности, за новостями профессионального сообщества разработчиков DNS, и, в частности, вообще-то уделять внимание и время обновлениям серверов;
- Либо управление собственной доменной зоной следовало бы передать стороннему провайдеру, специализирующемуся на такой работе (коих на свете существует, в принципе, масса).
Впрочем, к этой теме мы, вероятно, тоже ещё вернёмся.
