Как работает dns-сервер простыми словами

Различия в отношениях

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

Основной (Primary) и подчинённый (Slave) серверы

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

Главный (master) не имеет больше власти над зонами, чем Slave. Единственный различающий фактор между главным и подчиненным серверами — это то, откуда они читают свои файлы зон.

И главный, и подчинённый серверы являются авторитативными для зон, с которыми они работают. Главный (master) не имеет больше власти над зонами, чем Slave. Единственный различающий фактор между главным и подчиненным серверами — это то, откуда они читают свои файлы зон.

Главный сервер считывает файлы своей зоны из файлов на системном диске, обычно здесь администратор зоны добавляет, редактирует или передаёт исходные файлы зоны.

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

Серверы не обязательно должны относиться только к master или только к slave для всех зон, с которыми они работают. Главный или подчинённый статус присваивается по зонам, поэтому сервер может быть ведущим для некоторых зон и ведомым для других.

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

Публичные и частные серверы

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

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

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

С точки зрения безопасности особенно важно, чтобы на общедоступном сервере не было приватных записей. Это означает не перечислять ваши частные серверы имён с записями NS в публичных файлах зон.

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

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

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

Содержимое папки root

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

Например, на стандартной VDS/VPS такая директория может содержать в себе следующие папки:

  • /bin с системными программами, файлами и компонентами, необходимыми для загрузки ОС;
  • /boot с компонентами загрузчика, включающими в себя ядро Linux и базовый набор файлов для старта сервера;
  • /dev с файлами, привязанными к конкретным устройствам, подключаемым к системе;
  • /etc с другими скриптами и файлами, от которых не зависит запуск сервера.

Таких подкаталогов в корне может быть больше. Все зависит от конфигурации компьютера и ОС.

На виртуальном хостинге же папка public_html или ее аналог не содержит ничего, она пустая по умолчанию. В нее помещают HTML-документы, JS-скрипты и CSS-файлы необходимые для работы размещаемого сайта. Скорее всего, корнем для вас станет директория, в которую будет помещен файл index.html с главной страницей вашего ресурса.

Вход под суперпользователем

Чтобы войти под пользователем root можно переключиться в одну из виртуальных консолей, например, с помощью сочетания клавиш Ctrl+Alt+F1 и затем ввести логин root и пароль root пользователя.

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

Можно поступить полностью противоположным путем, ввести логин root и его пароль в графическом менеджере входа, чтобы окружение рабочего стола работало от имени root, и мы получаем все права root linux, но такой вариант крайне не рекомендованный, и очень опасный, вы можете случайно повредить всю систему. Поэтому этот способ был отключен во многих менеджерах входа.

Что они делают

Чтобы лучше понять что делает каждый тип, проследим за процессом открытия сайта в браузере.

  1. Переходим на сайт «google.com». Браузер передаёт этот запрос DNS-клиенту, который встроен в операционную систему.

  2. DNS-клиент проверяет локальный кеш на наличие IP адреса для запрашиваемого названия.

    Если соответствие найдено, то IP передаётся браузеру и он на него отправляет запрос для получения содержимого сайта. Работа с DNS на этом заканчивается.

    Если не найдено — отправляет запрос на внешний рекурсивный DNS-сервер, адрес которого указывается в настройках сетевого адаптера компьютера или получается автоматически от Интернет-провайдера по протоколу DHCP.

    Узнать IP адрес рекурсивного DNS-сервера можно командой «nslookup» в командной строке Windows (cmd). Просто запросите информацию для любого сайта.

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

    • Запрашивает у одного из корневых DNS-серверов IP адрес TLD-сервера, который отвечает за доменную зону «.com» (ведь ищем «google.com»).
    • Обращается к TLD-серверу зоны «.com», чтобы получить IP адрес авторитативного DNS-сервера, на котором есть информация о «google.com».
    • Запрашивает у авторитативного DNS-сервера IP сайта «google.com».
    • Наконец, получает нужный IP и отсылает его DNS-клиенту или сообщает — ничего не нашел, ошибка «DNS_PROBE_FINISHED_NXDOMAIN».
  4. DNS-клиент компьютера, получив IP для «google.com», кеширует информацию, чтобы при повторном запросе не проделывать предыдущие шаги, и передаёт браузеру.

  5. Браузер посылает на этот IP адрес http-запрос, чтобы в ответ получить содержимое сайта.

Как зайти в корень сайта

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

Основной — через терминал. То есть при помощи командной строки и текстовых утилит. Но есть и специализированное программное обеспечение с графическим интерфейсом.

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

Через терминал

