Система доменных имен

«DNS» перенаправляет здесь. Для других видов использования см. DNS (устранение неоднозначности) .

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

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

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

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

Система доменных имен первоначально использовала протокол Datagram пользователя (UDP) в качестве транспорта над IP. Надежность, безопасность и проблемы конфиденциальности породили использование протокола контроля передачи (TCP), а также многочисленные другие разработки протокола.

Функция

Часто используемая аналогия для объяснения DNS состоит в том, что он служит телефонной книгой для Интернета, переводя удобные для человека имена хостов компьютера в IP-адреса. Например, имя хоста www.example.com доменного пример рамках В . имени ​ ​ ​ ​ ​DNS может быть быстро и прозрачно обновлена, позволяя изменению местоположения службы в сети, не влияя на конечных пользователей, которые продолжают использовать то же имя хоста. Пользователи пользуются этим, когда они используют значимые равномерные локаторы ресурсов ( URL ) и адреса электронной почты, не зная, как компьютер на самом деле определяет услуги.

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

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

История

Использование более простого, более запоминающегося имени вместо численного адреса хозяина восходит к эпохе Arpanet . Исследовательский институт Стэнфорда (в настоящее время SRI International ) сохранил текстовый файл с именем hosts.txt , который сопоставлял имена хостов с числовыми адресами компьютеров на Arpanet. Элизабет Фейнлер разработала и поддерживала первый каталог Arpanet. Поддержание численных адресов, называемых списком назначенных чисел, было обработано Джоном Постелем в Южной Калифорнии Университета Институте информационных наук (ISI), чья команда тесно сотрудничала с SRI.

Адреса были назначены вручную. Компьютеры, включая их имена хостов и адреса, были добавлены в основной файл, связавшись с информационным центром SRI Network (NIC), режиссером Feinler по телефону в рабочее время. Позже Фейнлер установил каталог WHOIS на сервере в NIC для поиска информации о ресурсах, контактах и ​​объектах. Она и ее команда разработали концепцию доменов. Фейнлер предположил, что домены должны основываться на местоположении физического адреса компьютера. компьютеры в образовательных учреждениях будут иметь домен EDU . Например, Она и ее команда управляли реестрами именования ведущего с 1972 по 1989 год.

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

Целевая группа по инженерному интернет -инженерии опубликовала первоначальные спецификации в RFC 882 и RFC 883 в ноябре 1983 года. Они были обновлены в RFC 973 в январе 1986 года.

В 1984 году четыре студента UC Berkeley , Дуглас Терри, Марк Пейнтер, Дэвид Риггл и Сонниан Чжоу, написали первую Unix реализацию сервера имен для домена имени Интернета в Беркли, обычно называемой Bind . В 1985 году Кевин Данлэп из DEC существенно пересмотрел реализацию DNS. Майк Карелс , Фил Алмквист и Пол Викси затем взяли на себя обслуживание Bind. Консорциум Internet Systems был основан в 1994 году Риком Адамсом , Полом Викси и Карлом Маламудом , специально для предоставления дома для разработки и технического обслуживания Bind. Версии Bind с 4.9.3 были разработаны и поддерживались ISC, при поддержке спонсоров ISC. Как со-архитекторы/программисты, Боб Галли и Пол Викси выпустили первую, готовую к производству версии Bind версии 8 в мае 1997 года. С 2000 года более 43 различных основных разработчиков работали над Bind.

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

Структура

Доменное имя пространство

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

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

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

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

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

Окончательные описания правил формирования доменных имен появляются в RFC 1035, RFC 1123, RFC 2181 и RFC 5892. Доменное имя состоит из одной или нескольких частей, технически называемых метки , которые обычно объединяются и разграничиваются точки, такими, такими. as example.com.

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

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

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

Хотя технических ограничений не существует, чтобы предотвратить использование метков доменных имен от использования любого символа, представляющего октет, имена хостов используют предпочтительный формат и набор символов. разрешенные в метках, представляют собой подмножество набора символов ASCII , состоящее из символов A -Z Символы , , A -A -Z , цифр от 0 до 9 и дефиса. Это правило известно как правило LDH (буквы, цифры, дефис). Доменные имена интерпретируются независимым от случая. Метки могут не запускать или заканчивать с дефисом. Дополнительное правило требует, чтобы доменные имена верхнего уровня не были ячечны.

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

Название серверов

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

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

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

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

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

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

Когда сервер имен обозначен как авторитетный сервер для доменного имени, для которого он не имеет авторитетных данных, он представляет тип ошибки, называемой «хромой делегации» или «хромого ответа».

Операция

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

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

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

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

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

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

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

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

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

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

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

DNS Resolvers

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

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

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

