Служба доменных имен (DNS) | Microsoft Learn

Twitter LinkedIn Facebook Адрес электронной почты

  • Статья
  • Чтение занимает 2 мин

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

Система доменных имен (DNS) — это один из стандартных отраслевых протоколов, составляющих TCP/IP, и вместе DNS-клиент и DNS-сервер предоставляют службы разрешения имен имен компьютеров и пользователей.

Примечание

Помимо этого раздела, доступно следующее содержимое DNS.

  • Новые возможности DNS-клиента
  • Новые возможности DNS-сервера
  • Руководство по сценарию политики DNS

В Windows Server 2016 DNS — это роль сервера, которую можно установить с помощью диспетчер сервера или команд Windows PowerShell. При установке нового леса и домена Active Directory DNS автоматически устанавливается с Active Directory в качестве сервера глобального каталога для леса и домена.

доменные службы Active Directory (AD DS) использует DNS в качестве механизма расположения контроллера домена. При выполнении любой из основных операций Active Directory, таких как проверка подлинности, обновление или поиск, компьютеры используют DNS для поиска контроллеров домена Active Directory. Кроме того, контроллеры домена используют DNS для поиска друг друга.

Служба DNS-клиента включена во все версии клиента и сервера операционной системы Windows и по умолчанию выполняется при установке операционной системы.

При настройке сетевого подключения TCP/IP с IP-адресом DNS-сервера DNS-клиент запрашивает DNS-сервер для обнаружения контроллеров домена и разрешения имен компьютеров на IP-адреса. Например, когда сетевой пользователь с учетной записью пользователя Active Directory входит в домен Active Directory, служба DNS-клиента запрашивает DNS-сервер, чтобы найти контроллер домена для домена Active Directory. Когда DNS-сервер отвечает на запрос и предоставляет КЛИЕНТУ IP-адрес контроллера домена, клиент обращается к контроллеру домена и может начаться процесс проверки подлинности.

Службы DNS-сервера и DNS-клиента Windows Server 2016 используют протокол DNS, включенный в набор протоколов TCP/IP. DNS является частью прикладного уровня эталонной модели TCP/IP, как показано на следующем рисунке.

основы работы со службой, типы DNS-запросов

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

DNS (Domain Name System — система доменных имен) представляет собой распределенную систему хранения и обработки информации о доменных зонах. Она необходима, в первую очередь, для соотнесения IP-адресов устройств в сети и более адаптированных для человеческого восприятия символьных имен.

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

 

 

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

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

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

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

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

Иерархия и делегирование доменных имен

Домен представляет собой именованную ветвь в дереве имен, включающую в себя сам узел (напр., домен первого уровня «.com»), а также подчиненные ему узлы (напр., домен второго уровня «example.com», домен третьего уровня «mail.example.com» и т.д.). Для обозначения иерархической принадлежности доменных имен принято использовать понятие «уровень» — показатель положения узла в дереве доменов. Чем ниже значение уровня, тем выше иерархическое положение домена

  • «.» — домен нулевого уровня
  • «.ru» — домен первого (верхнего) уровня
  • «example.com» — домен второго уровня
  • «mail.example.com» — домен третьего уровня
  • Этот список можно продолжать

 

 

Обратите внимание на домен нулевого уровня «. » (dot — точка), также называемый корневым. На практике точку обычно не указывают («example.com» вместо «example.com.»), т.е. указание корневого домена не является обязательным условиям разрешения IP-адреса. Большинство клиентских программ (интернет-браузеров и т.д.) добавляют домен нулевого уровня автоматически и не отображают его пользователю. Доменное имя, не включающее обозначение домена нулевого уровня называется относительным, включающее же точку на конце — полностью определенным

(FQDN — Fully Qualified Domain Name).

Доменная зона — часть иерархического дерева доменных имен (напр. «.ru»), целиком переданная на обслуживание определенному DNS-серверу (чаще нескольким) с целью делегирования другому лицу ответственности за этот и все подчиненные домены («anyaddress.ru», «any.anyaddress.ru»).

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

Сам процесс делегирования представляет собой добавление в ресурсные записи родительской зоны («.ru»), так называемых «склеивающих» («glue») NS-записей для делегируемой дочерней зоны («example.com»), указывающих на DNS-сервера принимающей домен стороны (например, DNS-сервера нашей компании). С этого момента все ресурсные записи домена второго уровня «example.com» и всех его дочерних доменов (например, «mail.example.com» и т.д.) хранятся на DNS-серверах этой компании, а родительская зона «.ru» хранит только указывающие на эти сервера NS-записи.

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

DNS-клиент — набор программных средств для работы с DNS. Сам DNS-сервер периодически также выступает в качестве клиента.

Основные типы ресурсных записей

Ресурсная запись (RR — Resource Record) — единица хранения и передачи информации в DNS, включающая в себя следующие элементы (поля):

  • Имя (Name) — имя домена, к которому относится запись
  • TTL (Time To Live) — допустимое время хранения записи неответственным сервером
  • Тип (Type) — параметр, определяющий назначение и формат записи в поле данных (Rdata)
  • Класс (Class) — тип сети передачи данных (подразумевается возможность DNS работать с типами сетей, отличных от TCP/IP)
  • Длина поля данных (Rdlen)
  • Поле данных (Rdata) — содержание и формат поля зависят от типа записи

 

Ниже представлены типы dns записей, используемые чаще всего:

  • A (IPv4 Address Record — адресная запись) — связывает доменное имя с IPv4-адресом хоста
  • AAAA (IPv6 Address Record) — связывает доменное имя с IPv6-адресом хоста (аналогично А-записи)
  • CNAME (Canonical Name Record — каноническая запись имени) — используется для перенаправления на другое доменное имя
  • MX (Mail Exchange — почтовый обменник) — ссылается на почтовый сервер, обслуживающий домен
  • NS (Name Server — сервер имен) — ссылается на DNS-сервер, ответственный за домен
  • TXT — текстовое описание домена. Зачастую требуется для выполнения специфических задач (например, подтверждения права собственности на домен при привязке его к почтовому сервису)
  • PTR (Point to Reverse — запись указателя) — связывает ip-адрес машины с доменом, используется преимущественно для проверки сторонними почтовыми сервисами отправляемых через эту машину электронных писем на отношение к домену, указанному в параметрах почтового сервера. При несоответствии этих параметров письмо проверяется более тщательно по другим критериям.

Рекурсивные и нерекурсивные DNS-запросы

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

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

 

 

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

Как работают DNS-серверы

DNS работает очень просто:

  1. В поле поиска браузера вводится запрос — доменное имя. Браузер перенаправляет запрос DNS-серверу, который ищет совпадения между доменным именем и IP.
  2. Если совпадение найдено, DNS вернет IP-адрес, по которому браузер сделает запрос и отобразит полученные данные. Если совпадения не обнаружены, запрос будет перенаправлен корневому серверу.
  3. Если DNS-запись не найдётся у корневого сервера — браузер вернёт страницу с кодом ошибки.

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

О том как работать с файлом hosts, вы можете узнать из этого мануала, а если вы ищете удобный и бесплатный сервис по работе с DNS — обратите внимания на услугу DNS-хостинг от 1cloud.

Попробовать услугу

Поделиться в соцсетях:

Средняя оценка: 5,0, всего оценок: 26 Спасибо за Вашу оценку! К сожалению, проголосовать не получилось. Попробуйте позже

ru

191014 Санкт-Петербург ул. Кирочная, 9

+7(812)313-88-33

235 70

1cloud ltd

2022-08-16 Основы работы со службой DNS

191014 Санкт-Петербург ул. Кирочная, 9

+7(812)313-88-33

235 70

1cloud ltd

2022-08-16 Основы работы со службой DNS

600 auto

Что такое DNS? – Введение в DNS

DNS, или система доменных имен, преобразует удобочитаемые доменные имена (например, www.amazon.com) в машиночитаемые IP-адреса (например, 192.0.2.44).

 

 

Введение в DNS Введение в DNS Введение в DNS

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

