Блог о системном администрировании. статьи о linux, windows, схд netapp и виртуализации

Введение

Существует проверенная временем связка для прокси сервера — squid + sams. Я настраивал ее еще лет 8 назад на Freebsd. Недавно у меня появилась необходимость настроить что-то подобное на CentOS 7, и я с удивлением обнаружил, что ничего принципиально нового с тех пор не появилось. Никакой более удобной и информативной web панели к squid не придумали.

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

Приступим к настройке. В своей работе я буду подразумевать, что вы установили и настроили centos по моим рекомендациям. Советую ознакомиться с материалом. Это позволит здесь не тратить время на второстепенные настройки, которые не имеют прямого отношения к теме статьи.

Добавляем сервер к домену через realm

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

Итак, отключаем firewall и SELinux, если не сделали это раньше. Если не хотите отключать, то настройте сами. Данная настройка выходит за рамки статьи.

# mcedit /etc/sysconfig/selinux

меняем значение

SELINUX=disabled

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

setenforce 0

Выключаем firewalld.

# systemctl stop firewalld
# systemctl disable firewalld

Информационная таблица

xs.local	название домена
10.1.3.4	ip адрес контроллера домена
xs-winsrv.xs.local	полное имя контроллера домена
xs-design	имя сервера centos, который вводим в домен
admin51	учетная запись администратора домена

Перед дальнейшей настройкой, убедитесь, что с вашего сервера centos вы без проблем пингуете и резолвите контроллер домена по полному имени. Если есть какие-то проблемы, исправьте это либо указанием нужного dns сервера, либо правкой файла hosts.

Настроим синхронизацию времени с контроллером домена

Это важно, у вас должно быть одинаковое время с контроллером домена. Проверьте его и убедитесь, что стоят одинаковые часовые пояса

Устанавливаем утилиту для синхронизации времени chrony:

# yum install chrony

Добавляем в конфиг /etc/chrony.conf адрес контроллера домена. И делаем его единственным сервером для синхронизации, остальные удаляем.

server xs-winsrv.xs.local iburst

Сохраняем конфиг, запускаем chrony и добавляем в автозагрузку.

# systemctl start chronyd && systemctl enable chronyd

Проверим, что с синхронизацией.

Устанавливаем софт, который понадобится для дальнейшей работы.

# yum install realmd sssd sssd-libwbclient oddjob oddjob-mkhomedir adcli samba-common samba-common-tools

Делаем проверку перед вводом в домен.

# realm discover XS.LOCAL
xs.local
 type: kerberos
 realm-name: XS.LOCAL
 domain-name: xs.local
 configured: no
 server-software: active-directory
 client-software: sssd
 required-package: oddjob
 required-package: oddjob-mkhomedir
 required-package: sssd
 required-package: adcli
 required-package: samba-common-tools

Заводим в домен.

# realm join -U admin51 XS.LOCAL
Password for admin51:

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

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

# id [email protected]
uid=185001305([email protected]) gid=185000513(пользователи домена@xs.local) groups=185000513(пользователи домена@xs.local),185001329([email protected]),185001651([email protected]),185001327([email protected])

Еще несколько проверок.

# realm list

# adcli info xs.local

Сервер завели в домен. Приступаем к основному — настройке samba с интеграцией в AD.

Проверка работы DNS Server

Первым делом пойдем в каталог с логами и проверим, что там у нас:

# cd /var/named/chroot/var/log/named
# ls -l

Все файлы журнала созданы и начали наполняться. Можно проверить один из них. Например, посмотрим, как наш сервер centos (192.168.7.246) логирует запросы пользователей. Попробуем с компьютера 192.168.7.254 (windows) выполнить nslookup yandex.ru и посмотрим как это отразится в лог файле:

26-Sep-2015 19:25:30.923 client 192.168.7.254#56374 (yandex.ru): query: yandex.ru IN A + (192.168.7.246)
26-Sep-2015 19:25:31.013 client 192.168.7.254#56375 (yandex.ru): query: yandex.ru IN AAAA + (192.168.7.246)

Теперь выполним ping site1.ru, чтобы проверить, как сервер поддерживает нашу зону:

Смотрим, что в логах:

26-Sep-2015 19:28:01.660 client 192.168.7.254#49816 (site1.ru): query: site1.ru IN A + (192.168.7.246)

Таким образом очень удобно отследить, куда лезет компьютер. Например, можно поднять временно dns сервер, включить лог запросов. В клиенте указать единственный днс сервер, который мы настроили. Дальше можно отслеживать, к примеру, куда лезет винда после загрузки без нашего ведома. Или откуда грузится реклама в скайпе. Все запросы будут аккуратно складываться в файл, который потом можно спокойно анализировать, а затем, к примеру, настроить запрет сайтов на микротике.

Это все, что я хотел в данном материале рассказать. Тема настройки bind (named) достаточно обширная. Возможно я еще вернусь к ней.

Онлайн курсы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте .

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

• Знания, ориентированные на практику;
• Реальные ситуации и задачи;
• Лучшее из международных программ.

Решение проблем с помощью log-файлов

По умолчанию, сервер Bind хранит логи в файле /var/named/data/named.run.

Для его непрерывного просмотра вводим следующую команду:

tail -f /var/named/data/named.run

Степень детализации логов можно настроить в конфигурационном файле:

logging <channel default_debug <file «data/named.run»; severity dynamic; >; >;

* где file — путь к log-файлу; severity — уровень чувствительности к возникающим событиям. Возможны следующие варианты для severity:

• critical — критические ошибки.
• error — ошибки и выше (critical).
• warning — предупреждения и выше. Предупреждения не говорят о наличии проблем в работе сервиса, однако это такие событтия, которые могут привести с ошибкам, поэтому не стоит их игнорировать.
• notice — уведомления и выше.
• info — информация.
• debug — отладка (подробный лог).
• dynamic — тот же debug.

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

После изменения конфигурационного файла перезапускаем сервис:

Одним из важных сервисов, обеспечивающих функционирование современного интернета является сервис по преобразованию имени сайта в ip адрес. Настройкой реализации сервиса DNS мы займемся в этой статье на примере настройки Bind 9 (named) на сервере под управлением CentOS 7. Мы подготовим минимально необходимый базовый функционал и заглянем немного глубже в настройки логирования.

Настройка Bind

Первым делом настроим view. Открываем конфигурационный файл. В зависимости от типа операционной системы, его местоположение будет разным.

а) в CentOS / Red Hat:

vi /etc/named.conf

б) в Ubuntu / Debian:

vi /etc/bind/named.conf.default-zones

* в вашей инфраструктуре для описания зон могут использоваться другие файлы. Стоит это учитывать при настройке view.

Пример конфигурации для зон в 3-х представлениях — 2 внутренние сети и все остальные:

1. …
2. acl «internal-01» {192.168.0.0/24; };
3. acl «internal-02» {192.168.1.0/24; };
4. view «internal-01» {
5.     match-clients { «internal-01»; };
6.     zone «dmosk.ru» IN {
7.         type master;
8.         file «master/dmosk.ru.in01»;
9.     };
10. };
11. view «internal-02» {
12.     match-clients { «internal-02»; };
13.     zone «dmosk.ru» IN {
14.         type master;
15.         file «master/dmosk.ru.in02»;
16.         allow-transfer { 192.168.1.15; };
17.     };
18. };
19. view «external» {
20.     match-clients { «any»; };
21.     zone «dmosk.ru» IN {
22.         type master;
23.         file «master/dmosk.ru.any»;
24.     };
25. };

* для удобства восприятия, разные блоки конфигурации отмечены разными цветами. Рассмотрим их подробнее:

2, 3 — создаем 2 acl, в которых описываем подсети наших внутренних сетей. После мы их будем использовать для определения доступа к view.
5 — 12 — наш первый view для первой внутренней сети. В опции match-clients мы должны перечислить acl, для клиентов которой нужно отдавать записи зон, входящих в данный view.
14 — 22— view для второй внутренней сети

