DNS

Содержание
Введение
Ключевые характеристики DNS
Авторитетность
Дополнительные возможности
Терминология и принципы работы
Рекурсия
Обратный просмотр DNS
Похожие статьи

Введение

DNS (англ. Domain Name System «система доменных имён») — компьютерная распределённая система для получения информации о доменах.

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

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

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

Начиная с 2010 года в систему DNS внедряются средства проверки целостности передаваемых данных, называемые DNS Security Extensions (DNSSEC). Передаваемые данные не шифруются, но их достоверность проверяется криптографическими способами. Внедряемый стандарт DANE обеспечивает передачу средствами DNS достоверной криптографической информации (сертификатов), используемых для установления безопасных и защищённых соединений транспортного и прикладного уровней.

Ключевые характеристики DNS

DNS обладает следующими характеристиками:

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

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882, RFC 883 и RFC 973 как устаревшие.

Дополнительные возможности

Терминология и принципы работы

Ключевыми понятиями DNS являются:

Система DNS содержит иерархию DNS-серверов, соответствующую иерархии зон. Каждая зона поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный), на котором расположена информация о домене.

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

Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются.

Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP-датаграммы. TCP используется, когда размер данных ответа превышает 512 байт, и для AXFR-запросов.

Рекурсия

Термином рекурсия в DNS обозначают алгоритм поведения DNS-сервера:

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

DNS-запрос может быть рекурсивным — требующим полного поиска, — и нерекурсивным (или итеративным) — не требующим полного поиска.

Аналогично — DNS-сервер может быть рекурсивным (умеющим выполнять полный поиск) и нерекурсивным (не умеющим выполнять полный поиск).

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

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

Настройки нерекурсивного сервера, когда при ответе выдаются адреса серверов, которые обладают большим объёмом информации о запрошенной зоне, чем отвечающий сервер (чаще всего — адреса корневых серверов), являются некорректными, и такой сервер может быть использован для организации DoS-атак .

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

Рассмотрим на примере работу всей системы.

Предположим, мы набрали в браузере адрес

ru.wikipedia.org.

Браузер ищет соответствие этого адреса IP-адресу в файле hosts. Если файл не содержит соответствия, то далее браузер спрашивает у сервера DNS:

«какой IP-адрес у ru.wikipedia.org»?

Однако сервер DNS может ничего не знать не только о запрошенном имени, но и даже обо всём домене wikipedia.org.

В этом случае сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает —

«У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону org.»

Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает

«У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону wikipedia.org.»

Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.

В данном случае при разрешении имени, то есть в процессе поиска IP по имени:

Иногда допускается, чтобы запрошенный сервер передавал рекурсивный запрос «вышестоящему» DNS-серверу и дожидался готового ответа.

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

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

Обратный просмотр DNS

Обратный просмотр DNS (англ. reverse DNS lookup) — обращение к особой доменной зоне для определения имени узла по его IP-адресу c помощью PTR-записи.

Для выполнения запроса адрес узла переводится в обратную нотацию, способ перевода зависит от версии IP:

IPv4-адрес 192.168.0.1 превращается в 1.0.168.192.in-addr.arpa.;
IPv6-адрес 2001:db8::567:89ab — в b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов. Для этого в записях авторитетного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC.000/24) отвечает отдельный сервер.

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

Выполнение обратного запроса

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

PTR-записи не требуют какой-либо специальной обработки, это простые записи, подобные CNAME, которые определяют псевдонимы.

in-addr.arpa

DNS-запись in-addr.arpa выглядит так:

56.34.12.10.in-addr.arpa. IN PTR host1.example.net.

Это будет означать, что IP-адресу 10.12.34.56 соответствует имя узла host1.example.net.

DNS-запись ip6.arpa выглядит так:

5.4.3.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR host1.example.net.

Это будет означать, что IPv6-адресу 2001:0db8::1:2345 соответствует имя узла host1.example.net.

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

Для решения этой проблемы был создан RFC 2317, описывающий делегирование поддоменов in-addr.arpa в бесклассовой адресации.

Для делегирования диапазонов адресов IPv6 используется доменная зона ip6.arpa.

Похожие статьи:

Похожие статьи
DNS
Типы DNS серверов
Forward first | only
DNS сервер BIND на CentOS
SSH
PuTTY
Telnet
PSTools
Firefox
FreeSSHD
Компьютерные сети
Как создать туннель
Как сделать проброс портов
Дополнительные материалы
Cтатьи с других сайтов
Делегирование доменов
Регистрация доменов
Продление доменов
Домены. Общие вопросы и определения

Поиск по сайту

Подпишитесь на Telegram канал @aofeed чтобы следить за выходом новых статей и обновлением старых

Перейти на канал

@aofeed

Задать вопрос в Телеграм-группе

@aofeedchat

Контакты и сотрудничество:
Рекомендую наш хостинг beget.ru
Пишите на info@urn.su если Вы:
1. Хотите написать статью для нашего сайта или перевести статью на свой родной язык.
2. Хотите разместить на сайте рекламу, подходящую по тематике.
3. Реклама на моём сайте имеет максимальный уровень цензуры. Если Вы увидели рекламный блок недопустимый для просмотра детьми школьного возраста, вызывающий шок или вводящий в заблуждение - пожалуйста свяжитесь с нами по электронной почте
4. Нашли на сайте ошибку, неточности, баг и т.д. ... .......
5. Статьи можно расшарить в соцсетях, нажав на иконку сети: