Войти
Система доменных (DNS ) - это иерархическая и децентрализованная система именования компьютеров, служб или других ресурсов, подключенных к Интернету. или частная сеть. Он связывает различную информацию с доменными именами, присвоенными каждой из участвующих организаций. Наиболее заметно то, что он преобразует более легко запоминаемые имена доменов в числовые IP-адреса, необходимые для обнаружения и идентификации компьютерных служб и устройств с базовыми сетевыми протоколами. Предоставляя всемирную распределенную службу каталогов, систему доменных важных компонентов функциональности Интернета с 1985 года.
Система доменных делегирует полномочия за присвоение доменных имен и сопоставление этих имен с Интернет-ресурсами путем назначения авторитетных серверов имен для каждого домена. Сетевые администраторы могут делегировать полномочия над субдоменами выделенного им пространства имен другим серверам имен. Этот механизм предоставлен и отказоустойчивую службу и был разработан, чтобы избежать единой большой центральной базы данных.
Система доменных имен включает также технические функции службы базы данных, которая является ее ядром. Он определяет протокол DNS, подробную спецификацию структуры данных и данных, используется в DNS, как часть Internet Protocol Suite.
. Интернет поддерживает два основных пространства имен, домен иерархия имен и Интернет-протокол (IP) адресные пространства. Система доменных имен поддерживает услуги перевода между ней и другими пространствами. Интернет-серверы имен и протокол связи реализуют систему доменных имен. Сервер имен DNS - это сервер, на котором хранятся записи DNS для домена; сервер имен DNS отвечает на запросы к своей базе данных.
Наиболее распространенные типы записей, хранящиеся в базе данных DNS, - это для начала авторизации (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 является ее центральной ролью в распределенных интернет-сервисах, таких как облачные сервисы и сети доставки контента. Когда пользователь обращается к распределенной интернет-службе с помощью URL-адреса, доменное имя URL-адреса преобразуется в IP-адрес сервера ближайшего к пользователю. Ключевая функциональность используемого здесь DNS заключается в том, что разные пользователи могут одновременно получать разные переводы для одного и того же доменного имени, что является ключевым моментом отклонения от традиционного представления DNS с помощью телефонной книги. Этот процесс использования DNS для назначения ближайших серверов пользователей является ключом к обеспечению более быстрых и надежных ответов в Интернете и широко используется большинством основных интернет-сервисов.
DNS отражает структуру административной ответственности в Интернет. Каждый поддомен представляет собой зону зоны административной автономии, диспетчерскую систему. Для зон, управляемых реестром , административная информация часто дополняется регистр RDAP и WHOIS. Эти можно использовать для получения информации о конкретном хосте в Интернете и данных за него.
Использование более простого, более запоминающегося адреса вместо числовых адресов хоста назад в эпоху ARPANET. Стэнфордский исследовательский институт (ныне SRI International ) поддерживал текстовый файл с именем HOSTS.TXT, который сопоставляет имена хостов с числовыми компьютерами в ARPANET. Элизабет Фейнлер разработан и поддерживает первый каталог ARPANET. Поддержкой числовых адресов, называемой списком присвоенных номеров, занимался Джон Постел в Институте информационных наук (ISI) Университета Южной Калифорнии, чей команда сотрудничества сотрудничала с НИИ.
Адреса назначались вручную. Сетевой информационный центр (NIC) SRI, управляемый Элизабет Фейнлер, по телефону в рабочее время, были добавлены в основной файл обращения по телефону. Позже Фейнлер создал каталог WHOIS на сервере в сетевом адаптере для получения информации о ресурсах, контактах и объектах. Она и ее команда разработали концепцию доменов. Фейнлер предположил, что домены должны основываться на местонахождении физического адреса компьютера. Например, компьютеры в образовательных учреждениях будут иметь домен edu. Она и ее команда управляли реестром именования хостов с 1972 по 1989 год.
К началу 1980-х поддержание единой централизованной таблицы хостов стало медленным и громоздким, и развивающаяся сеть требовала автоматизированная система именования для решения технических и кадровые вопросы. Постел поручил найти компромисс между пятью конкурирующими предложениями решений Полу Мокапетрису. Вместо этого Mockapetris создал систему доменных имен в 1983 году.
Инженерная группа Интернета опубликовала исходные спецификации в RFC 882 и RFC 883 в Ноябрь 1983 г.
В 1984 г. четыре студента Калифорнийского университета в Беркли, Дуглас Терри, Марк Пейнтер, Дэвид Риггл и Сонниан Чжоу, написали первый образец сервера Unix для Интернет-домена имени Беркли, обычно называемый BIND. В 1985 году Кевин Данлэп из DEC начался пересмотрел DNS. Майк Карелс, Фил Алмквист и Пол Викси с тех пор BIND. В начале 1990-х BIND был перенесен на платформу Windows NT.
В ноябре 1987 года RFC 1034 и RFC 1035 заменили спецификацию DNS 1983 года. Несколько дополнительных запросах комментариев были предложены расширения основных протоколов DNS.
Пространство доменных имен состоит из древовидная структура данных. Каждый узел или лист в дереве имеет метку и ноль или более записей ресурсов (RR), которые содержат информацию, связанную с именем домена. Само доменное имя состоит из метки, соединенной с именем его родительского узла справа, разделенным точкой.
Дерево подразделяется на зоны, начиная с указанной зоны. Зона DNS может состоять только из одного домена или может состоять из множества доменов и поддоменов, в зависимости от административного выбора диспетчера зоны. DNS также можно разделить по классам, при этом отдельные классы можно рассматривать как массив параллельных пространств имен.
Иерархическая система доменных имен для класса Интернет, организованная в зоне, каждая из которых обслуживается сервером имен Административная ответственность за любую зону может быть разделена путем создания дополнительных зон. Говорят, что установлены полномочия на новую зону назначенному серверу. Родительская зона перестает быть авторитетной для новой зоны.
Окончательное описание правил формирования доменных имен содержится в RFC 1035, RFC 1123, RFC 2181 и RFC 5892. Доменное имя состоит из одной или нескольких частей, технически называемых метками, которые условно объединены и разделены точками, например example.com.
Крайняя правая метка обозначает домен верхнего уровня ; например, доменное имя www.example.com принадлежит домену верхнего уровня com.
Иерархия доменов спускается справаево; каждая метка слева определяет подразделение или субдомен домена справа. Например, в примере метки указывается поддомен домена com, а www - поддомен домена example.com. Это дерево подразделений может иметь до 127 уровней.
Метка может содержать от нуля до 63 символов. Пустая метка нулевой длины зарезервирована для центральной зоны. Полное доменное имя не может быть верной 253 символа в его текстовом представлении. Во внутреннем двоичном представлении DNS максимальная длина требует хранения 255 октетов, так как в нем также хранится длина имени.
Хотя не существуют технические ограничения на использование любых символов в метках имени домена, которые могут быть представлены октет, имена хостов используют предпочтительный формат и набор символов. Допустимые символы в метках - это подмножество набора символов ASCII, состоящее из символов от a до z, от A до Z, цифр от 0 до 9 и дефиса. Это правило известно как правило LDH (буквы, цифры, дефис). Доменные имена интерпретируются независимо от регистратора. Ярлыки не могут начинаться или заканчиваться дефисом. Дополнительное правило требует, чтобы имена доменов верхнего уровня не были полностью числовыми.
Ограниченный набор символов ASCII, разрешенный в DNS, препятствие представлению имен и слов многих языков в их алфавитах или сценариях. Чтобы это возможным, ICANN утвердила систему интернационализации доменных имен в приложениях (IDNA), с помощью которой можно сделать пользовательские приложения, такие как веб-браузеры, отображают строки Unicode в допустимый набор символов DNS с использованием Punycode. В 2009 году ICANN одобрила установку интернационализированных доменных имен национальных доменов верхнего уровня (ccTLD). Кроме многих реестры существующих именных верхних уровней (TLD ) приняли систему 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». Логин: подсказки системных адресов корневых серверов имен. Подсказки периодически обновляются администратором, получая набор данных из надежного источника.
Предположение, что преобразователь не имеет кэшированных записей для ускорения процесса, процесс разрешения начинается с запроса одного из корневых серверов. При обычной работе корневые серверы не отвечают напрямую, а отвечают на запросы более авторитетные серверы, например, запрос «www.wikipedia.org» относится к серверу организации. Теперь преобразователь упомянутые серверы и итеративно повторяет этот процесс, пока не получит достоверный ответ. Схема иллюстрирует этот процесс для хоста, который назван полным доменным именем «www.wikipedia.org».
Этот механизм создает большую нагрузку на трафик на корневые серверы, если разрешение в Интернете требует запуска с корневого сервера. На практике кэширование используется в DNS-сервере для разгрузки корневых серверов, и в результате корневые серверы фактически участвуют только в относительно небольших частях всех запросов.
Теоретически авторитетных серверов имен достаточно для работы в Интернете. Однако при работе только авторитетных серверов имен каждый DNS-запрос должен начинаться с рекурсивных запросов в центральной зоне системы доменных имен, и каждая пользовательская система должна быть представлена программное обеспечение преобразователя, способное ккурсивной работе.
Для повышения эффективности, уменьшения трафика DNS через Интернет и повышения производительности приложений конечных пользователей система доменных поддерживает кэш-серверы DNS, которые хранят результаты запросов DNS в течение периода определенного в конфигурации (время жизни ) рассматриваемой записи доменного имени. Обычно такие кэширующие DNS-серверы также реализуют рекурсивный алгоритм, необходимое для разрешения заданного имени, начиная с корня DNS, и заканчивая официальными серверами имен запрашиваемого домена. Благодаря этой функции, реализованной на сервере имен, пользовательские приложения повышают эффективность разработки и эксплуатации.
Комбинация DNS-кэширования и рекурсивных функций на сервере имен не является обязательной; функции могут быть реализованы независимо на серверах специального назначения.
Интернет-провайдеры обычно предоставляют своим клиентам рекурсивные и кэширующие серверы имен. Кроме того, многие домашние сетевые маршрутизаторы реализуют кэши и рекурсоры DNS для повышения эффективности локальной сети.
Клиентская сторона DNS называется преобразователем DNS. Сопоставитель отвечает за инициирование и упорядочение запросов, которые в конечном итоге приводят к полному разрешению (трансляции) искомого ресурса, например, трансляции доменного имени в IP-адрес. Преобразователи DNS классифицируются по множеству методов запросов, например рекурсивным, нерекурсивным и итеративным. В процессе разрешения может использоваться комбинация этих методов.
В нерекурсивном запросе преобразователь DNS запрашивает DNS-сервер, который предоставляет запись, для которой сервер является авторитетным, или предоставляет частичный результат без запросы к другим серверам. В случае кэширующего DNS-преобразователя нерекурсивный запрос его локального DNS-кеша дает результат и снижает нагрузку на вышестоящие DNS-серверы за счет кэширования записей ресурсов DNS на период время после первоначального ответа от вышестоящих DNS-серверов.
В рекурсивном запросе преобразователь DNS запрашивает один DNS-сервер, который, в свою очередь, может запрашивать другие DNS-серверы от имени запрашивающей стороны. Например, простой преобразователь заглушек, работающий на домашнем маршрутизаторе , обычно выполняет рекурсивный запрос к DNS-серверу, запущенному пользователем ISP. Рекурсивный запрос - это запрос, для которого 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. Для этого необходимо сначала разрешить example.org, которая представляет собой Соединенную Конвенцию. Чтобы разорвать зависимость, сервер имен для домена верхнего уровня org включает клей вместе с делегированием для example.org. Связующие записи - это записи, которые создают IP-адреса для ns1.example.org. Сопоставитель использует один или несколько из этих IP-адресов для одного запроса из авторитетных серверов домена, что позволяет ему выполнить DNS-запрос.
Стандартной практикой при реализации разрешения в приложениях является нагрузка на серверы системы доменных имен путем кэширования результатов локально или на промежуточных узлах преобразователя. Результаты, полученные из запроса DNS, всегда связаны со временем жизни (TTL), срок действия которого, по истечении которого результаты должны быть отброшены или обновлены. TTL устанавливается администратором полномочного DNS-сервера. Срок действия может действовать от нескольких секунд до дней или даже недель.
В результате этой распределенной работы кэширования изменений в локальной сети не требуются распространенные сроки всех кешей истек и обновлялся после TTL. RFC 1912 передает основные правила для соответствующих значений TTL.
Некоторые распознаватели могут переопределять значения TTL, поскольку протокол поддерживает кэширование на до шестидесяти восьми лет или вообще не поддерживает срок кэширования. Отрицательное кэширование, то есть кэширование факта записи, которая должна исходная запись Start of Authority (SOA), когда сообщение об отсутствии данных запрошенного типа. Значение минимального поля записи SOA и TTL самого SOA используется для определения TTL для отрицательного ответа.
A обратный поиск 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, или указав, что доменное имя не существует только потому, что один из его серверов имен не существует. не отвечает.
Некоторые приложения, такие как веб-браузеры, внутренний кеш DNS, чтобы избежать повторных поисков по сети. Эта практика может добавить дополнительные трудности при отладке проблем DNS, поскольку она скрывает такие данные. Эти кеши обычно используют очень короткое время кэширования, порядка одной минуты.
Internet Explorer представляет собой заметное исключение: версии до IE 3.x по умолчанию кэшируют записи DNS на 24 часа. Internet Explorer 4.x и более поздние версии (до IE 8) уменьшают значение тайм-аута по умолчанию до получаса, которое можно изменить, изменить конфигурацию по умолчанию.
Когда Google Chrome обнаруживает проблемы с DNS-сервером, он отображает конкретное сообщение об ошибке.
Система доменных имен включает в себя несколько других функций и возможностей.
Имена хостов и IP-адреса не обязательно должны совпадать однозначно. Несколько имен хостов могут соответствовать одному IP-адресу, что полезно в виртуальном хостинге, в котором многие веб-сайты обслуживаются с хоста. В качестве альтернативы, одно имя хоста может разрешить во множестве IP-адресов, чтобы облегчить отказоустойчивость и распределение нагрузки на нескольких экземплярах сервера в рамках предприятия или в глобальной сети Интернет.
DNS служит другим целям в дополнение к преобразованию имен в IP-адреса. Например, агенты передачи почты используют DNS, чтобы найти лучший почтовый сервер для доставки электронной почты : запись MX обеспечивает сопоставление между доменом и почтой. обменник; это может обеспечить дополнительный уровень отказоустойчивости и распределения нагрузки.
DNS используется для эффективного хранения и распределения IP-адресов электронной почты, занесенных в черный список. Распространенный метод состоит в том, чтобы использовать IP-адрес рассматриваемого хоста в субдоменном доменном имени более высокого уровня и преобразовать это имя в записи, указывает положительное или отрицательное значение.
Например:
Сервер электронной почты могут запрашивать черный список. Пример, чтобы узнать, находится ли конкретный подключенный к ним хост в черном списке. Многие из таких черных списков, как по подписке, так и бесплатно, доступны для использования администраторами электронной почты и программным обеспечением для защиты от спама.
Обычно предоставляется несколько серверов DNS для покрытия каждого домена. На уровне глобального DNS существует тринадцать групп корневых серверов имен с дополнительными «копиями», распространяемыми по миру через адресацию anycast.
Динамический DNS (DDNS) обновляет DNS-сервер с помощью IP-адреса клиента на лету, например, при перемещении между интернет-провайдерами или мобильными горячими точками или при изменении IP-адреса административно.
Протокол DNS использует два типа сообщений DNS: запросы и ответы; оба имеют одинаковый формат. Каждое сообщение состоит из заголовка и четырех разделов: вопрос, ответ, авторитетность и дополнительное пространство. Поле заголовка (флаги) контролирует содержимое этих четырех разделов.
Раздел заголовка состоит из следующих: идентификация, флаги, количество вопросов, ответов, количество авторитетных ресурсных записей (RR), и Количество дополнительных РУ. Каждое поле имеет длину 16 бит и отображается в указанном порядке. Поле идентификации используется для сопоставления ответов с запросами. Поле флага состоит из следующих подполей:
| Поле | Описание | Длина (биты ) |
|---|---|---|
| QR | Указывает, является ли сообщение запросом (0) или ответ (1) | 1 |
| OPCODE | Тип может быть QUERY (стандартный запрос, 0), IQUERY (обратный запрос, 1) или STATUS (запрос состояния сервера, 2) | 4 |
| AA | Авторитетный ответ в ответе указывает, ли DNS-сервер авторитетным для запрошенного имени хоста | 1 |
| TC | TrunCation, указывает, что это сообщение было усечено из-за чрезмерной длины | 1 |
| RD | Требуется рекурсия, указывает, имеет ли клиент рекурсивный запрос | 1 |
| RA | Доступна рекурсия в ответе указывает, поддерживает ли отвечающий DNS-сервер рекурсию | 1 |
| Z | Ноль, зарезервировано для будущего использования | 3 |
| RCODE | Код ответа, может быть NOERROR (0), FORMERR (1, Ошибка формата), SERVFAIL (2), NXDOMAIN (3, Несуществующий домен) и т. Д. | 4 |
После флага заголовок заканчивается четырьмя 16-битными целыми числами, которые содержат количество записей в каждом из с ледующих разделов, в такой же порядок.
Раздел вопросов имеет более простой формат, чем формат записи ресурсов, используемых в других разделах. Каждая запись вопроса (обычно в разделе всего одна) содержит следующие поля:
| Поле | Описание | Длина (октеты ) |
|---|---|---|
| NAME | Имя запрошенного ресурса | Переменная |
| TYPE | Тип RR (A, AAAA, MX, TXT и т. Д.) | 2 |
| КЛАСС | Код класса | 2 |
Имя домена разбито на метки, которые являются; каждая метка имеет префикс этой объединенной метки.
DNS в основном использует протокол пользовательских дейтаграмм (UDP) на номер порта 53 для обслуживания запросов. DNS-запросы состоят из одного запроса UDP от клиента, за которым следует один ответ UDP от сервера. Когда длина ответа превышает 512 байт. и клиент, и сервер поддерживают EDNS, используются более крупные пакеты UDP. В противном случае запрос снова отправляется с использованием протокола управления передачей (TCP). TCP также используется для таких задач, как зональные передачи. Поэтому мои реализации преобразователя используют TCP по всем запросам.
Система доменных имен определяет базу данных информационных элементов для сетевых ресурсов. Типы информационных элементов разделены на категории и организованы с помощью списка типов записей DNS, записей ресурсов (RR). Каждая запись имеет тип (имя и номер), срок действия (время жизни ), класс и данные, зависящие от типа. Записи ресурсов одного и того же типа описываются как набор записей ресурсов (RRset), не имеющий особого порядка. Преобразователи DNS возвращают весь набор по запросу, но серверы могут реализовать циклическое упорядочение для достижения балансировки нагрузки. Напротив, расширения безопасности системы доменных имен (DNSSEC) работают с полным набором записей ресурсов в каноническом порядке.
При отправке по сети Интернет-протокол все записи используют общий формат, указанный в RFC 1035 :
| Поле | Описание | Длина (октеты ) |
|---|---|---|
| ИМЯ | Имя узла, к которому относится эта запись | Переменная |
| ТИП | Тип RR в числовой форме (например, 15 для MX RR) | 2 |
| CLASS | Код класса | 2 |
| TTL | Количество секунд, в течение которых RR остается действительным (максимум 2-1, что составляет около 68 лет) | 4 |
| RDLENGTH | Длина поля RDATA (указывается в октетах) | 2 |
| RDATA | Дополнительные данные, специфичные для RR | Переменная, согласно RDLENGTH |
ИМЯ - это полное доменное имя узла в дереве. На проводе имя может быть сокращено с использованием сжатия меток, где концы доменных имен, упомянутых ранее в пакете, могут быть заменены на конец текущего домена. name.
TYPE - это тип записи. Он указывает формат данных и дает представление о предполагаемом использовании.. Например, запись A используется для преобразования доменного имени в адрес IPv4, запись NS перечисляет, какие серверы имен могут отвечать на запросы в зоне DNS, а запись MX указывает почтовый сервер, используемый для обработки почты для домена, указанного в адресе электронной почты.
RDATA - это данные, относящиеся к конкретному типу, такие как IP-адрес для записей адресов или приоритет и имя хоста для записей MX. Хорошо известные типы записей могут использовать сжатие меток в поле RDATA, но «неизвестные» типы записей не должны (RFC 3597 ).
КЛАСС записи установлен на IN (для Интернета) для общих записей DNS, включающих имена узлов Интернета, серверы или IP-адреса. Кроме того, существуют классы Хаос (CH) и Гесиод (HS). Каждый класс представляет собой независимое пространство имен с разными представителями зонами DNS.
В дополнение к другим параметрам, определенным в файле зоны, система доменных имен также использует несколько типов DNS (на проводе), например, при выполнении зональных передач (AXFR / IXFR) или для EDNS (OPT).
Система доменных имен поддерживает записи DNS с подстановочными знаками, которые определяют имена, начинающиеся с метки звездочки, '*', например, *. пример. Записи DNS, принадлежащие доменным именам с подстановочными знаками, определяют правила для создания ресурсов ресурсов в пределах одной зоны DNS путем замены целых меток поставщиком компонентов имени запроса, включая любые потомки. Например, в следующей конфигурации зоны DNS x.example указывает, что все субдомены, включая субдомены субдоменов, x.example использовать почтовый обменник (MX) a.x.example. Запись A для примера a.x. необходимы для указания IP-адреса почтового обменника. Так как это приводит к исключению этого доменного имени и его поддоменов из подстановочных совпадений, в зоне DNS должна быть определена дополнительная запись MX для субдомена, например, а также запись MX с подстановочными знаками для всех его субдоменов.
х. Пример. MX 10 a.x., пример. *.x.example. MX 10 a.x., пример. *.a.x.example. MX 10 a.x., пример. a.x. пример. MX 10 a.x., пример. a.x. пример. AAAA 2001: db8 :: 1
Роль записей с подстановочными знаками была уточнена в RFC 4592, поскольку исходное определение в RFC 1034 было неполным и приводило к неправильной интерпретации разработчикам.
Исходный протокол 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 могут быть одинаковыми на экранах обычных компьютеров. Эта уязвимость иногда используется в фишинге..
Такие методы, как обратный DNS с прямым подтверждением, также можно использовать для проверки результатов DNS.
DNS может также «просачиваться» из безопасных или отдельных соединений, если не уделять внимания их конфигурации, и DNS использовался злоумышленниками для обхода межсетевых экранов и эксфильтрации данных, поскольку его часто считают безобидным.
Первоначально пример как общедоступная, иерархическая, распределенная сильно и сильно кэшируемая база данных, протокол DNS не имеет средств контроля конфиденциальности. Запросы пользователей и ответы серверов имен отправляются в незашифрованном виде, что позволяет перехватить сетевые пакеты, перехватить DNS, отравить кеш DNS и посредник атаки. Этот недостаток обычно используется киберпреступниками и сетевыми операторами в маркетинговых целях, аутентификации пользователей на переадресованных порталах и цензуре.
Конфиденциальность пользователей раскрывается предложениями по увеличению уровня IP-информации клиентов в DNS. запросы (RFC 7871 ) в интересах сетей доставки контента.
Основные подходы, которые используются для решения проблем конфиденциальности DNS:
Решения, предотвращающие проверку DNS оператором локальной сети, критикуются за нарушение политик безопасности корпоративных сетей и цензуру в Интернете. Их также критикуют с точки зрения конфиденциальности, поскольку они передают разрешение DNS в руки небольшого числа компаний, известной монетизацией пользовательского трафика и централизацией разрешения имен DNS, что обычно считается вредным для Интернета.
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. Регистрант - это физическое или юридическое лицо, запросившее регистрацию домена. Реестр получает регистрационную информацию от каждого регистратора доменных имен, уполномоченный (аккредитован) назначать имена в зоне регистрации и публикует информацию с использованием протокола WHOIS. По состоянию на 2015 год рассматривается возможность использования RDAP.
ICANN публикует полный список TLD, реестров TLD и регистраторов доменных имен. Информация о регистранте, связанная с доменными именами, хранится в онлайн-базе данных, доступной через службу WHOIS. Для более чем 290 доменов верхнего уровня (ccTLD) с кодом страны реестры доменов информацию WHOIS (регистрант, серверы, даты истечения срока действия и т. Д.). Например, DENIC, Германия NIC, содержит данные домена DE. Примерно с 2001 года большинства реестров общих доменов верхнего уровня (gTLD) применяют так называемый подход с расширенным реестром, то есть хранятся данные WHOIS в центральных реестрах, а не в базах данных регистраторов.
Для доменов верхнего уровня в COM и NET используется тонкая модель реестра. Реестр доменов (например, GoDaddy, BigRock и PDR, VeriSign и т. Д. И т. Д.) Содержит основные данные WHOIS (т. Е. Регистратор и серверы имен, так далее.). С другой стороны, организации или зарегистрированные лица, использующие ORG, находятся исключительно в Реестре общественных интересов.
Некоторые реестрыенных доменных имен, часто называемые сетевыми информационными центрами (NIC), также как регистраторы для конечных пользователей, помимо предоставления доступа к наборам данных WHOIS. Реестры доменов верхнего уровня, такие как домены COM, NET и ORG, используют модель регистратор-регистратор, состоящую из множества регистраторов доменных имен. При этом методе управления реестр управляет только базой данных доменных имен и отношений с регистраторами. Регистранты (пользователи доменного имени) являются клиентами регистратора, в некоторых случаях посредством дополнительного субподряда с торговыми посредниками.
Система доменных названных документовми Запрос комментариев (RFC), опубликованных Инженерное задание Интернета Принудительно (Интернет-стандарты ). Ниже приведен список RFC, определяющий протокол DNS.
Эти RFC носят рекомендательный характер, но могут содержать полезную информацию, несмотря на то, что не определяют ни стандарта, ни BCP. (RFC 1796 )
Эти RFC имеют официальный статус Неизвестно, но из-за возраста их четко обозначены как таковые.
Интернет портал  | Викиверситет содержит обучающие ресурсы по доменному имени Система |