Обратите внимание, что здесь мы указали другие acl, файл с настройками зоны. Также для данной зоны мы разрешили трансфер на адрес 192.168.1.15.
24 — 31 — последняя view для всех остальных клиентов (как правило, из сети Интернет).

Базовая настройка DNS-сервера

Открываем на редактирование конфигурационный файл bind:

# vi /etc/named.conf

и редактируем следующее:

listen-on port 53 { 127.0.0.1; localhost; 192.168.166.155; };
…
allow-query { any; };

* где 192.168.166.155
— IP-адрес нашего NS-сервера, на котором он будет принимать запросы; allow-query
разрешает выполнять запросы всем, но из соображений безопасности можно ограничить доступ для конкретной сети, например, вместо any
написать 192.168.166.0/24
.

Для применения настроек выполните команду:

# systemctl restart named

Для проверки работоспособности сервера с другого компьютера сети (например, на Windows) выполняем команду:

> nslookup сайт 192.168.166.155

* данной командой мы пытаемся узнать IP-адреса сайта сайт
через сервер 192.168.166.155
.

Должно получиться, примерно, следующее:

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

Для тестирования новой конфигурации сервера имен bind нам пригодится команда dig из пакета dnsutils. Эту команду можно запустить на любом компьютере с сетевым доступом к вашему DNS-серверу, но лучше всего начать тестирование с локального узла. В рассматриваемом нами примере IP-адрес сервера имен 172.31.0.122. Сначала проверим прямое разрешение имени (получение IP-адреса по доменному имени):

dig @172.31.0.122 www.itproffi.ru

Теперь проверим обратную зону:

dig @172.31.0.122 -x 172.31.1.10

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

nslookup itproffi.ru 172.31.0.122

nslookup 172.31.1.10 172.31.0.122

BIND в окружении chroot

В системе CentOS это очень просто. Нужно только отметить, что активные пути BIND будут заменены на chroot-эквиваленты (к примеру, var/named станет /var/named/chroot/var/named). В CentOS 6 не нужно перемещать никаких файлов, поскольку пакет самостоятельно создаст символьные ссылки на не-chroot каталоги.

Чтобы включить эту функцию, используйте:

yum install bind-chroot -y
service named restart

Домены имеют как минимум два DNS сервера, один называется первичным сервером имён (ns1), а другой — вторичным сервером имён (ns2). Вторичные сервера обычно задействуются при проблемах с первичным сервером DNS: если один сервер недоступен, то второй становится активным. Возможны и более сложные схемы с использованием балансировки нагрузки, файерволов и кластеров.

Все DNS записи определённого домена добавляются в первичный сервер имён. Вторичный сервер просто синхронизирует всю информацию, получая её от первичного, на основании параметров, заданных на первичном сервере.

Эта инструкция опишет, как создать первичный DNS сервер, работающий на CentOS

Пожалуйста, обратите внимание, что DNS сервер, представленный в этой инструкции, будет публичным DNS, это означает, что сервер будет отвечать на запросы от любого IP адреса. Как ограничить доступ к серверу, описано в этой инструкции

Перед тем, как мы начнём, хотелось бы упомянуть, что DNS может быть установлен с или без chroot jail окружением. Окружение chroot jail ограничивает DNS сервер определённой директорией в системе, в отличие от полного системного доступа на сервере. Таким образом, любая уязвимость DNS сервера не скомпромитирует всю систему. Ограничение DNS сервера в определённой директории (процесс называется chrooting) также полезно в тестовых условиях.

Подготовка конфигурационных файлов

Как было упомянуто ранее, bind может быть настроен с или без chroot. Пути немного различаются, в зависимости от того, был ли установлен chroot.

	Путь до конфигурационного файла	Путь до файлов зоны
Без chroot	/etc/	/var/named/
С chroot	/var/named/chroot/etc/	/var/named/chroot/var/named/

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

Делаем резервную копию файла /etc/named.conf

Cp /etc/named.conf /etc/named.conf.bak

# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /etc/named.conf

# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /var/named/chroot/etc/named.conf

