Установка кэширующего dns сервера

Обновлено: 06.07.2024

Назначение DNS это перевод доменных имен, легко запоминаемых человеком в IP адреса которые понимают компьютеры, этот процесс называется-Разрешение имен.
Что нам даст установка собственного кеширующего DNS сервера?!
Это немного ускорит отклик сайтов + Linux не очень хорошо воспринимает имена NetBios, а ведь иногда приходится находить компьютеры или принтеры внутри локальной сети, а хочется это делать по именам.
Запоминать IP адреса- не удобно, а постоянно лазить к журнал работы DHCP сервера- тоже не наш метод. Вот для таких случаев и нужен DNS в локальной сети.
Сама установка пакета bind9 не отличается сложностью, затыки, обычно возникают на стадии его конфигурирования, т.к. после легко читаемых конфигурационных файлов системы, на человека сваливается непонятный синтаксис, кстати, очень похожий на язык программирования С. Т.к. сервер будет работать внутри локальной сети, то не имеет смысла переносить его в chroot окружение и вся настройка занимает совсем немного времени.
На этом, лирическую часть, можно завершить, переходим к установке и настройке.
Установим DNS сервер Bind9:

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

Находим секцию, она находится в самом начале конфигурационного файла, кроме нее там больше ничего нет…

Секция forwarders, отвечает за то, куда будет передаваться DNS запрос на разрешение имени, в случае если его нет в собственной базе. Последнее время меня совсем не радует, работа этих серверов у провайдера по этому можно подключить сторонние например гугловские, запомнить IP очень легко 8.8.8.8, на его примере я и буду вести настройку, но никто не мешает использовать, те что вам нравятся больше.

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

и добавим в него следующее:

Сохраняем и выходим
Теперь нам необходимо создать файл настройки зоны

и вставляем в него следующее:
(Прошу отнестись внимательно к синтаксису конфигурационного файла, даже точки имеют значение)

Теперь, при добавлении нового сетевого устройства, вам необходимо сделать 2 вещи:
1) Зарезервировать IP адрес на DHCP сервере, о том, как это сделать, можно прочитать в статье- Настройка DHCP сервера
2) Создать DNS зону для этого IP, вида devicename IN A XXX.XXX.XXX.XXX. Где: devicename-сетевое имя устройства; XXX.XXX.XXX.XXX-его IP адрес который зарезервирован на DHCP сервере.

теперь нам необходимо отредактировать файл resolv.conf

Сделано это для того чтобы сервер искал все в собственной базе, а уже потом BIND будет перенаправлять запросы к серверу 8.8.8.8 IP которого вписан в директиве forwarders.

Теперь можно проверять работоспособность:

Если тестирование происходит из под Windows:

Если тестируем из под Linux:

Должны пойти пинги на тот IP который вы указали вместо XXX.XXX.XXX.XXX

На этом настройку DNS сервера можно завершить.
Если возникла необходимость, интегрировать работу DNS с DHCP сервером, то можно воспользоваться статьей: Настройка DNS+DHCP сервера для локальной сети+динамическое обновление DNS зон

49 комментариев

Статья хорошая(лучше пока не видел), настроил, но мутновато! Автору спасибо! А что, конкретно, мутновато? И какие сложности возникли?

Теперь, при добавлении нового сетевого устройства, вам необходимо сделать 2 вещи: и поехали… и что то не совсем точно перекликается эта статья и настройка dhcp сервера. Статья написана не для гиков — написана доходчиво! Но хотелось бы с Биндом по подробнее) + днс сервер я повесил на 192.168.0.1 в dhcpd.conf и в /etc/network/interfaces gateway у меня 192.168.0.1/ gateway+dhcp+dns — роли сервера.
потом: /etc/bind/db.zonder
@ IN SOA zonder. root.zonder. (
20101015
4h;
1h;
1w;
1d );

Далее схема прежняя -гугловский сервер ищет в своей базе имя и если оно там есть, присылает нашему серверу IP, эти данные, в свою очередь, наш сервер добавляет в кеш и после этого начинает отдавать всем клиентам при повторном запросе. Что экономит время.

