Система доменных имен - Domain Name System

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

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

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

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

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

Функция

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

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

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

История

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

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

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

Engineering Task Force Интернета опубликовал исходные спецификации в 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 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».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обратный поиск

Обратный поиск DNS является запросом на DNS для доменных имен , когда IP - адрес известен. С IP-адресом может быть связано несколько доменных имен. DNS хранит IP-адреса в форме доменных имен как имена в специальном формате в записях указателей (PTR) внутри домена верхнего уровня инфраструктуры arpa . Для IPv4 это домен in-addr.arpa. Для IPv6 домен обратного просмотра - ip6.arpa. IP-адрес представлен в виде имени в обратном порядке представления октетов для IPv4 и в виде полубайтов в обратном порядке для IPv6.

При выполнении обратного поиска клиент DNS преобразует адрес в эти форматы перед запросом имени для записи PTR, следующей за цепочкой делегирования, как для любого запроса DNS. Например, если для Викимедиа назначен IPv4-адрес 208.80.152.2, он будет представлен как DNS-имя в обратном порядке: 2.152.80.208.in-addr.arpa. Когда преобразователь DNS получает запрос указателя (PTR), он начинает с запроса корневых серверов, которые указывают на серверы Американского реестра Интернет-номеров (ARIN) для зоны 208.in-addr.arpa. Серверы ARIN делегируют 152.80.208.in-addr.arpa в Wikimedia, которому преобразователь отправляет другой запрос для 2.152.80.208.in-addr.arpa, что приводит к авторитетному ответу.

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

Формат флагов заголовков
Поле Описание Длина ( бит )
QR Указывает, является ли сообщение запросом (0) или ответом (1) 1
OPCODE Тип может быть QUERY (стандартный запрос, 0), IQUERY (обратный запрос, 1) или STATUS (запрос состояния сервера, 2). 4
AA Авторитетный ответ в ответе указывает, является ли DNS-сервер авторитетным для запрашиваемого имени хоста. 1
TC TrunCation, указывает, что это сообщение было усечено из-за чрезмерной длины. 1
RD Требуется рекурсия, указывает, имеет ли клиент в виду рекурсивный запрос. 1
РА Доступная рекурсия в ответе указывает, поддерживает ли отвечающий DNS-сервер рекурсию. 1
Z Ноль, зарезервировано для использования в будущем 3
RCODE Код ответа может быть NOERROR (0), FORMERR (1, ошибка формата), SERVFAIL (2), NXDOMAIN (3, несуществующий домен) и т. Д. 4

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

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

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

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

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

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

DNS-over-UDP / 53 ("Do53")

С момента своего создания в 1983 году и до недавнего времени DNS в основном отвечал на запросы по протоколу пользовательских дейтаграмм (UDP) номер порта 53. Такие запросы состоят из запроса в открытом виде, отправленного в одном пакете UDP от клиента, на который в ответ был получен ответ. ответ в виде открытого текста, отправленный с сервера в виде одного пакета UDP. Если длина ответа превышает 512 байт и и клиент, и сервер поддерживают механизмы расширения для DNS (EDNS), могут использоваться более крупные пакеты UDP. Использование DNS-over-UDP ограничено, среди прочего, отсутствием в нем шифрования транспортного уровня, аутентификации, надежной доставки и длины сообщения.

DNS-over-TCP / 53 ("Do53 / TCP")

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

DNSCrypt

Протокол DNSCrypt , который был разработан в 2011 году вне рамок стандартов IETF, представил шифрование DNS на нисходящей стороне рекурсивных преобразователей, в котором клиенты шифруют полезные данные запросов с помощью открытых ключей серверов, которые публикуются в DNS (вместо того, чтобы полагаться на третьи стороны). сторонние центры сертификации), которые, в свою очередь, могут быть защищены подписями DNSSEC. DNSCrypt использует TCP или UDP-порт 443, тот же порт, что и зашифрованный веб-трафик HTTPS. Это обеспечило не только конфиденциальность содержимого запроса, но и значительную меру возможности обхода межсетевого экрана. В 2019 году DNSCrypt был дополнительно расширен для поддержки «анонимного» режима, аналогичного предлагаемому «Oblivious DNS», в котором входной узел получает запрос, зашифрованный открытым ключом другого сервера, и передает его этому сервер, который действует как выходной узел, выполняя рекурсивное разрешение. Конфиденциальность пар пользователь / запрос создается, поскольку входной узел не знает содержимого запроса, а выходные узлы не знают личности клиента. DNSCrypt был впервые внедрен OpenDNS в декабре 2011 года.

DNS-over-TLS («DoT»)

Стандарт IETF для зашифрованного DNS появился в 2016 году, использующий стандартную безопасность транспортного уровня (TLS) для защиты всего соединения, а не только полезной нагрузки DNS. Серверы DoT прослушивают TCP-порт 853. RFC7858 указывает, что может поддерживаться гибкое шифрование и аутентифицированное шифрование, но не делает обязательной аутентификацию сервера или клиента.

DNS-over-HTTPS ("DoH")

В 2018 году был представлен конкурирующий стандарт для транспорта запросов DNS, туннелирующий данные запросов DNS через HTTPS (который, в свою очередь, передает HTTP через TLS). DoH продвигался как более удобная для Интернета альтернатива DNS, поскольку, как и DNSCrypt, он передается через TCP-порт 443 и, таким образом, похож на веб-трафик, хотя на практике они легко различимы. DoH широко критиковали за снижение анонимности пользователей по сравнению с DoT.

DNS-over-TOR

Как и другие интернет-протоколы, DNS может работать через VPN и туннели . Одним из видов использования, которое стало достаточно распространенным с 2019 года, чтобы оправдать свое собственное часто используемое сокращение, является DNS-over- Tor . Повышение конфиденциальности Oblivious DNS может быть получено за счет использования ранее существовавшей сети Tor, состоящей из входных и выходных узлов, в сочетании с шифрованием транспортного уровня, обеспечиваемым TLS.

Забывчивый DNS-over-HTTPS ("ODoH")

В 2021 году была предложена «незаметная» реализация DoH, реализованная в виде черновика, сочетающая разделение входящего / исходящего трафика с туннелированием HTTPS и шифрованием транспортного уровня TLS в едином определенном протоколе.

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

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

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

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

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

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

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

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

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

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

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

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 (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:

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

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

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

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

RFC документы

Стандарты

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

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

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

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

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

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

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

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

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

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

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

Неизвестный

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

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

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

использованная литература

Источники

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