История системы доменных имен: «войны» протоколов

Продолжаем рассказ об истории 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-трафике. Принимающий сервер извлекает необходимые данные с помощью набора API. Обмен данными идет через стандартный порт 443, и если кто-то решит прослушать трафик, то он не извлечет из неё DNS-информацию.

В поддержку нового протокола высказались крупные ИТ-компании — Google и Mozilla — и интегрировали функциональность DNS over HTTPS в свои браузеры. Джефф Хастон из APNIC также заметил, что DoH упростит структуру сетей за счет сокращения числа используемых портов и ускорит преобразование адресов.

<i>Фото — </i><a href="https://www.flickr.com/photos/andrewfhart/8106200690/" target="_blank" rel="noopener noreferrer nofollow"><i>Andrew Hart</i></a><i> — CC BY-SA</i>
Фото — Andrew Hart — CC BY-SA

Но это мнение разделяют не все. По словам Пола Викси (Paul Vixie), разработчика DNS-сервера BIND, новый стандарт, наоборот, усложняет администрирование сетей в компаниях — сисадмины не могут блокировать вредоносные сайты. При этом DoH совсем не гарантирует анонимность запросов. Определить, к каким хостам обращается пользователь, можно по SNI и ответам OCSP. По данным исследования APNIC, третьей стороне (например, интернет-провайдеру) не нужны DNS-записи для определения ресурсов, которые посещает пользователь. Их можно установить с точностью в 95% только по IP.

По этой причине часть экспертов предлагает использовать альтернативный подход — DNS over TLS (DoT). В этом случае передача DNS-запросов происходит по выделенному порту 853. Так, данные по-прежнему шифруются, но при этом упрощается настройка сетей.

Пока сложно сказать, какой из стандартов победит. Уже сейчас многие облачные провайдеры и разработчики браузеров поддерживают оба протокола. Какой из них получит большее распространение покажет только время — в любом случае на это может уйти не одно десятилетие.

О чем мы пишем в корпоративном блоге:

  1. DevOps в облачном сервисе на примере 1cloud.ru
  2. Как развивалась архитектура нашего облака
  3. Где полезны объектные хранилища

P.S. Мы в 1cloud.ru предлагаем услугу «Облачное хранилище». Его можно использовать для хранения резервных копий, архивных данных и обмена корпоративными документами. Система хранения данных построена на дисках трех типов: HDD SATA, HDD SAS и SSD SAS. Их суммарный объем составляет несколько тысяч терабайтов.

МЕРОПРИЯТИЯ

Комментарии

ВАКАНСИИ

Добавить вакансию
AppSec Business Partner
по итогам собеседования
Backend Lead (Python, Django)
по итогам собеседования

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