Чтобы управлять сервером через терминал, надо подключиться к нему через Secure Shell (SSH). Для этого:

  • Запускаем терминал (в macOS или Linux).
  • Вводим команду ssh root@IP-адрес сайта.
  • Указываем пароль администратора для авторизации.

В Windows для выполнения этой задачи потребуется установить приложение PuTTY и указать IP-адрес сайта в нем.

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

Сразу же можно проверить его содержимое, воспользовавшись командой ls.

Через FTP-клиент

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

Рассмотрим эту процедуру на примере утилиты FileZilla:

FTP-клиенты мало чем отличаются от файловых менеджеров. Большая их часть визуально напоминает Total Commander. Перед вами появится двухпанельный интерфейс: в одной из панелей будут локальные файлы и папки, во второй — файлы и папки хостинга.

Для управления используются горячие клавиши или элементы в верхней панели FileZilla.

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

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

  • Открываем сайт Timeweb.
  • Заходим в саму ПУ.
  • Переходим во вкладку «Файловый менеджер».
  • Открываем директорию public_html.

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

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

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

  • Заходим в панель ISPmanager.
  • Авторизуемся, используя данные администратора.
  • Открываем меню «Система».
  • Выбираем подпункт «Менеджер файлов».

Через файловый менеджер

В Explorer (Windows) и в Finder (macOS) есть встроенная поддержка протокола FTP. То есть для подключения к серверу не нужно скачивать стороннее ПО. Достаточно ввести FTP-адрес в соответствующее поле файлового менеджера операционной системы.

В macOS это делается следующим образом:

  • Открываем Finder.
  • Одновременно нажимаем клавиши Cmd + K.
  • Указываем адрес сервера в формате ftp://IP-адрес сайта
  • Кликаем по кнопке «Подключиться».
  • Авторизуемся, используя данные, которые выдал хостинг.

В Windows:

  • Открываем Explorer.
  • Вводим во встроенную поисковую строку ftp://IP-адрес сайта
  • Авторизуемся, используя данные, которые выдал хостинг.

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

СТАТЬИ

12.02.16

Часто задаваемые вопросы

В: Несет ли Администратор домена ответственность за информацию на сайте, размещенном в Интернете под этим доменом?
О: Да. Администратор домена с момента внесения его имени в Реестр лично отвечает за использование домена, в том числе в незаконных целях, вне зависимости от того, кем осуществляется использование домена.

25.03.15

И первым был домен… Или товарный знак?

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

04.03.15

Защита от сквоттинга

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

Поддержка область «данныеDANE support

Можно использовать поддержку область «данные ( RFC 6394 и 6698 ) , чтобы указать клиентам DNS, какие ЦС должны получать сертификаты для имен доменов, размещенных на DNS-сервере.You can use DANE support (RFC 6394 and 6698) to specify to your DNS clients what CA they should expect certificates to be issued from for domains names hosted in your DNS server. Это предотвращает атаку «злоумышленник в середине», когда кто-то может повредить кэш DNS и указать DNS-имя на свой IP-адрес.This prevents a form of man-in-the-middle attack where someone is able to corrupt a DNS cache and point a DNS name to their own IP address.

Например, предположим, что вы размещаете защищенный веб-сайт, использующий SSL по адресу www.contoso.com, используя сертификат из хорошо известного центра с именем CA1.For instance, imagine you host a secure website that uses SSL at www.contoso.com by using a certificate from a well-known authority named CA1. Кто-то может получить сертификат для www.contoso.com от другого хорошо известного центра сертификации с именем CA2.Someone might still be able to get a certificate for www.contoso.com from a different, not-so-well-known, certificate authority named CA2. Затем сущность, в которой размещается фальшивый веб-сайт www.contoso.com, может повредить кэш DNS клиента или сервера, чтобы указать www.contoto.com на свой фальшивый сайт.Then, the entity hosting the fake www.contoso.com website might be able to corrupt the DNS cache of a client or server to point www.contoto.com to their fake site. Конечный пользователь будет представлять сертификат из CA2 и может просто подтвердить его и подключиться к поддельному сайту.The end user will be presented a certificate from CA2, and may simply acknowledge it and connect to the fake site. При использовании область «данные клиент отправляет запрос на DNS-сервер для contoso.com с запросом на запись ТЛСА и узнает, что сертификат для www.contoso.com был вызван CA1.With DANE, the client would make a request to the DNS server for contoso.com asking for the TLSA record and learn that the certificate for www.contoso.com was issues by CA1. Если он представлен сертификатом из другого ЦС, подключение прерывается.If presented with a certificate from another CA, the connection is aborted.

Политики DNSDNS Policies