Теперь, когда есть резервная копия конфигурационного файла, а сам оригинальнвй файл изменён, двигаемся дальше.

# vim /etc/named.conf

# vim /var/named/chroot/etc/named.conf

Следующие строки были добавлены/изменены.

Options {
## путь до файлов зон ##
directory «/var/named»;
## пенераправляем запросы на публичный DNS сервер Google для нелокальных доменов ##
forwarders { 8.8.8.8; };
};
## объявление прямой зоны для example.tst ##
zone «example.tst» IN {
type master;
file «example-fz»; ## файл для прямой зоны размещён в /var/named ##
allow-update { none; };
};
## объявление обратной зоны для сети 172.16.1.0 ##
zone «1.16.172.in-addr.arpa» IN {
type master;
file «rz-172-16-1»; ## файл для обратной зоны размещён в /var/named ##
allow-update { none; };
};

Базовая настройка ДНС сервера BIND

В данном примере мы будем настраивать на ДНС сервере BIND зону remoteshaman.com, потому в Вашем случае поменяете remoteshaman.com на своё доменное имя. Подправим /etc/named.conf до нужной кондиции предварительно сохранив его копию:

$ cp etcnamed.conf etcnamed.conf.bak
$ vi etcnamed.conf
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See usrsharedocbind*/sample for example named configuration files.
//
 
options {
        listen-on port 53 { localhost; 93.170.128.114; };
        #listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { any; };
        allow-transfer { none; };
        recursion no;
        version "Go away!";
 
        additional-from-auth no;
        additional-from-cache no;
 
        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;
 
        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";
 
        managed-keys-directory "/var/named/dynamic";
};
 
logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};
 
zone "." IN {
        type hint;
        file "named.ca";
};
 
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
 
zone "remoteshaman.com" IN {
    type master;
    file "zone/remoteshaman.com.zone";
    allow-update { none; };
};

В конце основного файла конфигурации /etc/named.conf мы добавили секцию «», в которой указали имя файла содержащего ресурсные ДНС записи о нашей зоне remoteshaman.com.

Обычно файлы зон сваливают прямо в каталог /var/named, что на мой взгляд как не эстетично, так и не практично — для зон мы создадим отдельный каталог /var/named/zone. Файл зоны «remoteshaman.com.zone» BIND будет искать в директории /var/named/zone, в которой мы его сейчас и создадим:

$ mkdir varnamedzone
$ chown named:named varnamedzone
$ chmod 0750 varnamedzone
$ vi varnamedzoneremoteshaman.com.zone
$ORIGIN remoteshaman.com.
$TTL 3d
 
@    IN    SOA    ns1.remoteshaman.com. www.remoteshaman.com.yandex.ru. (
        1458462568    ; serial
        1d            ; refresh after 1 day
        2h            ; retry after 2 hour
        4w            ; expire after 4 week
        1d            ; minimum TTL of 1 day
        )
 
@    86400    IN    NS    ns1.remoteshaman.com.
@    259200    IN    MX    10    mx.yandex.net.
@    3600    IN    SPF    "v=spf1 redirect=_spf.yandex.net"
@    259200    IN    TXT    google-site-verification=jr5WMEnS1hBd6ZgyT0HRwNpVbWMgDy9KgDdsbsse-Eo
 
remoteshaman.com.    259200    IN    A    93.170.128.114
ns1.remoteshaman.com.    259200    IN    A    93.170.128.114
www.remoteshaman.com.    259200    IN    CNAME    remoteshaman.com.

Проверяем файл нашей зоны и если всё «OK», то мы должны получить примерно такой вот результат:

$ named-checkzone remoteshaman.com varnamedzoneremoteshaman.com.zone
zone remoteshaman.comIN: loaded serial 1458462568
OK
$ service named start
$ service named status
version: 9.10.2 (Go away!) <id:53e49fb5>
boot time: Fri, 25 Mar 2016 05:28:17 GMT
last configured: Fri, 25 Mar 2016 06:30:11 GMT
CPUs found: 1
worker threads: 1
UDP listeners per interface: 1
number of zones: 9
debug level: 
xfers running: 
xfers deferred: 
soa queries in progress: 
query logging is OFF
recursive clients: 1000
tcp clients: 100
server is up and running
named (pid  13289) is running...

