Следующие три строки содержат типичные записи для компьютера, в данном случае для rowboat.cs.vu.nl. Эти строки содержат его IP-адрес, а также имена первого и второго хостов для доставки почты. Следом идет запись о компьютере, неспособном самостоятельно получать почту. Последняя строка, вероятно, описывает подключенный к интернету лазерный принтер.
Теоретически один сервер мог бы содержать всю базу данных DNS и отвечать на все запросы к ней. На практике он оказался бы настолько перегружен, что был бы бесполезен. Более того, если бы он когда-нибудь отключился, то весь интернет перестал бы работать.
Чтобы избежать проблем, связанных с хранением всей информации в одном месте, пространство имен DNS разделено на непересекающиеся зоны. На илл. 7.6 показан один из способов разделения пространства имен с илл. 7.1. Здесь каждая очерченная зона содержит некоторую часть общего дерева доменов.
Расстановка границ внутри каждой зоны определяется ее администратором. Это решение зависит от того, сколько серверов имен требуется в той или иной зоне. Например, у Чикагского университета (илл. 7.6) есть зона для домена uchicago.edu, которая управляет доменом cs.uchicago.edu, но не доменом eng.uchicago.edu, расположенным в отдельной зоне со своими серверами имен. Подобное решение может быть принято, когда факультет английского языка не хочет управлять собственным сервером имен, но этого хочет факультет вычислительной техники.
Илл. 7.6. Часть пространства имен DNS, разделенная на зоны (они обведены)
7.1.5. Разрешение имен
Каждая зона ассоциируется с одним или несколькими серверами имен. Это хосты, на которых находится база данных для зоны. Обычно у зоны есть один основной сервер имен, который берет информацию из файла на своем диске, и один или несколько второстепенных серверов, получающих данные с основного сервера. Для повышения надежности некоторые серверы имен могут быть расположены вне зоны.
Процесс поиска адреса по имени называется разрешением имен (name resolution). Распознаватель обращается с запросом разрешения имени домена к локальному серверу имен. Если искомый домен относится к сфере ответственности данного сервера (к примеру, домен top.cs.vu.nl относится к домену cs.vu.nl), тогда сервер возвращает авторитетную запись (authoritative record) ресурса (так называют запись, которая поступает из управляющего ею авторитетного источника). В отличие от кэшируемых записей (cached records), которые могут устаревать, авторитетные записи всегда считаются верными.
Но что происходит, если домен является удаленным, как, например, в случае, когда flits.cs.vu.nl пытается найти IP-адрес для домена cs.uchicago.edu в Чикагском университете? В этом случае, при отсутствии информации о запрашиваемом домене в локальном кэше, сервер имен отправляет удаленный запрос. Этот запрос выполняется, как показано на илл. 7.7. На первом шаге запрос передается локальному серверу имен. В нем указывается имя искомого домена, тип (A) и класс (IN).
Илл. 7.7. Пример поиска распознавателем имени удаленного хоста за десять шагов
На следующем шаге запрос направляется одному из корневых серверов имен (root name servers) на вершине иерархии. На таких серверах хранится информация о каждом домене верхнего уровня. На рис 7.7 этот шаг обозначен цифрой 2. Чтобы связаться с корневым сервером, каждый сервер имен должен обладать информацией об одном или нескольких подобных серверах. Обычно эти сведения находятся в файле системной конфигурации, который загружается в кэш DNS на этапе запуска сервера DNS. Это просто список записей NS для корня, вместе с соответствующими записями А.
Существует 13 корневых серверов DNS, которым без всякого воображения были присвоены имена от a-root-servers.net до m.root-servers.net. Каждый корневой сервер логически представляет собой просто отдельный хост. Но поскольку весь интернет зависит от корневых серверов, для них используются мощные и активно реплицируемые компьютеры. Большинство этих серверов расположено в разных географических точках, доступ к которым осуществляется путем произвольной маршрутизации (она сводится к доставке пакета ближайшему экземпляру адреса получателя). Произвольная рассылка была подробно описана в главе 5. Репликация этих серверов повышает надежность и производительность.
Корневой сервер имен вряд ли знает адрес искомого хоста в домене uchicago.edu, и, возможно, ему даже неизвестно, к какому серверу имен этот домен привязан. Но он должен знать сервер имен для домена edu, где расположен домен cs.uchicago.edu. Он возвращает имя и IP-адрес для этой части ответа на третьем шаге.
Затем локальный сервер имен проводит дальнейший поиск. Он отправляет весь запрос серверу имен домена edu (a.edu-servers.net). Этот сервер имен возвращает информацию о сервере имен домена uchicago.edu. На рисунке это шаги 4 и 5. Теперь, уже приблизившись к цели, локальный сервер имен отсылает запрос серверу имен домена uchicago.edu (шаг 6). Если искомое доменное имя расположено на факультете английского языка, то ответ будет найден уже на этом этапе, поскольку зона uchicago.edu включает в себя этот факультет. Однако факультет вычислительной техники использует собственный сервер имен. Если нужное доменное имя находится на факультете вычислительной техники, то запрос вернет имя и IP-адрес сервера имен этого факультета в зоне uchicago.edu (шаг 7).
Наконец, локальный сервер имен направляет запрос серверу имен факультета вычислительной техники в зоне uchicago.edu (шаг 8). Поскольку этот сервер отвечает за домен cs.uchicago.edu, он должен выдать нужный ответ. Он вернет окончательный ответ на шаге 9, после чего на шаге 10 локальный сервер имен передаст его хосту flits.cs.vu.nl.
7.1.6. Практическое ознакомление с DNS
Вы можете изучить этот процесс с помощью таких стандартных инструментов, как программа dig, устанавливаемая на большинстве 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-трафика требуется и для многих услуг, предлагаемых провайдерами, например для родительского контроля.