В данной статье мы рассмотрим простой пример установки BIND на CentOS 6-версии. BIND – одна из популярных реализаций DNS-сервера, с открытым исходным кодом. DNS – сервера выполняют преобразование DNS-имени в IP-адрес и наоборот.
Перед началом установки хотелось бы отметить, что рекомендуется иметь хотя бы два сервера в облаке, чтобы обеспечить лучшую работоспособность в случае отказа работы одного из серверов. В нашем примере мы предполагаем настройку как первичного, так и вторичного сервера DNS.
Обратите внимание, что если вы решили использовать большое количество доменных имен, то конфигурирование настроек подобным образом может оказаться не очень удобным.
Использование своего сервера DNS позволяет иметь более прямой контроль над инфраструктурой вашего хостинга, а так же DNS записями. Пожалуй, можно приступать к установке.
Первое что следует сделать, проверить актуальность системы, и обновить в случае необходимости. Проверить наличие обновлений вы можете посредством команды yum.
# yum update –y
После этого можно приступить в первичной установке BIND на сервер.
Первичная установка BIND на сервер
# yum install bind bind-utils –y
После установки сервера необходимо открыть конфигурационный файл для настройки конфигурации.
# vi -w /etc/named.conf
В конфигурации «options» вместо IP адреса 2.2.2.2 следует прописать адрес вашего второго сервера.
Options { #listen-on port 53 { 127.0.0.1; }; 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 { localhost; 2.2.2.2; }; recursion 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"; };
Из соображений безопасности мы закомментировали значение директивы «listen-on». Параметр обозначает, что сервер будет принимать обращения со всех доступных интерфейсов. Так же выставляем директиву в «recursion» в «no», так как это может послужить уязвимостью для DDOS-атак на сервер. В директиве «allow-transfer» указываем сервера, которым мы «доверяем», это наш второй сервер. Выставляем для директивы «allow-query» значение «any», это позволит получать надлежащий доступ к размещаемым доменным зонам.
Следующим шагом мы добавим запись для первого домена, в файле конфигурации named.conf
Zone "mydomain.com" IN { type master; file "mydomain.com.zone"; allow-update { none; }; };
После сохранения файла, мы можем приступить к созданию первого файла доменной зоны. Создаем файл, используя доменное имя использованное выше, т.е. mydomain.com.zone:
# vi /var/named/mydomain.com.zone
Файл мы создаем, поэтому нам в нем следует указать кое-какие параметры. Подобно примеру, показанному ниже, вы должны заменить адреса 1.1.1.1 – это адрес вашего первого сервера (NS1), 2.2.2.2 – это адрес вашего второго сервера (NS2), и 3.3.3.3 – адрес, на котором находится веб-сервер. Дополнительные записи доменных имен вы можете добавлять в том же формате.
$TTL 86400 @ IN SOA ns1.mydomain.com. root.mydomain.com. (2013042201 ;Serial 3600 ;Refresh 1800 ;Retry 604800 ;Expire 86400 ;Minimum TTL) ; указываем пару NS серверов IN NS ns1.mydomain.com. IN NS ns2.mydomain.com. ; замените адреса серверов на свои ns1 IN A 1.1.1.1 ns2 IN A 2.2.2.2 ; указываем имя хостов и IP серверов, которые будут отвечать @ IN A 3.3.3.3 www IN A 3.3.3.3
Теперь мы первично запускаем сервер named. Это может занять некоторое время, пока named сгенерирует файл rndc.key, создаваемый только при первом запуске.
# service named restart
# chkconfig named on
После предыдущих шагов настроек на данный момент мы уже должны иметь полностью работоспособный первичный DNS сервер. Чтобы проверить, что это дело работает, следует выполнить команду указанную ниже, а так же заменить адрес 1.1.1.1 на адрес вашего первичного сервера.
# dig @1.1.1.1 mydomain.com
Если вы увидите характерную запись, с обозначением полномочий, то ваш сервер имен настроен правильно.
Конфигурация вторичного DNS сервера
После того как первичный сервер был настроен, приступим к настройке вторичного сервера. Как уже мы делали ранее, обновляем систему, до актуальной версии.
# yum update –y
После этого устанавливаем BIND сервер, а так же его компоненты на вторичный сервер, аналогичным образом, как это делали ранее.
# vi /etc/named.conf options { #listen-on port 53 { 127.0.0.1; }; 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; }; recursion no; dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; /* путь до ISC DLV ключа */ bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; };
Добавляем запись зоны, аналогично первичному серверу, за исключением того, что в директиве type нужно указать slave, а так же поменять 1.1.1.1 на адрес первичного сервера.
Zone "mydomain.com" IN { type slave; masters { 1.1.1.1; }; file "mydomain.com.zone"; };
После конфигурирования вторичной зоны, следует перезапустить сервер named. Как и говорилось ранее, на этом сервере так же будет создан файл rndc.key, это займет немного времени.
Добавляем файл сервер в автозагрузку:
# chkconfig named on
Проверяем, что всё работает, заменяем 2.2.2.2 на адрес вашего вторичного сервера.
# dig @2.2.2.2 mydomain.com
После внесения изменений, внесенных в файл основной доменной зоны, вам следует поручать BIND серверу перезагружать конфигурацию. Есть директива serial
, значение которой должно увеличиваться вручную, главным образом служит для синхронизации между ведущим и ведомым серверами.
Для перезагрузки файла зон с новой конфигурацией, следует выполнить следующую команду на первичном сервере, затем на вторичном.
Одним из важных сервисов, обеспечивающих функционирование современного интернета является сервис по преобразованию имени сайта в ip адрес. Настройкой реализации сервиса DNS мы займемся в этой статье на примере настройки Bind 9 (named) на сервере под управлением CentOS 7. Мы подготовим минимально необходимый базовый функционал и заглянем немного глубже в настройки логирования.
Bind — самая распространенная на текущий день реализация ДНС сервера, которая обеспечивает преобразование IP адресов в dns-имена и наоборот. Его также называют named, например в Freebsd. Судя по информации из Википедии, сейчас 10 из 13 корневых ДНС серверов интернета работают на bind. Он установлен из коробки практически во всех linux дистрибутивах. Я рассмотрю его установку на сервер CentOS 7.
Устанавливаем Bind 9 (named) в CentOS 7
Первым делом проверим, установлен ли у нас днс сервер в системе:
# rpm -qa bind* bind-libs-lite-9.9.4-14.el7.x86_64 bind-license-9.9.4-14.el7.noarch
У меня не установлен, так как во время выбрал минимальный пакет программ. Сервер имен у нас будет работать в chroot окружении, так что устанавливаем соответствующие пакеты:
# yum - y install bind bind - utils bind - chrootЕще раз обращаю внимание, что мы будем использовать bind в chroot среде для увеличения безопасности. Это накладывает определенные особенности в настройке и управлении сервером. Нужно быть внимательным в этих мелочах. Итак, запускаем bind :
# systemctl start named-chroot # systemctl enable named-chroot ln -s "/usr/lib/systemd/system/named-chroot.service" "/etc/systemd/system/multi-user.target.wants/named-chroot.service"
Проверяем содержимое chroot каталога:
# ls -l /var/named/chroot/etc
Все в порядке, сервер запустился, необходимые файлы созданы, все готово для настройки. Займемся ей.
Настраиваем DNS сервер в CentOS 7
Файл конфигурации нашего сервера располагается по адресу /var/named/chroot/etc/named.conf . Открываем его и приводим к следующему виду:
# mcedit /var/named/chroot/etc/named.conf options { listen-on port 53 { any; }; listen-on-v6 port 53 { none; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; allow-query { 127.0.0.1; 192.168.7.0/24; }; recursion yes; allow-recursion { 127.0.0.1; 192.168.7.0/24; }; forwarders { 8.8.8.8; }; version "DNS Server"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; dnssec-enable no; dnssec-validation no; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; logging { channel default_file { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; }; category default { default_file; }; };
Эта конфигурация обеспечит работу обычного кэширующего сервера в локальной сети. Комментарии к некоторым параметрам:
Не забудьте отредактировать правила фаервола для корректной работы DNS сервера — открыть 53 порт UDP для работы кэширующего сервера, который мы сейчас настроили, и 53 порт TCP для пересылки зон, о которых речь пойдет дальше
Теперь создадим папку для логов. Не забываем, что мы работаем в chroot окружении:
# cd /var/named/chroot/var/log && mkdir named && chown named. named
Поддержка собственной зоны
Допустим, нам необходимо в нашем named разместить собственную зону site1.ru. Первым делом создаем файл зоны, которую будет обслуживать dns сервер:
# mcedit /var/named/chroot/var/named/site1.ru.zone $TTL 86400 @ IN SOA site1.ru. site1.ru.local. (2015092502 43200 3600 3600000 2592000) IN NS ns1.site1.ru. IN NS ns2.site1.ru. IN A 192.168.7.254 IN MX 10 mx.site1.ru. gate IN A 192.168.7.254 mx IN A 192.168.7.250 ns1 IN A 192.168.7.235 ns2 IN A 192.168.7.231
Описание синтаксиса файлов зон достаточно хорошо освещено в интернете, не хочется подробно на этом останавливаться. При желание каждый сам сможет посмотреть, если у него возникнет необходимость настроить поддержку собственной зоны.
Выставляем необходимые права:
# chown root:named /var/named/chroot/var/named/site1.ru.zone # chmod 0640 /var/named/chroot/var/named/site1.ru.zone
Zone "site1.ru" { type master; file "site1.ru.zone"; };
Перечитываем конфигурацию named с помощью rndc :
# rndc reconfig
Добавление в bind slave zone
Если вы хотите на своем сервере держать копию какой-то зоны, взятой с другого dns сервера, то добавьте следующие настройки в конфиг.
Zone "site.ru" IN { type slave; masters { 10.1.3.4; }; file "site.ru.zone"; };
10.1.3.4 — ip адрес dns сервера, с которого мы берем зону. Не забудьте на нем разрешить передачу зоны на ваш dns сервер.
Нужно добавить группе named разрешение на запись, чтобы стало вот так:
После этого можно перезапустить bind и проверить, что создался файл слейв зоны. С указанными выше настройками, он будет располагаться по адресу /var/named/chroot/var/named/site.ru.zone . Если у bind не будет прав для создания файла, в логе вы получите ошибку:
Dumping master file: tmp-7Swr6EZpcd: open: permission denied
Гораздо интереснее и полезнее разобраться с подробным логированием работы сервера. Я долгое время поверхностно хватался за всякие рекомендации и куски примерных конфигов в интернете, пока в не решил разобраться сам с этой темой и не полез в оригинальный мануал .
Bind дает широкие возможности для ведения логов. Можно фиксировать практически все, что связано с работой сервера. Я сейчас на простых примерах покажу, как это работает.
Первым делом в конфигурации мы задаем канал, куда будут складываться логи по тем или иным событиям. Вот пример подобного канала:
Channel general { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes;
Здесь указано название канала, которые мы придумываем сами — general, указан путь до файла, сказано, что хранить будем 3 версии лога размером не более 5 мегабайт. Параметр severity может принимать следующие значения:
Параметр print-time указывает на то, что в лог необходимо записывать время события. Помимо указанных мной настроек, в конфигурации канала могут быть добавлены следующие параметры:
- print-severity yes | no — указывает, писать или нет параметр severity в лог
- print-category yes | no — указывает писать или нет название категории логов
Я эти параметры не указал, так как по-умолчанию устанавливается значение no , которое лично меня устраивает.
Category general { general; };
| default | Сюда будут попадать события всех категорий из этой таблицы, если они не определены отдельно, за исключением категории queries, которую нужно включать специально. То есть если обозначить только категорию default, то в нее будут сыпаться события всех категорий. |
| general | Эта категория для всех логов, которые не включены ни в одну из перечисленных категорий. |
| database | Сообщения, относящиеся к хранению зон и кэшированию. |
| security | Подтверждение и отказ в выполнении запросов. |
| config | Все, что относится к чтению и выполнению файла конфигурация. |
| resolver | Разрешение имен, включая информацию о рекурсивных запросах, выполняемых от имени клиента кэширующим сервером. |
| xfer-in | Информация о получении зон. |
| xfer-out | Информация о передаче зон. |
| notify | Логирование операций протокола NOTIFY. |
| client | Выполнение клиентских запросов. |
| unmatched | Сообщения, которые named не смог отнести ни к одному классу или для которых не определено отображение. |
| network | Логирование сетевых операций. |
| update | Динамические апдейты. |
| update-security | Подтверждение или отклонение запросов на апдейт. |
| queries | Логирование запросов к ДНС серверу. Для включения этой категории необходимо отдельно задать параметр в конфигурации сервера. Это связано с тем, что эта категория генерирует очень много записей в лог файл, что может сказаться на производительности сервера. |
| query-errors | Ошибки запросов к серверу. |
| dispatch | Перенаправление входящих пакетов модулям сервера на обработку. |
| dnssec | Работа протоколов DNSSEC и TSIG. |
| lame-servers | Фиксируются ошибки, которые получает bind при обращении к удаленным серверам в попытке выполнить запрос на разрешение имени. |
| delegation-only | Логирование запросов, вернувших NXDOMAIN. |
| edns-disabled | Запросы, которые вынуждены использовать plain DNS из-за превышения timeouts. |
| RPZ | Все операции, связанные с выполнение Response Policy Zone (RPZ). |
| rate-limit | Операции связанные с одним или несколькими rate-limit statements в options или view. |
Таким образом, чтобы вывести все категории логов в отдельные файлы, необходимо в конфиг named добавить следующую конструкцию:
Logging { channel default { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel general { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel database { file "/var/log/named/database.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel security { file "/var/log/named/security.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel config { file "/var/log/named/config.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel resolver { file "/var/log/named/resolver.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel xfer-in { file "/var/log/named/xfer-in.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel xfer-out { file "/var/log/named/xfer-out.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel notify { file "/var/log/named/notify.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel client { file "/var/log/named/client.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel unmatched { file "/var/log/named/unmatched.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel network { file "/var/log/named/network.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel update { file "/var/log/named/update.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel update-security { file "/var/log/named/update-security.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel queries { file "/var/log/named/queries.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel query-errors { file "/var/log/named/query-errors.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel dispatch { file "/var/log/named/dispatch.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel dnssec { file "/var/log/named/dnssec.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel lame-servers { file "/var/log/named/lame-servers.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel delegation-only { file "/var/log/named/delegation-only.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel edns-disabled { file "/var/log/named/edns-disabled.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel rpz { file "/var/log/named/rpz.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel rate-limit { file "/var/log/named/rate-limit.log" versions 3 size 5m; severity dynamic; print-time yes; }; category default { default; }; category general { general; }; category database { database; }; category security { security; }; category config { config; }; category resolver { resolver; }; category xfer-in { xfer-in; }; category xfer-out { xfer-out; }; category notify { notify; }; category client { client; }; category unmatched { unmatched; }; category network { network; }; category update { update; }; category update-security { update-security; }; category queries { queries; }; category query-errors { query-errors; }; category dispatch { dispatch; }; category dnssec { dnssec; }; category lame-servers { lame-servers; }; category delegation-only { delegation-only; }; category edns-disabled { edns-disabled; }; category rpz { rpz; }; category rate-limit { rate-limit; }; };
Если мы хотим собирать все логи запросов из категории queries , то в раздел options файла конфигурации необходимо добавить параметр, который это разрешает:
Querylog yes;
Перезапускаем bind :
# systemctl restart named-chroot.service
Проверка работы 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) достаточно обширная. Возможно я еще вернусь к ней.
Онлайн курс "Администратор Linux"
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Администратор Linux» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Проверьте себя на вступительном тесте и смотрите программу детальнее по.Простыми словами. Версии используемого ПО — CentOS 7, BINВ 9.
Подготовка сервера
Устанавливаем все обновления:
Устанавливаем утилиту для синхронизации времени:
# yum install ntpdate
Настраиваем временную зону:
# \cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime
* в данном примере выбрано московское время.
И синхронизируем время с внешним сервером:
# ntpdate ru.pool.ntp.org
Открываем порт в firewall:
# firewall-cmd --permanent --add-port=53/udp
И перечитываем настройки сетевого экрана:
# firewall-cmd --reload
Установка и запуск BIND
Устанавливаем DNS-сервер следующей командой:
# yum install bind
Разрешаем автозапуск:
# systemctl enable named
Запускаем сервис имен:
# systemctl start named
И проверяем, что он работает корректно:
# systemctl status named
Базовая настройка 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 .
Должно получиться, примерно, следующее:
Описание глобальных опций
Перечисленные ниже параметры являются глобальными по отношению к DNS и всем настроенным зонам. Они задаются в конфигурационном файле named.conf, директиве options {}.
| Опции | Описания |
|---|---|
| directory | Указывает рабочий каталог сервера bind. Если не указан, /var/named |
| forwarders | Перечисляет серверы, на которые будет переведен запрос, в случае, если наш сервер не сможет его обработать (нет соответствующей зоны.) |
| forward | Переопределяет способ обработки запроса. Принимает два значения — ONLY или FIRST. Первое указывает на то, что сервер не будет пытаться искать совпадения среди локальных зон. Второе — сервер сначала будет перенаправлять запрос и если он не будет успешно обработан, искать соответствия во внутренней базе. |
| listen-on | На каких интерфейсах будет слушать bind |
| allow-transfer | Указание на список серверов на которые будут разрешены зонные передачи (репликация на вторичные NS) |
| allow-query | Список узлов, с которых разрешено обращаться к серверу. Если не задана, разрешено всем. |
| allow-notify | Перечисленным серверам разрешает отправку уведомлений об изменениях в настройках зоны. |
| allow-recursion | Задает список хостов, для которых разрешены рекурсивные запросы, остальным — будут разрешены итеративные. Если не задана, для всех рекурсивно. |
Пример глобальных настроек
options {
directory "/var/named";
forwarders { 192.168.0.10; 77.88.8.8; 8.8.8.8; };
listen-on { 127.0.0.1; localhost; 192.168.166.155; };
allow-transfer { 192.168.1.15; 192.168.0.0/24; };
allow-query { 192.168.1.0/24; 192.168.0.2; 192.168.0.3; };
allow-notify { 192.168.0.15; };
allow-recursion { any; };
}
Зоны bind
Для возможности искать соответствия в собственной базе доменов, необходимо создать и настроить зоны. Существуют следующие типы зон:
- Первичная, она же master, она же локальная. База, которая пополняется и редактируется на текущем сервере. Подробнее как настроить первичную зону bind .
- Вторичная или slave. База копирует настройки с первичной зоны на другом сервере. Подробнее как настроить вторичную зону bind .
- Заглушка или stub. Хранит у себя только записи NS, по которым все запросы переводятся на соответствующие NS-серверы.
- Кэширующая или hint. Не хранит на сетбе никаких записей — только результаты уже обработанных запросов для ускорения ответов на повторные обращения.
Решение проблем с помощью log-файлов
По умолчанию, сервер Bind хранит логи в файле
/var/named/data/named.run
.
Для его непрерывного просмотра вводим следующую команду:
tail /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.
Представляем вашему вниманию новый курс от команды The Codeby - "Тестирование Веб-Приложений на проникновение с нуля". Общая теория, подготовка рабочего окружения, пассивный фаззинг и фингерпринт, Активный фаззинг, Уязвимости, Пост-эксплуатация, Инструментальные средства, Social Engeneering и многое другое.
Домены имеют как минимум два DNS сервера, один называется первичным сервером имён (ns1), а другой — вторичным сервером имён (ns2). Вторичные сервера обычно задействуются при проблемах с первичным сервером DNS: если один сервер недоступен, то второй становится активным. Возможны и более сложные схемы с использованием балансировки нагрузки, файерволов и кластеров.
Все DNS записи определённого домена добавляются в первичный сервер имён. Вторичный сервер просто синхронизирует всю информацию, получая её от первичного, на основании параметров, заданных на первичном сервере.
Эта инструкция опишет, как создать первичный DNS сервер, работающий на CentOS . Пожалуйста, обратите внимание, что DNS сервер, представленный в этой инструкции, будет публичным DNS, это означает, что сервер будет отвечать на запросы от любого IP адреса. Как ограничить доступ к серверу, описано в этой инструкции.
Перед тем, как мы начнём, хотелось бы упомянуть, что DNS может быть установлен с или без chroot jail окружением. Окружение chroot jail ограничивает DNS сервер определённой директорией в системе, в отличие от полного системного доступа на сервере. Таким образом, любая уязвимость DNS сервера не скомпромитирует всю систему. Ограничение DNS сервера в определённой директории (процесс называется chrooting) также полезно в тестовых условиях.
Цель
Мы настроим DNS сервер в тестовых условиях для домена example.tst, который является гипотетическим (не существующим) доменом. Таким образом, мы не вмешаемся случайным образом в работу каких-либо реальных доменов.
В этом домене есть три следующих сервера.
| Сервер | IP адрес | Хостящиеся службы | FQDN |
| Сервер A | 172.16.1.1 | mail.example.tst | |
| Сервер B | 172.16.1.2 | Web, FTP |
www.example.tst ftp.example.tst |
| Сервер C | 172.16.1.3 | Primary DNS server | ns1.example.tst |
Мы настроем первичный DNS сервер и добавим необходимый домен и DNS записи как показанов в таблице.
Настраиваем имена хостов
Все хосты должны быть корректно определены с точки зрения FQDN . Это может быть сделано с использованием следующего метода.
Те, кто любит графический интерфейс, могут воспользоваться инструментами NetworkManaget. Для этого наберите команду nmtui . Откроется такой псевдографический интерфейс:
Выбираете «Изменить имя узла» и вводите ns1.example.tst
Когда готово, нажимаете и ОК.
Ещё один способ, всего в одну команду:
Hostnamectl set-hostname ns1.example.tst
После установки, имя хоста может быть проверено следующей командой.
# hostname ns1.example.tst
Hostnamectl status
Перед тем, как перейти к следующему шагу, убедитесь, что имя хоста для всех серверов задано должным образом.
Установка пакетов
Мы будем использовать bind для DNS, который с лёгкостью может быть установлен командой yum.
Установка DNS без chroot:
# yum install bind
Установка DNS с chroot:
# yum install bind bind-chroot
Подготовка конфигурационных файлов
Как было упомянуто ранее, 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; }; };
Подготовка файлов зон
Дефолтные файлы зон автоматически созданы в /var/named или /var/named/chroot/var/named (для chroot).
Подразумевая, что дефолтные файлы зон не представлены, мы можем скопировать файлы образцов из /usr.
# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/
# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/chroot/var/named
Отлично. Теперь дефолтные файлы зоны готовы, мы создаём наши собственные файлы зоны для example.tst и сети 172.16.1.0. Пока мы создаём файлы зоны, нужно помнить следующее.
- Символ ‘@’ означает NULL в файлах зоны.
- Каждая запись полного доменного имени (FQDN) заканчивается точкой ‘.’ например. mail.example.tst. Без точки, будут проблемы.
1. Прямая зона
Прямая зона содержит карту преобразований из имён в IP адреса. Для публичных доменов, DNS доменов, размещённых на хостингах, содержаться в файле прямой зоны.
# vim /var/named/example-fz
# vim /var/named/chroot/var/named/example-fz $TTL 1D @ IN SOA ns1.example.tst. mial.example.tst. (0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H) ; minimum IN NS ns1.example.tst. IN A 172.16.1.3 mail IN A 172.16.1.1 IN MX 10 mail.example.tst. www IN A 172.16.1.2 ns1 IN A 172.16.1.3 ftp IN CNAME www.example.tst.
Объяснение : Внутри файла зоны, SOA означает начало авторизации. Это полное доменное имя авторитетного сервера имен. После полного доменного имени, идёт контактный email адрес. Поскольку мы не можем использовать ‘@’ в [email protected], мы перезаписываем email адрес как mial.example.tst.
- NS : Имя сервера
- A : A запись или запись адреса — это IP адрес
- MX : Mail Exchanger запись. Здесь мы используем только один MX с приоритетом 10. В случае множества MX, мы можем использовать различные цифровые приоритеты. Нижний номер выигрывает. Например, MX 0 лучше чем MX 1.
- CNAME : имя в каноническом виде. Если на сервере размещено множество служб, весьма вероятно, что множество имён будут преобразовываться к одному серверу. CNAME сигнализирует, что другие имена сервер может иметь и отсылает к имени, которое содержится в A записи.
2. Обратная зона
Обратная зона содержит карту преобразований из IP адресов в имена. Здесь мы создаём обратную зону для сети 172.16.1.0. В реальном домене, DNS сервер владельца публичного IP блока содержится в файле обратной зоны.
# vim /var/named/rz-172-16-1
# vim /var/named/chroot/var/named/rz-172-16-1 $TTL 1D @ IN SOA ns1.example.tst. sarmed.example.tst. (0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H) ; minimum IN NS ns1.example.tst. 1 IN PTR mail.example.tst. 2 IN PTR www.example.tst. 3 IN PTR ns1.example.tst.
Объяснение : Большинство используемых параметров в обратной зоне идентичный прямой зоне, кроме одного.
- PTR : PTR или запись указателя, она указывает на полное доменное имя
Завершение
Теперь, когда файлы зон готовы, мы настроем разрешение файлов зоны.
# chgrp named /var/named/*
# chgrp named /var/named/chroot/var/named/*
Сейчас мы зададим IP адрес DNS сервера.
# vim /etc/resolv.conf nameserver 172.16.1.3
Наконец, мы можем запустить службу DNS и убедиться, что она добавлена в автозапуск.
# service named restart # chkconfig named on
Тестирование DNS
Мы можем использовать dig или nslookup для тестирования DNS. Вначале, мы установим необходимые пакеты.
# yum install bind-utils
1. Тестирование прямой зоны с использованием dig
# dig example.tst ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31184 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 86400 IN A 172.16.1.3 ;; AUTHORITY SECTION: example.com. 86400 IN NS ns1.example.com. ;; ADDITIONAL SECTION: ns1.example.com. 86400 IN A 172.16.1.3
2. Проверка PTR с помощью dig
Когда вы используете для тестирования dig, вам всегда следует искать статус "NOERROR". Любое другое состояние означает, что что-то не так.
# dig -x 172.16.1.1 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27415 ;; QUESTION SECTION: ;1.1.17.172.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.1.16.172.in-addr.arpa. 86400 IN PTR mail.example.tst. ;; AUTHORITY SECTION: 1.16.172.in-addr.arpa. 86400 IN NS ns1.example.tst. ;; ADDITIONAL SECTION: ns1.example.tst. 86400 IN A 172.16.1.3
3. Проверка MX с помощью dig
# dig example.tst mx
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35405
;; QUESTION SECTION:
;example.tst. IN MX
;; ANSWER SECTION:
example.tst. 14366 IN MX 10 mail.example.tst.
Подсказки при решении проблем
- У меня отключён SELinux.
- Убедитесь, что ваш файервол не блокирует UDP порт 53
- /var/log/messages должен содержать полезную информацию в случае, если что-то не так
- Убедитесь, что владельцев файлов зон является пользователь ‘named’
- Убедитесь, что IP адрес DNS сервера стоит на первом месте в /etc/resolv.conf
- Если вы используете example.tst в лабораторных условиях, убедитесь, что отсоединили сервер от Интернета, поскольку example.tst — это несуществующий домен.
Подытожим, этот урок фокусируется на хостинге домена example.tst в лабораторных условиях для демонстрационных целей. Пожалуйста, помните, что это не инструкция по созданию публичного DNS сервера, например DNS сервера, который отвечает на запросы от любых IP адресов. Если вы настраиваете рабочий DNS сервер, убедитесь, что проверили, какие политика относятся к публичным DNS. Другой урок освещает создание вторичного DNS, ограничение доступа к DNS серверу, и реализацию DNSSEC.
Гарант является доверенным посредником между Участниками при проведении сделки.
|
В этом руководстве речь пойдёт об установке и настройке DNS-сервера BIND.
Для выполнения инструкций рекомендуется настроить как минимум два облачных сервера для запуска серверов имен (nameservers); наличие нескольких серверов имён позволяет использовать запасные ресурсы в случае возникновения ошибки. Также можно рассмотреть возможность использования двух разных точек присутствия (POP). Предполагается использование первичного (мастер) и вторичного сервера имен (слейв).
Стоит отметить, что при управлении большим количеством доменов это может оказаться не самым эффективным решением, так как вам придётся вручную добавить домены и на мастер, и на слейв. С учетом сказанного, запуск собственных серверов имен – отличный способ обеспечить прямой контроль над хостинговой инфраструктурой и записями DNS.
Как всегда, для начала важно убедиться, что система находится в актуальном состоянии. Проверьте наличие обновлений с помощью yum:
Установка BIND
Чтобы установить пакеты BIND и bind-utils, используйте yum:
Затем откройте конфигурационный файл BIND и внесите в него некоторые коррективы.
nano -w /etc/named.conf
В файле найдите раздел options, который выглядит так (вместо 2.2.2.2 – IP-адрес второго сервера):
options {
directory "/var/named";
allow-query { any; };
allow-transfer { localhost; 2.2.2.2; };
recursion no;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
};
Директива listen-on должна быть закомментирована для прослушивания доступных интерфейсов. Директива recursion должна иметь значение off, чтобы предотвратить reflection DDoS-атаки. Директива allow-transfer добавляет в белый список IP-адрес вторичного сервера. кроме того, нужно изменить значение директивы allow-query на any, чтобы предоставить пользователям доступ к зонам.
Затем нужно добавить новую зону для первого домена. Для этого поместите в конце файла named.conf следующий код:
zone "mydomain.com" IN {
type master;
file "mydomain.com.zone";
allow-update { none; };
};
Сохраните изменения в named.conf. После этого можно приступать к созданию файла описания зоны (zone-файла).
Настройка зон BIND
Для начала нужно открыть zone-файл, указав имя, внесённое в предыдущий конфигурационный файл (mydomain.com.zone).
nano -w /var/named/mydomain.com.zone
Внесите в файл нижеприведённый код. Замените условные IP-адреса адресами ваших серверов (1.1.1.1 – IP-адрес первого сервера, 2.2.2.2 – IP-адрес второго сервера, 3.3.3.3 – IP, на который нужно направить домен (например, веб-сервер)). При необходимости внесите в код другие поправки.
$TTL 86400
@ IN SOA ns1.mydomain.com. root.mydomain.com. (
2013042201 ;Serial
3600 ;Refresh
1800 ;Retry
604800 ;Expire
86400 ;Minimum TTL
; Specify our two nameservers
IN NS ns1.mydomain.com.
IN NS ns2.mydomain.com.
; Resolve nameserver hostnames to IP, replace with your two droplet IP addresses.
ns1 IN A 1.1.1.1
ns2 IN A 2.2.2.2
; Define hostname -> IP pairs which you wish to resolve
@ IN A 3.3.3.3
www IN A 3.3
Запустите named. Запуск может занять несколько минут, поскольку при первом запуске named создаёт файл rndc.key.
service named restart
После успешного запуска демона named нужно убедиться, что он включён как сервис:
chkconfig named on
Теперь первичный сервер имён полностью готов. Чтобы убедиться в том, что BIND работает должным образом, запустите следующую команду, указав IP сервера вместо 1.1.1.1:
dig @1.1.1.1 mydomain.com
Если полученный результат содержит разделы answer и authority, значит, настройка выполнена правильно.
Настройка слейв сервера
Итак, мастер сервер готов к работе. Теперь нужно настроить вторичный сервер имён на втором облачном сервере.
Убедитесь, что система находится в актуальном состоянии.
Установите BIND и его утилиты на второй облачный сервер:
yum install bind bind-utils -y
Откройте named.conf и внесите в него такие же коррективы, как и на первом сервере, пропустив директиву allow transfer – эта директива не нужна, поскольку записи буду передаваться только с первичного сервера имен.
nano -w /etc/named.conf
options {
#listen-on port 53 { 127.0.0.1; };
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; };
recursion 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";
};
Добавьте зоны, настроенные на предыдущем сервере, заменив значение директивы type на slave. Укажите IP первого сервера вместо 1.1.1.1:
zone "mydomain.com" IN {
type slave;
masters { 1.1.1.1; };
file "mydomain.com.zone";
};
Настроив зону slave, запустите демон named. Опять же, на это может уйти несколько минут, поскольку при первом запуске на сервере демон создаёт файл rndc.key.
service named start
Как и на первом облачном сервере, проверьте, работает ли демон named:
chkconfig named on
Вторичный сервер имён теперь готов к работе. Чтобы убедиться, что он работает должным образом, используйте следующую команду, заменив 2.2.2.2 IP-адресом второго облачного сервера.
dig @2.2.2.2 mydomain.com
После внесения каких-либо изменений в файлы зоны первичного сервера необходимо перезагрузить BIND. Помните, что вам также нужно увеличить директиву serial, чтобы обеспечить синхронную работу первичного и вторичного сервера.
Чтобы перезапустить файлы зоны, используйте следующую команду сначала на мастере, а потом на слейве:
BIND в окружении chroot
В системе CentOS это очень просто. Нужно только отметить, что активные пути BIND будут заменены на chroot-эквиваленты (к примеру, var/named станет /var/named/chroot/var/named). В CentOS 6 не нужно перемещать никаких файлов, поскольку пакет самостоятельно создаст символьные ссылки на не-chroot каталоги.
Чтобы включить эту функцию, используйте:
yum install bind-chroot -y
service named restart