Страница полузащищенная
Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

Система доменных имен делегирует ответственность за назначение доменных имен и сопоставление этих имен с Интернет-ресурсами путем назначения авторитетных серверов имен для каждого домена. Сетевые администраторы могут делегировать полномочия над поддоменами выделенного им пространства имен другим серверам имен. Этот механизм обеспечивает распределенное и отказоустойчивое обслуживание и был разработан, чтобы избежать единой большой центральной базы данных.

Система доменных имен также определяет технические функции службы базы данных, которая является ее ядром. Он определяет протокол DNS, подробную спецификацию структур данных и обменов данными, используемых в DNS, как часть Internet Protocol Suite .

Интернет поддерживает два основных пространства имен: иерархию доменных имен [1] и адресные пространства Интернет-протокола (IP) . [2] Система доменных имен поддерживает иерархию доменных имен и предоставляет услуги перевода между ней и адресными пространствами. Серверы имен в Интернете и протокол связи реализуют систему доменных имен. [3] Сервер имен DNS - это сервер, на котором хранятся записи DNS для домена; сервер имен DNS отвечает на запросы к своей базе данных.

Наиболее распространенные типы записей, хранящихся в базе данных DNS, - это Start of Authority ( SOA ), IP-адреса ( A и AAAA ), почтовые обменники SMTP (MX), серверы имен (NS), указатели для обратного поиска DNS (PTR), и псевдонимы доменного имени (CNAME). Хотя DNS не предназначен для использования в качестве базы данных общего назначения, с течением времени DNS был расширен для хранения записей для других типов данных либо для автоматического поиска, например записей DNSSEC , либо для запросов людей, таких как записи ответственных лиц (RP). В качестве базы данных общего назначения DNS также использовался для борьбы с нежелательной электронной почтой.(спам) путем сохранения списка черных дыр в реальном времени (RBL). База данных DNS традиционно хранится в структурированном текстовом файле, файле зоны , но другие системы баз данных являются общими.

Функция

Для объяснения системы доменных имен часто используется аналогия, заключающаяся в том, что она служит телефонной книгой для Интернета, переводя понятные человеку имена хостов компьютеров в IP-адреса. Например, доменное имя www.example.com преобразуется в адреса 93.184.216.34 ( IPv4 ) и 2606: 2800: 220: 1: 248: 1893: 25c8: 1946 ( IPv6 ). DNS может быть быстро и прозрачно обновлен, что позволяет изменять местоположение службы в сети, не затрагивая конечных пользователей, которые продолжают использовать то же имя хоста. Пользователи пользуются этим, когда используют значимые унифицированные указатели ресурсов ( URL ) и адреса электронной почты. без необходимости знать, как компьютер на самом деле находит службы.

Важной и повсеместной функцией DNS является ее центральная роль в распределенных интернет-сервисах, таких как облачные сервисы и сети доставки контента . [4] Когда пользователь обращается к распределенной интернет-службе с помощью URL-адреса, доменное имя URL-адреса преобразуется в IP-адрес сервера, ближайшего к пользователю. Ключевые функции DNS, используемые здесь, заключаются в том, что разные пользователи могут одновременно получать разные переводы для одного и того жедоменное имя, что является ключевым моментом отличия от традиционной телефонной книги DNS. Этот процесс использования DNS для назначения ближайших серверов пользователям является ключом к обеспечению более быстрых и надежных ответов в Интернете и широко используется большинством основных Интернет-служб. [5]

DNS отражает структуру административной ответственности в Интернете. [6] Каждый поддомен является зоной административной автономии, делегированной менеджеру. Для зон, управляемых реестром , административная информация часто дополняется службами реестра RDAP и WHOIS . Эти данные можно использовать, чтобы получить представление о конкретном хосте в Интернете и отслеживать ответственность за него. [7]

История

Использование более простого и запоминающегося имени вместо числового адреса хоста восходит к эпохе ARPANET . Стэнфордский исследовательский институт (ныне SRI International ) поддерживал текстовый файл с именем HOSTS.TXT, который отображал имена хостов в числовые адреса компьютеров в ARPANET. [8] [9] Элизабет Фейнлер разработала и обслуживала первый каталог ARPANET. [10] [11] Обслуживание числовых адресов, называемых в Assigned Numbers Список, был обработан Джоном Постелем в Университете Южной Калифорнии «s информационного института наук (ISI), чья команда работала в тесном сотрудничестве с НИИ. [12]

Адреса назначались вручную. Компьютеры, включая их имена хостов и адреса, были добавлены в основной файл путем обращения в Центр сетевой информации (NIC) SRI , которым руководит Элизабет Фейнлер, по телефону в рабочее время. [13] Позже Фейнлер создал каталог WHOIS на сервере в сетевом адаптере для поиска информации о ресурсах, контактах и ​​объектах. [14] Она и ее команда разработали концепцию доменов. [14] Фейнлер предположил, что домены должны основываться на местонахождении физического адреса компьютера. [15] Компьютеры в образовательных учреждениях, например, будут иметь домен edu . [16]Она и ее команда управляли Реестром имен хостов с 1972 по 1989 год [17].

К началу 1980-х поддержание единой централизованной таблицы хостов стало медленным и громоздким, и возникающая сеть требовала автоматизированной системы именования для решения технических и кадровых проблем. Постел поручил Полу Мокапетрису найти компромисс между пятью конкурирующими предложениями решений . Вместо этого Mockapetris создал систему доменных имен в 1983 году. [13] [18]

Engineering Task Force Интернет опубликовала исходные спецификации в RFC 882 и RFC 883 в ноябре 1983 года [19] [20]

