Система доменных имен ( DNS ) — это иерархическая и распределенная служба имен , которая предоставляет систему именования для компьютеров , служб и других ресурсов в Интернете или других сетях Интернет-протокола (IP). Она связывает различную информацию с доменными именами ( идентификационными строками ), назначенными каждому из связанных объектов. Наиболее заметно, что она преобразует легко запоминаемые доменные имена в числовые IP-адреса, необходимые для обнаружения и идентификации компьютерных служб и устройств с помощью базовых сетевых протоколов . [1] Система доменных имен является важным компонентом функциональности Интернета с 1985 года.
Система доменных имен делегирует ответственность за назначение доменных имен и сопоставление этих имен с интернет-ресурсами, назначая авторитетные серверы имен для каждого домена. Сетевые администраторы могут делегировать полномочия над поддоменами своего выделенного пространства имен другим серверам имен. Этот механизм обеспечивает распределенный и отказоустойчивый сервис и был разработан, чтобы избежать единой большой центральной базы данных. Кроме того, DNS определяет техническую функциональность службы базы данных , которая лежит в ее основе. Она определяет протокол DNS, подробную спецификацию структур данных и обменов данными, используемых в DNS, как часть набора интернет-протоколов .
Интернет поддерживает два основных пространства имен : иерархию доменных имен и пространства IP-адресов . [2] Система доменных имен поддерживает иерархию доменных имен и предоставляет услуги перевода между ней и адресными пространствами. Серверы имен Интернета и протокол связи реализуют систему доменных имен. Сервер имен DNS — это сервер, который хранит записи DNS для домена; сервер имен DNS отвечает ответами на запросы к своей базе данных.
Наиболее распространенными типами записей, хранящихся в базе данных DNS, являются начало полномочий ( SOA ), IP-адреса ( A и AAAA ), почтовые обменники SMTP (MX), серверы имен (NS), указатели для обратного поиска DNS (PTR) и псевдонимы доменных имен (CNAME). Хотя DNS не предназначена для использования в качестве базы данных общего назначения, со временем она была расширена для хранения записей для других типов данных либо для автоматического поиска, например, записей DNSSEC , либо для запросов человека, например, записей ответственного лица (RP). Как база данных общего назначения, DNS также использовалась для борьбы с нежелательной электронной почтой (спамом) путем хранения списка черных дыр в реальном времени (RBL). База данных DNS традиционно хранится в структурированном текстовом файле, файле зоны , но распространены и другие системы баз данных.
Первоначально система доменных имен использовала протокол пользовательских датаграмм (UDP) в качестве транспорта по IP. Вопросы надежности, безопасности и конфиденциальности породили использование протокола управления передачей (TCP), а также многочисленные другие разработки протоколов.
Часто используемая аналогия для объяснения DNS заключается в том, что он служит телефонной книгой для Интернета, преобразуя понятные человеку имена хостов компьютеров в IP-адреса. Например, имя хоста www.example.comв доменном имени example.com преобразуется в адреса 93.184.216.34 ( IPv4 ) и 2606:2800:220:1:248:1893:25c8:1946 ( IPv6 ). DNS можно быстро и прозрачно обновить, что позволяет изменять местоположение сервиса в сети, не влияя на конечных пользователей, которые продолжают использовать то же имя хоста. Пользователи пользуются этим, когда используют осмысленные унифицированные указатели ресурсов ( URL ) и адреса электронной почты , не зная, как компьютер на самом деле находит сервисы.
Важной и повсеместной функцией DNS является ее центральная роль в распределенных интернет-сервисах, таких как облачные сервисы и сети доставки контента . [3] Когда пользователь получает доступ к распределенному интернет-сервису с помощью URL, доменное имя URL транслируется в IP-адрес сервера, который находится ближе всего к пользователю. Ключевая функциональность DNS, используемая здесь, заключается в том, что разные пользователи могут одновременно получать разные переводы для одного и того же доменного имени, что является ключевым моментом расхождения с традиционным представлением DNS как телефонной книги. Этот процесс использования DNS для назначения пользователям проксимальных серверов является ключом к предоставлению более быстрых и надежных ответов в Интернете и широко используется большинством основных интернет-сервисов. [4]
DNS отражает структуру административной ответственности в Интернете. [5] Каждый поддомен представляет собой зону административной автономии, делегированную менеджеру. Для зон, управляемых реестром , административная информация часто дополняется службами RDAP и WHOIS реестра . Эти данные могут использоваться для получения информации и отслеживания ответственности за определенный хост в Интернете. [6]
Использование более простого, более запоминающегося имени вместо числового адреса хоста восходит к эпохе ARPANET . Стэнфордский исследовательский институт (теперь SRI International ) поддерживал текстовый файл HOSTS.TXT , который сопоставлял имена хостов с числовыми адресами компьютеров в ARPANET. [7] [8] Элизабет Файнлер разработала и поддерживала первый каталог ARPANET. [9] [10] Поддержанием числовых адресов, называемых списком назначенных номеров, занимался Джон Постел из Института информационных наук (ISI) Университета Южной Калифорнии , чья команда тесно сотрудничала с SRI. [11]
Адреса назначались вручную. Компьютеры, включая их имена хостов и адреса, добавлялись в основной файл путем обращения в сетевой информационный центр SRI (NIC), которым руководила Файнлер, по телефону в рабочее время. [12] Позже Файнлер создала каталог WHOIS на сервере в NIC для извлечения информации о ресурсах, контактах и сущностях. [13] Она и ее команда разработали концепцию доменов. [13] Файнлер предложила, чтобы домены основывались на местоположении физического адреса компьютера. [14] Например, компьютеры в образовательных учреждениях имели домен edu . [15] Она и ее команда управляли реестром имен хостов с 1972 по 1989 год. [16]
К началу 1980-х годов поддержание единой централизованной таблицы хостов стало медленным и громоздким, а развивающаяся сеть требовала автоматизированной системы именования для решения технических и кадровых проблем. Постел поручил Полу Мокапетрису задачу по нахождению компромисса между пятью конкурирующими предложениями решений . Вместо этого Мокапетрис создал систему доменных имен в 1983 году, работая в Университете Южной Калифорнии . [12] [17]
Целевая группа по инжинирингу Интернета опубликовала оригинальные спецификации в RFC 882 и RFC 883 в ноябре 1983 года. [18] [19] Они были обновлены в RFC 973 в январе 1986 года.
В 1984 году четыре студента Калифорнийского университета в Беркли , Дуглас Терри, Марк Пейнтер, Дэвид Риггл и Соннянь Чжоу, написали первую реализацию сервера имен Unix для домена имен Интернета в Беркли, обычно называемого BIND . [20] В 1985 году Кевин Данлэп из DEC существенно переработал реализацию DNS. Затем Майк Карелс , Фил Альмквист и Пол Викси взяли на себя поддержку BIND. Консорциум Internet Systems был основан в 1994 году Риком Адамсом , Полом Викси и Карлом Маламудом специально для того, чтобы предоставить дом для разработки и поддержки BIND. Версии BIND, начиная с 4.9.3, разрабатывались и поддерживались ISC при поддержке спонсоров ISC. Как соавторы-архитекторы/программисты, Боб Хэлли и Пол Викси выпустили первую готовую к производству версию BIND версии 8 в мае 1997 года. С 2000 года над BIND работали более 43 различных разработчиков ядра. [21]
В ноябре 1987 года RFC 1034 [22] и RFC 1035 [5] заменили спецификации DNS 1983 года. Несколько дополнительных запросов на комментарии предложили расширения основных протоколов DNS. [23]
Пространство доменных имен состоит из древовидной структуры данных . Каждый узел или лист в дереве имеет метку и ноль или более записей ресурсов (RR), которые содержат информацию, связанную с доменным именем. Само доменное имя состоит из метки, соединенной с именем его родительского узла справа, разделенного точкой. [24]
Дерево подразделяется на зоны, начиная с корневой зоны . Зона DNS может состоять из стольких доменов и поддоменов, сколько выберет менеджер зоны. DNS также может быть разделена по классам , где отдельные классы можно рассматривать как массив параллельных деревьев пространств имен. [25]
Административная ответственность за любую зону может быть разделена путем создания дополнительных зон. Полномочия над новой зоной, как говорят, делегируются назначенному серверу имен. Родительская зона перестает быть полномочной для новой зоны. [25]
Окончательные описания правил формирования доменных имен содержатся в RFC 1035, RFC 1123, RFC 2181 и RFC 5892. Доменное имя состоит из одной или нескольких частей, технически называемых метками , которые традиционно объединяются и разделяются точками, например example.com.
Самая правая метка указывает на домен верхнего уровня ; например, доменное имя www.example.com принадлежит домену верхнего уровня com .
Иерархия доменов спускается справа налево; каждая метка слева определяет подразделение или поддомен домена справа. Например, метка example определяет поддомен домена com , а www является поддоменом example.com. Это дерево подразделов может иметь до 127 уровней. [26]
Метка может содержать от нуля до 63 символов, поскольку длина может составлять только 6 бит. Нулевая метка нулевой длины зарезервирована для корневой зоны. Полное доменное имя не может превышать длину 253 символов в текстовом представлении (или 254 с конечной точкой). [22] Во внутреннем двоичном представлении DNS эта максимальная длина 253 требует 255 октетов памяти, поскольку она также хранит длину первой из многих меток и добавляет последний нулевой байт. [5] Длина 255 достигается только при наличии не менее 6 меток (с учетом последней нулевой метки). [ необходима цитата ]
Хотя не существует технических ограничений, запрещающих меткам доменных имен использовать любые символы, которые можно представить октетом, имена хостов используют предпочтительный формат и набор символов. Символы, разрешенные в метках, являются подмножеством набора символов ASCII , состоящего из символов от a до z , от A до Z , цифр от 0 до 9 и дефиса. Это правило известно как правило LDH (буквы, цифры, дефис). Доменные имена интерпретируются независимо от регистра. [27] Метки не могут начинаться или заканчиваться дефисом. [28] Дополнительное правило требует, чтобы доменные имена верхнего уровня не были полностью цифровыми. [28]
Ограниченный набор символов ASCII, разрешенных в DNS, не позволял отображать имена и слова многих языков в их родных алфавитах или сценариях. Чтобы сделать это возможным, ICANN одобрила систему интернационализации доменных имен в приложениях (IDNA), с помощью которой пользовательские приложения, такие как веб-браузеры, сопоставляют строки Unicode с допустимым набором символов DNS с помощью Punycode . В 2009 году ICANN одобрила установку интернационализированных доменных имен с кодом страны верхнего уровня ( ccTLD ) . Кроме того, многие реестры существующих доменных имен верхнего уровня ( TLD ) приняли систему IDNA, руководствуясь RFC 5890, RFC 5891, RFC 5892, RFC 5893.
Система доменных имен поддерживается распределенной системой баз данных, которая использует модель клиент-сервер . Узлами этой базы данных являются серверы имен . Каждый домен имеет по крайней мере один авторитетный DNS-сервер, который публикует информацию об этом домене и серверах имен всех подчиненных ему доменов. Верхнюю часть иерархии обслуживают корневые серверы имен , серверы для запроса при поиске ( разрешении ) TLD .
Авторитетный сервер имен — это сервер имен, который дает ответы на запросы DNS только на основе данных, настроенных исходным источником, например, администратором домена или с помощью динамических методов DNS, в отличие от ответов, полученных с помощью запроса к другому серверу имен, который только поддерживает кэш данных.
Авторитетный сервер имен может быть как первичным , так и вторичным сервером. Исторически термины «главный/ведомый» и «первичный/вторичный» иногда использовались взаимозаменяемо [29], но в настоящее время используется последняя форма. Первичный сервер — это сервер, который хранит оригинальные копии всех записей зоны. Вторичный сервер использует специальный механизм автоматического обновления в протоколе DNS в связи со своим первичным сервером для поддержания идентичной копии первичных записей.
Каждой зоне DNS должен быть назначен набор авторитетных серверов имен. Этот набор серверов хранится в родительской доменной зоне с записями серверов имен (NS).
Авторитетный сервер указывает свой статус предоставления окончательных ответов, считающихся авторитетными , устанавливая флаг протокола, называемый битом « Авторитетный ответ » ( AA ) в своих ответах. [5] Этот флаг обычно воспроизводится на видном месте в выходных данных инструментов запросов администрирования DNS, таких как dig , чтобы указать , что отвечающий сервер имен является авторитетным для рассматриваемого доменного имени. [5]
Когда сервер имен назначается в качестве полномочного сервера для доменного имени, для которого у него нет полномочных данных, возникает тип ошибки, называемый «некорректным делегированием» или «некорректным ответом». [30] [31]
Резолверы доменных имен определяют серверы доменных имен, ответственные за рассматриваемое доменное имя, с помощью последовательности запросов, начиная с самой правой (верхнего уровня) доменной метки.
Для правильной работы своего преобразователя доменных имен сетевой хост настраивается с начальным кэшем ( подсказками ) известных адресов корневых серверов имен. Подсказки периодически обновляются администратором путем извлечения набора данных из надежного источника.
Если предположить, что у резолвера нет кэшированных записей для ускорения процесса, процесс разрешения начинается с запроса к одному из корневых серверов. В типичной работе корневые серверы не отвечают напрямую, а отвечают ссылкой на более авторитетные серверы, например, запрос для "www.wikipedia.org" направляется на серверы org . Теперь резолвер запрашивает серверы, на которые он ссылается, и итеративно повторяет этот процесс, пока не получит авторитетный ответ. На схеме этот процесс проиллюстрирован для хоста, который назван полным доменным именем "www.wikipedia.org".
Этот механизм возложил бы большую нагрузку на трафик на корневые серверы, если бы каждое разрешение в Интернете требовало начинать с корня. На практике кэширование используется в DNS-серверах для разгрузки корневых серверов, и в результате корневые серверы имен фактически участвуют только в относительно небольшой части всех запросов.
Теоретически, авторитетных серверов имен достаточно для работы Интернета. Однако, при работе только авторитетных серверов имен, каждый запрос DNS должен начинаться с рекурсивных запросов в корневой зоне системы доменных имен, и каждая пользовательская система должна будет реализовать программное обеспечение-резолвер, способное к рекурсивным операциям. [32]
Для повышения эффективности, сокращения трафика DNS в Интернете и повышения производительности в приложениях конечных пользователей система доменных имен поддерживает серверы кэширования DNS, которые хранят результаты запросов DNS в течение периода времени, определенного в конфигурации ( время жизни ) рассматриваемой записи доменного имени. Обычно такие серверы кэширования DNS также реализуют рекурсивный алгоритм, необходимый для разрешения заданного имени, начиная с корня DNS и заканчивая авторитетными серверами имен запрашиваемого домена. Благодаря реализации этой функции на сервере имен пользовательские приложения становятся более эффективными в разработке и эксплуатации.
Сочетание кэширования DNS и рекурсивных функций на сервере имен не является обязательным; функции могут быть реализованы независимо на серверах специального назначения.
Интернет-провайдеры обычно предоставляют своим клиентам рекурсивные и кэширующие серверы имен. Кроме того, многие домашние сетевые маршрутизаторы реализуют кэширование DNS и рекурсию для повышения эффективности локальной сети.
Клиентская сторона DNS называется DNS-резолвером. Резолвер отвечает за инициирование и упорядочивание запросов, которые в конечном итоге приводят к полному разрешению (трансляции) искомого ресурса, например, трансляции доменного имени в IP-адрес. DNS-резолверы классифицируются по различным методам запросов, таким как рекурсивные , нерекурсивные и итеративные . Процесс разрешения может использовать комбинацию этих методов. [22]
В нерекурсивном запросе DNS-резолвер запрашивает DNS-сервер, который предоставляет запись, для которой сервер является полномочным, или предоставляет частичный результат без запроса других серверов. В случае кэширующего DNS-резолвера нерекурсивный запрос его локального DNS-кеша предоставляет результат и снижает нагрузку на вышестоящие DNS-серверы путем кэширования записей ресурсов DNS на определенный период времени после первоначального ответа от вышестоящих DNS-серверов.
В рекурсивном запросе DNS-резолвер запрашивает один DNS-сервер, который, в свою очередь, может запрашивать другие DNS-серверы от имени запрашивающей стороны. Например, простой заглушечный резолвер, работающий на домашнем маршрутизаторе, обычно делает рекурсивный запрос к DNS-серверу, запущенному интернет-провайдером пользователя . Рекурсивный запрос — это тот, на который DNS-сервер полностью отвечает, запрашивая другие серверы имен по мере необходимости. При типичной работе клиент отправляет рекурсивный запрос кэширующему рекурсивному DNS-серверу, который впоследствии отправляет нерекурсивные запросы для определения ответа и отправки одного ответа обратно клиенту. Резолвер или другой DNS-сервер, действующий рекурсивно от имени резольвера, договаривается об использовании рекурсивной службы с помощью битов в заголовках запроса. DNS-серверы не обязаны поддерживать рекурсивные запросы.
Процедура итеративного запроса — это процесс, в котором DNS-резолвер запрашивает цепочку из одного или нескольких DNS-серверов. Каждый сервер направляет клиента на следующий сервер в цепочке, пока текущий сервер не сможет полностью разрешить запрос. Например, возможное разрешение www.example.com запросит глобальный корневой сервер, затем сервер "com" и, наконец, сервер "example.com".
Серверы имен в делегировании идентифицируются по имени, а не по IP-адресу. Это означает, что разрешающий сервер имен должен выдать еще один DNS-запрос, чтобы узнать IP-адрес сервера, на который он был направлен. Если имя, указанное в делегировании, является поддоменом домена, для которого предоставляется делегирование, то имеет место циклическая зависимость .
В этом случае сервер имен, предоставляющий делегирование, должен также предоставить один или несколько IP-адресов для уполномоченного сервера имен, упомянутого в делегировании. Эта информация называется Glue . Делегирующий сервер имен предоставляет этот Glue в виде записей в дополнительном разделе ответа DNS и предоставляет делегирование в разделе полномочий ответа. Glue-запись представляет собой комбинацию сервера имен и IP-адреса.
Например, если полномочный сервер имен для example.org — ns1.example.org, компьютер, пытающийся разрешить www.example.org, сначала разрешает ns1.example.org. Поскольку ns1 содержится в example.org, для этого требуется сначала разрешить example.org, что представляет собой циклическую зависимость. Чтобы разорвать зависимость, сервер имен для домена верхнего уровня org включает клей вместе с делегированием для example.org. Клеевые записи — это адресные записи, которые предоставляют IP-адреса для ns1.example.org. Резолвер использует один или несколько из этих IP-адресов для запроса одного из полномочных серверов домена, что позволяет ему выполнить DNS-запрос.
Распространенным подходом к снижению нагрузки на DNS-серверы является кэширование результатов разрешения имен локально или на промежуточных хостах-резолверах. Каждый результат DNS-запроса имеет время жизни (TTL), которое указывает, как долго информация остается действительной, прежде чем ее нужно будет удалить или обновить. Это TTL определяется администратором авторитетного DNS-сервера и может варьироваться от нескольких секунд до нескольких дней или даже недель. [33]
В результате этой распределенной архитектуры кэширования изменения в записях DNS не распространяются по всей сети немедленно, а требуют истечения срока действия всех кэшей и их обновления по истечении TTL. RFC 1912 передает основные правила для определения соответствующих значений TTL.
Некоторые резолверы могут переопределять значения TTL, так как протокол поддерживает кэширование до шестидесяти восьми лет или вообще не кэширует. Отрицательное кэширование , т. е. кэширование факта отсутствия записи, определяется серверами имен, уполномоченными для зоны, которые должны включать запись Start of Authority (SOA) при сообщении об отсутствии данных запрошенного типа. Значение минимального поля записи SOA и TTL самого SOA используются для установления TTL для отрицательного ответа.
Обратный поиск DNS — это запрос DNS на доменные имена, когда известен IP-адрес. С IP-адресом может быть связано несколько доменных имен. DNS хранит IP-адреса в форме доменных имен как специально отформатированные имена в записях указателей (PTR) в домене верхнего уровня инфраструктуры arpa . Для IPv4 доменом является in-addr.arpa. Для IPv6 доменом обратного поиска является ip6.arpa. IP-адрес представлен как имя в обратном порядке октетного представления для IPv4 и обратном порядке полубайтного представления для IPv6.
При выполнении обратного поиска DNS-клиент преобразует адрес в эти форматы перед запросом имени для записи PTR, следуя цепочке делегирования, как и для любого DNS-запроса. Например, предположим, что адрес IPv4 208.80.152.2 назначен Wikimedia, он представлен как имя DNS в обратном порядке: 2.152.80.208.in-addr.arpa. Когда DNS-резолвер получает запрос указателя (PTR), он начинает с запроса корневых серверов, которые указывают на серверы Американского реестра интернет-номеров (ARIN) для зоны 208.in-addr.arpa. Серверы ARIN делегируют 152.80.208.in-addr.arpa в Wikimedia, на которую резолвер отправляет другой запрос для 2.152.80.208.in-addr.arpa, что приводит к авторитетному ответу.
Пользователи обычно не взаимодействуют напрямую с DNS-резолвером. Вместо этого DNS-разрешение происходит прозрачно в таких приложениях, как веб-браузеры , почтовые клиенты и другие интернет-приложения. Когда приложение делает запрос, требующий поиска доменного имени, такие программы отправляют запрос на разрешение DNS -резолверу в локальной операционной системе, который, в свою очередь, обрабатывает требуемые коммуникации.
DNS-резолвер почти всегда будет иметь кэш (см. выше), содержащий последние поиски. Если кэш может предоставить ответ на запрос, резольвер вернет значение в кэше программе, которая сделала запрос. Если кэш не содержит ответа, резольвер отправит запрос на один или несколько назначенных DNS-серверов. В случае большинства домашних пользователей поставщик интернет-услуг, к которому подключается машина, обычно предоставляет этот DNS-сервер: такой пользователь либо настроил адрес этого сервера вручную, либо разрешил DHCP установить его; однако, когда системные администраторы настроили системы на использование собственных DNS-серверов, их DNS-резолверы указывают на отдельно поддерживаемые серверы имен организации. В любом случае, запрошенный таким образом сервер имен будет следовать процессу, описанному выше, пока он либо успешно не найдет результат, либо нет. Затем он возвращает свои результаты DNS-резолверу; предполагая, что он нашел результат, резольвер должным образом кэширует этот результат для будущего использования и возвращает результат программному обеспечению, которое инициировало запрос.
Некоторые крупные интернет-провайдеры настроили свои DNS-серверы так, чтобы они нарушали правила, например, не соблюдая TTL или указывая, что доменное имя не существует, просто потому, что один из его серверов имен не отвечает. [34]
Некоторые приложения, такие как веб-браузеры, поддерживают внутренний кэш DNS, чтобы избежать повторных поисков через сеть. Эта практика может добавить дополнительные трудности при отладке проблем DNS, поскольку она скрывает историю таких данных. Эти кэши обычно используют очень короткое время кэширования, порядка одной минуты. [35]
Internet Explorer представляет собой заметное исключение: версии до IE 3.x по умолчанию кэшируют записи DNS на 24 часа. Internet Explorer 4.x и более поздние версии (до IE 8) уменьшают значение тайм-аута по умолчанию до получаса, которое можно изменить, изменив конфигурацию по умолчанию. [36]
Когда Google Chrome обнаруживает проблемы с DNS-сервером, он отображает определенное сообщение об ошибке.
Система доменных имен включает в себя ряд других функций и возможностей.
Имена хостов и IP-адреса не обязательно должны совпадать в отношении один к одному. Несколько имен хостов могут соответствовать одному IP-адресу, что полезно при виртуальном хостинге , когда множество веб-сайтов обслуживаются с одного хоста. В качестве альтернативы одно имя хоста может разрешаться во множество IP-адресов для обеспечения отказоустойчивости и распределения нагрузки на несколько экземпляров серверов в масштабах предприятия или глобального Интернета.
DNS служит и другим целям, помимо преобразования имен в IP-адреса. Например, агенты пересылки почты используют DNS для поиска лучшего почтового сервера для доставки электронной почты : запись MX обеспечивает сопоставление между доменом и почтовым обменником; это может обеспечить дополнительный уровень отказоустойчивости и распределения нагрузки.
DNS используется для эффективного хранения и распространения IP-адресов хостов электронной почты, занесенных в черный список. Распространенный метод заключается в том, чтобы поместить IP-адрес хоста субъекта в поддомен доменного имени более высокого уровня и разрешить это имя в запись, которая указывает на положительный или отрицательный признак.
Например:
Почтовые серверы могут запрашивать blacklist.example, чтобы узнать, находится ли в черном списке определенный хост, подключающийся к ним. Многие из таких черных списков, как на основе подписки, так и бесплатные, доступны для использования администраторами электронной почты и антиспамовым программным обеспечением.
Для обеспечения устойчивости в случае сбоя компьютера или сети обычно предоставляется несколько DNS-серверов для покрытия каждого домена. На верхнем уровне глобального DNS существует тринадцать групп корневых серверов имен , с дополнительными «копиями» из них, распределенными по всему миру посредством anycast- адресации.
Динамический DNS (DDNS) обновляет DNS-сервер с помощью IP-адреса клиента «на лету», например, при перемещении между интернет-провайдерами или мобильными точками доступа , или когда IP-адрес изменяется административно.
Протокол DNS использует два типа сообщений DNS, запросы и ответы; оба имеют одинаковый формат. Каждое сообщение состоит из заголовка и четырех разделов: вопрос, ответ, полномочия и дополнительный пробел. Поле заголовка ( флаги ) управляет содержимым этих четырех разделов. [22]
Раздел заголовка состоит из следующих полей: Идентификация , Флаги , Количество вопросов , Количество ответов , Количество записей ресурсов полномочий (RR) и Количество дополнительных RR . Каждое поле имеет длину 16 бит и отображается в указанном порядке. Поле идентификации используется для сопоставления ответов с запросами. Поле флага состоит из следующих подполей:
После слова флагов заголовок заканчивается четырьмя 16-битными целыми числами, которые содержат количество записей в каждом из последующих разделов в том же порядке.
Раздел вопросов имеет более простой формат, чем формат записи ресурса, используемый в других разделах. Каждая запись вопроса (обычно только одна в разделе) содержит следующие поля:
Доменное имя разбивается на отдельные метки, которые объединяются; каждая метка имеет префикс в виде длины этой метки. [38]
Система доменных имен определяет базу данных информационных элементов для сетевых ресурсов. Типы информационных элементов категоризируются и организуются с помощью списка типов записей DNS , записей ресурсов (RR). Каждая запись имеет тип (имя и номер), время истечения срока действия ( время жизни ), класс и данные, специфичные для типа. Записи ресурсов одного типа описываются как набор записей ресурсов (RRset), не имеющий специального порядка. DNS-резолверы возвращают весь набор по запросу, но серверы могут реализовывать циклический порядок для достижения балансировки нагрузки . Напротив, расширения безопасности системы доменных имен (DNSSEC) работают с полным набором записей ресурсов в каноническом порядке.
При отправке по сети Интернет-протокола все записи (ответ, полномочия и дополнительные разделы) используют общий формат, указанный в RFC 1035: [39]
ИМЯ — это полное доменное имя узла в дереве. [ требуется пояснение ] На линии имя может быть сокращено с помощью сжатия меток, при котором окончания доменных имен, упомянутых ранее в пакете, могут быть заменены на окончание текущего доменного имени.
TYPE — тип записи. Он указывает формат данных и дает подсказку об их предполагаемом использовании. Например, запись A используется для перевода доменного имени в адрес IPv4 , запись NS перечисляет, какие серверы имен могут отвечать на запросы в зоне DNS , а запись MX указывает почтовый сервер, используемый для обработки почты для домена, указанного в адресе электронной почты.
RDATA — это данные, имеющие типоспецифическую релевантность, например IP-адрес для записей адресов или приоритет и имя хоста для записей MX. Известные типы записей могут использовать сжатие меток в поле RDATA, но «неизвестные» типы записей не должны (RFC 3597).
CLASS записи устанавливается на IN (для Internet ) для общих записей DNS, включающих имена хостов Интернета, серверы или IP-адреса. Кроме того, существуют классы Chaos (CH) и Hesiod (HS). [40] Каждый класс представляет собой независимое пространство имен с потенциально различными делегированиями зон DNS.
Помимо записей ресурсов, определенных в файле зоны , система доменных имен также определяет несколько типов запросов, которые используются только при взаимодействии с другими узлами DNS ( по сети ), например, при выполнении переносов зон (AXFR/IXFR) или для EDNS (OPT).
Система доменных имен поддерживает подстановочные записи DNS , которые указывают имена, начинающиеся с метки звездочки , *, например, *.example. [22] [41] Записи DNS, принадлежащие подстановочным доменным именам, определяют правила для создания записей ресурсов в пределах одной зоны DNS путем замены целых меток соответствующими компонентами имени запроса, включая любых указанных потомков. Например, в следующей конфигурации зона DNS x.example указывает, что все поддомены, включая поддомены поддоменов, x.example используют почтовый обменник (MX) axexample . Запись A для axexample необходима для указания IP-адреса почтового обменника. Поскольку это приводит к исключению этого доменного имени и его поддоменов из подстановочных совпадений, в зоне DNS также должны быть определены дополнительная запись MX для поддомена axexample , а также подстановочная запись MX для всех его поддоменов.
x.пример. MX 10 a.x.пример. *.x.пример. MX 10 a.x.пример. *.axпример. MX 10 a.x.пример. axпример. MX 10 a.x.пример. axпример. AAAA 2001:db8::1 Роль записей с подстановочными знаками была уточнена в RFC 4592, поскольку первоначальное определение в RFC 1034 было неполным и приводило к неправильному толкованию со стороны разработчиков. [41]
Первоначальный протокол DNS имел ограниченные возможности для расширения новыми функциями. В 1999 году Пол Викси опубликовал в RFC 2671 (замененном RFC 6891) механизм расширения, названный Extension Mechanisms for DNS (EDNS), который ввел необязательные элементы протокола без увеличения накладных расходов, когда они не используются. Это было достигнуто с помощью записи псевдоресурса OPT, которая существует только в проводных передачах протокола, но не в каких-либо файлах зоны. Также были предложены начальные расширения (EDNS0), такие как увеличение размера сообщения DNS в датаграммах UDP.
Динамические обновления DNS используют код операции UPDATE DNS для динамического добавления или удаления записей ресурсов из базы данных зоны, поддерживаемой на авторитетном сервере DNS. [42] Эта возможность полезна для регистрации сетевых клиентов в DNS, когда они загружаются или иным образом становятся доступными в сети. Поскольку загружающемуся клиенту может каждый раз назначаться другой IP-адрес с сервера DHCP , невозможно предоставить статические назначения DNS для таких клиентов.
С момента своего возникновения в 1983 году DNS использовал протокол пользовательских датаграмм (UDP) для транспортировки по IP. Его ограничения мотивировали многочисленные разработки протоколов для надежности, безопасности, конфиденциальности и других критериев в последующие десятилетия.
UDP резервирует порт номер 53 для серверов, прослушивающих запросы. [5] Такие запросы состоят из открытого текстового запроса, отправленного в одном пакете UDP от клиента, на который сервер отвечает открытым текстовым ответом, отправленным в одном пакете UDP. Когда длина ответа превышает 512 байт, и и клиент, и сервер поддерживают механизмы расширения для DNS (EDNS), могут использоваться более крупные пакеты UDP. [43] Использование DNS по UDP ограничено, среди прочего, отсутствием шифрования на транспортном уровне, аутентификации, надежной доставки и длины сообщения. В 1989 году RFC 1123 определил необязательный транспорт протокола управления передачей (TCP) для запросов DNS, ответов и, в частности, переносов зон . Благодаря фрагментации длинных ответов TCP обеспечивает более длинные ответы, надежную доставку и повторное использование долгоживущих соединений между клиентами и серверами. Для более крупных ответов сервер направляет клиента на транспорт TCP.
DNS поверх TLS появился как стандарт IETF для зашифрованного DNS в 2016 году, использующий Transport Layer Security (TLS) для защиты всего соединения, а не только полезной нагрузки DNS. Серверы DoT прослушивают порт TCP 853. RFC 7858 указывает, что могут поддерживаться оппортунистическое шифрование и аутентифицированное шифрование, но не делает аутентификацию сервера или клиента обязательной.
DNS через HTTPS был разработан как конкурирующий стандарт для передачи DNS-запросов в 2018 году, туннелируя данные DNS-запросов через HTTPS, который передает HTTP через TLS. DoH продвигался как более удобная для веб-сайтов альтернатива DNS, поскольку, как и DNSCrypt, он использует TCP-порт 443 и, таким образом, выглядит похожим на веб-трафик, хотя на практике их легко различить без надлежащего заполнения. [44]
RFC 9250, опубликованный в 2022 году Internet Engineering Task Force , описывает DNS over QUIC . Он имеет «свойства конфиденциальности, аналогичные DNS over TLS (DoT) [...], и характеристики задержки, аналогичные классическому DNS over UDP». Этот метод не то же самое, что DNS over HTTP/3 . [45]
Oblivious DNS (ODNS) был изобретен и реализован исследователями Принстонского университета и Чикагского университета как расширение незашифрованного DNS, [46] до того, как DoH был стандартизирован и широко распространен. Apple и Cloudflare впоследствии развернули технологию в контексте DoH, как Oblivious DoH (ODoH). [47] ODoH объединяет разделение входящего/исходящего трафика (изобретенное в ODNS) с туннелированием HTTPS DoH и шифрованием транспортного уровня TLS в одном протоколе. [48]
DNS может работать через виртуальные частные сети (VPN) и протоколы туннелирования . Использование, которое стало обычным с 2019 года, оправдывая его собственную часто используемую аббревиатуру, — DNS через Tor . Преимущества конфиденциальности Oblivious DNS могут быть получены за счет использования уже существующей сети Tor входящих и исходящих узлов в сочетании с шифрованием транспортного уровня, предоставляемым TLS. [49]
Протокол DNSCrypt , разработанный в 2011 году вне рамок стандартов IETF , ввел шифрование DNS на нисходящей стороне рекурсивных резолверов, где клиенты шифруют полезные данные запросов с помощью открытых ключей серверов, которые публикуются в DNS (вместо того, чтобы полагаться на сторонние центры сертификации) и которые, в свою очередь, могут быть защищены подписями DNSSEC. [50] DNSCrypt использует порт TCP или UDP 443, тот же порт, что и зашифрованный веб-трафик HTTPS. Это ввело не только конфиденциальность относительно содержания запроса, но и значительную меру возможности обхода брандмауэра. В 2019 году DNSCrypt был дополнительно расширен для поддержки «анонимного» режима, аналогичного предлагаемому «Oblivious DNS», в котором входной узел получает запрос, который был зашифрован открытым ключом другого сервера, и ретранслирует его на этот сервер, который действует как выходной узел, выполняя рекурсивное разрешение. [51] Конфиденциальность пар пользователь/запрос создается, поскольку входящий узел не знает содержание запроса, в то время как исходящие узлы не знают личность клиента. DNSCrypt был впервые реализован в производстве OpenDNS в декабре 2011 года. Существует несколько бесплатных и открытых реализаций программного обеспечения, которые дополнительно интегрируют ODoH. [52] Он доступен для различных операционных систем, включая Unix, Apple iOS, Linux, Android и Windows.
Первоначально проблемы безопасности не были основными соображениями проектирования программного обеспечения DNS или любого программного обеспечения для развертывания в раннем Интернете, поскольку сеть не была открыта для участия широкой публики. Однако расширение Интернета в коммерческий сектор в 1990-х годах изменило требования к мерам безопасности для защиты целостности данных и аутентификации пользователей .
Несколько уязвимостей были обнаружены и использованы злоумышленниками. Одной из таких проблем является отравление кэша DNS , при котором данные распределяются по кэширующим резолверам под предлогом того, что они являются авторитетным исходным сервером, тем самым загрязняя хранилище данных потенциально ложной информацией и длительным сроком действия (time-to-live). Впоследствии запросы легитимных приложений могут перенаправляться на сетевые хосты, работающие со злым умыслом.
Традиционно ответы DNS не имеют криптографической подписи , что приводит к многочисленным возможностям атак; расширения безопасности системы доменных имен (DNSSEC) изменяют DNS, добавляя поддержку криптографически подписанных ответов. [53] DNSCurve был предложен в качестве альтернативы DNSSEC. Другие расширения, такие как TSIG , добавляют поддержку криптографической аутентификации между доверенными узлами и обычно используются для авторизации операций передачи зоны или динамического обновления.
Некоторые доменные имена могут использоваться для достижения эффекта подмены. Например, paypal.com и paypa1.com — это разные имена, однако пользователи могут не различать их в графическом пользовательском интерфейсе в зависимости от выбранного шрифта пользователя . Во многих шрифтах буква l и цифра 1 выглядят очень похожими или даже идентичными. Эта проблема, известная как атака IDN-омографа , остро стоит в системах, поддерживающих интернационализированные доменные имена , поскольку многие коды символов в ISO 10646 могут выглядеть одинаково на типичных экранах компьютеров. Эта уязвимость иногда используется в фишинге . [54]
Для проверки результатов DNS также можно использовать такие методы, как обратный DNS с подтверждением .
DNS также может «утекать» из защищенных или частных соединений, если не уделять должного внимания их конфигурации, и порой DNS использовался злоумышленниками для обхода брандмауэров и кражи данных, поскольку часто считался безобидным.
Первоначально разработанный как публичная, иерархическая, распределенная и сильно кэшированная база данных, протокол DNS не имеет контроля конфиденциальности. Пользовательские запросы и ответы сервера имен отправляются в незашифрованном виде, что позволяет перехватывать сетевые пакеты , перехватывать DNS , отравление кэша DNS и проводить атаки типа «человек посередине» . Этот недостаток обычно используется киберпреступниками и сетевыми операторами в маркетинговых целях, для аутентификации пользователей на порталах захвата и для цензуры . [55]
Конфиденциальность пользователей еще больше повышается в связи с предложениями по повышению уровня клиентской IP-информации в DNS-запросах (RFC 7871) в интересах сетей доставки контента .
Основные подходы, используемые для решения проблем конфиденциальности с помощью DNS:
Решения, предотвращающие проверку DNS локальным сетевым оператором, критикуются за нарушение политик безопасности корпоративных сетей и цензуры в Интернете. Они также критикуются с точки зрения конфиденциальности, как передача разрешения DNS в руки небольшого числа компаний, известных монетизацией пользовательского трафика и централизацией разрешения имен DNS, что обычно воспринимается как вредное для Интернета. [55]
Google является доминирующим поставщиком платформы в Android , браузера в Chrome и DNS-резолвера в службе 8.8.8.8. Будет ли этот сценарий случаем, когда одна корпоративная организация находится в положении всеобъемлющего контроля над всем пространством имен Интернета? Netflix уже выставил приложение, которое использовало свой собственный механизм разрешения DNS независимо от платформы, на которой приложение работало. Что, если бы приложение Facebook включало DoH? Что, если бы iOS от Apple использовала механизм разрешения DoH для обхода локального разрешения DNS и перенаправляла все DNS-запросы с платформ Apple на набор управляемых Apple резольверов имен?
— Конфиденциальность DNS и IETF
Право на использование доменного имени делегируется регистраторами доменных имен, аккредитованными Корпорацией по управлению доменными именами и IP-адресами (ICANN) или другими организациями, такими как OpenNIC , которые отвечают за надзор за системами имен и номеров Интернета. Помимо ICANN, каждый домен верхнего уровня (TLD) технически поддерживается и обслуживается административной организацией, управляющей реестром. Реестр отвечает за управление базой данных имен в своей авторитетной зоне, хотя этот термин чаще всего используется для TLD. Регистратор — это лицо или организация, которые запросили регистрацию домена. [23] Реестр получает регистрационную информацию от каждого регистратора доменных имен , который уполномочен (аккредитован) назначать имена в соответствующей зоне и публикует информацию с использованием протокола WHOIS . По состоянию на 2015 год рассматривается использование RDAP . [56]
ICANN публикует полный список TLD, реестров TLD и регистраторов доменных имен. Информация о регистрантах, связанная с доменными именами, хранится в онлайн-базе данных, доступной через службу WHOIS. Для большинства из более чем 290 национальных доменов верхнего уровня (ccTLD) реестры доменов хранят информацию WHOIS (регистратор, серверы имен, даты истечения срока действия и т. д.). Например, DENIC , NIC Германии, хранит данные домена DE. Примерно с 2001 года большинство реестров общих доменов верхнего уровня (gTLD) приняли этот так называемый подход «толстого реестра», т. е. хранение данных WHOIS в центральных реестрах вместо баз данных регистраторов.
Для доменов верхнего уровня на COM и NET используется тонкая модель реестра. Реестр доменов (например, GoDaddy , BigRock и PDR , VeriSign и т. д. и т. п.) содержит основные данные WHOIS (т. е. регистратор и серверы имен и т. д.). Организации или регистранты, использующие ORG, с другой стороны, находятся исключительно в Public Interest Registry .
Некоторые реестры доменных имен, часто называемые сетевыми информационными центрами (NIC), также выполняют функции регистраторов для конечных пользователей, в дополнение к предоставлению доступа к наборам данных WHOIS. Реестры доменов верхнего уровня, такие как для доменов COM, NET и ORG, используют модель реестр-регистратор, состоящую из многих регистраторов доменных имен. [57] При этом методе управления реестр управляет только базой данных доменных имен и отношениями с регистраторами. Регистранты ( пользователи доменного имени) являются клиентами регистратора, в некоторых случаях через дополнительный субподряд реселлеров.
Мы исследуем, можно ли отличить трафик DoH от зашифрованного веб-трафика. С этой целью мы обучаем модель машинного обучения для классификации трафика HTTPS как веб-трафика или DoH. Используя нашу модель идентификации DoH, мы показываем, что авторитарный интернет-провайдер может правильно идентифицировать ≈97,4% пакетов DoH, при этом неправильно классифицируя только 1 из 10 000 веб-пакетов.
DNS поверх HTTPS (DoH) устраняет многие, но не все риски, а его транспортный протокол (т. е. HTTPS) вызывает опасения относительно конфиденциальности из-за (например) "cookie-файлов". Сеть Tor существует для предоставления TCP-цепям некоторой свободы от отслеживания, наблюдения и блокировки. Таким образом: в сочетании с Tor, DoH и принципом "Не делай этого, затем" (DDTT) для смягчения отпечатков пальцев запросов я описываю DNS поверх HTTPS поверх Tor (DoHoT).
Эти RFC носят рекомендательный характер, но могут предоставить полезную информацию, несмотря на то, что не определяют ни стандарт, ни BCP. (RFC 1796)
Эти RFC имеют официальный статус «Неизвестно» , но из-за своего возраста не имеют четкой маркировки.