Точка с запятой- комментарий. Начало выражения – (, а его завершение — )

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

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

150ms ответ от сервера через атлантический океан не получить в обозримой перспективе (хотя конечно есть изыски, вроде оптоволокна с воздушной сердцевиной или радиорелейной связи, но это для простых смертных едва-ли доступно).

Когда мы пытаемся например из России открыть web-сайт, расположенный в США (его NS сервера вероятно там же), и домен не нашелся в DNS-кэше вашего провайдера — то ждать придется долго даже на гигабитном интернете, возможно даже целую секунду: пока мы через океан получим имена NS серверов домена, пока разрезолвим их IP, пока отправим и получим собственно сам DNS запрос…

Пару лет назад Google завела свои публичные DNS сервера, а для агитации перехода на них — они разработали утилитку NameBench, которая прогоняет тесты DNS по вашей истории серфинга и показывает, насколько Google DNS быстрее DNS сервера вашего провайдера.

Но мне удалось сделать свой DNS сервер, который работает быстрее Google Public DNS, и в этой краткой заметке хочу поделится результатами.

pdnsd — кэширующий DNS proxy. Помимо банального кэширования DNS запросов (с возможностью жестко задавать минимальный TTL — может быть нужно на очень плохом интернете), он умеет отсылать запрос одновременно на несколько «родительских» DNS серверов, и отдавать клиенту первый вернувшийся ответ.

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

Ставится в Ubuntu — банальным apt-get.

Пара моментов в конфиге

В принципе, кэширование можно сделать менее агрессивным (min_ttl=1m например), но за год работы проблем особых не возникло. В случае проблем — при желании можно вытереть одну запись из кэша:
или сразу все:

Результаты тестирования в NameBench

Видим, что для 50% запросов ответ мы получаем менее чем за 10мс, для 85% быстрее Google Public DNS, ну а дальше результаты естественно совпадают с гуглом.

Запоминать IP адреса- не удобно, а постоянно лазить к журнал работы DHCP сервера- тоже не наш метод. Вот для таких случаев и нужен DNS в локальной сети. Сама установка пакета bind9 не отличается сложностью, затыки, обычно возникают на стадии его конфигурирования, т.к. после легко читаемых конфигурационных файлов системы, на человека сваливается непонятный синтаксис, кстати, очень похожий на язык программирования С. Т.к. сервер будет работать внутри локальной сети, то не имеет смысла переносить его в chroot окружение и вся настройка занимает совсем немного времени. На этом, лирическую часть, можно завершить, переходим к установке и настройке.

Установим DNS сервер Bind9:

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

Находим секцию, она находится в самом начале конфигурационного файла, кроме нее там больше ничего нет…

и добавим в него следующее:

Сохраняем и выходим
Теперь нам необходимо создать файл настройки зоны

теперь нам необходимо отредактировать файл resolv.conf

Сделано это для того чтобы сервер искал все в собственной базе, а уже потом BIND будет перенаправлять запросы к серверу 8.8.8.8 IP которого вписан в директиве forwarders.
Теперь можно проверять работоспособность:
Если тестирование происходит из под Windows:

Если тестируем из под Linux:

Должны пойти пинги на тот IP который вы указали вместо XXX.XXX.XXX.XXX

Можно так же проверять скорость обработки запросов коммандой dig

Общие сведения

Named - это демон, входящий в состав пакета bind9 и являющийся сервером доменных имен. Демон named может реализовывать функции серверов любого типа: master, slave, cache. На приведенной схеме я постарался максимально прозрачно отобразить основной принцип работы DNS сервера BIND. Бинарник, который выполняет основную работу, расположен в /usr/sbin/named. Он берет настройки из основного конфигурационного файла, который называется named.conf и расположен в каталоге /etc/bind. В основном конфиге описывается рабочий каталог асервера, зачастую это каталог /var/cache/bind, в котором лежат файлы описания зон и другие служебные файлы. Соответствие названия зоны и файла описания зоны задает раздел zone с параметром file. Раздел zone так же задает тип ответственности данного сервера за зону (master, slave и др.), а так же определяет особые параметры для текущей зоны (например, на каком интерфейсе обрабатывать запросы для текущей зоны). В файлах описания зон содержатся параметры зон и записи ресурсов (пути, указанные в данном абзаце могут отличаться, это зависит от дистрибутива Linux или параметров сборки сервера из исходников).

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

