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

Продолжаем рассказ об истории 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. Их суммарный объем составляет несколько тысяч терабайтов.

РУБРИКИ В СТАТЬЕ

МЕРОПРИЯТИЯ

Комментарии 0

ВАКАНСИИ

Программист С++
Санкт-Петербург, по итогам собеседования
Программист С++
Новосибирск, по итогам собеседования

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

BUG