Компьютерные сети. 6-е изд.

7.1. Служба имен доменов DNS

Теоретически программа может обращаться к веб-страницам, почтовым ящикам и другим ресурсам, используя сетевые адреса (то есть IP-адреса) компьютеров, на которых они хранятся, однако пользователям тяжело запоминать эти адреса. Кроме того, размещение веб-страницы компании по адресу 128.111.24.41 будет означать, что в случае переезда сервера компании на новый компьютер потребуется сообщить новый IP-адрес всем заинтересованным лицам. Хотя такой переезд веб-сайта с одного IP-адреса на другой кажется маловероятным, в действительности это вполне распространенное явление при балансировке нагрузки. Например, контент многих современных сайтов размещается на большом количестве компьютеров, часто в территориально разных кластерах. А хостинг-провайдерам иногда нужно переместить соединение какого-нибудь клиента с одного веб-сервера на другой. Проще всего это сделать с помощью службы имен доменов (Domain Name System, DNS).

Имена компьютеров отделяются от их адресов путем использования удобочитаемых высокоуровневых имен. Таким образом, к веб-серверу компании можно обращаться по имени www.cs.uchicago.edu, независимо от того, какой у него IP-адрес. Поскольку устройства на сетевом пути пересылают трафик к получателю, руководствуясь его IP-адресом, эти удобочитаемые доменные имена нужно конвертировать в IP-адреса; именно это и делает DNS. В следующих разделах мы узнаем, как DNS выполняет это преобразование и каким изменениям она подверглась за прошедшие десятилетия. В частности, серьезное развитие в последние годы получила защита личной информации пользователей. Мы подробно обсудим эти вопросы и последние разработки в области шифрования DNS, связанные с обеспечением конфиденциальности.

7.1.1. История и общие сведения

Во времена сети ARPANET имена всех компьютеров сети и их IP-адреса сохранялись в файле hosts.txt. Каждую ночь все хосты получали этот файл с сайта, на котором он хранился. В сети, состоящей из нескольких сотен больших компьютеров, работающих в системе с разделением времени, такой подход оправдывал себя.

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

DNS представляет собой сочетание иерархической схемы именования с распределенной базой данных, реализующей эту схему. В первую очередь DNS служит для преобразования имен хостов в IP-адреса, но у нее есть и ряд иных применений, которые мы подробно обсудим ниже. Система DNS является одним из наиболее активно развивающихся протоколов интернета. Она описана в документах RFC 1034, RFC 1035, RFC 2181 и доработана в ряде других RFC.

7.1.2. Процесс поиска DNS

DNS работает следующим образом. Для преобразования имени в IP-адрес прикладная программа вызывает библиотечную процедуру (обычно это gethostbyname или ее аналог), передавая ей имя в качестве параметра. Этот процесс иногда называют оконечным распознавателем (stub resolver). Он отправляет запрос с именем локальному DNS-распознавателю, или, как его еще часто называют, локальному рекурсивному распознавателю (local recursive resolver) или просто локальному распознавателю, который выполняет рекурсивный поиск (recursive lookup) имени, используя некоторый набор DNS-распознавателей. В итоге локальный распознаватель возвращает ответ с соответствующим IP-адресом оконечному распознавателю, который затем передает результат той функции, от которой поступил исходный запрос. И запрос, и ответ передаются как UDP-пакеты. После этого, уже имея IP-адрес, программа может связаться с хостом, соответствующим тому DNS-имени, которое она искала. Далее в этой главе мы рассмотрим этот процесс более подробно.

Обычно оконечный распознаватель направляет запрос рекурсивного поиска локальному распознавателю, то есть он просто выдает запрос и ожидает ответа. Локальный распознаватель, в свою очередь, направляет ряд запросов соответствующим серверам имен для каждого элемента именной иерархии. Сервер имен, отвечающий за определенную часть этой иерархии, при этом считается авторитетным сервером имен (authoritative name server) для этого домена. Как мы увидим позже, система DNS использует кэширование, но кэш при этом может устаревать. Авторитетный сервер имен обладает, как понятно из названия, непререкаемым авторитетом. Он по определению всегда прав. Перед тем как переходить к более детальному рассмотрению работы DNS, давайте немного поговорим об иерархии серверов имен DNS и процессе выделения имен.