Процедура итеративного запроса - это процесс, в котором DNS решает, запрашивает цепь одного или нескольких серверов DNS. Каждый сервер относится к клиенту на следующий сервер в цепочке, пока текущий сервер не сможет полностью разрешить запрос. Например, возможное разрешение www.example.com запрашивает глобальный корневой сервер, а затем сервер «com» ​​и, наконец, сервер "example.com".

Круглые зависимости и клейкие записи

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

В этом случае сервер имен, предоставляющий делегирование, также должен предоставить один или несколько IP -адресов для авторитетного сервера имен, упомянутого в делегировании. Эта информация называется клеем . Сервер делегирования имен предоставляет этот клей в форме записей в дополнительном разделе ответа DNS и предоставляет делегирование в разделе «Органа» ответа. Клейская запись - это комбинация сервера имен и IP -адрес.

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

Запишите кэширование

Общий подход к снижению бремени на серверах 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 домен-inddr.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. Серверы Арин Серверы 152.80.208.in-addr.arpa в Wikimedia, на который резольвер отправляет еще один запрос для 2.152.80.208.in-addr.arpa, что приводит к авторитетному ответу.

Поиск клиента

Последовательность разрешения DNS

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

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

Разбитые резолюры

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

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

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

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

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

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

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

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

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

Например:

• Адрес 203.0.113.5 включен в черный список. Это указывает на 5.113.0.203.blacklist.example , который решается до 127.0.0.1 .
• Адрес 203.0.113.6 не внесен в черный список и указывает на 6.113.0.203.blacklist.example . Это имя хоста либо не настроено, либо разрешается до 127.0.0.2 .

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

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

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

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

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

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

Заголовок Flags Format

Поле	Описание	Длина ( биты )
QR	Указывает, является ли сообщение запросом (0) или ответом (1)	1
ОПОД	Тип может быть запросом (стандартный запрос, 0), iQuery (обратный запрос, 1) или статус (запрос состояния сервера, 2)	4
Аа	Авторитетный ответ в ответ указывает, является ли DNS -сервер авторитетным для запроса hostName	1
ТК	Усечение, указывает на то, что это сообщение было усечено из -за чрезмерной длины	1
Rd.	Рекурсия требует, указывает, означает ли клиент рекурсивный запрос	1
Солнце	Рекурсия доступна в ответе, указывает, поддерживает ли ответ DNS -сервер рекурсив	1
С	Ноль, зарезервирован для будущего использования	3
RCODE	Код ответа, может быть noerror (0), formerr (1, ошибка формата), Servfail (2), nxdomain (3, не существующий домен) и т. Д.	4

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

Header DNS

Смещения		0								1								2								3
Октет	Кусочек	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
0	0	Идентификатор транзакции																Флаги
																		QR	ОПОД				Аа	ТК	Rd.	Солнце	С			RCODE
4	32	Количество вопросов																Количество ответов
8	64	Количество полномочий RRS																Количество дополнительных RR

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

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

Поля записи ресурсов (RR)

Поле	Описание	Длина ( октеты )
ИМЯ	Название запрошенного ресурса	Переменная
ТИП	Тип RR (A, AAAA, MX, TXT и т. Д.)	2
СОРТ	Код класса	2

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

Ресурсные записи

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

При отправке через сеть интернет -протоколов все записи (ответ, авторитет и дополнительные разделы) используют общий формат, указанный в RFC 1035:

Поля записи ресурсов (RR)

Поле	Описание	Длина ( октеты )
ИМЯ	Название узла, к которому относится эта запись	Переменная
ТИП	Тип RR в числовой форме (например, 15 для MX RR)	2
СОРТ	Код класса	2
Ттл	Подсчет секунды, что RR остается действительным (максимум 2 раза 2 31 −1, который составляет около 68 лет)	4
Rdlength	Длина поля RDATA (указано в октете)	2
Rdata	Дополнительные RR-специфические данные	Переменная, согласно

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

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

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

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

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

Wildcard Records

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

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

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

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

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

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

Динамические обновления DNS Используйте Update DNS OpCode для динамического добавления или удаления записей ресурсов из базы данных зоны, поддерживаемой на авторитетном DNS -сервере. Этот объект полезен для регистрации клиентов сети в DNS, когда они загружаются или становятся иным образом доступны в сети. Поскольку клиенту загрузки может быть назначен другой IP -адрес каждый раз с сервера DHCP , невозможно предоставить статические задания DNS для таких клиентов.

Транспортные протоколы

Со времени его происхождения в 1983 году DNS использовал пользовательский протокол Datagram (UDP) для транспортировки через IP. Его ограничения мотивировали многочисленные разработки протоколов для надежности, безопасности, конфиденциальности и других критериев в следующие десятилетия.