Проверяем работу нашего ДНС сервера:

$ nslookup remoteshaman.com 93.170.128.114
Server:        93.170.128.114
Address:    93.170.128.114#53
 
Name:    remoteshaman.com
Address: 93.170.128.114

Если при «ресолве» мы получаем ошибку:

$ nslookup www.remoteshaman.com 93.170.128.114
Server:        93.170.128.114
Address:    93.170.128.114#53
 
** server can't find www.remoteshaman.com: NXDOMAIN

значит в конце CNAME записи забыли поставить точку.

Как добавить статический маршрут в CentOS

Для управления маршрутизацией в CentOS может понадобиться добавить статический маршрут. Сделать это достаточно просто с помощью консольной команды. Для начала проверим существующие маршруты, используя netstat:

В данном случае у нас один маршрут для адреса 0.0.0.0/0.0.0.0 шлюз используется 192.168.159.2, он же шлюз по-умолчанию. То есть по сути, статических маршрутов никаких нет. Добавим один из них.

Допустим, у нас есть подсеть 192.168.8.0 маска 255.255.255.0, трафик в эту подсеть маршрутизирует шлюз 192.168.159.5 Добавляем маршрут:

Проверяем, появился ли добавленный маршрут в таблицу маршрутизации:

Все в порядке, маршрут добавлен. Делаем то же самое с помощью утилиты ip.

Но после перезагрузки этот статический маршрут будет удален. Чтобы этого не произошло и добавленные маршруты сохранялись, необходимо их записать в специальный файл. В папке /etc/sysconfig/network-scripts создаем файл с именем route-eth0 следующего содержания:

Перезагружаемся и проверяем, на месте ли маршрут:

Все в порядке, статический маршрут добавлен.

Зона прямого просмотра

Зоны прямого просмотра делегируются нам владельцем родительского домена.

Пример файла зоны, для которой мы являемся мастером (SOA ns1.model.local.)
Сервер ns.example.com. указан в качестве вторичного.

Параметры времени жизни записи:

• TTL — время, на которое запись считается действительной, после выдачи сервером. Записи в кэше хранятся в течение TTL.
• Negative Cache TTL — время действия ответа об отсутствии записи (NXDOMAIN). Запись о том, что запрошенное имя не существует хранится в кэше на это время.

TTL можно задавать отдельно для каждой записи. Negative Cache TTL — действует на зоны в целом.

Особенности настройки

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

1. Any должен быть внизу.

Наши блоки view читаются системой сверху вниз. Если сервер DNS при поиске нужной зоны натыкается на подходящий вариант, он использует его. Таким образом, если view с match-clients { «any»; }; поместить в самый верх, будет использоваться только этот блок, а другие так и не задействуются.

2. Настройка зон внутри view.

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

3. Вне view не должно быть зон.

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

Зоны bind

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

1. Первичная, она же master, она же локальная. База, которая пополняется и редактируется на текущем сервере. Подробнее как настроить первичную зону bind.
2. Вторичная или slave. База копирует настройки с первичной зоны на другом сервере. Подробнее как настроить вторичную зону bind.
3. Заглушка или stub. Хранит у себя только записи NS, по которым все запросы переводятся на соответствующие NS-серверы.
4. Кэширующая или hint. Не хранит на сетбе никаких записей — только результаты уже обработанных запросов для ускорения ответов на повторные обращения.

Базовая настройка DNS-сервера

Открываем на редактирование конфигурационный файл bind:

# vi /etc/named.conf

и редактируем следующее:

listen-on port 53 { 127.0.0.1; localhost; 192.168.166.155; };
…
allow-query { any; };

* где 192.168.166.155
— IP-адрес нашего NS-сервера, на котором он будет принимать запросы; allow-query
разрешает выполнять запросы всем, но из соображений безопасности можно ограничить доступ для конкретной сети, например, вместо any
написать 192.168.166.0/24
.