Служба DNS, такая как Amazon Route 53, является глобально распределенной службой, которая переводит удобочитаемые имена, такие как www.example.com, в числовые IP-адреса, такие как 192.0.2.1, которые компьютеры используют для подключения друг к другу. Система DNS в Интернете работает во многом как телефонная книга, управляя сопоставлением имен и номеров. DNS-серверы преобразуют запросы имен в IP-адреса, контролируя, к какому серверу попадет конечный пользователь, когда он введет доменное имя в свой веб-браузер. Эти запросы называются запросов .

Типы службы DNS

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

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

Начните работу с AWS бесплатно

Создайте бесплатную учетную запись
или войдите в консоль

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

Обратите внимание, что Amazon Route 53 в настоящее время недоступен на уровне бесплатного пользования AWS.

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

  1. Пользователь открывает веб-браузер, вводит www.example.com в адресную строку и нажимает Enter.
  2. Запрос на www.example.com перенаправляется на преобразователь DNS, который обычно управляется поставщиком услуг Интернета (ISP) пользователя, например поставщиком кабельного Интернета, поставщиком широкополосного доступа DSL или корпоративной сетью.
  3. Преобразователь DNS для интернет-провайдера перенаправляет запрос на www.example.com на корневой сервер имен DNS.
  4. Преобразователь DNS для интернет-провайдера снова перенаправляет запрос на www.example.com, на этот раз на один из серверов имен TLD для доменов .com. Сервер имен для доменов .com отвечает на запрос именами четырех серверов имен Amazon Route 53, связанных с доменом example.com.
  5. Преобразователь DNS для интернет-провайдера выбирает сервер имен Amazon Route 53 и перенаправляет запрос на www.example.com на этот сервер имен.
  6. Сервер имен Amazon Route 53 ищет в размещенной зоне example.com запись www.example.com, получает соответствующее значение, например IP-адрес веб-сервера, 192.0.2.44, и возвращает IP-адрес в DNS-преобразователь.
  7. Резолвер DNS для провайдера наконец-то получил IP-адрес, который нужен пользователю. Преобразователь возвращает это значение веб-браузеру. Сопоставитель DNS также кэширует (сохраняет) IP-адрес для example. com в течение указанного вами периода времени, чтобы он мог быстрее реагировать при следующем переходе на example.com. Для получения дополнительной информации см. время жизни (TTL).
  8. Веб-браузер отправляет запрос www.example.com на IP-адрес, полученный от преобразователя DNS. Здесь ваш контент — это, например, веб-сервер, работающий на экземпляре Amazon EC2, или корзина Amazon S3, настроенная как конечная точка веб-сайта.
  9. Веб-сервер или другой ресурс по адресу 192.0.2.44 возвращает веб-страницу для www.example.com в веб-браузер, и веб-браузер отображает страницу.
                                              90844 908444 908444

                                              Дополнительная литература: Глубокое погружение в DNS

                                              Служба

                                              — Служба доменных имен (DNS)

                                              Служба доменных имен (DNS) — это интернет-служба, которая сопоставляет IP-адреса и полные доменные имена (FQDN) друг с другом. Таким образом, DNS избавляет от необходимости запоминать IP-адреса. Компьютеры, на которых работает DNS, называются серверы имен . Ubuntu поставляется с BIND (Berkley Internet Naming Daemon), наиболее распространенной программой, используемой для поддержки сервера имен в Linux.

                                              Установка

                                              В командной строке терминала введите следующую команду для установки DNS:

                                               sudo apt установить bind9

                                              Очень полезным пакетом для тестирования и устранения проблем с DNS является пакет dnsutils . Очень часто эти инструменты уже установлены, но для проверки и/или установки dnsutils введите следующее:

                                               sudo apt установить dnsutils

                                              Конфигурация

                                              Существует множество способов настройки BIND9. Некоторые из наиболее распространенных конфигураций — это кэширующий сервер имен, первичный сервер и вторичный сервер.

                                              • При настройке в качестве кэширующего сервера имен BIND9 найдет ответ на запрос имени и запомнит ответ при повторном запросе домена.

                                              • В качестве основного сервера BIND9 считывает данные для зоны из файла на своем хосте и является полномочным для этой зоны.

                                              • В качестве вторичного сервера BIND9 получает данные зоны от другого сервера имен, уполномоченного для этой зоны.

                                              Обзор

                                              Файлы конфигурации DNS хранятся в каталоге /etc/bind . Основной файл конфигурации — /etc/bind/named.conf , который в макете, предоставляемом пакетом, включает только эти файлы.

                                              • /etc/bind/named.conf.options : глобальные параметры DNS
                                              • /etc/bind/named.conf.local : для ваших зон
                                              • /etc/bind/named.conf.default-zones : зоны по умолчанию, такие как localhost, его реверс и корневые подсказки

                                              Раньше корневые серверы имен описывались в файле /etc/bind/db.root . Теперь это предоставляется файлом /usr/share/dns/root.hints , поставляемым с пакетом dns-root-data, и упоминается в файле конфигурации named. conf.default-zones выше.

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

                                              Кэширующий сервер имен

                                              Конфигурация по умолчанию действует как сервер кэширования. Просто раскомментируйте и отредактируйте /etc/bind/named.conf.options , чтобы установить IP-адреса DNS-серверов вашего интернет-провайдера:

                                               экспедиторов {
    1.2.3.4;
    5.6.7.8;
};

                                              Примечание

                                              Замените 1.2.3.4 и 5.6.7.8 на IP-адреса фактических серверов имен.

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

                                               sudo systemctl перезапустить bind9.service

                                              См. dig для получения информации о тестировании кэширующего DNS-сервера.

                                              Основной сервер

                                              В этом разделе BIND9будет настроен как Основной сервер для домена example.com . Просто замените example.com своим полным доменным именем (Fully Qualified Domain Name).

                                              Файл зоны переадресации

                                              Чтобы добавить зону DNS в BIND9, превратив BIND9 в основной сервер, сначала отредактируйте /etc/bind/named.conf.local :

                                              .
                                               зона "example.com" {
    тип мастер;
    файл "/etc/bind/db.example.com";
};

                                              Примечание

                                              Если bind будет получать автоматические обновления файла, как с DDNS, используйте /var/lib/bind/db.example.com вместо /etc/bind/db.example.com как здесь, так и в приведенной ниже команде копирования.

                                              Теперь используйте существующий файл зоны в качестве шаблона для создания файла /etc/bind/db.example. com :

                                               sudo cp /etc/bind/db.local /etc/bind/db.example.com

                                              Отредактируйте новый файл зоны /etc/bind/db.example.com и измените localhost. на полное доменное имя вашего сервера, оставив дополнительный . в конце. Изменить 127.0.0.1 на IP-адрес сервера имен и root.localhost на действительный адрес электронной почты, но с . вместо обычного символа @ , снова оставив . в конце. Измените комментарий, чтобы указать домен, для которого предназначен этот файл.

                                              Создайте запись A для базового домена, example.com . Кроме того, создайте запись A для ns.example.com , сервер имен в этом примере:

                                               ;