DNS над UDP/TCP/53 (DO53)

UDP резервирует порт номер 53 для серверов, слушающих запросы. Такие запросы состоят из прозрачного текстового запроса, отправленного в одном пакете UDP от клиента, ответил с помощью обратного текста, отправленного в один пакет UDP с сервера. Когда длина ответа превышает 512 байт, а также механизмы расширения поддержки клиента и сервера для DNS (EDN) могут использоваться большие пакеты UDP. Использование DNS над UDP ограничено, среди прочего, отсутствием шифрования транспортного слоя, аутентификации, надежной доставки и длины сообщений. В 1989 году RFC 1123 указал необязательный протокол контроля передачи (TCP) для запросов DNS, ответов и, в частности, передачи зон . С помощью фрагментации длинных ответов TCP позволяет более длительные ответы, надежную доставку и повторное использование долгоживущих соединений между клиентами и серверами. Для более крупных ответов сервер относится к клиенту к TCP Transport.

DNS над TLS (DOT)

В 2016 году DNS над TLS стал стандартом IETF для зашифрованных DNS, используя безопасность транспортного уровня (TLS) для защиты всего соединения, а не только полезной нагрузки DNS. Dot Servers слушают на порту TCP 853. RFC   7858 указывает, что оппортунистическое шифрование и аутентифицированное шифрование могут быть поддержаны, но не сделали ни сервера, ни аутентификации, ни клиента обязательной.

DNS над HTTPS (DOH)

DNS Over HTTPS был разработан в качестве конкурирующего стандарта для транспортировки запросов DNS в 2018 году, данные запросов DNS Tunneling DNS по HTTPS, который транспортирует HTTP через TLS. DOH был продвинут в качестве более удобной для веб-сайтов альтернативы DNS, поскольку, как и DNSCRYPT, он использует TCP-порт 443 и, таким образом, выглядит похоже на веб-трафик, хотя они легко дифференцируют на практике без надлежащей заполнения.

DNS Over Whate (Doq)

RFC 9250, опубликованный в 2022 году Целевой группой Internet Engineering , описывает DNS над QUIC . Он обладает «свойствами конфиденциальности, похожими на DNS по сравнению с TLS (DOT) [...], и задержки, аналогичные классическим DNS по UDP». Этот метод не совпадает с DNS, а не HTTP/3 .

Не обращая внимания на DOH (ODOH) и предшественник, не обращая внимания на DNS (ODNS)

Не обращая внимания на DNS (ODNS) был изобретен и реализован исследователями из Принстонского университета и Чикагского университета в качестве расширения на незашифрованные DNS, До того, как DOH был стандартизирован и широко развернут. Apple и Cloudflare впоследствии развернули технологию в контексте DOH, как не обращая внимания на DOH (ODOH). Odoh объединяет разделение Ingress/Egress (изобретено в ODN) с туннелированием HTTPS DOH и шифрованием транспортного слоя TLS в одном протоколе.

DNS над Tor

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

Dnscrypt

Протокол DNScrypt , который был разработан в 2011 году за пределами структуры стандартов IETF , введенный шифрование DNS на нижней стороне рекурсивных разрешений, в которых клиенты шифровали запросы, используя общественные ключи серверов, которые опубликованы в DNS (а не полагаются на треть. Сертификат Сертификата) и которые, в свою очередь, могут быть защищены подписями DNSSEC. DNSCRYPT использует либо TCP, либо UDP -порт 443, тот же порт, что и HTTPS зашифрованный веб -трафик. Это ввело не только конфиденциальность в отношении содержания запроса, но и значительную меру возможности брандмауэра. В 2019 году DNScrypt был дополнительно расширен для поддержки «анонимного» режима, аналогичного предлагаемому «не обращающим внимания DN Сервер, который действует как выходной узел, выполняя рекурсивное разрешение. Создается конфиденциальность паров пользователей/запросов, поскольку узел Ingress не знает содержания запроса, в то время как эмические узлы не знают идентификации клиента. DNSCRYPT был впервые реализован в производстве OpenDNS в декабре 2011 года. Существует несколько бесплатных реализаций программного обеспечения с открытым исходным кодом, которые дополнительно интегрируют ODOH. Он доступен для различных операционных систем, включая UNIX, Apple IOS, Linux, Android и Windows.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Альтернативный корень DNS
• Сравнение программного обеспечения DNS Server
• Децентрализованное местоположение объекта и маршрутизация
• Похищение домена
• DNS угон
• DNS долгоживущие запросы
• DNS Management Software
• DNS над HTTPS
• DNS над TLS
• Иерархическое пространство имен
• IPv6 Brokenness и DNS Whitelisting
• Многоадресная ткань DNS
• Общественный рекурсивный сервер имен
• Resolv.conf
• Split-Horizon DNS
• Список типов записей DNS
• Список управляемых поставщиков DNS
• Зона файл
• DNS утечка