Для применения настроек выполните команду:

# systemctl restart named

Для проверки работоспособности сервера с другого компьютера сети (например, на Windows) выполняем команду:

> nslookup сайт 192.168.166.155

* данной командой мы пытаемся узнать IP-адреса сайта сайт
через сервер 192.168.166.155
.

Должно получиться, примерно, следующее:

Проверка

Настройки завершены. Чтобы убедиться в их корректности, первым делом, проверяем конфигурационный файл командой:

named-checkconf

* команда должна вернуть пустую строку.

После проверяем корректность настройки зон:

named-checkconf -z

Команда должна вернуть что-то на подобие:

zone dmosk.ru/IN: loaded serial 2020120401
zone dmosk.ru/IN: loaded serial 2020120401
zone dmosk.ru/IN: loaded serial 2020120401

* в данном примере для зоны dmosk.ru проверены все файлы. Они корректны.

Теперь можно перезапустить сервер DNS.

а) CentOS / Red Hat:

systemctl restart named

б) Ubuntu / Debian:

systemctl restart bind9

Переходим на клиентский компьютер в первом сетевом сегменте (192.168.0.0/24). Для проверки работы нашего сервера вводим команду (на Linux или Windows клиенте):

nslookup dmosk.ru 192.168.0.2

Мы должны увидеть IP из нашей зоны во view internal-01:

Server:         192.168.0.2
Address:        192.168.0.2#53
Name:   dmosk.ru
Address: 192.168.0.20

Переходим на другой компьютер в сетевом сегменте 192.168.1.0/24. Вводим:

nslookup dmosk.ru 192.168.1.2

В моем случае был получен уже другой ответ:

Server:         192.168.1.2
Address:        192.168.1.2#53
Name:   dmosk.ru
Address: 192.168.1.20

Выполняем команду с компьютера вне диапазонов 192.168.0.0/24 или 192.168.1.0/24:

nslookup dmosk.ru 92.53.123.165

Пример ответа:

Server:         92.53.123.165
Address:        92.53.123.165#53
Name:   dmosk.ru
Address: 92.53.123.166

Мы настроили Split DNS на Linux сервере с Bind.

Частное FQDN имя сервера

Включение роли DNS

1. Запустите Server Manager
2. В правом верхнем углу окна Server Manager нажмите Manage и из выпадающего меню выберите Add Roles and Features
3. В окне мастера Add Roles and Features Wizard нажмите Next
4. Оставьте опцию по умолчанию Role-based or feature-based installation и нажмите Next
5. Выберите сервер, которому нужно назначить новую роль и нажмите Next
6. В списке выберите DNS Server. В появившемся диалоговом окне оставьте значения по умолчанию, нажмите Add Features и Next
7. На странице Features нажмите Next
8. На странице DNS Server нажмите Next
9. Нажмите Install
10. По окончании установки нажмите Close

Добавление новой зоны

1. В правом верхнем углу оснастки выберите Tools и в выпадающем меню DNS
2. Откроется DNS manager. Кликните правой кнопкой мыши по имени сервера и выберите New Zone…
3. В мастере New Zone Wizard нажмите Next
4. Оставьте Primary zone по умолчанию и нажмите Next
5. Выберите Forward lookup zone и нажмите Next
6. Укажите имя зоны, в нашем примере, example.com, и нажмите Next
7. На странице Zone File оставьте параметры по умолчанию и нажмите Next
8. На странице Dynamic Update оставьте параметры по умолчанию, нажмите Next и Finish

Добавление нового хоста

1. Кликните правой кнопкой мыши по созданной зоне и выберите New Host (A or AAAA)…
2. Укажите имя хоста, в нашем примере, pbx
3. Укажите частный (локальный) IP адрес сервера 3CX Phone System
4. Нажмите Add Host. Появится сообщение о том, что запись pbx.example.com создана. Нажмите OK и Done

Именно это FQDN имя вы указываете во время инсталляции сервера 3CX Phone System в разделе FQDN.nslookup pbx.example.com