Для корректной работы протокола аутентификации Kerberos, а значит и всего домена ALD Pro в целом, необходима служба разрешения имен. В FreeIPA равно как и в ALD Pro используется служба разрешения имен bind 9 и плагин bind-dyndb-ldap, который обеспечивает совместимости службы и базы данных LDAP.
Конфигурационные файлы службы разрешения имен
Конфигурационные файлы хранятся в папке /etc/bind:
- /etc/bind/db.* - файлы зон DNS
- /etc/bind/bind.keys – файл с ключами для обеспечения работы DNSSEC
- /etc/bind/rndc.keys – файл с ключами для выполнения аутентификации транзакций через BIND (например для обновления записей DHCP сервером)
- /etc/bind/named.conf – основной файл с настройками DNS
- /etc/bind/named.conf.default-zones – содержит зоны по умолчанию (пересылки, обратные и широковещательные)
- /etc/bind/named.conf.local – содержит зоны по умолчанию (пересылки, обратные и широковещательные)
- /etc/bind/named.conf.options – содержит опции DNS сервера
- /etc/bind/zones.rfc1918 – содержит список частных обратных зон (10.x.x.x и так далее)
Кроме стандартных файлов, создающихся при установке bind 9, тут присутствуют 2 дополнительных файла, предназначенные для работы FreeIPA. Стандартные файлы настроек bind 9 изменяются FreeIPA автоматически и все сделанные пользователем изменения в них будут утеряны, поэтому настройки следует выполнять строго в нижеперечисленных конфигурационных файлах:
- /etc/bind/ipa-ext.conf – в этом файле, по умолчанию пустом, можно разместить специфические настройки, которые не будут изменены или стерты при обновлении FreeIPA.
- /etc/bind/ipa-options-ext.conf – содержит опции DNS сервера
Файл /etc/bind/ipa-options-ext.conf мы настраивали после установки первого контроллера домена, последние 2 строки в нем были добавлены нами, а третья с конца изменена:
Файл /etc/bind/ipa-ext.conf по умолчанию не содержит настроек
Содержимое файла /etc/bind/named.conf формируется FreeIPA:
Как мы можем видеть подключаются следующие конфигурационные файлы:
- /etc/bind/named.conf.default-zones
- /etc/bind/bind.keys
- /etc/bind/ipa-ext.conf
- /etc/bind/ipa-options-ext.conf
А в файле /var/cache/bind/named.run формируется журнал работы bind 9.
В конце файла размещены настройки dyndb, из которых видно, что настройки сервера в каталоге LDAP хранятся в атрибутах записи и дочерних записях уникального имени (англ. Distinguished Name, DN) «cn=dns,dc=ald,dc=local», а для аутентификации используется метод sasl.
Размещение настроек службы разрешения имен в каталоге LDAP
На вкладке «Глобальная конфигурация DNS» ( Роли и службы сайта - Служба разрешения имен - Глобальная конфигурация DNS ) представлены настройки, хранящиеся в атрибутах записи «cn=dns,dc=ald,dc=local», и список серверов DNS из дочерних записей «cn=servers,cn=dns,dc=ald,dc=local», как показано на рисунке ниже:
Зоны DNS и параметры зоны
На вкладке «Зоны DNS» представлен список зон (как прямых, так и обратных).
Выберем доменную зону «ald.local» и перейдем в её настройки, выбрав вкладку «Параметры зоны»:
Параметрами зоны представлены атрибуты SOA записи зоны. SOA запись или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, параметры времени (TTL) кеширования зонной информации и взаимодействия DNS-серверов.
Рассмотрим список параметров зоны:
- Полномочный сервер имен (primary name server) – сервер-владелец зоны
- Адрес электронной почты администратора (Responsible Person)
- Номер SOA (Serial Number) – номер зоны
- Обновление SOA (Refresh) – периодичность запросов на обновление к серверу-владелицу зоны в секундах
- Повторный запрос SOA (Retry) – время (в секундах) через которое будет выполнен повторный запроса информации, если не было ответа от сервера-владельца
- Окончание действия SOA (Expire) – время (в секундах), в течение которого вторичный DNS будет пытаться завершить синхронизацию зоны с первичным
- Минимальный срок жизни SOA (Minimum TTL) – время жизни кэша для негативного ответа на запрос в зоне.
- Срок жизни по умолчанию (Default TTL) – время по умолчанию, в течение которого информация будет кэшироваться другими DNS-серверами.
- Срок жизни (TTL) – время, в течение которого информация будет кэшироваться другими DNS-серверами.
- Динамическое обновление (Allow-update) – может быть разрешено или запрещено
- Разрешить запрос (Allow-query) – определяет, кому разрешено выполнять запросы записей из этой зоны, по умолчанию разрешено всем («any»)
- Разрешить перенос (Allow-transfer) – определяет, кому разрешен перенос зоны, т.е. её копирование, по умолчанию не разрешено никому («none»)
- Глобальные перенаправители (Global forwarders) – тут можно указать один или несколько глобальных перенаправителей
- Политика перенаправления (Update-policy) – определяет политику перенаправления DNS запросов, принимает один из трех вариантов:
o Сначала перенаправлять
o Только перенаправлять
o Перенаправление отключено
- Состояние зоны DNS – может быть включено или выключено
Как мы можем убедится, свершившись с рисунком ниже, та же самая информация хранится и в каталоге LDAP в записи «idnsname=ald.local,cn=dns,dc=ald,dc=local»
В SOA записи есть атрибут serial number (серийный номер). Этот атрибут используется при трансфере зон. BIND 9 это иерархичный сервер, есть сервер - master, есть много slave серверов и все они могут делать трансфер зон и тем самым распределять нагрузку на чтение. И чтобы сервера могли перечитывать зону, только в том случае, если в ней произошли изменения - ввели атрибут serial number. Т.е. если администратор исправляет какую-то запись в зоне, то serial number увеличивается (дополнительно изменяется временная метка).
При работе в Free IPA такая схема работы нарушается. Когда происходит репликация информации между множеством серверов через LDAP становиться невозможным поддерживать атрибут serial number в целостном состоянии. И чтобы корректно делать трансфер зон и доверять атрибуту serial number, разработчики сделали так, что каждый сервер ведет эту нумерацию самостоятельно, потому что нет гарантии в какой последовательности будут получены изменения. При изменении зоны на нескольких серверах, эти изменения могут быть получены непоследовательно, т.е. последнее изменение может быть получено не последним, а, например, в середине цепочки изменений. И администратор может замечать что в SOA записях атрибут serial number имеет разное значение. Так же это можно заметить при сравнении репликации, эта информация будет "подсвечиваться" и на нее можно не обращать внимания. То, что serial number на разных контроллерах отличается это нормально, т.к. каждый контроллер ведет счет этого атрибута самостоятельно. Если Вы планируете использовать внешний DNS и будете делать трансфер зоны, то делать это нужно с одного и того же контроллера, потому что только в пределах одного контроллера значение serial number будет консистентно. Если же есть необходимость выполнять трансфер зоны с другого контроллера, то с него сначала нужно сделать полный трансфер а потом повторные трансферы при изменении значения.
Записи в доменной зоне
Посмотрим содержимое вкладки «записи ресурсов DNS»
Тут мы видим список всех ресурсных записей (от англ. Resource Records, RR), хранящихся в зоне. Каждая ресурсная запись состоит из следующих полей (хотя в интерфейсе нам доступны только три из них: имя, тип и данные):
- Имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись.
- Тип (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи.
- Класс (CLASS) ресурсной записи — теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети.
- TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера.
- Длина поля данных (RDLEN).
- Поле данных (RDATA), формат и содержание которого зависит от типа записи.
Кликнем на записи _kerberos._tcp, которая используется для определения сервера KDC по TCP протоколу. В данном случае в данных мы видим приоритет, вес, порт и цель.
Типы ресурсных записей DNS
Наиболее важные типы DNS-записей:
- Запись A (address record) или запись адреса связывает имя хоста с адресом протокола IPv4, то есть запрос A-записи на имя dc1.ald.local вернёт IPv4-адрес сервера dc1 в домене ald.local.
- Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6, работает также, как А-запись, только с другим протоколом.
- Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя.
- Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
- Запись NS (name server) указывает на DNS-сервер для данного домена.
- Запись PTR (pointer) обратная DNS-запись или запись указателя связывает IP-адрес хоста с его каноническим именем, то есть запрос в домене на IP-адрес хоста в reverse-форме вернёт имя (FQDN) данного хоста.
- SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Active Directory.
Служебная запись (SRV-запись) — стандарт в DNS, определяющий местоположение, то есть имя хоста и номер порта серверов для определённых служб. Определяется в RFC 2782.
SRV-запись имеет такой формат:
_service._proto.name TTL class SRV priority weight port target
Где:
- service: символьное имя сервиса (например, _ldap).
- proto: транспортный протокол, используемый сервисом, как правило TCP или UDP.
- name: доменное имя, для которого эта запись действует.
- TTL: стандарт DNS, время жизни.
- class: стандарт DNS, поле класса (это всегда IN).
- SRV: тип записи (всегда SRV).
- priority: приоритет целевого хоста, более низкое значение означает более предпочтительный.
- weight: относительный вес для записей с одинаковым приоритетом, более высокое значение означает более предпочтительный.
- port: порт TCP или UDP, на котором работает сервис.
- target: каноническое имя машины, предоставляющей сервис.
В домене FreeIPA возможно добавление пользовательских SRV-записей для различных служб, включая NTP.
Для работы некоторых служб, включая NTP, в домене FreeIPA уже существуют специфичные механизмы и записи (через записи типа A или AAAA), однако данные типы записей не поддерживают веса и приоритеты.
При необходимости использовать SRV-записи для локализации NTP-серверов в сети, можно использовать SRV-запись для NTP, которая может выглядеть так:
_ntp._udp.ald.local. 86400 IN SRV 10 5 123 ntpserver.ald.local.
Где:
- _ntp._udp.ald.local.: _ntp - указывает на сервис NTP, _udp - определяет протокол взаимодействия при получении данных от сервиса (порт для взаимодействия определен далее в записи), ald.local. - имя домена.
- 86400: это время жизни (TTL) для этой записи в секундах.
- IN: это класс записи.
- SRV: это тип DNS записи.
- 10: это приоритет для этого сервера; серверы с низким числом имеют высший приоритет.
- 5: это вес для этого сервера; если есть несколько серверов с одинаковым приоритетом, серверы с более высоким весом предпочтительнее.
- 123: это порт, на котором доступна услуга (для NTP это обычно 123).
ntpserver.ald.local.: это CNAME конкретного компьютера в домене, который предоставляет эту услугу (он должен отвечать по протоколу и порту, которые определены в этой записи).
Особенности работы с SRV-записями в домене FreeIPA:
Клиенты домена получают динамические SRV-записи посредством системы доменных имен (DNS).
1. Когда клиент хочет подключиться к определенному сервису, например, к NTP серверу, он отправляет DNS запрос на получение SRV-записи этого сервиса.
2. Сервер DNS отвечает на этот запрос, передавая доменное имя и порт, на котором сервис работает.
3. Затем клиент может устанавливать соединение с этим сервисом, используя полученные данные.
Однако не все сервисы и приложения могут работать с SRV-записями. Поддержка SRV-записей зависит от способности приложения распознавать и использовать их.
Список (пополняемый) других вышедших материалов об ALD Pro:
1. Установка первого контроллера домена ALD Pro 2.2.1:
2. Ввод клиента в домен ALD Pro
3. Установка резервного контроллера домена ALD PRO 2.2.1:
4. Механизм репликации в ALD Pro 2.2.1
5. Служба синхронизации времени Chrony
6. Сервер разрешения имен BIND 9 в ALD Pro 2.2.1
- Видео