; Файл данных BIND для example.com
;
$TTL 604800
@ В SOA example.com. root.example.com. (
                              2; Серийный
                         604800 ; Обновить
                          86400 ; Повторить попытку
                        2419200 ; Срок действия
                         604800 ) ; Отрицательный TTL кэша
@ В NS ns. example.com.
@ В А 192.168.1.10
@ В АААА ::1
нс В А 192.168.1.10

                                              Вы должны увеличивать серийный номер каждый раз, когда вы вносите изменения в файл зоны. Если вы вносите несколько изменений перед перезапуском BIND9, просто увеличьте серийный номер один раз.

                                              Теперь вы можете добавить записи DNS в конец файла зоны. Дополнительные сведения см. в разделе Общие типы записей.

                                              Примечание

                                              Многие администраторы предпочитают использовать дату последнего редактирования в качестве серийного номера зоны, например 2020012100 , что равно ггггммддсс 9.0118 (где сс — серийный номер)

                                              После внесения изменений в файл зоны необходимо перезапустить BIND9, чтобы изменения вступили в силу:

                                               sudo systemctl перезапустить bind9.service

                                              Файл обратной зоны

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

                                              Отредактируйте /etc/bind/named.conf.local и добавьте следующее:

                                               зона "1.168.192.in-addr.arpa" {
    тип мастер;
    файл "/etc/bind/db.192";
};

                                              Примечание

                                              Замените 1.168.192 первыми тремя октетами той сети, которую вы используете. Также назовите файл зоны /etc/bind/db.192 соответствующим образом. Он должен соответствовать первому октету вашей сети.

                                              Теперь создайте файл /etc/bind/db.192 :

                                               sudo cp /etc/bind/db.127 /etc/bind/db.192

                                              Следующее редактирование /etc/bind/db.192 изменение тех же параметров, что и /etc/bind/db.example.com :

                                               ;