В 1984 году четыре студента Калифорнийского университета в Беркли , Дуглас Терри, Марк Пейнтер, Дэвид Риггл и Сонниан Чжоу, написали первую реализацию сервера имен Unix для доменного имени в Интернете Беркли, обычно называемого BIND . [21] В 1985 году Кевин Данлэп из DEC существенно пересмотрел реализацию DNS. Майк Карелс , Фил Алмквист и Пол Викси с тех пор поддерживают BIND. [22] В начале 1990-х BIND был перенесен на платформу Windows NT .

В ноябре 1987 года RFC 1034 [1] и RFC 1035 [3] заменили спецификации DNS 1983 года. В нескольких дополнительных запросах комментариев предлагались расширения основных протоколов DNS. [23]

Структура

Пространство доменных имен

Пространство доменных имен состоит из древовидной структуры данных . Каждый узел или лист в дереве имеет метку и ноль или более записей ресурсов (RR), которые содержат информацию, связанную с именем домена. Само доменное имя состоит из метки, соединенной с именем его родительского узла справа, разделенного точкой. [24]

Дерево подразделяется на зоны, начиная с корневой зоны . Зона DNS может состоять только из одного домена, или может состоять из множества доменов и суб-доменов, в зависимости от выбора административного менеджера зоны. DNS также можно разделить по классам, при этом отдельные классы можно рассматривать как массив параллельных деревьев пространств имен. [25]

Иерархическая система доменных имен для класса Интернет , организованная в зоны, каждая из которых обслуживается сервером имен.

Административная ответственность за любую зону может быть разделена путем создания дополнительных зон. Говорят, что полномочия на новую зону делегированы назначенному серверу имен. Родительская зона перестает быть авторитетной для новой зоны. [25]

Синтаксис доменного имени, интернационализация

Полное описание правил формирования доменных имен содержится в RFC 1035 , RFC 1123 , RFC 2181 и RFC 5892 . Доменное имя состоит из одной или нескольких частей, технически называемые ярлыки , которые обычно сцепленных и разделённых точками, например, example.com.

Самая правая метка обозначает домен верхнего уровня ; например, доменное имя www.example.com принадлежит домену верхнего уровня com .

Иерархия доменов спускается справа налево; каждая метка слева указывает подразделение или субдомен домена справа. Например, в примере метки указывается поддомен домена com , а www - поддомен домена example.com. Это дерево подразделений может иметь до 127 уровней. [26]

Метка может содержать от нуля до 63 символов. Пустая метка нулевой длины зарезервирована для корневой зоны. Полное доменное имя не может превышать длину 253 символа в его текстовом представлении. [1] Во внутреннем двоичном представлении DNS максимальная длина требует 255 октетов памяти, так как в нем также хранится длина имени. [3]

Хотя нет технических ограничений на использование любого символа в метках доменного имени, которые могут быть представлены октетами, имена хостов используют предпочтительный формат и набор символов. Допустимые символы в метках - это подмножество набора символов ASCII , состоящее из символов от a до z , от A до Z , цифр от 0 до 9 и дефиса. Это правило известно как правило LDH (буквы, цифры, дефис). Доменные имена интерпретируются независимо от регистра. [27] Ярлыки не могут начинаться или заканчиваться дефисом. [28] Дополнительное правило требует, чтобы имена доменов верхнего уровня не были полностью числовыми.[28]

Ограниченный набор символов ASCII, разрешенный в DNS, препятствовал представлению имен и слов многих языков в их родных алфавитах или скриптах. Чтобы сделать это возможным, ICANN утвердила систему интернационализации доменных имен в приложениях (IDNA), с помощью которой пользовательские приложения, такие как веб-браузеры, преобразуют строки Unicode в действительный набор символов DNS с помощью Punycode . В 2009 году ICANN одобрила установку интернационализированных доменных имен национальных доменов верхнего уровня ( ccTLD ) . Кроме того, многие реестры существующих доменов верхнего уровня имена ( TLD s ) приняли систему IDNA, руководствуясьRFC 5890 , RFC 5891 , RFC 5892 , RFC 5893 .

Серверы имен

Система доменных имен поддерживается распределенной системой баз данных , которая использует модель клиент-сервер . Узлами этой базы данных являются серверы имен . В каждом домене есть по крайней мере один авторитетный DNS-сервер, который публикует информацию об этом домене и серверах имен всех подчиненных ему доменов. Верхняя часть иерархии обслуживается корневыми серверами имен , серверами, которые запрашивают при поиске ( разрешении ) TLD.

Авторитетный сервер имен

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

Авторитетный сервер имен может быть первичным или вторичным сервером. Исторически термины « главный / подчиненный» и « первичный / вторичный» иногда использовались взаимозаменяемо [29], но в настоящее время используется последняя форма. Первичный сервер - это сервер, на котором хранятся исходные копии всех записей зоны. Вторичный сервер использует специальный механизм автоматического обновления в протоколе DNS для связи со своим первичным, чтобы поддерживать идентичную копию первичных записей.

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

Авторитетный сервер указывает свой статус предоставления окончательных ответов, который считается авторитетным , путем установки флага протокола, называемого битом « Авторитетный ответ » ( AA ) в своих ответах. [3] Этот флаг обычно воспроизводится на видном месте в выходных данных инструментов администрирования DNS, таких как dig , чтобы указать, что отвечающий сервер имен является органом власти для рассматриваемого доменного имени. [3]

Операция

Механизм разрешения адресов

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

Преобразователь DNS, реализующий итеративный подход, предусмотренный RFC 1034 ; в этом случае преобразователь обращается к трем серверам имен для разрешения полного доменного имени «www.wikipedia.org».

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

