Илл. 7.3. Отношения между реестрами и регистраторами
Доменное имя, которое ищет хост (такое, как www.cs.uchicago.edu или cisco.com), обычно называют полностью квалифицированным доменным именем (Fully Qualified Domain Name, FQDN). Оно начинается с наиболее конкретизированной части доменного имени, с отделением каждой части иерархии с помощью символа «.». (Строго говоря, все FQDN также заканчиваются символом «.», который означает корень иерархии DNS, однако большинство операционных систем подставляет эту часть имени автоматически.)
Имя каждого домена, подобно полному пути к файлу в файловой системе, состоит из пути от этого домена до корня (безымянного). Компоненты пути разделяются точками. В отличие от того, как это принято в UNIX (/com/cisco/eng), домен технического отдела корпорации Cisco может выглядеть как eng.cisco.com. Следует отметить, что при такой иерархической системе имя eng.cisco.com. не конфликтует с потенциальным использованием eng в домене eng.uchicago.edu., который мог бы использоваться факультетом английского языка Чикагского университета.
Имена доменов могут быть абсолютными и относительными. Абсолютное имя домена всегда оканчивается точкой (например, eng.cisco.com.), тогда как относительное имя — нет. Чтобы однозначно определить истинное значение относительного имени, его нужно интерпретировать в некотором контексте. В обоих случаях именованный домен означает определенный узел дерева и все узлы под ним.
Имена доменов нечувствительны к регистру символов: edu, Edu и EDU означают одно и то же. Длина отдельных компонентов имени может составлять до 63 символов, но длина полного имени не должна превышать 255. Тот факт, что система DNS нечувствительна к регистру, используется для защиты от различных видов DNS-атак (включая отравление кэша DNS) с помощью метода 0x20-кодирования (Дейгон и др.; Dagon et al., 2008), который мы подробно обсудим далее в этой главе.
Как правило, новые домены могут добавляться в иерархию как родовых, так и национальных доменов. Так, домен cc.gatech.edu можно без проблем поместить (зачастую так и происходит) в список национального домена us в виде cc.gt.atl.ga.us. Однако на практике большинство организаций в США используют родовые домены, а большинство организаций за пределами США — домены страны, к которой они относятся. Не существует каких-либо правил, запрещающих регистрацию нескольких доменов верхнего уровня. Крупные компании часто именно так и поступают (например: sony.com, sony.net и sony.nl).
Каждый домен управляет распределением доменов, расположенных под ним. Например, в Японии домены ac.jp и co.jp используются как аналог доменов edu и com. В Голландии вообще не проводится деление по такому принципу, и все домены организаций находятся непосредственно под доменом nl. Все австралийские университеты располагаются в домене edu.au. В качестве примера можно привести следующие домены, выбранные для факультетов вычислительной техники и электротехники трех университетов:
1) cs.uchicago.edu (Чикагский университет, США);
2) cs.vu.nl (Университет Врийе, Нидерланды);
3) ee.uwa.edu.au (Университет Западной Австралии).
Для создания нового домена требуется разрешение домена, в который он будет включен. Например, если в Чикагском университете появится исследовательская группа по вопросам безопасности, которая захочет использовать домен security.cs.uchicago.edu, то ей нужно будет получить разрешение от тех, кто управляет доменом cs.uchicago.edu. (К счастью, этих людей, как правило, не так сложно найти благодаря федеративной архитектуре управления DNS.) Аналогично, если будет создан, скажем, новый Университет Северной и Южной Дакоты, то для присвоения ему домена unsd.edu (при условии, что он свободен) потребуется обратиться за разрешением к менеджеру домена edu. Так удается избежать конфликта имен, а каждый домен отслеживает состояние всех своих поддоменов. После создания и регистрации домена в нем могут создаваться такие поддомены, как cs.unsd.edu, для чего уже не требуется разрешение вышестоящих доменов.
Структура доменов отражает не физическое строение сети, а логическое разделение между организациями и их внутренними подразделениями. Так, факультеты вычислительной техники и электротехники могут использовать разные домены, даже если они находятся в одном здании и пользуются общей LAN. И наоборот, если факультет вычислительной техники расположен в двух корпусах университета, хосты обоих зданий, скорее всего, принадлежат к одному и тому же домену.
7.1.4. DNS-запросы и DNS-ответы
Теперь рассмотрим структуру, формат и назначение DNS-запросов, а также разберемся с тем, каким образом DNS-серверы выдают ответы на них.
DNS-запросы
Как было сказано выше, DNS-клиент обычно направляет запрос локальному рекурсивному распознавателю, который выполняет итеративные операции поиска, чтобы в конечном итоге выполнить запрос. Наиболее распространенный тип запроса — запрос А-записи, позволяющей сопоставить доменное имя с IP-адресом соответствующей конечной точки интернета. В DNS есть разные записи ресурсов (с другими запросами); мы обсудим их в следующем разделе, посвященном записям ресурсов (то есть ответам).
Хотя DNS почти всегда использовалась в основном для сопоставления удобочитаемых имен с IP-адресами, за прошедшие годы DNS-запросы использовались для множества других задач. Еще один популярный вид DNS-запроса — проверка на наличие домена в черном списке DNS (Domain Name Service Black List, DNSBL). Этот список используется для отслеживания IP-адресов, связанных с распространением спама и вредоносных программ. Для поиска доменного имени в DNSBL клиент может направить DNS-запрос А-записи специальному DNS-серверу, например pbl.spamhaus.org. Он производит сопоставление со списком IP-адресов, которые не должны соединяться с почтовыми серверами. Чтобы проверить конкретный IP-адрес, нужно просто изменить порядок октетов в IP-адресе на обратный и поставить полученный результат перед именем сервера pbl.spamhaus.org.
Так, например, чтобы проверить адрес 127.0.0.2, нужно сделать запрос для 2.0.0.127.pbl.spamhaus.org. При наличии этого IP-адреса в списке DNS-запрос возвращает IP-адрес, в котором, как правило, закодирована дополнительная информация (например, сведения о том, как данная запись попала в список). Если данного IP-адреса в списке нет, DNS-сервер сообщает об этом с помощью соответствующего ответа NXDOMAIN, означающего «такого домена нет» («no such domain»).
Расширения и улучшения DNS-запросов
Со временем DNS-запросы стали более изощренными и сложными, поскольку клиенты нуждались во все более конкретизированной и актуальной информации и вместе с тем возрастали требования безопасности. Существенным расширением DNS-запросов за последние годы стало использование клиентской подсети EDNS (EDNS0 CS Extended DNS Client Subnet, или просто EDNS Client Subnet), что позволяет локальному рекурсивному распознавателю клиента передавать авторитетному серверу имен IP-адрес подсети оконечного распознавателя.
Благодаря механизму клиентской подсети EDNS авторитетный сервер имен для доменного имени может узнать IP-адрес клиента, направившего исходный запрос. Обычно это позволяет ему произвести более эффективное сопоставление с ближайшей копией реплицируемого сервиса. Например, если клиент выдаст запрос для домена google.com, авторитетный сервер имен для Google в большинстве случаев вернет имя, соответствующее ближайшему к клиенту интерфейсному серверу. Конечно, сделать это можно, лишь зная, в какой части сети (а в идеале и в какой части мира) находится клиент. Обычно авторитетный сервер имен видит только IP-адрес локального рекурсивного распознавателя.
Если клиент, инициировавший запрос, находится рядом с соответствующим локальным распознавателем, то авторитетный сервер этого домена может сопоставить клиента, просто руководствуясь местоположением локального рекурсивного DNS-распознавателя. Но клиенты все чаще используют локальные рекурсивные распознаватели, IP-адрес которых не позволяет определить местоположение клиента. Например, компании Google и CloudFlare используют общие DNS-распознаватели (с адресами 8.8.8.8 и 1.1.1.1 соответственно). Если клиент настроен на использование одного из таких распознавателей, авторитетный сервер не сможет извлечь полезную информацию из сведений об IP-адресе этого распознавателя. Механизм клиентской подсети EDNS решает эту проблему, включая IP-адрес подсети в запрос от локального рекурсивного распознавателя, чтобы авторитетный сервер видел IP-адрес подсети клиента, который инициировал запрос.