Вы можете использовать политику DNS для управления трафиком на основе Geo-Location, интеллектуальных ответов DNS в зависимости от времени суток, для управления одним DNS-сервером, настроенным для раздельного — развертывания, применения фильтров к запросам DNS и многого другого.You can use DNS Policy for Geo-Location based traffic management, intelligent DNS responses based on the time of day, to manage a single DNS server configured for split-brain deployment, applying filters on DNS queries, and more. Следующие элементы содержат более подробные сведения об этих возможностях.The following items provide more detail about these capabilities.

  • Балансировка нагрузки приложений.Application Load Balancing. При развертывании нескольких экземпляров приложения в разных местах можно использовать политику DNS для балансировки нагрузки трафика между разными экземплярами приложения, динамически выделяя нагрузку на трафик для приложения.When you have deployed multiple instances of an application at different locations, you can use DNS policy to balance the traffic load between the different application instances, dynamically allocating the traffic load for the application.

  • -Управление трафиком на основе географического расположения.Geo-Location Based Traffic Management. С помощью политики DNS можно разрешить основным и дополнительным DNS-серверам отвечать на запросы клиентов DNS на основе географического расположения клиента и ресурса, к которому пытается подключиться клиент, предоставляя клиенту IP-адрес ближайшего ресурса.You can use DNS Policy to allow primary and secondary DNS servers to respond to DNS client queries based on the geographical location of both the client and the resource to which the client is attempting to connect, providing the client with the IP address of the closest resource.

  • Разделение мозгового DNS-сервера.Split Brain DNS. При разделенном — мозге DNS записи DNS разбиваются на разные области зоны на одном DNS-сервере, а DNS-клиенты получают ответ в зависимости от того, являются ли клиенты внутренними или внешними клиентами.With split-brain DNS, DNS records are split into different Zone Scopes on the same DNS server, and DNS clients receive a response based on whether the clients are internal or external clients. Вы можете настроить раздельный — мозг DNS для Active Directory интегрированных зон или для зон на автономных DNS-серверах.You can configure split-brain DNS for Active Directory integrated zones or for zones on standalone DNS servers.

  • Записей.Filtering. Вы можете настроить политику DNS для создания фильтров запросов на основе заданных вами условий.You can configure DNS policy to create query filters that are based on criteria that you supply. Фильтры запросов в политике DNS позволяют настроить DNS-сервер на отправку пользовательского способа на основе DNS-запроса и DNS-клиента, отправляющего запрос DNS.Query filters in DNS policy allow you to configure the DNS server to respond in a custom manner based on the DNS query and DNS client that sends the DNS query.

  • Экспертизы.Forensics. С помощью политики DNS можно перенаправить вредоносные DNS-клиенты на — несуществующий, а не направить их на компьютер, к которому они пытаются связаться.You can use DNS policy to redirect malicious DNS clients to a non-existent IP address instead of directing them to the computer they are trying to reach.

  • Перенаправление на основе времени суток.Time of day based redirection. Политику DNS можно использовать для распределения трафика приложений между различными географически распределенными экземплярами приложения с помощью политик DNS, основанных на времени суток.You can use DNS policy to distribute application traffic across different geographically distributed instances of an application by using DNS policies that are based on the time of day.

Политики DNS также можно использовать для Active Directory интегрированных зон DNS.You can also use DNS policies for Active Directory integrated DNS zones.

Дополнительные сведения см. в описании сценария политики DNS.For more information, see the DNS Policy Scenario Guide.

Набираем адрес в строке или DNS сервер в работе

Чтобы там не заявляли, но основным сервером, который будет направлять Вас при поиске нужного ресурса (где бы он не находился), будет один из тринадцати корневых зарубежных серверов. Любой из вновь подключаемых серверов верхнего уровня ПО УМОЛЧАНИЮ знает IP адреса каждого из них, и дополнительного сервера ему не требуется. И теперь цепочка

поиск – запрос – ответ

выглядит так (напрягайте память – все аббревиатуры и понятия из текста выше сейчас понадобятся):

«Тут один DNS ищет сайт.xxx: найдёшь – вернёшь ответ сам»

Все TLD сервера, в свою очередь, знают IP адреса всех SLD серверов. Так, если француз искал блог samsebeadmin.ru, то корневой сервер делегирует поиск другим авторизованным серверам, которые контролируют работу зоны .RU. Продолжаем пример с французом.

  1. Цепочку запроса подхватывает один из TLD RU-зоны серверов, который отвечает за работу моего домена (доменного имени) – samsebeadmin.ru. Сайт обнаружился.
  2. Теперь TLD сервер для зоны .RU выдаёт французу ссылку на адрес того DNS сервера, который отвечает за адрес найденного сайта (за домен).
  3. DNS сервер для samsebeadmin.ru выдаёт клиенту готовый IP адрес блога. Цепочка замкнулась, француз – на сайте.