Предполагая, что преобразователь не имеет кэшированных записей для ускорения процесса, процесс разрешения начинается с запроса к одному из корневых серверов. При обычной работе корневые серверы не отвечают напрямую, а отвечают ссылкой на более авторитетные серверы, например, запрос «www.wikipedia.org» относится к серверам организации . Теперь распознаватель запрашивает упомянутые серверы и итеративно повторяет этот процесс, пока не получит достоверный ответ. Схема иллюстрирует этот процесс для хоста, который назван полным доменным именем «www.wikipedia.org».

Этот механизм создает большую нагрузку на корневые серверы, если каждое разрешение в Интернете требует запуска с корневого сервера. На практике кеширование используется в DNS-серверах для разгрузки корневых серверов, и в результате корневые серверы имен фактически участвуют только в относительно небольшой части всех запросов.

Рекурсивный и кеширующий сервер имен

Теоретически для работы Интернета достаточно авторитетных серверов имен. Однако при работе только авторитетных серверов имен каждый DNS-запрос должен начинаться с рекурсивных запросов в корневой зоне системы доменных имен, и каждая пользовательская система должна будет реализовать программное обеспечение преобразователя, способное к рекурсивной работе.

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

Комбинация DNS-кеширования и рекурсивных функций на сервере имен не является обязательной; функции могут быть реализованы независимо на серверах специального назначения.

Интернет-провайдеры обычно предоставляют своим клиентам рекурсивные и кэширующие серверы имен. Кроме того, многие домашние сетевые маршрутизаторы реализуют кэши и рекурсоры DNS для повышения эффективности локальной сети.

Преобразователи DNS

Клиентская сторона DNS называется преобразователем DNS. Сопоставитель отвечает за инициирование и упорядочение запросов, которые в конечном итоге приводят к полному разрешению (трансляции) искомого ресурса, например, трансляции доменного имени в IP-адрес. Преобразователи DNS классифицируются по множеству методов запросов, например рекурсивным , нерекурсивным и итеративным . В процессе разрешения проблем может использоваться комбинация этих методов. [1]

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

Например, если авторитетный сервер имен для example.org - ns1.example.org, компьютер, пытающийся разрешить www.example.org, сначала разрешает ns1.example.org. Поскольку ns1 содержится в example.org, для этого необходимо сначала разрешить example.org, который представляет собой циклическую зависимость. Чтобы разорвать зависимость, сервер имен для организации домена верхнего уровня включает клей вместе с делегированием для example.org. Связующие записи - это записи адресов, которые предоставляют IP-адреса для ns1.example.org. Сопоставитель использует один или несколько из этих IP-адресов для запроса одного из авторитетных серверов домена, что позволяет ему выполнить DNS-запрос.

Кеширование записей

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

В результате этой распределенной архитектуры кэширования изменения в записях DNS не распространяются по сети немедленно, а требуют, чтобы срок действия всех кешей истек и обновлялся после TTL. RFC 1912 передает основные правила для определения соответствующих значений TTL.