Формат файла конфигурации для 4-ой версии программы отличается от того, который применяется в восьмой и девятой версиях BIND. Учитывая, что я рассчитываю на установку нового DNS сервера, а старую версию смысла ставить не вижу, посему буду рассматривать конфиг новой версии.

Исходные данные

Для корректной работы DNS нем необходимо иметь настроенную сеть. DNS в текущей статье будет настроен на дистрибутиве Debian, особенности других дистрибутивов тоже будут отмечены. Конфиг сети стенда следующий:

Установка BIND9

Для работы DNS сервера необходимо установить пакет bind9 (в некоторых дистрибутивах - bind). Как отмечено на схеме - основным конфигурационным файлом BIND является файл named.conf (данный файл может быть размещен в каталоге /etc, иногда в /etc/bind ).

Параметры (синтаксис) named.conf

Синтаксис файла named.conf придерживается следующих правил:

IP-адреса - список IP должен быть разделен символом ";" , возможно указывать подсеть в формате 192.168.1.1/24 или 192.168.1.1/255.255.255.0, (для исключения IP перед ним нужно поставить знак !), возможно указывать имена "any", "none", "localhost" в двойных кавычках.

В файлах описания зон - символ @ является "переменной" хранящей имя зоны, указанной в конфигурационном файле named.conf или в директиве @ $ORIGIN текущего описания зоны.

Каждая завершенная строка параметров должна завершаться символом ; .

Раздел Acl

Acl (access control list) - позволяет задать именованный список сетей. Формат раздела: acl "имя_сети" ;

Раздел Options

Раздел Options задает глобальные параметры конфигурационного файла, управляющие всеми зонами. Данный раздел имеет формат: options ;. Options может быть "вложен" в раздел Zone, при этом он переопределяет глобальные параметры. Часто используемые операторы options:

allow-query список_ip> - Разрешает ответы на запросы только из список_ip. При отсутствии - сервер отвечает на все запросы.
allow-recursion список_ip> - На запросы из список_ip будут выполняться рекурсивные запросы. Для остальных - итеративные. Если не задан параметр, то сервер выполняет рекурсивные запросы для всех сетей.
allow-transfer список_ip> - Указывает список серверов, которым разрешено брать зону с сервера (в основном тут указывают slave сервера)
directory /path/to/work/dir - указывает абсолютный путь к рабочему каталогу сервера. Этот оператор допустим только в разделе options.
forwarders ip порт, ip порт...> - указывает адреса хостов и если нужно порты, куда переадресовывать запросы (обычно тут указываются DNS провайдеров ISP).
forward ONLY или forward FIRST - параметр first указывает, DNS-серверу пытаться разрешать имена с помощью DNS-серверов, указанных в параметре forwarders, и лишь в случае, если разрешить имя с помощью данных серверов не удалось, то будет осуществлять попытки разрешения имени самостоятельно.
notify YES|NO - YES - уведомлять slave сервера об изменениях в зоне, NO - не уведомлять.
recursion YES|NO - YES - выполнять рекурсивные запросы, если просит клиент, NO - не выполнять (только итеративные запросы). Если ответ найден в кэше, то возвращается из кэша. (может использоваться только в разделе Options)

Раздел Zone

Определяет описание зон(ы). Формат раздела: zone операторы_раздела_zone>; Операторы, которые наиболее часто используются:

