История системы доменных имен: «войны» протоколов
Продолжаем рассказ об истории 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 упростит структуру сетей за счет сокращения числа используемых портов и ускорит преобразование адресов.
Но это мнение разделяют не все. По словам Пола Викси (Paul Vixie), разработчика DNS-сервера BIND, новый стандарт, наоборот, усложняет администрирование сетей в компаниях — сисадмины не могут блокировать вредоносные сайты. При этом DoH совсем не гарантирует анонимность запросов. Определить, к каким хостам обращается пользователь, можно по SNI и ответам OCSP. По данным исследования APNIC, третьей стороне (например, интернет-провайдеру) не нужны DNS-записи для определения ресурсов, которые посещает пользователь. Их можно установить с точностью в 95% только по IP.
По этой причине часть экспертов предлагает использовать альтернативный подход — DNS over TLS (DoT). В этом случае передача DNS-запросов происходит по выделенному порту 853. Так, данные по-прежнему шифруются, но при этом упрощается настройка сетей.
Пока сложно сказать, какой из стандартов победит. Уже сейчас многие облачные провайдеры и разработчики браузеров поддерживают оба протокола. Какой из них получит большее распространение покажет только время — в любом случае на это может уйти не одно десятилетие.
О чем мы пишем в корпоративном блоге:
- DevOps в облачном сервисе на примере 1cloud.ru
- Как развивалась архитектура нашего облака
- Где полезны объектные хранилища
P.S. Мы в 1cloud.ru предлагаем услугу «Облачное хранилище». Его можно использовать для хранения резервных копий, архивных данных и обмена корпоративными документами. Система хранения данных построена на дисках трех типов: HDD SATA, HDD SAS и SSD SAS. Их суммарный объем составляет несколько тысяч терабайтов.