Некоторые преобразователи могут переопределять значения TTL, поскольку протокол поддерживает кэширование на срок до шестидесяти восьми лет или вообще не поддерживает кеширование. Отрицательное кэширование , то есть кэширование факта отсутствия записи, определяется серверами имен, уполномоченными для зоны, которая должна включать запись начала авторизации (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, он будет представлен как 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-серверов. В случае большинства домашних пользователей поставщик услуг Интернета, к которому подключается машина, обычно предоставляет этот DNS-сервер: такой пользователь либо настроит адрес этого сервера вручную, либо разрешит DHCP.установить его; однако, если системные администраторы настроили системы на использование собственных DNS-серверов, их DNS-преобразователи указывают на отдельно обслуживаемые серверы имен организации. В любом случае запрашиваемый таким образом сервер имен будет следовать описанному выше процессу , пока он либо не найдет результат, либо не найдет его. Затем он возвращает свои результаты распознавателю DNS; предполагая, что он нашел результат, распознаватель должным образом кэширует этот результат для использования в будущем и передает результат обратно программе, которая инициировала запрос.

Сломанные резолверы

Некоторые крупные интернет-провайдеры настроили свои DNS-серверы так, чтобы они нарушали правила, например, не соблюдая TTL, или указывая, что доменное имя не существует только потому, что один из его серверов имен не отвечает. [30]

Некоторые приложения, такие как веб-браузеры, поддерживают внутренний DNS-кеш, чтобы избежать повторных поисков по сети. Эта практика может добавить дополнительные трудности при отладке проблем DNS, поскольку она скрывает историю таких данных. Эти кеши обычно используют очень короткое время кэширования, порядка одной минуты. [31]

Internet Explorer представляет собой заметное исключение: версии до IE 3.x по умолчанию кэшируют записи DNS на 24 часа. Internet Explorer 4.x и более поздние версии (до IE 8) уменьшают значение тайм-аута по умолчанию до получаса, которое можно изменить, изменив конфигурацию по умолчанию. [32]

Когда Google Chrome обнаруживает проблемы с DNS-сервером, он отображает конкретное сообщение об ошибке.

Другие приложения

Система доменных имен включает в себя несколько других функций и возможностей.

Имена хостов и IP-адреса не обязательно должны совпадать один-к-одному. Несколько имен хостов могут соответствовать одному IP-адресу, что полезно при виртуальном хостинге , когда многие веб-сайты обслуживаются с одного хоста. В качестве альтернативы, одно имя хоста может разрешаться во многие IP-адреса, чтобы облегчить отказоустойчивость и распределение нагрузки на несколько экземпляров серверов в рамках предприятия или глобального Интернета.

DNS служит другим целям в дополнение к преобразованию имен в IP-адреса. Например, агенты передачи почты используют DNS, чтобы найти лучший почтовый сервер для доставки электронной почты : запись MX обеспечивает сопоставление между доменом и почтовым обменником; это может обеспечить дополнительный уровень отказоустойчивости и распределения нагрузки.

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

Например:

  • Адрес 102.3.4.5 занесен в черный список. Он указывает на 5.4.3.102.blacklist.example, который разрешается в 127.0.0.1.
  • Адрес 102.3.4.6 не занесен в черный список и указывает на 6.4.3.102.blacklist.example. Это имя хоста либо не настроено, либо преобразуется в 127.0.0.2.

Почтовые серверы могут запрашивать blacklist.example, чтобы узнать, находится ли конкретный подключенный к ним хост в черном списке. Многие из таких черных списков, как по подписке, так и бесплатно, доступны для использования администраторами электронной почты и программным обеспечением для защиты от спама.

Чтобы обеспечить отказоустойчивость в случае сбоя компьютера или сети, обычно предоставляется несколько DNS-серверов для покрытия каждого домена. На верхнем уровне глобальной DNS существует тринадцать групп корневых серверов имен с дополнительными «копиями», распространяемыми по всему миру посредством произвольной адресации.

Динамический DNS (DDNS) обновляет DNS-сервер с помощью IP-адреса клиента на лету, например, при перемещении между интернет-провайдерами или мобильными точками доступа или когда IP-адрес изменяется административно.

Формат сообщения DNS

Протокол DNS использует два типа сообщений DNS, запросы и ответы; оба имеют одинаковый формат. Каждое сообщение состоит из заголовка и четырех разделов: вопрос, ответ, авторитетность и дополнительное пространство. Поле заголовка ( флаги ) управляет содержанием этих четырех разделов. [1]

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

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

Раздел вопросов

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

Доменное имя разбито на отдельные метки, которые объединяются; каждая метка имеет префикс длины этой метки. [34]

Транспортный протокол DNS

DNS в основном использует протокол пользовательских дейтаграмм (UDP) на порту 53 для обслуживания запросов. [3] DNS-запросы состоят из одного UDP-запроса от клиента, за которым следует один UDP-ответ от сервера. Когда длина ответа превышает 512 байт и и клиент, и сервер поддерживают EDNS , используются более крупные пакеты UDP. В противном случае запрос отправляется снова с использованием протокола управления передачей (TCP). TCP также используется для таких задач, как передача зон . Некоторые реализации преобразователя используют TCP для всех запросов.

Записи ресурсов

Система доменных имен определяет базу данных информационных элементов для сетевых ресурсов. Типы информационных элементов разделены на категории и организованы со списком типов записей DNS , ресурсных записей (RR). Каждая запись имеет тип (имя и номер), срок действия ( время жизни ), класс и данные для конкретного типа. Записи ресурсов одного и того же типа описываются как набор записей ресурсов (RRset), не имеющий особого порядка. Преобразователи DNS возвращают весь набор по запросу, но серверы могут реализовать циклическое упорядочение для достижения балансировки нагрузки . Напротив, расширения безопасности системы доменных имен (DNSSEC) работают с полным набором записей ресурсов в каноническом порядке.

При отправке по сети Интернет-протокола все записи используют общий формат, указанный в RFC 1035 : [35]

ИМЯ - это полное доменное имя узла в дереве [ требуется пояснение ] . На проводе имя может быть сокращено с использованием сжатия меток, где концы доменных имен, упомянутых ранее в пакете, могут быть заменены концом текущего доменного имени.

ТИП - это тип записи. Он указывает формат данных и дает представление о предполагаемом использовании. Например, запись A используется для преобразования имени домена в адрес IPv4 , запись NS перечисляет, какие серверы имен могут отвечать на запросы в зоне DNS , а запись MX указывает почтовый сервер, используемый для обработки почты для указанного домена. в адресе электронной почты.

RDATA - это данные, относящиеся к определенному типу, такие как IP-адрес для записей адресов или приоритет и имя хоста для записей MX. Хорошо известные типы записей могут использовать сжатие меток в поле RDATA, но «неизвестные» типы записей не должны ( RFC 3597 ).

CLASS от записи установлен в положение IN (для Интернета ) для общих записей DNS , связанных с интернет - хостов, серверов или IP - адреса. Кроме того, существуют классы Хаос (CH) и Гесиод (HS). [36] Каждый класс представляет собой независимое пространство имен с потенциально различными зонами DNS.

В дополнение к ресурсным записям, определенным в файле зоны , система доменных имен также определяет несколько типов запросов, которые используются только для связи с другими узлами DNS ( на проводе ), например, при выполнении зональных передач (AXFR / IXFR) или для EDNS. (ОПТ).

Записи DNS с подстановочными знаками

Система доменных имен поддерживает записи DNS с подстановочными знаками, которые определяют имена, начинающиеся с метки звездочки , '*', например, * .example. [1] [37] Записи DNS, принадлежащие именам доменов с подстановочными знаками, определяют правила для создания записей ресурсов в пределах одной зоны DNS путем замены целых меток соответствующими компонентами имени запроса, включая любые указанные потомки. Например, в следующей конфигурации зона DNS x.example указывает, что все субдомены, включая субдомены субдоменов, x.example используют почтовый обменник (MX) axexample . Рекорд A для axexampleнеобходимо для указания IP-адреса почтового обменника. Поскольку это приводит к исключению этого доменного имени и его поддоменов из совпадений с подстановочными знаками, в зоне DNS также должна быть определена дополнительная запись MX для поддомена axexample , а также запись MX с подстановочными знаками для всех его поддоменов.

x.example. MX 10 axexample.* .x.example. MX 10 axexample.* .axexample. MX 10 axexample.axexample. MX 10 axexample.axexample. AAAA 2001: db8 :: 1

Роль записей с подстановочными знаками была уточнена в RFC 4592 , поскольку исходное определение в RFC 1034 было неполным и привело к неправильной интерпретации разработчиками. [37]

Расширения протокола

Исходный протокол DNS имел ограниченные возможности для расширения за счет новых функций. В 1999 году Пол Викси опубликовал в RFC 2671 (замененном RFC 6891 ) механизм расширения, называемый механизмами расширения для DNS (EDNS), который вводил необязательные элементы протокола без увеличения накладных расходов, когда они не используются. Это было достигнуто с помощью записи псевдоресурса OPT, которая существует только в проводных передачах протокола, но не в каких-либо файлах зоны. Также были предложены начальные расширения (EDNS0), такие как увеличение размера сообщения DNS в дейтаграммах UDP.

Обновления динамической зоны

Обновления динамического DNS используют код операции UPDATE DNS для динамического добавления или удаления записей ресурсов из базы данных зоны, поддерживаемой на полномочном DNS-сервере. Эта функция описана в RFC 2136 . Эта возможность полезна для регистрации сетевых клиентов в DNS, когда они загружаются или становятся доступными в сети иным образом. Поскольку загружающемуся клиенту каждый раз может быть назначен другой IP-адрес с сервера DHCP , невозможно предоставить статические назначения DNS для таких клиентов.

Проблемы с безопасностью

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

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

Ответы DNS традиционно не имеют криптографической подписи , что приводит к множеству возможностей атак; в системе доменных имен Расширения безопасности (DNSSEC) изменить DNS , чтобы добавить поддержку криптографически подписанных ответов. DNSCurve был предложен в качестве альтернативы DNSSEC. Другие расширения, такие как TSIG , добавляют поддержку криптографической аутентификации между доверенными узлами и обычно используются для авторизации передачи зоны или операций динамического обновления.

Некоторые доменные имена могут использоваться для достижения эффекта спуфинга. Например, paypal.com и paypa1.com - это разные имена, но пользователи могут быть не в состоянии различить их в графическом пользовательском интерфейсе в зависимости от выбранного пользователем шрифта . Во многих шрифтах буква l и цифра 1 выглядят очень похожими или даже идентичными. Эта проблема остро стоит в системах, поддерживающих интернационализированные доменные имена , поскольку многие коды символов в ISO 10646 могут выглядеть одинаковыми на экранах обычных компьютеров. Эта уязвимость иногда используется в целях фишинга . [38]

Такие методы, как обратный DNS с прямым подтверждением, также могут быть использованы для проверки результатов DNS.

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

Проблемы с конфиденциальностью и отслеживанием

Первоначально разработанный как общедоступная, иерархическая, распределенная и сильно кэшированная база данных, протокол DNS не имеет средств контроля конфиденциальности. Пользовательские запросы и ответы сервера имен отправляются в незашифрованном виде , который позволяет сети перехвата пакетов , DNS угон , отравление кэша DNS и человек-в-середине атаки . Этот недостаток обычно используется киберпреступниками и операторами сетей для маркетинговых целей, аутентификации пользователей на перехватывающих порталах и цензуры . [39]

Конфиденциальность пользователей дополнительно раскрывается предложениями по увеличению уровня информации об IP- адресе клиента в запросах DNS ( RFC 7871 ) в интересах сетей доставки контента .

Основные подходы, которые используются для решения проблем конфиденциальности с DNS:

  • VPN , которые передают разрешение DNS оператору VPN и скрывают пользовательский трафик от местного интернет-провайдера,
  • Tor , который заменяет традиционное разрешение DNS анонимными доменами .onion , скрывая как разрешение имен, так и пользовательский трафик за счетчиком наблюдения за луковой маршрутизацией ,
  • Доверенные и публичные сервера DNS, которые двигают фактическое разрешение DNS для стороннего поставщика, который обычно обещает мало или нет лесозаготовительных запроса и необязательных дополнительных функций, таких как DNS-уровень рекламы или блокирование порнографии.
    • Общедоступные DNS-серверы могут запрашиваться с использованием традиционного протокола DNS, и в этом случае они не обеспечивают защиты от локального наблюдения, или DNS-over-HTTPS , DNS-over-TLS и DNSCrypt , которые действительно обеспечивают такую ​​защиту.

Решения, предотвращающие проверку DNS со стороны оператора локальной сети, критикуются за нарушение политик безопасности корпоративной сети и цензуру в Интернете. Их также критикуют с точки зрения конфиденциальности, поскольку они передают разрешение DNS в руки небольшого числа компаний, известных своей монетизацией пользовательского трафика и централизацией разрешения имен DNS, что обычно считается вредным для Интернета. [39]

Google является доминирующим поставщиком платформы в Android, браузера в Chrome и преобразователя DNS в службе 8.8.8.8. Будет ли в этом сценарии случай, когда отдельное юридическое лицо находится в позиции всеобъемлющего контроля над всем пространством имен Интернета? Netflix уже представил приложение, которое использует собственный механизм разрешения DNS независимо от платформы, на которой оно работает. Что, если бы приложение Facebook включало DoH? Что, если бы Apple iOS использовала механизм разрешения DoH, чтобы обойти локальное разрешение DNS и направить все запросы DNS с платформ Apple на набор управляемых Apple преобразователей имен?

-  Конфиденциальность DNS и IETF

Регистрация доменного имени

Право на использование доменного имени делегируется регистраторами доменных имен, которые аккредитованы Интернет-корпорацией по присвоению имен и номеров (ICANN) или другими организациями, такими как OpenNIC , которые отвечают за надзор за системами имен и номеров в Интернете. В дополнение к ICANN, каждый домен верхнего уровня (TLD) обслуживается и технически обслуживается административной организацией, ведущей реестр. Реестра отвечает за эксплуатацию базы данных имен в пределах своей авторитетной зоны, хотя этот термин чаще всего используется для TLD. Регистранте это лицо или организация, попросивший для регистрации домена. [23] Реестр получает регистрационную информацию от каждого доменного имени.регистратор , который уполномочен (аккредитован) назначать имена в соответствующей зоне и публикует информацию с использованием протокола WHOIS . По состоянию на 2015 год рассматривается возможность использования RDAP . [40]

ICANN публикует полный список TLD, реестров TLD и регистраторов доменных имен. Информация о регистранте, связанная с доменными именами, хранится в онлайн-базе данных, доступной через службу WHOIS. Для большинства из более чем 290 доменов верхнего уровня с кодом страны (ccTLD) реестры доменов поддерживают информацию WHOIS (регистрант, серверы имен, даты истечения срока действия и т. Д.). Например, DENIC , Германия NIC, хранит данные домена DE. Примерно 2001, самый домен Родового верхнего уровня (оДВа) реестры приняли этот так называемый толстым реестр подход, в частности , сохранение данных WHOIS в центральных реестрах вместо регистратора баз данных.

Для доменов верхнего уровня в COM и NET используется тонкая модель реестра. Реестр доменов (например, GoDaddy , BigRock и PDR , VeriSign и т. Д. И т. Д.) Содержит основные данные WHOIS (т. Е. Регистратор, серверы имен и т. Д.). С другой стороны, организации или зарегистрированные лица, использующие ORG, находятся исключительно в Реестре общественных интересов .

Некоторые реестры доменных имен, часто называемые сетевыми информационными центрами (NIC), также выполняют функции регистраторов для конечных пользователей, помимо предоставления доступа к наборам данных WHOIS. Реестры доменов верхнего уровня, такие как домены COM, NET и ORG, используют модель регистратора-регистратора, состоящую из множества регистраторов доменных имен. [41] При этом методе управления реестр управляет только базой данных доменных имен и отношениями с регистраторами. В регистрантах (пользователи доменного имени) являются клиентами регистратора, в некоторых случаях с помощью дополнительного субподряда посредников.

RFC документы

Стандарты

Система доменных имен определяется документами запроса комментариев (RFC), опубликованными инженерной группой Интернета ( стандарты Интернета ). Ниже приведен список RFC, определяющих протокол DNS.

  • RFC 1034 , Доменные имена - концепции и возможности
  • RFC 1035 , Доменные имена - реализация и спецификация
  • RFC 1123 , Требования к Интернет-хостам - применение и поддержка
  • RFC 1995 , Инкрементальная передача зоны в DNS
  • RFC 1996 , Механизм быстрого уведомления об изменении зоны (DNS NOTIFY)
  • RFC 2136 , Динамические обновления в системе доменных имен (ОБНОВЛЕНИЕ DNS)
  • RFC 2181 , Разъяснения к спецификации DNS
  • RFC 2308 , отрицательное кэширование DNS-запросов (DNS NCACHE)
  • RFC 2672 , Перенаправление нетерминального DNS-имени
  • RFC 2845 , Аутентификация транзакции с секретным ключом для DNS (TSIG)
  • RFC 3225 , указывающий, что резолвер поддерживает DNSSEC
  • Требования к размеру сообщений сервера / распознавателя с поддержкой RFC 3226 , DNSSEC и IPv6 A6
  • RFC 3596 , Расширения DNS для поддержки IP версии 6
  • RFC 3597 , Обработка неизвестных типов записей ресурсов DNS (RR)
  • RFC 4343 , Разъяснение нечувствительности к регистру в системе доменных имен (DNS)
  • RFC 4592 , роль подстановочных знаков в системе доменных имен
  • RFC 4635 , Идентификаторы алгоритма HMAC SHA TSIG
  • RFC 5001 , параметр идентификатора сервера имен DNS (NSID)
  • RFC 5011 , Автоматические обновления якорей доверия безопасности DNS (DNSSEC)
  • RFC 5452 , Меры по повышению устойчивости DNS к поддельным ответам
  • RFC 5890 , Интернационализированные доменные имена для приложений (IDNA): определения и структура документов
  • RFC 5891 , Интернационализированные доменные имена в приложениях (IDNA): протокол
  • RFC 5892 , Кодовые точки Unicode и интернационализированные доменные имена для приложений (IDNA)
  • RFC 5893 , сценарии с написанием справа налево для интернационализированных доменных имен для приложений (IDNA)
  • RFC 6891 , механизмы расширения для DNS (EDNS0)
  • RFC 7766 , DNS Transport over TCP - Требования к реализации

Предлагаемые стандарты безопасности

  • RFC 4033 , Введение в безопасность DNS и требования
  • RFC 4034 , Записи ресурсов для расширений безопасности DNS
  • RFC 4035 , Модификации протокола для расширений безопасности DNS
  • RFC 4509 , Использование SHA-256 в записях ресурсов лица, подписывающего делегирование (DS) DNSSEC
  • RFC 4470 , Минимальное покрытие записей NSEC и подписание DNSSEC в режиме онлайн
  • RFC 5155 , DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
  • RFC 5702 , Использование алгоритмов SHA-2 с RSA в записях ресурсов DNSKEY и RRSIG для DNSSEC
  • RFC 5910 , Сопоставление расширений безопасности системы доменных имен (DNS) для Extensible Provisioning Protocol (EPP)
  • RFC 5933 , Использование алгоритмов подписи ГОСТ в записях ресурсов DNSKEY и RRSIG для DNSSEC
  • RFC 7830 , параметр заполнения EDNS (0)
  • RFC 7858 , Спецификация DNS через безопасность транспортного уровня (TLS)
  • RFC 8310 , Профили использования для DNS через TLS и DNS через DTLS
  • RFC 8484 , DNS-запросы через HTTPS (DoH)

Экспериментальные RFC

  • RFC 1183 , Новые определения DNS RR

Лучшие текущие практики

  • RFC 2182 , Выбор и работа вторичных DNS-серверов (BCP 16)
  • RFC 2317 , Бесклассовое делегирование IN-ADDR.ARPA (BCP 20)
  • RFC 5625 , Рекомендации по внедрению DNS-прокси (BCP 152)
  • RFC 6895 , Система доменных имен (DNS). Вопросы IANA (BCP 42)
  • RFC 7720 , протокол службы корневых имен DNS и требования к развертыванию (BCP 40)

Информационные RFC

Эти RFC носят рекомендательный характер, но могут предоставить полезную информацию, несмотря на то, что не определяют ни стандарта, ни BCP. ( RFC 1796 )

  • RFC 1178 , Выбор имени для вашего компьютера (FYI 5)
  • RFC 1591 , Структура системы доменных имен и делегирование
  • RFC 1912 , Общие ошибки работы и конфигурации DNS
  • RFC 2100 , Именование хостов
  • RFC 3696 , Прикладные методы проверки и преобразования имен
  • RFC 3833 . Анализ угроз системы доменных имен (DNS)
  • RFC 4892 , Требования к механизму идентификации экземпляра сервера имен
  • RFC 5894 , Интернационализированные доменные имена для приложений (IDNA): предыстория, объяснение и обоснование
  • RFC 5895 , Отображение символов для интернационализированных доменных имен в приложениях (IDNA) 2008
  • RFC 7626 , Вопросы конфиденциальности DNS
  • RFC 7706 , Уменьшение времени доступа к корневым серверам путем запуска одного из них в режиме обратной петли
  • RFC 8499 , терминология DNS

Неизвестный

Эти RFC имеют официальный статус Неизвестно , но из-за их возраста не имеют четкого обозначения как таковые.

  • RFC 920 , Требования к домену - Указаны исходные домены верхнего уровня
  • RFC 1032 , Руководство администратора домена
  • RFC 1033 , Руководство по работе с администраторами домена
  • RFC 1101 , DNS-кодирование сетевых имен и других типов

Смотрите также

  • Альтернативный корень DNS
  • Сравнение программного обеспечения DNS-серверов
  • Взлом домена
  • Перехват DNS
  • Программное обеспечение для управления DNS
  • DNS через HTTPS
  • DNS через TLS
  • Иерархическое пространство имен
  • Нарушение IPv6 и белые списки DNS
  • Многоадресный DNS
  • Публичный рекурсивный сервер имен
  • resolv.conf
  • Разделенный горизонт DNS
  • Список типов записей DNS
  • Список управляемых DNS-провайдеров
  • Файл зоны
  • Утечка DNS

Рекомендации

  1. ^ a b c d e f RFC 1034 , Доменные имена - концепции и средства , P. Mockapetris, The Internet Society (ноябрь 1987 г.)
  2. ^ RFC 781 , Интернет-протокол - Спецификация протокола Интернет-программы DARPA , Институт информационных наук, J. Postel (Ed.), The Internet Society (сентябрь 1981 г.)
  3. ^ a b c d e f RFC 1035 , Доменные имена - реализация и спецификация , P. Mockapetris, The Internet Society (ноябрь 1987 г.)
  4. ^ J. Дилли, Б. Мэггс, Дж Парих, Х. Прокоп, Р. Sitaraman, и Б. Weihl. «Глобально распределенная доставка контента, IEEE Internet Computing, сентябрь / октябрь 2002 г., стр. 50-58» (PDF) .
  5. ^ Nygren., E .; Ситараман РК; Солнце, Дж. (2010). «Сеть Akamai: платформа для высокопроизводительных Интернет-приложений» (PDF) . Обзор операционных систем ACM SIGOPS . 44 (3): 2–19. DOI : 10.1145 / 1842733.1842736 . S2CID 207181702 . Проверено 19 ноября 2012 года .  
  6. ^ Пол Mockapetris (ноябрь 1987). «Формат SOA RDATA» . Доменные имена - реализация и спецификация . IETF . сек. 3.3.13. DOI : 10,17487 / RFC1035 . RFC 1035 . Проверено 18 декабря 2015 .
  7. ^ Champika Wijayatunga (февраль 2015). «Обработка злоупотреблений DNS» (PDF) . АПНИК . Проверено 18 декабря +2016 .
  8. ^ RFC 3467 , «Роль системы доменных имен (DNS)», JC Klensin, J. Klensin (февраль 2003 г.).
  9. ^ Лю, Крикет; Альбиц, Пол (2006). DNS и BIND (5-е изд.). O'Reilly Media. п. 3. ISBN 978-0-596-10057-5.
  10. Перейти ↑ Evans 2018 , p. 112.
  11. Перейти ↑ Evans 2018 , p. 113.
  12. ^ IEEE Annals [3B2-9] man2011030074.3d 29/7/011 11:54 Стр. 74
  13. ^ a b «Почему сеть все еще работает на Рождество? Пол Мокапетрис - Зал славы Интернета» . internethalloffame.org .
  14. ^ а б Эванс 2018 , стр. 119.
  15. Перейти ↑ Evans 2018 , p. 120.
  16. Перейти ↑ Evans 2018 , p. 120-121.
  17. ^ "Элизабет Файнлер" . Интернет-зал славы . Архивировано из оригинального 14 сентября 2018 года . Проверено 25 ноября 2018 .
  18. ^ "Пол Мокапетрис | Интернет-зал славы" . internethalloffame.org . Проверено 12 февраля 2020 .
  19. ^ Андрей Robachevsky (26 ноября 2013). «С 30-летием, DNS!» . Интернет-общество . Проверено 18 декабря 2015 .
  20. ^ Элизабет Фейнлер, IEEE Annals, 3B2-9 man2011030074.3d 29/7/011 11:54 Стр.
  21. ^ Терри, Дуглас Б .; и другие. (12–15 июня 1984 г.). "Сервер доменных имен в Интернете в Беркли" . Летняя конференция, Солт-Лейк-Сити, 1984: Материалы . Группа пользователей программных средств ассоциации USENIX. С. 23–31.
  22. ^ Консорциум Интернет-систем. «Наиболее широко используемое программное обеспечение сервера имен: BIND» . История BIND . Проверено 28 июля 2013 года .
  23. ^ а б Пол Хоффман; Эндрю Салливан; Кадзунори Фудзивара (декабрь 2015 г.). Терминология DNS . IETF . DOI : 10,17487 / RFC7719 . RFC 7719 . Проверено 18 декабря 2015 .
  24. ^ Пол Mockapetris (ноябрь 1987). «Спецификации и терминология пространств имен» . Доменные имена - концепции и возможности доменов . IETF . сек. 3.1. DOI : 10,17487 / RFC1034 . RFC 1034 . Проверено 17 декабря 2015 года .
  25. ^ a b Пол Мокапетрис (ноябрь 1987 г.). «Как база данных делится на зоны» . Доменные имена - концепции и возможности доменов . IETF . сек. 4.2. DOI : 10,17487 / RFC1034 . RFC 1034 . Проверено 17 декабря 2015 года .
  26. ^ Линдси, Дэвид (2007). Международный закон об именах доменов: ICANN и UDRP . Bloomsbury Publishing. п. 8. ISBN 978-1-84113-584-7.
  27. ^ Сетевая рабочая группа IETF, январь 2006 г., RFC 4343 : Разъяснение нечувствительности к регистру системы доменных имен (DNS)
  28. ^ a b RFC 3696 , Прикладные методы проверки и преобразования имен , Дж. Кленсин
  29. ^ Фудзивара, Кадзунори; Салливан, Эндрю; Хоффман, Пол. «Терминология DNS» . tools.ietf.org . Проверено 21 июня 2020 .
  30. ^ "Провайдеры игнорируют DNS TTL?" . Slashdot . 2005 . Проверено 7 апреля 2012 .
  31. Бен Андерсон (7 сентября 2011 г.). «Бен Андерсон: Почему кеширование DNS в веб-браузере может быть плохим» . Проверено 20 октября 2014 года .
  32. ^ «Как Internet Explorer использует кеш для записей хоста DNS» . Корпорация Microsoft . 2004 . Проверено 25 июля 2010 .
  33. ^ «Параметры системы доменных имен (DNS)» . IANA . DNS RCODE . Проверено 14 июня 2019 .
  34. ^ Джеймс Ф. Куроз и Кейт В. Росс, Компьютерные сети: подход сверху вниз, 6-е изд. Эссекс, Англия: Pearson Educ. Limited, 2012 г.
  35. ^ RFC 5395 , Соображения IANA по системе доменных имен (DNS) , Д. Истлейк, 3-е (ноябрь 2008 г.), раздел 3
  36. ^ RFC 5395 , Соображения IANA по системе доменных имен (DNS) , Д. Истлейк, 3-е (ноябрь 2008 г.), стр. 11
  37. ^ a b RFC 4592 , Роль подстановочных знаков в системе доменных имен , Э. Льюис (июль 2006 г.)
  38. ^ APWG. «Глобальный опрос о фишинге: использование доменных имен и тенденции в 1П2010». 15.10.2010 apwg.org Архивировано 3 октября 2012 г. на Wayback Machine
  39. ^ a b Хьюстон, Джефф (июль 2019 г.). «Конфиденциальность DNS и IETF» (PDF) . Журнал Интернет-протокола .
  40. ^ «Рабочий профиль протокола доступа к регистрационным данным (RDAP) для реестров и регистраторов рДВУ» . ICANN . 3 декабря 2015. Архивировано из оригинала 22 декабря 2015 года . Проверено 18 декабря 2015 .
  41. ^ «Найти регистратора» . VeriSign, Inc . Проверено 18 декабря 2015 .

Источники

  • Эванс, Клэр Л. (2018). Широкая группа: Нерассказанная история женщин, которые сделали Интернет . Нью-Йорк: Портфолио / Пингвин. ISBN 9780735211759.

внешняя ссылка

  • Викси, Пол (2007-04-01). «Сложность DNS» . Очередь ACM . Архивировано из оригинала на 2007-06-10.
  • Zytrax.com , Руководство с открытым исходным кодом - DNS для ученых-ракетчиков.
  • Управление Интернетом и система доменных имен: проблемы для исследовательской службы Конгресса США
  • Болл, Джеймс (28 февраля 2014 г.). «Познакомьтесь с семью людьми, у которых есть ключи к всемирной интернет-безопасности» . Хранитель . Guardian News & Media Limited . Проверено 28 февраля 2014 .