Ссылки

Источники

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

Дальнейшее чтение

Стандарты трек

• RFC 1034 , доменные имена - концепции и объекты
• RFC 1035 , доменные имена - реализация и спецификация
• RFC 1123 , Требования к интернет -хостам - применение и поддержка
• RFC 1995 , инкрементная зона переноса в DNS
• RFC 1996 , механизм для быстрого уведомления об изменениях зоны (DNS уведомление)
• RFC 2136 , Динамические обновления в системе доменных имен (обновление DNS)
• RFC 2181 , разъяснения спецификации DNS
• RFC 2308 , Отрицательное кэширование запросов DNS (DNS NCACHE)
• RFC 3225 , что указывает на поддержку резолюции DNSSEC
• RFC 3226 , DNSSEC и IPv6 A6 SERVER/SERVER SERVER/RESOLVER Размер сообщений Требования
• 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 Security Security (DNSSEC)
• RFC 5452 , Меры по обеспечению DNS более устойчивости против кованых ответов
• RFC 5890 , Интернационализированные доменные имена для приложений (IDNA): определения и структура документов
• RFC 5891 , Интернационализированные доменные имена в приложениях (IDNA): протокол
• RFC 5892 , точки кода Unicode и интернационализированные доменные имена для приложений (IDNA)
• RFC 5893 , Сценарии справа налево для интернационализированных доменных имен для приложений (IDNA)
• RFC 6672 , перенаправление имени DNS без терминала DNS
• RFC 6891 , Механизмы расширения для DNS (EDNS0)
• RFC 7766 , DNS Transport Over TCP - требования к реализации
• RFC 8945 , Аутентификация Transaction Transaction Secret Key для DNS (TSIG)

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

• RFC 4033 , DNS Security Введение и требования
• RFC 4034 , Записи ресурсов для расширений безопасности DNS
• RFC 4035 , Модификации протокола для расширений безопасности DNS
• RFC 4509 , Использование SHA-256 в DNSSEC DELEGTION SIGNER (DS) Records
• RFC 4470 , минимально охватывая записи NSEC и онлайн-подпись DNSSEC
• RFC 5155 , DNS Security Security (DNSSEC) Хэшированный аутентифицированный отказ в существовании
• RFC 5702 , Использование алгоритмов SHA-2 с RSA в DNSKEY и RRSIG Resource Records для DNSSEC
• RFC 5910 , Система доменных имен (DNS) Сопоставление расширений для расширяемого протокола обеспечения (EPP)
• RFC 5933 , Использование алгоритмов подписи GOST в DNSKEY и RRSIG Resource Records для 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 , Соображения IANA System (DNS) (DNS) (BCP 42)
• RFC 7720 , протокол службы и развертывания DNS -имени (BCP 40)

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

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

• RFC 1178 , выбор имени для вашего компьютера (к вашему сведению 5)
• RFC 1591 , Структура системы и делегирование доменных имен
• RFC 1912 , общие ошибки в эксплуатации и конфигурации DNS
• RFC 2100 , именование хозяев
• RFC 3696 , Методы применения для проверки и преобразования имен
• RFC 3833 . Анализ угроз системы доменных имен (DNS)
• RFC 4892 , Требования к механизму, идентифицирующий экземпляр сервера имен
• RFC 5894 , Интернационализированные доменные имена для приложений (IDNA): фон, объяснение и обоснование
• RFC 5895 , отображение символов для интернационализированных доменных имен в приложениях (IDNA) 2008
• RFC 8806 , запустив корневой сервер, локальный для разрешения
• RFC 9076 , соображения конфиденциальности DNS
• RFC 9156 , DNS -запрос минимизации имени для повышения конфиденциальности
• RFC 9499 , DNS -терминология

Неизвестный

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

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

Внешние ссылки

• Викси, Пол (4 мая 2007 г.). «Сложность DNS» . Acm queue . Архивировано из оригинала 29 марта 2023 года.
• Болл, Джеймс (28 февраля 2014 г.). «Познакомьтесь с семью людьми, которые держат ключи от всемирной интернет -безопасности» . Хранитель . Guardian News & Media Limited . Получено 28 февраля 2014 года .
• Крюгер, Леннард Г. (18 ноября 2016 г.). «Управление интернетом и система доменных имен: проблемы для Конгресса» (PDF) . Исследовательская служба Конгресса . Получено 27 июля 2024 года .
• Zytrax.com , Руководство с открытым исходным кодом - DNS для ученых -ракетологи.
• Старайтесь с DNS - сайтом, где вы можете провести эксперименты с DNS.