; Файл обратных данных BIND для локальной сети 192.168.1.XXX
;
$TTL 604800
@ В SOA ns.example.com. root.example.com. (
                              2; Серийный
                         604800 ; Обновить
                          86400 ; Повторить попытку
                        2419200 ; Срок действия
                         604800 ) ; Отрицательный TTL кэша
;
@ В НС нс. 
10 В PTR ns.example.com.

                                              Серийный номер в обратной зоне также необходимо увеличивать при каждом изменении. Для каждой записи , которую вы настраиваете в /etc/bind/db.example.com , то есть для другого адреса, вам необходимо создать запись PTR в /etc/bind/db.192 .

                                              После создания файла обратной зоны перезапустите BIND9:

                                               sudo systemctl перезапустить bind9.service

                                              Дополнительный сервер

                                              Один раз Первичный сервер был настроен как Дополнительный сервер. Настоятельно рекомендуется использовать для поддержания доступности домена в случае, если основной становится недоступным.

                                              Во-первых, на основном сервере необходимо разрешить передачу зоны. Добавьте параметр allow-transfer в примеры определений зон Forward и Reverse в /etc/bind/named.conf.local :

                                              .
                                               зона "example.com" {
    тип мастер;
    файл "/etc/bind/db. example.com";
    разрешить передачу { 192.168.1.11; };
};
    
зона "1.168.192.in-addr.arpa" {
    тип мастер;
    файл "/etc/bind/db.192";
    разрешить передачу {192.168.1.11; };
};

                                              Примечание

                                              Замените 192.168.1.11 на IP-адрес вашего вторичного сервера имен.

                                              Перезапустите BIND9 на основном сервере:

                                               sudo systemctl перезапустить bind9.service

                                              Затем на вторичном сервере установите пакет bind9 так же, как и на первичном. Затем отредактируйте /etc/bind/named.conf.local и добавьте следующие объявления для зон Forward и Reverse:

                                               зона "example.com" {
    тип вторичный;
    файл "db.example.com";
    мастера { 192.168.1.10; };
};
          
зона "1.168.192.in-addr.arpa" {
    тип вторичный;
    файл "db.192";
    мастера { 192.168.1.10; };
};

                                              Примечание

                                              Замените 192.168.1.10 на IP-адрес вашего основного сервера имен.

                                              Перезапустите BIND9 на вторичном сервере:

                                               sudo systemctl перезапустить bind9.service

                                              В /var/log/syslog вы должны увидеть что-то похожее на следующее (некоторые строки были разделены, чтобы соответствовать формату этого документа):

                                               клиент 192.168.1.10#39448: получено уведомление для зоны «1.168.192.in-addr.arpa»
зона 1.168.192.in-addr.arpa/IN: Начата передача.
передача '100.18.172.in-addr.arpa/IN' с 192.168.1.10#53:
 подключен через 192.168.1.11#37531
зона 1.168.192.in-addr.arpa/IN: передан серийный номер 5
передача '100.18.172.in-addr.arpa/IN' с 192.168.1.10#53:
 Перевод завершен: 1 сообщения,