allow-update список_ip> - указывает системы, которым разрешено динамически обновлять данную зону.
file "имя_файла" - указывает путь файла параметров зоны (должен быть расположен в каталоге, определенном в разделе options оператором directory)
masters список_ip> -указывает список мастер-серверов. (допустим только в подчиненных зонах)
type "тип_зоны" - указывает тип зоны, описываемой в текущем разделе,тип_зоны может принимать следующие значения:
- forward - указывает зону переадресации, которая переадресовывает запросы, пришедшие в эту зону.
- hint - указывает вспомогательную зону (данный тип содержит информацию о корневых серверах, к которым сервер будет обращаться в случае невозможности найти ответ в кэше)
- master - указывает работать в качестве мастер сервера для текущей зоны.
- slave - указывает работать в качестве подчиненного сервера для текущей зоны.
Дополнительные параметры конфигурации

Значения времени в файлах зон по умолчанию указывается в секундах, если за ними не стоит одна из следующих букв: S - секунды, M - минуты, H- часы, D - дни, W - недели. Соответственно, запись 2h20m5s будет иметь значение 2 часа 20 минут 5 секунд и соответствовать 8405 секунд.

В конфигурационных файлах BIND могут применяться следующие директивы:
- $TTL - определяет TTL по-умолчанию для всех записей в текущей зоне.
- $ORIGIN - изменяет имя зоны с указанного в файле named.conf. При этом, область действия данной директивы не распространяется "выше" (то есть если файл включен директивой $INCLUDE, то область действия$ORIGN не распространяется на родительский)
- $INCLUDE - включает указанный файл как часть файла зоны.
Для того чтобы локальный резолвер сервера тоже использовал локальный DNS, необходимо привести файл resolv.conf к следующему виду:

Если в имени ресурсной записи встречается символ "*", то это он означает что вместо него можно подразумевать любую разрешенную последовательность символов. Такую запись называют "wildcard запись". Однако, символ "*" не может быть использован где угодно. Это может быть только первый символ в поле Name текущего домена, отделенный от остальных символом "."

Настройка кэширующего DNS сервера

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

Для того, чтобы BIND работал в качестве кэширующего сервера, необходимо иметь конфигурационные файлы заполненные необходимой информацией:
- named.conf;
- описание серверов корневой зоны (зона типа hint);
- описание зоны 127.in-addr.arpa.
В данном примере приведен кэширующий DNS сервер, обрабатывающий запросы из списка сетей lan, в которую входит только одна локальная сеть 192.168.1.1/24 и петлевой интерфейс. При необходимости можно включить туда и другие сети. После определения списка сетей в директиве acl, в любом месте конфига можно будет ссылаться на этот список по имени (в нашем примере имя - lan), что, собственно и сделано в разделе options. Большинство параметров я прокомментировал, но отдельного внимания требует раздел, описывающий зону корневых серверов. В параметре file задан относительный путь к файлу описания корневых серверов (путь, относительно рабочего каталога сервера). За обновлениями данного файла необходимо следить, хотя он обновляется довольно редко (откуда брать обновленный файл я писал в теории DNS). Как вы заметили, имеется так же две записи для зоны localhost и две записи обратных зон для бродкаст доменов. Назначение этих зон состоит в том, чтобы избежать трансляции случайных запросов имен соответствующих IP-адресов на серверы, обслуживающие корневую зону.

Чтобы не вносить неразбериху в куче конфигурационных файлов, в статье я привожу примеры на основе единого конфигурационного файла. На самом деле, в последних версиях Debian (и других дистрибутивах Linux), файл named.conf выглядит следующим образом:

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

Далее, хочу обратить внимание на наличие файлов зон в каталоге, указанном в разделе options в параметре directory с именами, соответствующими параметрам file в разделах, описывающих зоны:

Рассматривать файлы "петлевых" и бродкастовых зон не вижу смысла, т.к. после установки пакета bind настройки заданные по умолчанию в данных файлах вполне приемлемы. Далее, при организации мастер сервера мы рассмотрим пример описания файла зоны. Хочу обратить внимание, что мы настраиваем кэширующий сервер, а определяем мы его и как master для некоторых из зон. В нашем случае "кэширующий" говорит о том, что наш сервер не поддерживает ни одну из реально существующих зон, т.е. ему не делегировано прав на такое обслуживание.