Получив запрос от оконечного распознавателя хоста, локальный распознаватель осуществляет процесс разрешения имен, пока не найдет нужный ответ (или не найдет его вовсе). Он не возвращает частичные ответы. С другой стороны, корневой сервер имен (и каждый последующий) не отправляет запрос локальному серверу имен рекурсивно. Он возвращает частичный ответ и переходит к следующему запросу. Локальный распознаватель обеспечивает продолжение процесса разрешения имен путем выдачи дальнейших итеративных запросов.

В ходе процесса разрешения имен обычно используются оба механизма. Рекурсивные запросы практически всегда кажутся предпочтительными, но многие серверы имен (особенно корневые) их не обрабатывают. Они слишком загружены. Итеративные запросы перекладывают ответственность на их источник. Для локального сервера имен разумно поддерживать рекурсивные запросы, чтобы предоставлять сервис хостам на своем домене. Эти хосты не обязательно должны быть сконфигурированы для запуска полного сервера имен, достаточно возможности обращения к локальному серверу. Каждый запрос содержит 16-битный идентификатор транзакции; он копируется в ответ, и, таким образом, сервер имен может выдавать необходимые ответы, даже когда поступает много запросов одновременно.

Все ответы, в том числе все возвращенные частичные ответы, хранятся в кэше. Так, если компьютер, расположенный в домене cs.vu.nl, запросит имя cs.uchicago.edu, ответ будет сохранен в кэше. Если вскоре после этого другой хост в домене cs.vu.nl тоже запросит имя cs.uchicago.edu, ответ уже будет известен. Более того, если хост запрашивает другой хост в том же домене, например noise.cs.uchicago.edu, запрос может быть направлен напрямую на авторитетный сервер имен для домена cs.uchicago.edu. Сходным образом, при запросе других доменов по адресу uchicago.edu запрос может быть передан напрямую серверу имен домена uchicago.edu. Использование ответов, сохраненных в кэше, серьезно сокращает количество шагов в запросе и повышает производительность. Такой сценарий на самом деле является худшим из возможных вариантов, так как в кэше нет полезной информации.

Кэшированные ответы не являются авторитетными, так как изменения в домене cs.uchicago.edu не распространяются автоматически на все кэши по всему миру, хранящие информацию об этом домене. В силу этого время жизни записей кэша не должно быть слишком большим. Именно поэтому каждый элемент базы данных DNS, о которой мы поговорим чуть позже, называемый записью ресурсов DNS, содержит поле Time_to_live. Оно сообщает удаленным серверам имен, как долго хранить эту запись в кэше. Если какой-либо компьютер обладает постоянным IP-адресом в течение многих лет, такую информацию можно хранить в кэше в течение суток. В случае более изменчивой информации запись безопаснее удалить спустя несколько секунд или одну минуту.

DNS-запросы имеют простой формат, который содержит разную информацию, включая запрашиваемое имя (QNAME), и вспомогательные сведения, такие как идентификатор транзакции (он часто используется для сопоставления запросов с ответами). Изначально этот идентификатор состоял только из 16 бит, а запросы и ответы были незащищенными. Такой подход делал систему DNS уязвимой для различных видов атак, в том числе так называемого отравления кэша, о котором мы подробно поговорим в главе 8. При выполнении ряда итеративных операций поиска рекурсивный DNS-распознаватель может отправить все содержимое поля QNAME ряду авторитетных серверов имен, возвращающих ответы. В какой-то момент разработчики протокола заметили, что отправка всего содержимого поля QNAME каждому авторитетному серверу среди итеративных распознавателей была небезопасной. Теперь многие рекурсивные распознаватели используют QNAME-минимизацию, при которой локальный распознаватель отправляет ту часть запроса, которую способен обработать соответствующий авторитетный сервер имен. Например, при разрешении с помощью QNAME-минимизации имени www.cs.uchicago.edu локальный распознаватель отправит авторитетному серверу для домена uchicago.edu только строку cs.uchicago.edu, а не полностью квалифицированное доменное имя (FQDN), чтобы избежать его раскрытия для авторитетного сервера. Более подробную информацию о QNAME-минимизации вы найдете в RFC 7816.