6 записей, 212 байт, 0,002 с (106000 байт/с)
зона 1.168.192.in-addr.arpa/IN: отправка уведомлений (серийный номер 5)
клиент 192.168.1.10#20329: получено уведомление для зоны «example.com»
зона example.com/IN: Передача началась.
передача 'example.com/IN' с 192.168.1.10#53: подключено через 192.168.1.11#38577
зона example. com/IN: передан серийный номер 5
перенос 'example.com/IN' из 192.168.1.10#53: Передача завершена: 1 сообщения,
8 записей, 225 байт, 0,002 с (112500 байт/с)

                                              Примечание

                                              Примечание. Зона передается только в том случае, если серийный номер на основной зоне больше, чем на дополнительной. Если вы хотите, чтобы ваш основной DNS уведомлял другие вторичные DNS-серверы об изменениях зоны, вы можете добавить also-notify { ipaddress; }; от до /etc/bind/named.conf.local , как показано в примере ниже:

                                               зона "example.com" {
    тип мастер;
    файл "/etc/bind/db.example.com";
    разрешить передачу {192.168.1.11; };
    также-уведомить { 192.168.1.11; };
};
зона "1.168.192.in-addr.arpa" {
    тип мастер;
    файл "/etc/bind/db.192";
    разрешить передачу {192.168.1.11; };
    также-уведомить { 192.168.1.11; };
};

                                              Примечание

                                              Каталог по умолчанию для файлов неавторизованных зон — /var/cache/bind/ . Этот каталог также настроен в AppArmor, чтобы позволить демону named писать в него. Дополнительные сведения о AppArmor см. в разделе «Безопасность — AppArmor».

                                              Поиск и устранение неисправностей

                                              В этом разделе рассматривается диагностика проблем с конфигурациями DNS и BIND9.

                                              Тестирование

                                              разрешение.conf

                                              Первым шагом в тестировании BIND9 является добавление IP-адреса сервера имен в преобразователь хостов. Первичный сервер имен должен быть настроен так же, как и другой хост для двойной проверки. Подробную информацию о добавлении адресов серверов имен к сетевым клиентам см. в разделе Конфигурация DNS-клиентов. В конце концов, ваш сервер имен 9Строка 0128 в /etc/resolv.conf должна указывать на 127.0.0.53 , и у вас должен быть параметр search для вашего домена. Что-то вроде этого:

                                               сервер имен 127.0.0.53
поиск example.com

                                              Чтобы проверить, какой DNS-сервер использует ваш локальный резолвер, запустите:

                                               systemd-разрешение --статус

                                              Примечание

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

                                              копать

                                              Если вы установили пакет dnsutils, вы можете проверить свои настройки с помощью утилиты поиска DNS dig:

                                              • После установки BIND9 используйте dig против интерфейса loopback, чтобы убедиться, что он прослушивает порт 53. Из командной строки терминала:

                                                 копать -x 127.0.0.1

                                                В выводе команды вы должны увидеть строки, подобные следующим:

                                                 ;; Время запроса: 1 мс
;; СЕРВЕР: 192.168.1.10#53(192.168.1.10)

                                              • Если вы настроили BIND9 в качестве кэширующего сервера имен , «выкопайте» внешний домен, чтобы проверить время запроса:

                                                 копать ubuntu.com

                                                Обратите внимание на время запроса в конце вывода команды:

                                                 ;; Время запроса: 49 мс

                                                После второго раскопа должно быть улучшение:

                                                 ;; Время запроса: 1 мс

                                              пинг

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

                                               пинг example. com

                                              Проверяет, может ли сервер имен преобразовать имя ns.example.com в IP-адрес. Вывод команды должен выглядеть так:

                                              .
                                               PING ns.example.com (192.168.1.10) 56 (84) байт данных.
