Centos не работает dns

Проблема с настройкой DNS сервера на CentOS 7

Всем доброго времени суток! На CentOS 7 на локальном сервере «SRV2» после настройки BIND происходит ошибка по разрешению зоны:

При том обратная зона работает:

Правила Firewalld прописал. Сеть настраивал через NetworkManager

Конфигурационный файл named.conf:

zone «forward.bind» <
type master;
@ IN SOA Rosa-software.ru. root.Rosa-software.ru.
@ IN NS Rosa-software.ru.

Ничего не смущает?

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

Может все-таки научиться писать конфиг для начала? А логи потом?
named-checkconf и named-checkzone придумали для того что бы, не логи читать, а за ранее проверить, до перезапуска бинда синтаксис и поправить. А то в варианте «читай логи» это уже постфактум «когда отвалилось и может быть всё целиком».

named-checkconf это частности, касающиеся только bind, а просмотреть логи полезно в случае любой проблемы.

когда отвалилось и может быть всё целиком.

Ну после нескольких таких отвалов может и сам нагуглится checkconfig.

а просмотреть логи полезно в случае любой проблемы.

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

Исправление

Привел файлы к такому виду.

Вывод named-checkconf -z:

Также заметил, что когда в конфигурационном файле отключаю параметр «recursion», то ошибка «;; connection timed out; no servers could be reached» сменяется на «REFUSED»

В логах только то, что если изменить выше описанный параметр, то выводится «query denied», хотя я явным образом прописал это. Если же параметр «recursion» не изменять, то будут бесконечные запросы IPV6 в сторону НЕИЗВЕСТНЫХ МНЕ серверов.

Также заметил, что когда в конфигурационном файле отключаю параметр «recursion», то ошибка «;; connection timed out; no servers could be reached» сменяется на «REFUSED»

Добавь в options в /etc/named.conf allow query < localhost; localnets; >; .

Исправление 2

Привел named.conf к такому виду:

Если «recursion no» — получаю SERFFAIL

Если «recursion yes» — получаю «;; connection timed out; no servers could be reached»

В логах ничего не изменилось. При параметре «recursion yes» он все ссылается на другие DNS сервера. При выключенном просто «query cache denied»

В Дебиане все работает ДАЖЕ С кривым конфигом 🙁

Я смотрел в логи, также отключил рекурсию «recursion no»

В итоге стал получать ошибку «REFUSED»

А в логах «client . 172.16.11.10 query cache denied»

Есть идеи касательно этого?

Вы в курсе, что означает символ ″@″ в файле зоны и откуда берётся ORIGIN, если не задан явно? https://www.zytrax.com/books/dns/ch8/origin.html

Вы в выхлопе увидели что-то про Rosa-software.ru ? И я не увидел.

В Дебиане все работает ДАЖЕ С кривым конфигом 🙁

По Станиславскому «не верю», этого не может быть потому что этого не может быть.

В своем сообщении Проблема с настройкой DNS сервера на CentOS 7 (комментарий) я намекнул совсем на другое. Впрочем выше mky вам уже ответил.

Решение

Все заработало Хотите верьте, хотите нет

Но файл зоны в конфиге нужно было назвать zone «rosa-software.ru»

Все заработало Хотите верьте, хотите нет
Но файл зоны в конфиге нужно было назвать zone «rosa-software.ru»

Сколько у вас «открытий чудных». Даже не вериться. Сами не верим.

Но файл зоны в конфиге нужно было назвать zone «rosa-software.ru»

И не файл а правильно прописать название домена после zone, имя файла зоны может быть хоть ‘bla-bla-bla’

PS Прежде чем «прыгать», хотя бы документацию почитали по настройке bind, за много лет в части базовой настройки нифига не поменялось. Стыдно товарищ.

Ничего страшного, всё случается 🙂

Я имел ввиду то, что невнимательно написал основной конфиг «на пофиг», и думал, заработает.

Источник

Почему не работает dns сервер на centos?

//
// 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 /usr/share/doc/bind*/sample/ for example named configuration files.
//
// See the BIND Administrator’s Reference Manual (ARM) for details about the
// configuration located in /usr/share/doc/bind-/Bv9ARM.html

options <
listen-on port 53 < any; >;
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»;
recursing-file «/var/named/data/named.recursing»;
secroots-file «/var/named/data/named.secroots»;
allow-query < any; >;

/*
— If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
— If you are building a RECURSIVE (caching) DNS server, you need to enable
recursion.
— If your recursive DNS server has a public IP address, you MUST enable access
control to limit queries to your legitimate users. Failing to do so will
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes;

dnssec-enable yes;
dnssec-validation yes;

/* Path to ISC DLV key */
bindkeys-file «/etc/named.root.key»;

pid-file «/run/named/named.pid»;
session-keyfile «/run/named/session.key»;
>;

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

zone «.» IN <
type hint;
file «named.ca»;
>;
zone «test.loc» IN <
type master;
file «/etc/named/test.loc.zone»;
allow-update < none; >;
>;
include «/etc/named.rfc1912.zones»;
include «/etc/named.root.key»;

$TTL 86400
@ IN SOA ns1.test.loc. ns2.test.loc. (
2017011301 ;Serial
3600 ;Refresh
1800 ;Retry
604800 ;Expire
86400 ;Minimum TTL
)
IN NS ns1.test.loc.
IN NS ns2.test.loc.
IN MX 10 mail.test.loc.

@ IN A 192.168.56.229
ns1 IN A 192.168.56.229
ns2 IN A 192.168.56.229
mail IN A 192.168.56.229
www IN A 192.168.56.229

named-checkzone test.loc /etc/named/test.loc.zone

dig @192.168.56.229 -t A +short www.test.loc

;; connection timed out; no servers could be reached

Источник

Установка Bind 9 (named) в CentOS 7

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

Что такое DNS сервер BIND

Bind — самая распространенная на текущий день реализация ДНС сервера, которая обеспечивает преобразование IP адресов в dns-имена и наоборот. Его также называют named, например в Freebsd. Судя по информации из Википедии, сейчас 10 из 13 корневых ДНС серверов интернета работают на bind. Он установлен из коробки практически во всех linux дистрибутивах. Я рассмотрю его установку на сервер CentOS 7.

Устанавливаем Bind 9 (named) в CentOS 7

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

У меня не установлен, так как во время инсталляции centos выбрал минимальный пакет программ. Сервер имен у нас будет работать в chroot окружении, так что устанавливаем соответствующие пакеты:

Еще раз обращаю внимание, что мы будем использовать bind в chroot среде для увеличения безопасности. Это накладывает определенные особенности в настройке и управлении сервером. Нужно быть внимательным в этих мелочах. Итак, запускаем bind :

Проверяем содержимое chroot каталога:

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

Настраиваем DNS сервер в CentOS 7

Файл конфигурации нашего сервера располагается по адресу /var/named/chroot/etc/named.conf . Открываем его и приводим к следующему виду:

Эта конфигурация обеспечит работу обычного кэширующего сервера в локальной сети. Комментарии к некоторым параметрам:

listen-on-v6 port 53 < none; >;	Отключили работу на интерфейсе ipv6.
allow-query < 127.0.0.1; 192.168.7.0/24; >;	Разрешаем обычные запросы только из локальной сети.
allow-recursion < 127.0.0.1; 192.168.7.0/24; >;	Разрешаем рекурсивные запросы только из локальной сети.
forwarders < 8.8.8.8; >;	Перенаправляем запросы, которые сами не резолвим, на днс сервер гугла. У меня указан он просто для примера. Тут лучше всего указать сначала ДНС серверы провайдера.
version «DNS Server»;	Скрываем версию бинда, вместо этого выводим указанную строку.

Теперь создадим папку для логов. Не забываем, что мы работаем в chroot окружении:

Поддержка собственной зоны

Допустим, нам необходимо в нашем named разместить собственную зону site1.ru. Первым делом создаем файл зоны, которую будет обслуживать dns сервер:

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

Выставляем необходимые права:

Дальше подключаем файл зоны в конфигурационном файле bind — /var/named/chroot/etc/named.conf :

Перечитываем конфигурацию named с помощью rndc:

Добавление в bind slave zone

Если вы хотите на своем сервере держать копию какой-то зоны, взятой с другого dns сервера, то добавьте следующие настройки в конфиг.

10.1.3.4 — ip адрес dns сервера, с которого мы берем зону. Не забудьте на нем разрешить передачу зоны на ваш dns сервер.

Чтобы сервер смог корректно сохранить файл со slave зоной, необходимо добавить разрешение на запись bind для директории /var/named/chroot/var/named. По-умолчанию она имеет следующие права:

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

После этого можно перезапустить bind и проверить, что создался файл слейв зоны. С указанными выше настройками, он будет располагаться по адресу /var/named/chroot/var/named/site.ru.zone. Если у bind не будет прав для создания файла, в логе вы получите ошибку:

Настройка логов в bind (named)

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

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

Первым делом в конфигурации мы задаем канал, куда будут складываться логи по тем или иным событиям. Вот пример подобного канала:

Здесь указано название канала, которые мы придумываем сами — general, указан путь до файла, сказано, что хранить будем 3 версии лога размером не более 5 мегабайт. Параметр severity может принимать следующие значения:

Описание параметров severity

critical	Только критические ошибки.
error	Обычные ошибки и все что выше.
warning	Предупреждения и все, что выше.
notice	Уведомления и все, что выше.
info	Информационные сообщения и все что выше.
debug	Сообщения уровня debug и все, что выше. Уровни debug регулируются значениями 0, 1, 2, 3.
dynamic	То же, что и debug, только его уровень регулируется глобальной настройкой сервера.

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

• print-severity yes | no — указывает, писать или нет параметр severity в лог
• print-category yes | no — указывает писать или нет название категории логов

Я эти параметры не указал, так как по-умолчанию устанавливается значение no, которое лично меня устраивает.

Дальше необходимо указать категорию логов и в какой канал мы будем ее записывать:

Категорий у днс сервера bind достаточно много. Вот мой перевод полного списка с описаниями:

Описание категорий логов в bind (named)

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 добавить следующую конструкцию:

Если мы хотим собирать все логи запросов из категории queries, то в раздел options файла конфигурации необходимо добавить параметр, который это разрешает:

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

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

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

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

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

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

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

Источник