С первого раза, возможно, трудно всё это понять. Прочтите материал ещё раз внимательно и не торопясь. И тогда, я думаю, Вы во всём разберётесь.

Корневой DNS-сервер работает почти вхолостую

Специалисты компьютерного центра Калифорнийского университета в Сан-Диего провели исследование характера нагрузки на один из 13 корневых DNS-серверов Интернета, сообщает интернет-издание iOne.ru.

Эти серверы используются для трансляции привычных текстовых интернет-адресов в цифровые IP-адреса. Для исследований был выбран один из корневых серверов, расположенный в Калифорнии. Изучение трафика сервера производилось на протяжении суток. Данные, полученные исследователями, можно назвать сенсационными. Как оказалось, 98% всех запросов к корневому серверу являлись избыточными мусором. Согласно полученным результатам, из приблизительно 152 млн. запросов к калифорнийскому корневому DNS-серверу, 70% представляли собой повторы запросов к одним и тем же доменам из одних и тех же сетей.

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

Около 12% запросов обращены к сайтам в несуществующих доменных зонах типа .elvis, .corp или .localhost. Еще 7% запросов уже содержат IP-адреса, то есть не требуют обработки DNS-сервером. Оставшиеся 2% и представляют собой запросы, которые действительно должен обрабатывать корневой сервер.

Набираем адрес в строке или DNS сервер в работе

Чтобы там не заявляли, но основным сервером, который будет направлять вас при поиске нужного ресурса (где бы он не находился), будет один из тринадцати корневых забугорных серверов. Любой из вновь подключаемых серверов верхнего уровня ПО УМОЛЧАНИЮ знает IP адреса каждого из них, и дополнительного сервера ему не требуется. И теперь цепочка

поиск – запрос – ответ

выглядит так (напрягайте память – все аббревиатуры и понятия из текста выше сейчас понадобятся):

“Тут один DNS ищет сайт.xxx: найдёшь – вернёшь ответ сам”

Все TLD сервера, в свою очередь, знают IP адреса всех SLD серверов. Так, если француз искал блог computer76.ru, то корневой сервер делегирует поиск другим авторизованным серверам, которые контролируют работу зоны .RU. Продолжаем пример с французом.

  • цепочку запроса подхватывает один из TLD RU-зоны серверов, который отвечает за работу моего домена (доменного имени) –computer76.ru. Сайт обнаружился.
  • теперь TLD сервер для зоны .RU выдаёт французу ссылку на адрес того DNS сервера, который отвечает за адрес найденного сайта (за домен)
  • DNS сервер для computer76.ru выдаёт клиенту готовый IP адрес блога. Цепочка замкнулась, француз – на сайте.

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

Глобальная DNS

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

RFC 1034

RFC 1035

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

  • Корневой сервер имён, он же ROOT сервер – представлен символом ТОЧКА “.“.
  • Домены верхнего уровня (Top Level Domens – TLD) – делятся внутри на Общие домены (gTLD) типа .com, .net, .org, .edu и т.п. и Национальные домены (ccTLD) типа .us, .uk, .ru, .fr и т.п.
  • Домены второго уровня (Secondary Level Domain – SLD) – это остальная часть доменов, которые раздаются коммерческими или государственными организациями. Характерный вид: наличие справа от главного имени адреса ещё одной точки:

сайт.msk.ru    сайт.spb.ru  и т.д.

Таким образом, структура DNS выглядит так:

  • Корневой уровень
  • Домены верхнего уровня
  • Домены второго уровня
  • Поддомены
  • Конечные хосты

В состав такой иерархии вводится понятие доменов третьего уровня, чьё место в URL сразу слева от имени второго домена. Так часто именуют поддомены на ресурсах, которые играют роль специального раздела основного сайта.

Теперь вы знаете, какие DNS серверы принимают участие, когда вы обращаетесь к моему блогу:

Каждая ветка или пункт доменной системы закреплён за ответственной организацией, которая отвечает за его администрирование. Так что привыкайте к следующему понятию в DNS системе: авторитетный источник. Авторитетной мы будем называть именно ту организацию, которая ответственна именно за конкретную часть DNS цепочки или DNS узла.

Запросы DNS

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

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

Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.

Обратный запрос посылает IP  и просит вернуть доменное имя.

Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.

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

Давайте разберем, что тут нарисовано по шагам:

  1. Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запрос резолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
  2. Резолвер посылает запрос указанному серверу имен.
  3. Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запрос серверу, отвечающему за корневую зону.
  4. Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
  5. Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
  6. пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
  7. и «вложенности» доменных имен.
  8. В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
  9. Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.

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

Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

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

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий