Главная » Хабрахабр » Что-что случится 1 февраля?

Что-что случится 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 страницах.

Как говорится, если ТЗ вашего проекта не похоже на что-то такое, даже не пытайтесь меня приглашать.

В некоторых из вышеупомянутых RFC отчаяние, обуревающее работающих с протоколом людей, выплёскивается даже в название. Необходимость реализовывать обработку всех описанных на 3 тысячах страниц функций и исключительных ситуаций — тяжёлая работа и сама по себе, а вдобавок целый ряд DNS-серверов реализует ту или иную функциональность неправильно, что приводит к необходимости дополнительно обрабатывать ещё и нестандартное поведение.

1 февраля в рамках скоординированной акции будут выпущены обновлённые версии всех основных DNS-серверов, в которых поддержка определённого некорректного поведения будет прекращена отныне и навсегда. По мнению ключевых разработчиков DNS, ситуация со сложностью программного кода уже достаточно серьёзная, чтобы принимать радикальные меры.

А подробнее?

Чтобы пояснить, что именно перестанет поддерживаться, приведу аналогию. Представьте, будто до 1999 года людей не пускали на самолёт с багажом, а в 1999 году официальным решением контролирующего органа пассажирам разрешили брать на борт сумки (определённого веса и габаритов). Достаточно удобно, правда? Можно перевезти массу полезных вещей.

Вот только представьте теперь, что в 2019 году до сих пор существуют самолёты, на которые с сумками нельзя, и вплоть до посадки на борт у вас нет возможности узнать, можно ли брать с собой багаж.

Грубо говоря, самолёты, не умеющие брать багаж на борт (хотя бы минимальный), в феврале в связи с двадцатилетним юбилеем первого стандарта EDNS перестанут пускать в целый ряд аэропортов. Примерно так обстоят дела с расширением EDNS, отсутствие поддержки которого с 1 февраля приведёт к недоступности ряда веб-сайтов.

Кроме того, сам по себе выпуск обновлённых версий DNS-серверов не приведёт к проблемам моментально, поскольку операторам ещё предстоит на эти версии перейти, а это занимает время. Объявление об этом было выпущено достаточно заблаговременно: в марте-мае 2018 года основные организаторы DNS Flag Day проинформировали общественность на ряде популярных отраслевых конференций. В их числе такие гиганты, как Google (и их знаменитый DNS-сервер с IP-адресом 8. Но, что более существенно, целый ряд облачных провайдеров DNS-услуг также присоединился к DNS Flag Day. 8. 8. 8), Cloudflare, Facebook и Cisco.

8. В результате сайты, пользующиеся DNS-серверами без поддержки EDNS (то есть «самолётами», не умеющими «брать на борт багаж») уже с 1 февраля перестанут работать для всех, кто пользуется открытыми DNS-серверами 8. 8, 9. 8. 9. 9. 1. 9, 1. 1 и рядом других. 1. По мере обновления DNS-серверов у провайдеров связи список будет расти.

Системные администраторы старой закалки даже любят гордиться многолетним аптаймом таких машин. Особенность функционирования DNS-сервера в корпоративной инфраструктуре — в том, что есть он обычно не просит, работает себе и работает, поэтому его зачастую никто и никогда не обновляет. Проблема в том, что, когда возникает необходимость обновиться, выясняется, что для этого нужно, например, также переехать с FreeBSD 5 на FreeBSD 10 (реальный случай), для чего, в числе прочих бед, потребуется перезагрузка, а из перезагрузки старый сервер уже может просто-напросто не выйти.

Некоторые организации используют файрволлы (как программные, так и программно-аппаратные), которые принудительно сбрасывают все DNS-пакеты с функцией EDNS. Самое неприятное, что решение проблемы в общем случае не сводится к простому обновлению DNS-серверов. В принципе, если говорить про файрволлы и DPI-решения в целом, то давно известен достаточно невысокий уровень качества разработки ряда таких решений. В числе прочего этим занимались старые модели Juniper SRX, но ими дело отнюдь не ограничивается. Все эти годы от объективно вызванных ими проблем страдали разработчики протокола DNS, а теперь они решили нанести ответный удар.

Вот только обновление подобных решений может занять существенное время, а в каких-то случаев, вероятно, потребуется выбросить некогда дорогостоящее оборудование на помойку и приобрести новое, что вызовет множество сложностей, например, в рамках российского бюджетного цикла (особенно если выбрасываемая аппаратура была произведена за рубежом, а больше возможности покупать зарубежное у организации по тем или иным причинам — финансовым, политическим, идеологическим — нет).

Заметим, что незамедлительного решения требуют только те проблемы, которые соответствующий инструмент проверки отображает с красными знаками «STOP» или «SLOW». Так что тем, у кого наблюдается эта проблема, самое время начать её решать. Восклицательный знак в жёлтом треугольнике пока является лишь предупреждением и 1 февраля проблем не вызовет (хотя в долгосрочной перспективе и эту проблему нужно исправить).

А дальше что?

Во-первых, каких-то значимых катаклизмов DNS Flag Day уже спровоцировать не должен.

Тем не менее, нельзя не заметить, что как раз Алексей — тот человек, который очень хорошо в курсе, как порой устроена и на какую аппаратуру завязана сетевая инфраструктура крупных российских организаций и государственных учреждений. В разнообразных обсуждениях можно услышать критику оригинального поста Алексея Лукацкого на Хабре: мол, автор взял излишне алармистский тон. RU и .РФ, проблема, которая до поста Лукацкого регистрировалась у целого ряда известных сайтов, сегодня уже проявляется в следовых количествах, то есть запись в блоге Cisco (и последующие заметки, скажем, в блоге Роскомсвободы) возымели должный эффект. Согласно исследованию, результаты которого, по всей видимости, имеются в распоряжении Координационного центра доменов .

В системе DNS ещё осталось много мест, которые разработчикам хотелось бы расшить как можно оперативнее; кроме того, DNS вообще не единственный такой протокол, в котором есть что разобрать. Однако успешность DNS Flag Day очевидным образом приведёт к последствиям, главное из которых состоит в том, что такие акции будут проводиться и в дальнейшем. Пример с BGP-атрибутом 0xFF, о котором мы расскажем в следующей статье, наглядно показывает: порой Интернету полезна прививка.

Что, на сегодняшний день, оставляет системных администраторов перед достаточно однозначной дилеммой:

  1. Либо администратор DNS-сервера должен следить за жизнью Интернет-сообщества, в частности, за новостями профессионального сообщества разработчиков DNS, и, в частности, вообще-то уделять внимание и время обновлениям серверов;
  2. Либо управление собственной доменной зоной следовало бы передать стороннему провайдеру, специализирующемуся на такой работе (коих на свете существует, в принципе, масса).

Впрочем, к этой теме мы, вероятно, тоже ещё вернёмся.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Как изучение критической уязвимости DHCP в Windows 10 привело к обнаружению еще двух ошибок безопасности

Изображение: Unsplash А в некоторых случаях таких новых уязвимостей оказывается больше одной. Как было описано в предыдущей статье про CVE-2019-0726, иногда поиск деталей об уже известной уязвимости приводит к обнаружению новой уязвимости. Как всегда происходит при поиске уязвимостей, даже если ...

Быстрорастворимое проектирование

Люди учатся архитектуре по старым книжкам, которые писались для Java. Книжки хорошие, но дают решение задач того времени инструментами того времени. Время поменялось, C# уже больше похож на лайтовую Scala, чем Java, а новых хороших книжек мало. Увидим обзор типовых ...