Да, чуть не забыл, демон named должен быть разрешен для запуска на необходимых уровнях выполнения ОС (команда в RedHat - /sbin/chkconfig bind9 on, в Debian - /usr/sbin/update-rc.d bind9 defaults). После изменения конфигурационных файлов можно добавить сервис в автозагрузку и запустить демон:

Давайте рассмотрим другие варианты сервера.

Главный (master) сервер зоны

Основной конфиг содержит следующие настройки:

Отдельно хочется описать параметр allow-transfer < 10.0.0.191; >;. Данный параметр описывает серверы, которым разрешено скачивать копию зоны - т.н. slave серверА. В следующем примере мы разберем настройку slave DNS.

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

а так же в домене in-addr.arpa.

Вторичный (secondary, slave) авторитетный сервер зоны

Основная функция slave сервера - автоматическая синхронизация описания зоны с master сервером. Данная задача регламентируется документом RFC 1034 в разделе 4.3.5. Согласно данному документу обмен данными между серверами рекомендовано производить по протоколу TCP, посредством запроса AXFR. По этому запросу за одно TCP соединение должна передаваться вся зона целиком (RFC 1035).

Так же, slave DNS-сервер делит нагрузку с master сервером или принимает на себя всю нагрузку в случае аварии па первом сервере.

Прежде чем приступить к настройке slave DNS сервера, необходимо проверить возможность получения зоны вручную со вторичного сервера с помощью следующей команды:

Получение зоны прошло успешно. Далее, для настройки подчиненного сервера, алгоритм следующий:
1. Скопироватьконфигурационный файл named.conf с master сервера;
2. Заменитьпараметр type master на type slave в тех зонах, для которых он будет вторичным;
3. Параметр allow-transfer < 10.0.0.191; >;заменить на masters < 10.0.0.152;>; в тех зонах, для которых он будет вторичным;
4. Удалить зоны, которые не будет обслуживать текущий сервер, в том числе и корневую, если slave не будет отвечать на рекурсивные запросы;
5. Создать каталоги для логов, как в предыдущем примере.
Итого, мы получаем конфиг slave сервера:

после перезапуска наш slave сервер благополучно скопирует необходимую ему информацию с главного сервера, о чем будет говорить наличие файлов в каталоге:

Настройка netfilter (iptables) для DNS BIND

Собственно, настроив работу сервера, неплохо было бы его защитить. Мы знаем, что сервер работает на 53/udp порту. Почитав статью о том, что такое netfilter и правила iptables и ознакомившись с практическими примерами iptables, можно создать правила фильтрации сетевого трафика:

Это типовой пример! Для задания правил iptables под Ваши задачи и конфигурацию сети, необходимо понимать принцип работы netfilter в Linux, почитав вышеуказанные статьи.

Устранение неполадок

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

Отличным инструментом для диагностики являются команды диагностики DNS.

Резюме

В текущей статье я описал настройку основных конфигураций DNS сервера BIND. Целью статьи было - дать представление о работе сервера BIND в UNIX. Я практически не затронул вопросы безопасности ДНС и мало затронул такие специфичные настройки, как работа сервера в пограничном режиме, когда в разные сети отдается разная информация о зоне(нах). Для более глубокого освоения я предоставлю список дополнительных источников, в которых, я надеюсь, удастся получить нужную информацию. На этом ставлю точку. До новых встреч.

Читайте также:

Установка кэширующего dns сервера

49 комментариев

Пара моментов в конфиге

Результаты тестирования в NameBench

Общие сведения

Исходные данные

Установка BIND9

Параметры (синтаксис) named.conf

Раздел Acl

Раздел Options

Раздел Zone

Дополнительные параметры конфигурации

Настройка кэширующего DNS сервера

Главный (master) сервер зоны

Вторичный (secondary, slave) авторитетный сервер зоны

Настройка netfilter (iptables) для DNS BIND

Устранение неполадок