Что-что случится 1 февраля 2020 года?

22 мая 2019

TL;DR: начиная с февраля 2020 года, DNS-серверы, не поддерживающие обработку DNS-запросов как по UDP, так и по TCP, могут перестать работать.

Это продолжение поста «Что-что случится 1 февраля?» от 24 января 2019 г. Читателю рекомендуется бегло ознакомиться с первой частью истории, дабы понимать контекст.

Вид на улицу Бангкока​​​​​​

Бангкок, вообще, место на любителя. Конечно, там тепло, дёшево, и кухня интересная, и визы половине населения Земли туда не нужно получать заблаговременно, однако к запахам надо ещё привыкнуть, а городские улицы заставляют в лучшем случае вспомнить классику киберпанка.

В частности, пейзаж слева наблюдается недалеко от центра столицы Таиланда, через одну улицу от отеля Shangri-La, где 12-13 мая прошло 30-е собрание организации DNS-OARC, некоммерческой организации, занимающейся вопросами безопасности, стабильности и развития системы доменных имён DNS.

Слайды из программы DNS-OARC 30 в принципе рекомендуются к изучению всем, кого интересует работа DNS, однако самое, пожалуй, интересное — это то, чего в слайдах не было. А именно, 45-минутный круглый стол с обсуждением результатов DNS Flag Day, случившегося 1 февраля 2019 года.

А самое интересное в круглом столе — решение, что практика DNS Flag Day будет продолжена.

Problems, officer?

Как показывают разнообразные исследования, эффект первого DNS Flag Day свёлся к минимуму. Да, для кого-то процесс адаптации мог стать болезненным, но в конечном счёте практически все устаревшие DNS-серверы были обновлены, а некорректно настроенные файрволлы — настроены корректно.

Соответственно, организаторы Flag Day воспринимают произошедшее как большую победу и, окрылённые успехом, не собираются останавливаться на достигнутом.

В рамках круглого стола обсуждались следующие задачи, которые грядущие «дни флага» могут помочь выполнить:
 

  • Поддержка согласования версии EDNS на публичных DNS-серверах;
  • Поддержка рАнДоМизаЦиИ заглавных и строчных символов в запросах DNS с целью повышения энтропии, содержащейся в запросах и ответах;
  • Поддержка DNS over TCP на DNS-серверах (как авторитативных, так и рекурсивных);
  • Реализация RFC 8020, предписывающего рекурсивным резолверам прекращать обращение к домену и всем его поддоменам в случае получения ответа типа NXDOMAIN;
  • Отсутствие поддержки IPv6 и пр.

В конечном счёте, принято решение, которое было оглашено на пленарном заседании RIPE 78 одновременно с публикацией данного поста.

Повторимся: начиная с февраля 2020 года, DNS-серверы, не поддерживающие обработку DNS-запросов как по UDP, так и по TCP, могут перестать работать.

Конкретная дата, впрочем, ещё не определена. Скорее всего, это будет 1 февраля, однако день может быть изменен. Впрочем, по мнению организаторов DNS Flag Day 2020 (а это те же лица и компании, что и в этом году), девяти месяцев на реализацию поддержки TCP в существующих DNS-инсталляциях вполне достаточно, поэтому откладывать событие вряд ли имеет смысл.

Over TCP

На сегодняшний день TCP в DNS в целом поддерживается.

Работа системы доменных имён с использованием TCP нужна по целому ряду причин:

  1. Доставка ответов, размер которых превышает path MTU, без использования ненадёжной IP-фрагментации;
  2. Поддержка DNSSEC;
  3. Борьба с DDoS-атаками и пр.

С клиентской стороны DNS over TCP поддерживается уже давно практически любым stub resolver'ом, включая Windows.

В сущности, DNS over TCP уже очень давно не является опциональным. Как замечает Марк Эндрюс, разработчик DNS-сервера Bind, RFC 1123 (опубликованный в 1989 году) позволял не реализовывать обработку DNS-запросов и ответов поверх TCP, только если оператор сервера хорошо понимает последствия и в состоянии поддержать полную функциональность протокола DNS без TCP. На сегодняшний день последнее уже просто невозможно.

Анализ 34 миллионов доменов из 59 TLD показывает, что требование использовать TCP приводит сегодня к проблемам примерно у 7% доменов. Для сравнения, в ноябре 2018 года — за 3 месяца до первого DNS Flag Day — проблемы с EDNS имело 5,68% тестируемых сайтов.

Из этих 7%:

  • 90% проблем связано с работой авторитативных серверов 10 компаний;
  • 68% проблем замыкается на серверах одной единственной компании — китайского оператора Hichina;
  • Вместе с другими проблемными китайскими провайдерами — AliDNS и Xinnet — эта доля уже 72%;
  • Половина списка также имела проблемы с EDNS в ноябре 2018, но успешно их решила.

Организаторы Flag Day достигли консенсуса в том, что тысячи операторов, составляющих сообщество DNS, не должны больше оплачивать поддержку костылей ради пары десятков компаний, не обновляющих свои серверы.

Важный момент, как и в прошлый раз, последствия могут быть не только для владельцев DNS-серверов, но и для администраторов сетей, блокирующих доступ к порту 53/TCP на файрволле.
К февралю 2020 года доступ по порту 53/TCP к DNS-серверам должен работать.

А дальше что?

Само собой, организаторы Flag Day обновят свой сайт и добавят туда и информацию о DNS Flag Day 2020, и утилиты для проверки любых доменов на совместимость с требованиями 2020 года.

Не забудьте осуществить такую проверку до конца года, дабы удостовериться, что проблем у вас не возникнет.

Либор Пельтан из CZ.NIC подробно расскажет о планах DNS Flag Day 2020 на грядущем собрании евразийской группы сетевых операторов ENOG в Тбилиси 3-4 июня. Трансляция с переводом на русский будет доступна в режиме реального времени на сайте, там же (и в Telegram-чате ENOG Talk) можно будет задавать вопросы.

За происходящим также можно следить в Twitter.

DNS Flag Day 2021 будет планироваться, вероятнее всего, по аналогичному графику, начиная с DNS-OARC 32 весной 2020 года. Заявки на костыли, которые давно пора бы закопать, принимаются и коллекционируются на Github.

Ознакомьтесь со всеми функциями
в 7-дневной пробной версии

Наши специалисты готовы оказать вам поддержку

Будьте в курсе наших новостей и продуктов!

Подпишитесь на ежемесячный обзор самых популярных идей Интернета от CURATOR!

E-mail *

Читайте также

Curator
Мы включили TLS 1.3. Почему вам стоит сделать то же самое
В начале года, в отчете о проблемах и доступности интернета за 2018-2019 мы уже писали , что распространение TLS 1.3 неизбежно. Некоторое время назад мы сами развернули версию 1.3 протокола Transport Layer Security и, после сбора и анализа данных, наконец, готовы рассказать об особенностях этого перехода. Председатели рабочей группы IETF TLS пишут : «Вкратце, TLS 1.3 должен предоставить фундамент более безопасного и эффективного Интернета на следующие 20 лет». Разработка TLS 1.3 заняла долгих 10 лет. Мы в Qrator Labs, вместе со всей остальной отраслью, внимательно следили за процессом создания протокола от первоначального проекта. За это время потребовалось написать 28 последовательных версий черновика для того, чтобы в конечном счёте в 2019 году свет увидел сбалансированный и удобный в развертывании протокол. Активная поддержка TLS 1.3 рынком уже очевидна: внедрение проверенного и надежного протокола безопасности отвечает требованиям времени. По словам Эрика Рескорлы (технического директора Firefox и единственного автора TLS 1.3) в интервью The Register : «Это полная замена TLS 1.2, использующая те же ключи и сертификаты, поэтому клиент и сервер могут автоматически общаться по TLS 1.3, если оба его поддерживают», — сказал он. «Уже есть хорошая поддержка на уровне библиотек, а Chrome и Firefox по умолчанию включают TLS 1.3».
27 апреля 2019
Curator
БД ClickHouse в нейтрализации DDoS
Двухуровневая схема фильтрации трафика с машинным обучением На высоком уровне сервис фильтрации Qrator состоит из двух уровней: на первом мы незамедлительно оцениваем, если определенный запрос является злонамеренным с помощью проверок с сохранением состояния и без и, на втором, принимаем решение о том, задержать ли источник в черном списке и на какой срок. Получающийся в итоге черный список может быть представлен в виде уникальной таблицы IP-адресов.
04 марта 2019
Curator
Ускорение SQLAlchemy для архитектурных космонавтов
Это доклад инженера-программиста Алексея Старкова на конференции Moscow Python Conf++ 2018 в Москве. Видео в конце поста. Всем привет! Меня зовут Алексей Старков — это я, в свои лучшие годы, работаю на заводе. Теперь я работаю в Qrator Labs. В основном, всю свою жизнь, я занимался C и C++ — люблю Александреску, «Банду Четырех», принципы SOLID — вот это всё. Что и делает меня архитектурным космонавтом. Последние пару лет пишу на Python, потому что мне это нравится. Собственно, кто такие «архитектурные космонавты»? Первый раз я встретил данный термин у Джоэля Спольски, вы наверное его читали. Он описывает «космонавтов», как людей, которые хотят построить идеальную архитектуру, которые навешивают абстракцию, над абстракцией, над абстракцией, которая становится все более и более общей. В конце концов, эти уровни идут так высоко, что описывают все возможные программы, но не решают никаких практических задач. В этот момент у «космонавта» (это последний раз, когда данный термин окружен кавычками) кончается воздух и он умирает. Я тоже имею тенденции к архитектурной космонавтике, но в этом докладе я расскажу немного о том, как это меня укусило и не позволило построить систему с необходимой производительностью. Главное — как я это поборол. Краткое содержание моего доклада: было / стало.
23 ноября 2018
Ваша подписка успешно активирована
На главную