Продолжаем говорить об истории DNS. Обсуждаем точку зрения экспертов и компаний, выступающих за и против внедрения протоколов DNS over HTTPS и DNS over TLS, а также спецификации EDNS.
Опасения вокруг EDNS
Стандартизированный в 1987 году (RFC1035) механизм работы DNS не учитывал многие изменения и требования к безопасности, которые пришли с развитием интернета. Даже автор системы доменных имен — Пол Мокапетрис (Paul Mockapetris) — в одном из интервью отметил, что не ожидал настолько широкого распространения своего творения. По его оценкам DNS должна была работать с десятками миллионов IP-адресов, но их общее количество превысило 300 млн.
Изначально возможностей для расширения функциональности DNS было немного. Но ситуация изменилась в 1999 году, когда опубликовали спецификацию EDNS0 (RFC2671). В ней добавили новый тип псевдозаписи — OPT. Она содержит 16 флагов, описывающих свойства DNS-запроса.
Отметим, что стандарт EDNS0 должен был стать временным решением. В перспективе его бы заменила обновленная версия EDNS1. Но вместо превращения в EDNS1 (для которого есть драфт), спецификация начала обрастать опциями и интеграциями и используется до сих пор.
EDNS0 также позволил прикреплять к DNS-записям информацию о подсети клиента. Такой подход применяет сеть распространения контента Akamai, чтобы определять ближайший к пользователю сервер. Однако Джефф Хастон (Geoff Huston), ведущий научный сотрудник интернет-регистратора APNIC, отмечает, что так снижается общий уровень информационной безопасности. Серверы, управляющие DNS-зонами, получают возможность идентифицировать пользователя, отправившего запрос на скачивание того или иного файла. Плюс возрастает нагрузка на локальные резолверы. Они вынуждены добавлять ключи поиска (lookup key) для подсетей в свой кэш, снижая его эффективность.
Несмотря на опасения, новую функциональность внедрили Google Public DNS и OpenDNS. Возможно, в будущем в спецификацию EDNS0 внесут правки, которые улучшат ситуацию с безопасностью. Подобные модификации могут сделать в EDNS1, если она выйдет из статуса черновика.
Споры о DoH/DoT
Протокол DNS не шифрует сообщения, передаваемые между клиентом и сервером. Поэтому при перехвате запросов можно узнать, какие ресурсы посещает пользователь. Для решения проблемы в октябре прошлого года инженеры из IETF и ICANN опубликовали стандарт DNS over HTTPS (DoH).
Новый подход предлагает отправлять DNS-запросы не напрямую, а скрывать их в HTTPS-трафике. Обмен данными идет через стандартный порт 443, и если кто-то решит прослушать трафик, то извлечь DNS-информацию ему будет достаточно затруднительно. В поддержку нового протокола высказались Google и Mozilla — они интегрировали функциональность DNS over HTTPS в свои браузеры.
Джефф Хастон из APNIC также заметил, что DoH упростит структуру сетей за счет сокращения числа используемых портов и ускорит преобразование адресов.
Но это мнение разделяют не все. По словам Пола Викси (Paul Vixie), разработчика DNS-сервера BIND, новый стандарт, наоборот, усложняет администрирование сетей. При этом DoH совсем не гарантирует анонимность запросов. Определить, к каким хостам обращается пользователь, можно по SNI и ответам OCSP. По данным исследования APNIC, третьей стороне не нужны DNS-записи для определения ресурсов, которые посещает пользователь. Их можно установить с точностью в 95% только по IP.
По этой причине часть экспертов предлагает использовать альтернативный подход — DNS over TLS (DoT). В этом случае передача DNS-запросов происходит по выделенному порту 853. Так, данные по-прежнему шифруются, но при этом упрощается работа с сетью.
Пока сложно сказать, какой из стандартов победит. Уже сейчас многие облачные провайдеры и разработчики браузеров поддерживают оба протокола. Какой из них получит большее распространение покажет только время — в любом случае на это может уйти не одно десятилетие.