64 байта от 192.168.1.10: icmp_seq=1 ttl=64 время=0,800 мс
64 байта от 192.168.1.10: icmp_seq=2 ttl=64 время=0,813 мс

                                              именованная контрольная зона

                                              Отличный способ проверить файлы зон — использовать утилиту named-checkzone , установленную вместе с bind9 пакет. Эта утилита позволяет убедиться в правильности конфигурации перед перезапуском BIND9 и внесением изменений.

                                              • Чтобы проверить наш пример файла зоны пересылки, введите в командной строке следующее:

                                                 name-checkzone example.com /etc/bind/db.example.com

                                                Если все настроено правильно, вы должны увидеть вывод, похожий на:

                                                 зона example.com/IN: загружен серийный номер 6
ХОРОШО

                                              • Аналогично, для проверки файла зоны реверса введите следующее:

                                                 именованная контрольная зона 1. 168.192.in-addr.arpa /etc/bind/db.192

                                                Вывод должен быть похож на:

                                                 зона 1.168.192.in-addr.arpa/IN: загружен серийный номер 3
ХОРОШО

                                              Примечание

                                              Серийный номер вашего файла зоны, вероятно, будет другим.

                                              Быстрая регистрация временных запросов

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

                                              Чтобы включить ведение журнала запросов на , выполните:

                                               sudo rndc queryвойти в систему

                                              Аналогично, чтобы отключить, введите:

                                               sudo rndc querylog отключен

                                              Журналы будут отправлены в системный журнал и будут отображаться в /var/log/syslog по умолчанию:

                                              , 20 января, 19:40:50 new-n1 named[816]: получена команда канала управления «querylog on»
20 января 19:40:50 new-n1 named[816]: ведение журнала запросов включено
20 января 19:40:57 new-n1 named[816]: client @0x7f48ec101480 192. 168.1.10#36139 (ubuntu.com): запрос: ubuntu.com IN A +E(0)K (192.168.1.10)

                                              Примечание

                                              Количество журналов, созданных при включении querylog , может быть огромным!

                                              Регистрация

                                              BIND9 имеет множество доступных параметров конфигурации ведения журнала, но два основных из них — это канал и категория , которые настраивают, куда направляются журналы и какая информация регистрируется соответственно.

                                              Если параметры ведения журнала не настроены, конфигурация по умолчанию:

                                               ведение журнала {
     категория по умолчанию { default_syslog; default_debug; };
     категория не имеет себе равных { ноль; };
};

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

                                              Нам нужно настроить канал , чтобы указать, в какой файл отправлять сообщения, и категорию . В этом примере категория будет регистрировать все запросы. Отредактируйте /etc/bind/named.conf.local и добавьте следующее:

                                               ведение журнала {
    канал query.log {
        файл "/var/log/named/query.log";
        отладка серьезности 3;
    };
    запросы категорий { query.log; };
};

                                              Примечание

                                              Параметр отладки может иметь значение от 1 до 3. Если уровень не указан, по умолчанию используется уровень 1.

                                              • Поскольку демон named работает от имени пользователя bind , необходимо создать каталог /var/log/named и изменить владельца:

                                                 sudo mkdir /var/log/named
sudo chown bind:bind /var/log/named

                                              • Теперь перезапустите BIND9, чтобы изменения вступили в силу:

                                                 sudo systemctl перезапустить bind9.service

                                              Вы должны увидеть файл /var/log/named/query.log , заполненный информацией о запросе. Это простой пример параметров ведения журнала BIND9. Дополнительные сведения о расширенных параметрах см. в разделе Дополнительная информация.

                                              Каталожные номера

                                              Общие типы записей

                                              В этом разделе рассматриваются некоторые из наиболее распространенных типов записей DNS.

                                              • Запись : Эта запись сопоставляет IP-адрес с именем хоста.

                                                 www IN A 192.168.1.12

                                              • Запись CNAME : используется для создания псевдонима существующей записи A. Вы не можете создать запись CNAME , указывающую на другую запись CNAME .

                                                 веб В CNAME www

                                              • Запись MX : используется для определения адреса электронной почты. Должен указывать на Запись , а не CNAME .

                                                 @ IN MX 1 mail.example.com.
почта ИН А 192.168.1.13

                                              • Запись NS : используется для определения серверов, обслуживающих копии зоны.

                                                No related posts.