До недавнего времени в качестве транспортного протокола DNS-запросы и DNS-от­веты использовали UDP, исходя из тех соображений, что такие запросы и ответы должны быть быстрыми и легковесными и не могут позволить себе накладные расходы «тройного рукопожатия» в TCP. Но после выявления недостаточной безопасности протокола DNS, что сопровождалось множеством попыток использовать его уязвимость (начиная с атак отравления кэша и заканчивая DDoS-атаками), отмечается растущая тенденция к использованию TCP в качестве транспортного протокола для DNS. Со временем это позволило системе DNS эффективно применять современные безопасные протоколы транспортного и прикладного уровней, такие как DNS поверх TLS (DNS-over-TLS, DoT) и DNS поверх HTTPS (DNS-over-HTTPS, DoH). Мы подробно коснемся этих моментов далее.

Если оконечный DNS-распознаватель не получает ответа в течение сравнительно короткого периода времени (периода ожидания), DNS-клиент направляет этот запрос к другому серверу домена после нескольких повторных попыток. Эта возможность предусмотрена на случай, если сервер выйдет из строя или будет потерян ответный пакет.

7.1.3. Пространство имен и иерархия DNS

Управление большим и постоянно меняющимся набором имен — нетривиальная задача. На обычных письмах требуется, так или иначе, указывать страну, регион, город, улицу, номер дома, квартиру и фамилию получателя. Благодаря использованию такой иерархической схемы не возникает путаницы между Марвином Андерсоном, живущим на Мейн-стрит в Уайт-Плейнс, штат Нью-Йорк, и Марвином Андерсоном с Мейн-стрит в Остине, штат Техас. Система DNS работает аналогично.

Основа иерархии доменных имен разработана Корпорацией по управлению доменными именами и IP-адресами (ICANN). Она была создана именно для этих целей в 1998 году, поскольку интернет превратился в мировою экономическую среду. Весь интернет разделен на более чем 250 доменов верхнего уровня (top-level domains), каждый из которых охватывает множество хостов. Все домены делятся на поддомены, которые тоже разделены на поддомены, и т.д. Все эти домены составляют иерархию пространства имен, которую можно представить в виде дерева (илл. 7.1). Его листьями являются домены, которые не имеют поддоменов (но, безусловно, содержат хосты). Конечный домен может состоять из одного хоста или представлять компанию и содержать в себе тысячи хостов.

Илл. 7.1. Часть доменного пространства интернета

Существует несколько типов доменов верхнего уровня: родовой домен верхнего уровня, рДВУ (generic Top Level Domain, gTLD), национальный домен верхнего уровня, нДВУ (country code Top Level Doman, ccTLD), и др. Некоторые из представленных на илл. 7.2 исходных рДВУ появились еще в 1980-х годах; впоследствии они были дополнены рядом других доменов верхнего уровня, предложенных организации ICANN. За каждым государством в соответствии с международным стандартом ISO 3166 закреплен один национальный домен. Интернационализированные доменные имена стран, в которых используется алфавит, отличный от латинского, были введены в 2010 году. Эти домены позволяют именовать хосты, используя символы арабской, кириллической, китайской и других видов письменности.

Домен

Использование

Дата основания

Ограниченный?

com

Коммерция

1985

Нет

edu

Образовательные учреждения

1985

Да

gov

Правительство

1985

Да

int

Международные организации

1988

Да

mil

Военные

1985

Да

net

Сетевые провайдеры

1985

Нет

org

Некоммерческие организации

1985

Нет

aero

Авиатранспорт

2001

Да

biz

Бизнес

2001

Нет

coop

Кооперативы

2001

Да

info

Информация

2002

Нет

museum

Музеи

2002

Да

name

Люди

2002

Нет

pro

Профессионалы

2002

Да

cat

Каталония

2005

Да

jobs

Занятость

2005

Да

mobi

Мобильные устройства

2005

Да

tel

Контактная информация

2005

Да

travel

Индустрия путешествий

2005

Да

xxx

Секс-индустрия

2010

Нет

Илл. 7.2. Исходные родовые ДВУ по состоянию на 2010 год. На 2020 год существовало уже более 1200 рДВУ

В 2011 году существовало только 22 рДВУ, но в июне 2011 года члены ICANN проголосовали за снятие ограничений на создание дополнительных рДВУ, что позволило компаниям и другим организациям выбирать практически произвольные домены верхнего уровня, в том числе содержащие нелатинские символы (например, кириллические). ICANN начала принимать заявки на оформление таких ДВУ нового типа в начале 2012 года. При этом изначально стоимость оформления ДВУ составляла около $200 000. Ряд новых рДВУ был введен в действие в 2013 году. Так, в июле 2013 года начали действовать первые четыре рДВУ, введенные на основе соглашения, подписанного в Дурбане (Южная Африка). Все четыре новых домена содержали нелатинские символы: слово «интернет» по-арабски, «онлайн» и «сайт» по-русски и «игра» по-китайски. Множество заявок на оформление рДВУ подали и некоторые технологические гиганты, например, компании Google и Amazon запросили примерно по 100 новых рДВУ. На сегодняшний день широкое распространение получили такие рДВУ, как top, loan, xyz и т.д.

Что касается доменов второго уровня наподобие name-of-company.com, то получить такое имя достаточно просто. Управление доменами верхнего уровня осуществляют компании, называемые реестрами (registries). Их назначает ICANN. Например, реестром, отвечающим за домен com, является компания Verisign. Непосредственную продажу доменных имен пользователям осуществляют регистраторы (registrars). Существует много таких компаний, которые конкурируют друг с другом по стоимости и уровню обслуживания. К широко известным регистраторам относятся компании Domain.com, GoDaddy и NameCheap. На илл. 7.3 показаны отношения между реестрами и регистраторами в рамках процесса регистрации доменного имени.

Илл. 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-адрес подсети клиента, который инициировал запрос.

Как отмечалось ранее, имена в DNS-запросах нечувствительны к регистру. Это позволило современным DNS-распознавателям включить в запрос дополнительные биты идентификатора транзакции, установив символы в поле QNAME в произвольный регистр. 16-битный идентификатор уязвим к различным видам атаки отравления кэша, включая атаку Каминского, о которой пойдет речь в главе 8. Отчасти эта уязвимость обусловлена тем, что длина DNS-идентификатора транз­акции составляет лишь 16 бит. Увеличение длины потребовало бы изменений в спецификации протокола DNS, а это непростая задача.

В итоге было разработано альтернативное решение — метод 0x20-кодирования, который сводится к следующему. Локальный рекурсивный распознаватель переключает регистр в каждом поле QNAME («uchicago.edu» может превратиться в «uCHicaGO.EDu» и т.п.), что позволяет использовать каждый символ доменного имени в качестве дополнительного бита DNS-идентификатора транзакции. Конечно, важно, чтобы никакой другой распознаватель не менял регистр поля QNAME в последующих итеративных запросах или ответах. При сохранении регистра соответствующий ответ содержит поле QNAME с тем регистром, который ему присвоил локальный рекурсивный распознаватель, и в результате эти биты добавляются в идентификатор транзакции. Конечно, все это выглядит как лишенные какой-либо элегантности костыли, но именно так происходит внесение изменений в широко используемое программное обеспечение с сохранением обратной совместимости.

DNS-ответы и записи ресурсов DNS

У каждого домена, независимо от того, является ли он единственным хостом или доменом верхнего уровня, может быть набор ассоциированных с ним запи­сей ресурсов (resource records). Эти записи являются базой данных DNS. Для одного хоста запись ресурсов чаще всего представляет собой просто его IP-адрес, но существует еще много других записей. Когда распознаватель передает имя домена DNS-серверу, то, что он получает обратно, представляет собой записи ресурсов, ассоциированные с этим именем. Таким образом, основная функция системы DNS заключается в преобразовании доменных имен в записи ресурсов.

Записи ресурса состоят из пяти частей. Хотя для эффективности они часто перекодируются в двоичную форму, в большинстве описаний они представлены в виде ASCII-текста, по одной строке на каждую запись:

Domain_name Time_to_live Class Type Value

Поле Domain_name (Имя домена) сообщает, к какому домену относится текущая запись. Обычно для каждого домена имеется несколько записей ресурсов, и каждая копия базы данных хранит информацию о множестве доменов. Поле имени домена используется в качестве первичного ключа поиска при выполнении запросов. Порядок записей в базе данных значения не имеет.

Поле Time_to_live указывает, насколько стабильно состояние записи. Редко меняющимся данным присваивается высокое значение этого поля, например 86 400 (число секунд в сутках). Если же информация непостоянна (как, например, курсы акций) или ее вынуждены часто менять операторы сетей (например, для балансировки нагрузки при использовании одного имени для нескольких IP-адресов), то ей может быть присвоено небольшое значение, такое как 60 с (1 мин). Мы вернемся к этому вопросу, когда будем обсуждать кэширование.

Третье поле в записи ресурсов — Class (Класс). Для интернет-информации это всегда IN. Для прочей информации применяются другие коды, но на практике они встречаются редко.

Поле Type сообщает тип записи. Существует много типов DNS-записей. Наиболее важные из них перечислены на илл. 7.4.

Запись SOA (Start Of Authority — начальная точка полномочий) сообщает имя первичного источника информации о зоне сервера имен (описанного ниже), адрес электронной почты его администратора, уникальный порядковый номер, различные флаги и тайм-ауты.

Тип

Значение

Значение

SOA

Начальная запись зоны

Параметры для этой зоны

A

IPv4-адрес хоста

32-битное целое число

AAAA

IPv6-адрес хоста

128-битное целое число

MX

Обмен почтой

Приоритет, с которым домен хочет принимать электронную почту

NS

Сервер имен

Имя сервера для этого домена

CNAME

Каноническое имя

Имя домена

PTR

Указатель

Псевдоним IP-адреса

SPF

Правила отправки почты

Правила отправки почты, закодированные в текстовом виде

SRV

Служба

Хост, предоставляющий данную службу

TXT

Текст

Описательный ASCII-текст

Илл. 7.4. Основные типы записей ресурсов DNS

Распространенные типы записей

Самым важным типом записей является A (Address — адрес). Эти записи содержат 32-разрядный IPv4-адрес интерфейса для хоста. Соответствующая запись AAAA («quad A» — «четыре A») содержит 128-разрядный IPv6-адрес. У каждого хоста в интернете должен быть как минимум один IP-адрес, чтобы другие компьютеры могли с ним взаимодействовать. Иногда у хостов есть несколько сетевых интерфейсов. В таком случае они обладают несколькими записями ресурсов типа A или AAAA. Кроме того, один сервис (например, google.com) может быть размещен на множестве компьютеров, рассредоточенных по всему миру (Колдер и др.; Calder et al., 2013). В таких случаях DNS-распознаватель может возвращать несколько IP-адресов для одного доменного имени. В случае географически распределенного сервиса для улучшения производительности и балансировки нагрузки распознаватель может возвращать клиенту один или несколько IP-адресов ближайшего к нему (с точки зрения географии или топологии) сервера.

Еще один существенный тип записей — NS. Они несут информацию о сервере имен для домена или поддомена. Это хост, на котором содержится копия базы данных для домена. Он используется в ходе процесса поиска имен, о котором мы вскоре поговорим подробнее.

Записи MX сообщают имя хоста, готового принимать электронную почту для указанного домена. Дело в том, что не каждый компьютер готов это делать. Если письмо отправлено, скажем, на адрес bill@microsoft.com, то передающий хост прежде всего должен найти в домене microsoft.com почтовый сервер, готовый к получению почты. Эту информацию может предоставить запись MX.

Записи CNAME позволяют создавать псевдонимы. Допустим, что кто-то, имеющий представление о том, как формируются имена в интернете, хочет отправить сообщение пользователю paul на факультете вычислительной техники Чикагского университета. Действуя наудачу, этот человек пытается использовать адрес paul@cs.chicago.edu. Однако адрес не сработает, поскольку на самом деле факультет использует домен cs.uchicago.edu. В таком случае для удобства тех, кто этого не знает, Чикагский университет может создать запись CNAME, которая будет направлять пользователей и программы по нужному пути. Для этого можно использовать запись следующего вида:

www.cs.uchicago.edu 120 IN CNAME hnd.cs.uchicago.edu

Записи CNAME широко используются для присвоения псевдонимов веб-сайтам, поскольку адреса веб-серверов (которые часто начинаются с префикса www), как правило, размещаются на устройствах, используемых для нескольких целей, при этом www не является их основным именем.

Записи PTR указывают на другое имя и обычно используются для связывания IP-адреса с соответствующим именем. Просмотр записи PTR, связывающей имя с соответствующим IP-адресом, называется обратным просмотром (reverse lookup).

SRV представляют собой более новый тип записей, позволяющий идентифицировать хост как определенный сервис в рамках домена. Например, веб-сервер для домена www.cs.uchicago.edu может быть идентифицирован как hnd.cs.uchicago.edu. Данный тип записей является обобщением записей типа MX, которые выполняют ту же задачу, но только для почтовых серверов.

Записи SPF позволяют домену закодировать информацию о том, какие компьютеры в рамках домена будут отправлять письма в остальную часть интернета. Это помогает принимающим устройствам отсеивать недопустимую почту. Если почта поступает от компьютера с именем dodgy, в то время как согласно записям домена почта должна поступать только от компьютера с именем smtp, велика вероятность того, что данные сообщения являются спамом.

Последний в списке тип записей, TXT, изначально предназначался для того, чтобы позволить доменам идентифицировать себя произвольным образом. Сегодня эти записи обычно используются для кодирования машиночитаемой информации; обычно это SPF-информация.

Наконец, рассмотрим последнее поле записи ресурсов — Value (Значение). Оно может содержать число, имя домена или текстовую ASCII-строку — это зависит от типа записи. Краткое описание полей Value для каждого из основных типов записей дано на илл. 7.4.

Записи DNSSEC

В ходе изначального внедрения DNS безопасность этого протокола не учитывалась. В частности, серверы имен и распознаватели DNS могли манипулировать содержимым любой DNS-записи, в результате чего клиент мог получать некорректную информацию. В спецификации RFC 3833 описаны некоторые проблемы безопасности DNS, а также их решение с помощью записей DNSSEC. Записи DNSSEC позволяют включать в ответы серверов имен DNS цифровую подпись, которую впоследствии может проверить распознаватель (локальный или оконечный), чтобы убедиться в том, что DNS-запись не подвергалась изменениям или искажениям. Каждый DNS-сервер вычисляет хеш (своего рода длинную контрольную сумму) набора записей ресурсов (Resource Record Set, RRSET) для каждого набора записей ресурсов одного типа, используя свои закрытые криптографические ключи. Соответствующие открытые ключи можно использовать для проверки подписей наборов RRSET. (Если вы не знакомы с шифрованием, в главе 8 будет предоставлена более подробная техническая информация.)

Прежде чем проверять подпись набора RRSET с помощью соответствующего открытого ключа сервера имен, естественно, нужно убедиться в подлинности самого ключа. Это можно сделать, если открытый ключ авторитетного сервера имен подписан родительским сервером в иерархии имени. Например, авторитетный сервер имен домена .edu может подписывать открытый ключ, привязанный к авторитетному серверу имен домена uchicago.edu, и т.д.

Технология DNSSEC подразумевает наличие двух записей ресурсов, привязанных к открытым ключам: RRSIG и DNSKEY. Запись RRSIG ассоциируется с подписью набора RRSET, который подписывается соответствующим закрытым ключом авторитетного сервера имен. Запись DNSKEY представляет собой открытый ключ для соответствующего набора RRSET, подписываемого закрытым ключом родителя. Такая иерархическая структура подписей делает возможным групповое распространение открытых ключей DNSSEC для иерархии серверов имен. Отдельно требуется распространять только открытые ключи корневого уровня, и они могут распространяться так же, как распознаватели получают информацию об IP-адресах корневых серверов имен. В главе 8 мы подробнее остановимся на технологии DNSSEC.

DNS-зоны

На илл. 7.5 показано, какую информацию может содержать типичная запись ресурсов DNS для определенного доменного имени. Здесь представлена часть базы данных (гипотетической) для домена cs.vu.nl (см. илл. 7.1), которую часто называют файлом DNS-зоны (DNS zone file), или просто DNS-зоной (DNS zone). Данный файл зоны содержит семь типов записей ресурсов.

Первая незакомментированная строка листинга на илл. 7.5 содержит базовую информацию о домене, которая для нас не важна. Далее две строки указывают на два хоста, на которые нужно попытаться доставить электронную почту для person@cs.vu.nl. Сначала следует связаться с хостом zephyr. В случае неудачи следует попробовать доставить письмо хосту top. Следующая строка задает в качестве сервера имен домена хост star.

После пустой строки, добавленной для удобства чтения, следуют строки, сообщающие IP-адреса хостов star, zephyr и top. Затем следует псевдоним www.cs.vu.nl, позволяющий не обращаться к какому-то конкретному компьютеру. Создание этого псевдонима позволяет домену cs.vu.nl изменять свой веб-сервер, не меняя адрес, по которому люди к нему обращаются. С той же целью в следующей строке создается псевдоним ftp.cs.vu.nl для FTP-сервера.

; Authoritative data for cs.vu.nl

cs.vu.nl. 86400 IN SOA star boss (9527,7200,7200,241920,86400)

cs.vu.nl. 86400 IN MX 1 zephyr

cs.vu.nl. 86400 IN MX 2 top

cs.vu.nl. 86400 IN NS star

star 86400 IN A 130.37.56.205

zephyr 86400 IN A 130.37.20.10

top 86400 IN A 130.37.20.11

www 86400 IN CNAME star.cs.vu.nl

ftp 86400 IN CNAME zephyr.cs.vu.nl

flits 86400 IN A 130.37.16.112

flits 86400 IN A 192.31.231.165

flits 86400 IN MX 1 flits

flits 86400 IN MX 2 zephyr

flits 86400 IN MX 3 top

rowboat IN A 130.37.56.201

IN MX 1 rowboat

IN MX 2 zephyr

little-sister IN A 130.37.62.23

laserjet IN A 192.31.231.216

Илл. 7.5. Часть гипотетической базы данных DNS (файла зоны) домена cs.vu.nl

В секции, относящейся к хосту flits, указаны два IP-адреса и три возможных варианта адреса для обработки почты, направляемой на адрес flits.cs.vu.nl. Разу­меется, прежде всего нужно попробовать доставить письмо самому хосту flits. Но если он выключен, необходимо обратиться к хостам zephyr и top.

Следующие три строки содержат типичные записи для компьютера, в данном случае для 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-трафика требуется и для многих услуг, предлагаемых провайдерами, например для родительского контроля.

В итоге мы имеем дело с двумя не зависящими друг от друга проблемами. Одна из них — смещение 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. Например, создание домена ххх заняло несколько лет и повлекло за собой несколько судебных разбирательств. Размещение контента для взрослых на отдельном домене — это хорошо или плохо? (Многие хотели вообще запретить публикацию подобных материалов в интернете; другая точка зрения сводилась к тому, что лучше выделить для них отдельный домен, чтобы облегчить их поиск и блокировку для фильтров родительского контроля.) Некоторые домены самоорганизуются, другие имеют ограничения в отношении того, кто может получить имя (см. илл. 7.2). Вопрос в том, какие ограничения оправданны. Возьмем для примера домен pro, предназначенный для квалифицированных специалистов. Кто именно является таким специалистом? Врачи и адвокаты точно входят в эту категорию. А что насчет самозанятых фотографов, учителей музыки, фокусников, сантехников, парикмахеров, дезинсекторов, татуировщиков, наемников и проституток? Можно ли отнести к этой категории представителей данных профессий? И кто должен это определять?

Также можно зарабатывать на именах доменов. Например, Тувалу, небольшая островная страна между Гавайями и Австралией, сдала в аренду права на свой домен tv за $50 млн, так как он отлично подходит для телевизионных сайтов. Практически все общеупотребительные английские слова используются в качестве имен поддоменов com (вместе с самыми распространенными опечатками). Попробуйте набрать любое слово, касающееся домашнего хозяйства, животных, растений, частей тела и т.д. Регистрация доменных имен с целью их выгодной перепродажи заинтересованной стороне даже получила специальное название — киберсквоттинг (cybersquatting). Не успев зарегистрироваться в начале эры интернета, многие компании обнаружили, что самые очевидные доменные имена уже заняты. В целом, если не были нарушены права на товарный знак и не было замечено мошенничества, здесь работает правило «кто не успел, тот опоздал». Но политика разрешения споров по поводу имен доменов пока еще не устоялась.