Компьютерные сети. 6-е изд. - Эндрю Таненбаум

большинстве UNIX-систем. Например, напечатав

dig ns @a.edu-servers.net cs.uchicago.edu

вы отправите запрос имени cs.uchicago.edu на сервер имен a.edu-servers.net и выведете результат. Вы увидите информацию, которая была получена на четвертом шаге в приведенном выше примере, и узнаете имя и IP-адрес серверов имен для домена uchicago.edu. Большинство организаций использует несколько серверов имен на тот случай, если один из них даст сбой, часто около пяти-шести. Если у вас есть доступ к системе UNIX, Linux или MacOS, поэкспериментируйте с программой dig и посмотрите, чего можно добиться с ее помощью. Это позволит вам существенно углубить свое понимание системы DNS. (Программу dig также можно использовать и в Windows, но в этом случае вам придется установить ее самостоятельно.)

Хотя цель создания DNS проста и понятна, вполне очевидно, что это большая и сложная распределенная система, включающая в себя миллионы совместно работающих серверов имен. DNS формирует ключевую связь между удобочитаемыми доменными именами и IP-адресами хостов. Она использует репликацию и кэширование для повышения производительности и надежности и сама по себе максимально устойчива.

Иногда приложениям нужно использовать имена более гибко, например, присвоить контенту имя, а затем преобразовать его в IP-адрес ближайшего хоста, содержащего этот контент. По такой схеме производится поиск и скачивание фильмов. Главное — найти конкретный фильм, и совершенно неважно, на каком компьютере находится его копия. Соответственно, нам нужен IP-адрес любого ближайшего компьютера, содержащего копию искомого фильма. Такого преобразования можно достичь, к примеру, с помощью сетей доставки контента. Об их использовании поверх DNS подробно рассказано в разделе 7.5.

7.1.7. DNS и конфиденциальность

Изначально запросы и ответы системы DNS не шифровались. В результате любое устройство или средство подслушивания в сети (другое устройство, системный администратор, сеть кофейных автоматов и т.д.) теоретически могло просматривать трафик пользователя системы DNS и извлекать информацию об этом человеке. Например, изучив трафик сайта uchicago.edu, можно выяснить, что пользователь посетил сайт Чикагского университета. Эта информация вполне безобидна, но в случае сайта webmd.com просмотр трафика позволяет узнать, что пользователь провел некое медицинское исследование. Сочетая эти данные с другой информацией, часто можно получить более конкретные сведения и узнать, какой именно веб-сайт посещает пользователь.

Проблемы конфиденциальности DNS-запросов становятся все более актуальными по мере развития таких новых областей применения, как IoT и умные дома. Например, DNS-запросы от устройств могут раскрывать сведения о том, какие именно устройства используют люди в своих умных домах и насколько активно. Так, DNS-запросы, отправляемые подключенной к интернету камерой или находящимся в спящем режиме монитором, позволяют однозначно идентифицировать это устройство (Апторп и др; Apthorpe et al., 2019). Учитывая растущую конфиденциальность активности пользователей, применяющих устройства с выходом в интернет (будь то браузер или умное устройство), потребность в шифровании запросов и ответов DNS становится все более актуальной.

Некоторые последние тенденции, например тренд в сторону шифрования DNS-запросов и DNS-ответов, могут привести к полному видоизменению DNS. Многие компании, включая CloudFlare, Google и ряд других, предоставляют пользователям возможность направить DNS-трафик на локальные рекурсивные распознаватели этих компаний, при этом позволяя шифровать трафик (к примеру, с помощью TLS и HTTPS) между оконечным DNS-распознавателем и локальным распознавателем компании. Некоторые из этих компаний сотрудничают с разработчиками браузеров (например, браузера Mozilla), чтобы в конечном итоге весь DNS-трафик по умолчанию передавался на их локальные распознаватели.

Если пересылка всех запросов и ответов DNS будет осуществляться облачным провайдером по шифруемому каналу, это может иметь очень серьезные последствия для архитектуры интернета в будущем. В частности, интернет-провайдеры не смогут отслеживать DNS-запросы, поступающие из домашних сетей абонентов, в то время как раньше это был один из основных способов проверки сетей на предмет вредоносных программ (Антонакакис и др.; Antonakakis et al., 2010). Просмотр содержимого DNS-трафика требуется и для многих услуг, предлагаемых провайдерами, например для родительского контроля.

В итоге мы имеем дело с двумя не зависящими друг от друга проблемами. Одна из них — смещение DNS в сторону шифруемой передачи, что почти все считают положительной переменой (изначально это вызвало ряд вопросов о производительности, но по большей части они решены). Вторая, более сложная проблема — вопрос о том, кто должен управлять локальными рекурсивными распознавателями. Раньше это, как правило, был провайдер пользователя. Но если процесс DNS-разрешения переместится в браузер за счет протокола DoH, то браузеры смогут управлять доступом к DNS-трафику (а на сегодня два самых популярных браузера почти полностью контролируются одним главным поставщиком, компанией Google). В конечном счете оператор локального рекурсивного распознавателя сможет просматривать содержимое DNS-запросов пользователя и ассоциировать их с IP-адресом. При этом пользователь сможет выбрать, кому доверить просмотр своего DNS-трафика — своему провайдеру или крупной рекламной компании. Но от стандартных настроек браузера будет зависеть, кто в итоге просмотрит большую часть этого трафика. В настоящее время многие организации, начиная с интернет-провайдеров и заканчивая провайдерами контента и рекламными компаниями, пытаются ввести в практику доверенные рекурсивные распознаватели (Trusted Recursive Resolvers, TRR). Это локальные рекурсивные распознаватели, которые используют для разрешения клиентских запросов DoT или DoH. Как эти тенденции повлияют на архитектуру DNS, покажет время.

Даже протоколы DoT и DoH не могут полностью решить проблемы DNS в сфере конфиденциальности, поскольку оператору локального распознавателя все равно приходится предоставлять частную информацию, а именно содержимое DNS-запросов и IP-адреса клиентов, от которых они поступают. Недавно в качестве альтернативы были предложены улучшенные версии DNS и DoH, в частности «забывчивый DNS» (oblivious DNS, ODNS) (Шмитт и др.; Schmitt et al., 2019) и «забывчивый DoH» (oblivious DoH, ODoH) (Киннир и др.; Kinnear et al., 2019). Благодаря этому оконечный распознаватель шифрует исходный запрос перед тем, как передать его локальному распознавателю, а тот передает его авторитетному серверу имен. Сервер может выполнить дешифрование и разрешить запрос, но при этом ему неизвестен идентификатор или IP-адрес оконечного распознавателя, который инициировал запрос. Схема этих взаимодействий представлена на илл. 7.8.

Илл. 7.8. «Забывчивый DNS»

Большая часть этих реализаций пока находится на начальном этапе развития, в виде первых прототипов и проектов стандартов, обсуждаемых в рамках рабочей группы по конфиденциальности DNS комитета IETF.

7.1.8. Разногласия по поводу способов именования

По мере того как интернет распространяется по всему миру и все больше развивается с точки зрения коммерции, растет число спорных вопросов (особенно в отношении именования доменов). Разногласия возникают и в самой ICANN. Например, создание домена ххх заняло несколько лет и повлекло за собой несколько судебных разбирательств. Размещение контента для взрослых на отдельном домене — это хорошо или плохо? (Многие хотели