Реклама на портале

Dns кэширование. Настройка кеширующего DNS сервера (BIND) для локальной сети

Назначение DNS это перевод доменных имен, легко запоминаемых человеком в IP адреса которые понимают компьютеры, этот процесс называется-Разрешение имен. Что нам даст установка собственного кеширующего DNS сервера? Это немного ускорит отклик сайтов + Linux не очень хорошо воспринимает имена NetBios, а ведь иногда приходится находить компьютеры или принтеры внутри локальной сети, а хочется это делать по именам.

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

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

# apt - get install bind9

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

# vim / etc / bind / named . conf . options

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

options { directory "/var/cache/bind" ; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http://www.kb.cert.org/vuls/id/800113 // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0"s placeholder. // forwarders { // 0.0.0.0; // }; auth - nxdomain no ; # conform to RFC1035 listen - on - v6 { any ; }; };

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

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

forwarders { 8.8.8.8 ; 193.58.251.251 ; //Российская служба DNS -SkyDNS };

В эту секцию лучше вписать IP того сервера который у вас указан в файле /etc/resolv.conf или вписать туда в секциюnameserver этот IP. Сохраняем изменения и выходим. Перезапускаем сервер и проверяем. Набираем в командной строке nslookup mail.ru
Должно выдать:

Non - authoritative answer : Name : mail . ru Addresses : 94.100.191.202

Это говорит о том, что наш сервер не является, главным в обслуживании этой зоны (mail.ru), но запросы добавил в кеш!
Теперь нужно создать ДНС зону для нашей сети чтобы машины могли находить различные сетевые сервисы - могут быть, например, сетевые принтеры, они могут быть как самостоятельными так и расшаренными на других рабочих станциях.
Нашу зону можно назвать orgname –т.е. название организации.
Первым делом создаем зону, для этого отредактируем named.conf.local

# vim / etc / bind / named . conf . local

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

zone "orgname" { type master ; file "/etc/bind/db.orgname" ; };

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

# vim / etc / bind / db . orgname

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

@ IN SOA orgname . root . orgname . (20101015 4h ; время обновления - 4 часа 1h ; повтор каждый час 1w ; как долго хранить информацию - 1 неделю 1d ) ; TTL (время жизни ) записи - 1 день @ IN NS orgname . ; имя сервера имен @ IN A 192.168.10.1 ; A - запись - IP адрес нашего ДНС сервера который обслуживает эту зону, @ означает что это корневая зона. * IN CNAME @ printer IN A 192.168.10.25 ; Можно создать ДНС запись сетевого принтера который находится по адресу 192.168.10.25

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

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

# vim / etc / resolv . conf

и вписать туда:

nameserver 127.0.0.1

все что там было можно закоментировать поставив #
перезапускам сервер

# reboot

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

ping devicename . orgname

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

ping devicename . orgname - c 4

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

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

# dig @127.0.0.1 tut.by ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @127.0.0.1 tut.by ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63893 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;tut.by. IN A ;; ANSWER SECTION: tut.by. 103 IN A 178.172.160.5 tut.by. 103 IN A 178.172.160.4 tut.by. 103 IN A 178.172.160.2 tut.by. 103 IN A 178.172.160.3 ;; AUTHORITY SECTION: . 6029 IN NS i.root-servers.net. . 6029 IN NS b.root-servers.net. . 6029 IN NS m.root-servers.net. . 6029 IN NS k.root-servers.net. . 6029 IN NS e.root-servers.net. . 6029 IN NS d.root-servers.net. . 6029 IN NS j.root-servers.net. . 6029 IN NS g.root-servers.net. . 6029 IN NS l.root-servers.net. . 6029 IN NS f.root-servers.net. . 6029 IN NS h.root-servers.net. . 6029 IN NS a.root-servers.net. . 6029 IN NS c.root-servers.net. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Mar 22 16:46:24 MSK 2016 ;; MSG SIZE rcvd: 310

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

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

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, особенности других дистрибутивов тоже будут отмечены. Конфиг сети стенда следующий:

Dns:~# cat /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.0.0.152 netmask 255.255.255.0 gateway 10.0.0.254 auto eth1 iface eth1 inet static address 192.168.1.1 netmask 255.255.255.0

где 10.0.0.152/24 - внешний интерфейс (подсеть, выделенная провайдером), 192.168.1.1/24 - внутренний (Локальная сеть). Настраиваемая зона будет иметь имя example.com. В примере со slave сервером , вторичный сервер будет расположен на IP 10.0.0.191 .

Установка 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 "имя_сети" {ip; ip; ip; };

Раздел Options

Раздел 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 секунд.

Любое имя хоста/записи, не оканчивающиеся точкой считается неFQDN именем и будет дополнено именем текущей зоны. Например, запись domen в файле зоны examle.com будет развернуто в FQDN-имя domen.examle.com. .

В конфигурационных файлах BIND могут применяться следующие директивы :

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

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

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

Dns:~# mkdir /var/log/bind/ dns:~# chmod 744 /var/log/bind/ dns:~# ps aux | grep named bind 4298 0.0 3.4 46792 13272 ? Ssl Jul05 0:00 /usr/sbin/named -u bind root 4815 0.0 0.1 3304 772 pts/4 S+ 18:19 0:00 grep named dns:~# chown bind /var/log/bind/ dns:~# ls -ld /var/log/bind/ drwxr--r-- 2 bind root 4096 Июл 6 18:18 /var/log/bind/

Dns:~# cat /var/cache/bind/example.com $TTL 3D @ IN SOA ns.example.com. root.example.com. (2011070601 ; serial 8H ; refresh 2H ; retry 2W ; expire 1D) ; minimum @ IN NS ns.example.com. @ IN NS ns2.example.com. @ IN A 10.0.0.152 @ IN MX 5 mx.example.com. ns IN A 10.0.0.152 ns2 IN A 10.0.0.191 mx IN A 10.0.0.152 www IN CNAME @

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

Dns:~# cat /var/cache/bind/0.0.10.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS ns.examle.com. IN NS ns2.example.com. 152 IN PTR examle.com. 191 IN PTR ns.example.com. * IN PTR examle.com. dns:~# cat /var/cache/bind/1.168.192.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS ns.examle.com. IN NS ns2.example.com. * IN PTR examle.com.

Наша сеть небольшая, предполагается, что в сети совсем мало машин. Все сервисы сети размещены на одном хосте example.com., поэтому и master DNS (ns.example.com.) и почтовый сервер (mx.example.com.) указывает на одну машину (10.0.0.152).

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

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

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

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

Root@debian:~# dig @10.0.0.152 example.com. axfr ; <<>> DiG 9.7.3 <<>> @10.0.0.152 example.com. axfr ; (1 server found) ;; global options: +cmd example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 example.com. 259200 IN NS ns.example.com. example.com. 259200 IN NS ns2.example.com. example.com. 259200 IN A 10.0.0.152 example.com. 259200 IN MX 5 mx.example.com. mx.example.com. 259200 IN A 10.0.0.152 ns.example.com. 259200 IN A 10.0.0.152 ns2.example.com. 259200 IN A 10.0.0.191 www.example.com. 259200 IN CNAME example.com. example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 ;; Query time: 14 msec ;; SERVER: 10.0.0.152#53(10.0.0.152) ;; WHEN: Fri Jul 8 15:33:54 2011 ;; XFR size: 11 records (messages 1, bytes 258)

  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 сервера:

Root@debian:~# cat /etc/bind/named.conf options { directory "/var/cache/bind"; allow-query { any; }; // отвечать на запросы со всех интерфейсов recursion no; // запретить рекурсивные запросы auth-nxdomain no; // для совместимости RFC1035 listen-on-v6 { none; }; // IPv6 нам не нужен version "unknown"; // не отображать версию DNS сервера при ответах }; // нижеописанные зоны определяют сервер авторитетным для петлевых // интерфейсов, а так же для броадкаст-зон (согласно RFC 1912) zone "localhost" { type master; file "localhost"; }; zone "127.in-addr.arpa" { type master; file "127.in-addr.arpa"; }; zone "0.in-addr.arpa" { type master; file "0.in-addr.arpa"; }; zone "255.in-addr.arpa" { type master; file "255.in-addr.arpa"; }; // описание основной зоны zone "example.com" { type slave; file "example.com"; masters { 10.0.0.152; }; }; //описание обратной зоны zone "0.0.10.in-addr.arpa" { type slave; file "0.0.10.in-addr.arpa"; masters { 10.0.0.152; }; }; // настройки логирования logging { channel "misc" { file "/var/log/bind/misc.log" versions 4 size 4m; print-time YES; print-severity YES; print-category YES; }; channel "query" { file "/var/log/bind/query.log" versions 4 size 4m; print-time YES; print-severity NO; print-category NO; }; category default { "misc"; }; category queries { "query"; }; };

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

Root@debian:~# ls -la /var/cache/bind/ итого 28 drwxrwxr-x 2 root bind 4096 Июл 8 18:47 . drwxr-xr-x 10 root root 4096 Июл 8 15:17 .. -rw-r--r-- 1 bind bind 416 Июл 8 18:32 0.0.10.in-addr.arpa ...... -rw-r--r-- 1 bind bind 455 Июл 8 18:32 example.com ........

В принципе,/stroallow-transfer {pngp slave сервер может не хранить копию зоны у себя в файловой системе. Эта копия нужна только в момент старта DNS. Наличие копии зоны в файловой системе может избавить от сбоя при недоступности master сервера во время запуска slave DNS. Если не указать опцию file в разделе zone, то копия не создается.

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

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

Dns ~ # iptables-save # типовые правила iptables для DNS *filter:INPUT DROP :FORWARD DROP :OUTPUT DROP -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP # разрешить доступ локальной сети к DNS серверу: -A INPUT -s 192.168.1.1/24 -d 192.168.1.1/32 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -p icmp -j ACCEPT -A OUTPUT -p udp -m udp --sport 32768:61000 -j ACCEPT -A OUTPUT -p tcp -m tcp --sport 32768:61000 -j ACCEPT -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # разрешить доступ DNS серверу совершать исходящие запросы -A OUTPUT -p udp -m udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT COMMIT

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

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

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

Jul 5 18:12:43 dns-server named: starting BIND 9.7.3 -u bind Jul 5 18:12:43 dns-server named: built with "--prefix=/usr" "--mandir=/usr/share/man" "--infodir=/usr/share/info" "--sysconfdir=/etc/bind" "--localstatedir=/var" "--enable-threads" "--enable-largefile" "--with-libtool" "--enable-shared" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gnu-ld" "--with-dlz-postgres=no" "--with-dlz-mysql=no" "--with-dlz-bdb=yes" "--with-dlz-filesystem=yes" "--with-dlz-ldap=yes" "--with-dlz-stub=yes" "--with-geoip=/usr" "--enable-ipv6" "CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" "CPPFLAGS=" Jul 5 18:12:43 dns-server named: adjusted limit on open files from 1024 to 1048576 Jul 5 18:12:43 dns-server named: found 1 CPU, using 1 worker thread Jul 5 18:12:43 dns-server named: using up to 4096 sockets Jul 5 18:12:43 dns-server named: loading configuration from "/etc/bind/named.conf" Jul 5 18:12:43 dns-server named: reading built-in trusted keys from file "/etc/bind/bind.keys" Jul 5 18:12:43 dns-server named: using default UDP/IPv4 port range: Jul 5 18:12:43 dns-server named: using default UDP/IPv6 port range: Jul 5 18:12:43 dns-server named: listening on IPv4 interface lo, 127.0.0.1#53 Jul 5 18:12:43 dns-server named: listening on IPv4 interface eth1, 192.168.1.1#53 Jul 5 18:12:43 dns-server named: generating session key for dynamic DNS Jul 5 18:12:43 dns-server named: could not configure root hints from "/etc/bind/db.root": file not found Jul 5 18:12:43 dns-server named: loading configuration: file not found # файл не найден Jul 5 18:12:43 dns-server named: exiting (due to fatal error) Jul 5 18:15:05 dns-server named: starting BIND 9.7.3 -u bind Jul 5 18:15:05 dns-server named: built with "--prefix=/usr" "--mandir=/usr/share/man" "--infodir=/usr/share/info" "--sysconfdir=/etc/bind" "--localstatedir=/var" "--enable-threads" "--enable-largefile" "--with-libtool" "--enable-shared" "--enable-static" "--with-openssl=/usr" "--with-gssapi=/usr" "--with-gnu-ld" "--with-dlz-postgres=no" "--with-dlz-mysql=no" "--with-dlz-bdb=yes" "--with-dlz-filesystem=yes" "--with-dlz-ldap=yes" "--with-dlz-stub=yes" "--with-geoip=/usr" "--enable-ipv6" "CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2" "LDFLAGS=" "CPPFLAGS=" Jul 5 18:15:05 dns-server named: adjusted limit on open files from 1024 to 1048576 Jul 5 18:15:05 dns-server named: found 1 CPU, using 1 worker thread Jul 5 18:15:05 dns-server named: using up to 4096 sockets Jul 5 18:15:05 dns-server named: loading configuration from "/etc/bind/named.conf" Jul 5 18:15:05 dns-server named: using default UDP/IPv4 port range: Jul 5 18:15:05 dns-server named: using default UDP/IPv6 port range: Jul 5 18:15:05 dns-server named: listening on IPv4 interface lo, 127.0.0.1#53 Jul 5 18:15:05 dns-server named: listening on IPv4 interface eth1, 192.168.1.1#53 Jul 5 18:15:05 dns-server named: automatic empty zone: 254.169.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 2.0.192.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 100.51.198.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 113.0.203.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: D.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 8.E.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 9.E.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: A.E.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: B.E.F.IP6.ARPA Jul 5 18:15:05 dns-server named: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA Jul 5 18:15:05 dns-server named: zone 0.in-addr.arpa/IN: loaded serial 1 Jul 5 18:15:05 dns-server named: zone 127.in-addr.arpa/IN: loaded serial 1 Jul 5 18:15:05 dns-server named: zone 255.in-addr.arpa/IN: loaded serial 1 Jul 5 18:15:05 dns-server named: zone localhost/IN: loaded serial 2 Jul 5 18:15:05 dns-server named: running # запуск прошел удачно

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

Резюме

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

Система доменных имен : http://citforum.ru/internet/dns/khramtsov/
RFC 1034 - Domain Names - Concepts and Facilities: http://tools.ietf.org/html/rfc1034
RFC 1035 - Domain Names - Implementation and Specification: http://tools.ietf.org/html/rfc1035
RFC 1537 - Common DNS Data File Configuration Errors: http://tools.ietf.org/html/rfc1537
RFC 1591 - Domain Name System Structure and Delegation: http://tools.ietf.org/html/rfc1591
RFC 1713 - Tools for DNS Debugging: http://tools.ietf.org/html/rfc1713
RFC 2606 - Reserved Top Level DNS Names: http://tools.ietf.org/html/rfc2606
Безопасность DNS (DNSSEC): http://book.itep.ru/4/4/dnssec.htm
BIND 9 Administrator Reference Manual : http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.html
Secure BIND Template : http://www.cymru.com/Documents/secure-bind-template.html
Хорошо расписаны параметры конфига на русском : http://www.bog.pp.ru/work/bind.html
Автоматическое создание файла зоны : http://www.zonefile.org/?lang=en#zonefile

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

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

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

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

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

Разрешения имен DNS

Для небольших сетей, которые не подвержены частым изменениям, файл /etc/hosts можно использовать как рудиментарный метод определения имени домена для разрешения IP -адреса.

Этот файл, использует очень простым синтаксис, позволяет связать имя (и/или псевдоним) с IP -адресом. Это выполняется следующим образом:

Например,

192.168.0.1 gateway gateway.mydomain.com 192.168.0.2 web web.mydomain.com

Таким образом, вы можете связаться с веб-машиной либо по имени web.mydomain.com , либо по её IP -адресу.

Для больших сетей или тех, которые подвержены частым изменениям, использование файла /etc/hosts для разрешения имен доменов на IP -адреса не будет приемлемым решением. Именно здесь возникает необходимость в специальном сервисе.

Залезем за кулисы работы DNS . DNS -сервер запрашивает большую базу данных в виде дерева, которое начинается с корневой («.» ) зоны.

Следующий рисунок поможет нам понять о чём идет речь:

На изображении выше корневая зона (.) содержит com , edu и net домены первого уровня. Каждый из этих доменов управляется (или может управляться) различными организациями, чтобы избежать зависимости от одной большой — центральной. Это позволяет правильно распределять запросы по иерархии.

Давайте посмотрим, что происходит:

1. Когда клиент делает запрос на DNS -сервер для web1.sales.me.com , сервер отправляет запрос на верхний (корневой) DNS -сервер, который направляет запрос на сервер имен в зону .com .

Это, в свою очередь, отправляет запрос на сервер имен следующего уровня (в зону me.com ), а затем на sales.me.com . Этот процесс повторяется столько раз, сколько необходимо, пока полное доменное имя (полное доменное имя, web1.sales.me.com в этом примере) не будет возвращено сервером имен зоны, в которой он находится.

2. В этом примере сервер имен в sales.me.com отвечает за адрес web1.sales.me.com и возвращает желаемую ассоциацию для имени домена-IP и другую информацию (если он настроен для этого).

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

Установка и настройка DNS-сервера

В Linux наиболее используемым DNS -сервером является bind (сокращение от Berkeley Internet Name Daemon), которое может быть установлено следующим образом:

# yum install bind bind-utils # zypper install bind bind-utils # aptitude install bind9 bind9utils

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

# cp /etc/named.conf /etc/named.conf.orig # cp /etc/bind/named.conf /etc/bind/named.conf.orig

Затем давайте откроем named.conf и перейдем к блоку параметров, где нам нужно указать следующие настройки для рекурсивного кеширующего сервера с IP 192.168.0.18/24 , к которому могут обращаться только хосты в той же сети (в качестве меры безопасности).

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

Options { ... listen-on port 53 { 127.0.0.1; 192.168.0.18}; allow-query { localhost; 192.168.0.0/24; }; recursion yes; forwarders { 8.8.8.8; 8.8.4.4; }; … }

Вне блока опций мы определим нашу зону sales.me.com (в Ubuntu это обычно делается в отдельном файле с именем named.conf.local ), который отображает домен с заданным IP -адресом и обратной зоной для сопоставления IP -адреса к соответствующей области.

Однако фактическая конфигурация каждой зоны будет проходить в отдельных файлах, как указано в директиве файла («master» означает, что мы будем использовать только один DNS-сервер).

Добавьте следующие строки в файл named.conf :

Zone "sales.me.com." IN { type master; file "/var/named/sales.me.com.zone"; }; zone "0.168.192.in-addr.arpa" IN { type master; file "/var/named/0.162.198.in-addr.arpa.zone"; };

Обратите внимание, что inaddr.arpa (для адресов IPv4) и ip6.arpa (для IPv6) являются соглашениями для конфигураций обратной зоны.

После сохранения вышеуказанных изменений в named.conf мы можем проверить наличие ошибок следующим образом:

# named-checkconf /etc/named.conf

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

Настройка DNS-зон

В файлах /var/named/sales.me.com.zone и /var/named/0.168.192.in-addr.arpa.zone мы настроим прямую (домен → IP-адрес) и обратную (IP-адрес → домен) зоны.

Сначала рассмотрим прямую конфигурацию:

1. В верхней части файла вы найдете строку, начинающуюся с TTL (сокращение от Time To Live), в которой указано, как долго кешированный ответ должен «жить» перед его заменой результатами нового запроса.

В строке, расположенной ниже, мы свяжемся с нашим доменом и укажем адрес электронной почты, с которой должны быть отправлены уведомления (обратите внимание, что root.sales.me.com означает ).

2. Запись SOA (Start of Authority) указывает, что эта система является авторитетным сервером имен для машин внутри домена sales.me.com .

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

Serial используется для выделения одной версии файла определения зоны из предыдущей (где могли быть изменены параметры). Если кешированный ответ указывает на вывод с другим Serial , запрос выполняется снова, вместо того, чтобы вернутся к клиенту.

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

Кроме того, Retry сообщает серверу, как часто вторичный объект должен пытаться связаться с основным, если ответ от первичного не получен, тогда как Expire указывает, когда определение зоны во вторичном режиме больше не действует после того, как становится невозможно получить ответ от главного сервера, и отрицательный TTL — это время, в течение которого не кэшируется несуществующий домен (NXdomain ).

3. NS -запись указывает, что является авторитетным DNS -сервером для нашего домена (на который указывает знак @ в начале строки).

4. Запись A (для адресов IPv4) или AAAA (для адресов IPv6) преобразует имена в IP -адреса.

В приведенном ниже примере:

Dns: 192.168.0.18 (the DNS server itself) web1: 192.168.0.29 (a web server inside the sales.me.com zone) mail1: 192.168.0.28 (a mail server inside the sales.me.com zone) mail2: 192.168.0.30 (another mail server)

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

6. Запись CNAME устанавливает псевдоним (www.web1) для хоста (web1).

ВАЖНО : важно наличие точки (.) в конце имен.

$TTL 604800 @ IN SOA sales.me.com. root.sales.me.com. (2016051101 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 604800) ; Negative TTL ; @ IN NS dns.sales.me.com. dns IN A 192.168.0.18 web1 IN A 192.168.0.29 mail1 IN A 192.168.0.28 mail2 IN A 192.168.0.30 @ IN MX 10 mail1.sales.me.com. @ IN MX 20 mail2.sales.me.com. www.web1 IN CNAME web1

Давайте посмотрим на конфигурацию обратной зоны (/var/named/0.168.192.in-addr.arpa.zone). Запись SOA такая же, как и в предыдущем файле, тогда как последние три строки с записью PTR (указатель) указывают последний октет в адресе хостов IPv4 mail1 , web1 и mail2 (192.168.0.28, 192.168.0.29, и 192.168.0.30, соответственно).

$TTL 604800 @ IN SOA sales.me.com. root.sales.me.com. (2016051101 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 604800) ; Minimum TTL @ IN NS dns.sales.me.com. 28 IN PTR mail1.sales.me.com. 29 IN PTR web1.sales.me.com. 30 IN PTR mail2.sales.me.com.

Вы можете проверить файлы зон на наличие ошибок:

# named-checkzone sales.me.com /var/named/sales.me.com.zone # named-checkzone 0.168.192.in-addr.arpa /var/named/0.168.192.in-addr.arpa.zone

На следующем скриншоте показано, каков ожидаемый результат вывода:

В противном случае вы получите сообщение об ошибке и советом по её устранению:

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

В CentOS и openSUSE выполните:

# systemctl restart named

И не забудьте также включить его:

# systemctl enable named

В Ubuntu :

$ sudo service bind9 restart

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

In /etc/sysconfig/network-scripts/ifcfg-enp0s3 for CentOS and openSUSE ---- DNS1=192.168.0.18 ---- In /etc/network/interfaces for Ubuntu ---- dns-nameservers 192.168.0.18

Теперь перезапустите службу сети, чтобы применить изменения.

Тестирование DNS-сервера

На этом этапе мы готовы запросить наш DNS -сервер для локальных и внешних имен и адресов. Следующие команды вернут IP -адрес, связанный с хостом web1 :

# host web1.sales.me.com # host web1 # host www.web1

Как мы можем узнать, кто обрабатывает электронные письма для sales.me.com ? Узнать это легко — просто запросите записи MX для домена:

# host -t mx sales.me.com

Аналогично, давайте проведем обратный запрос. Это поможет нам узнать имя IP -адреса:

# host 192.168.0.28 # host 192.168.0.29

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

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

# rndc querylog

И проверьте файл /var/log/messages (в CentOS и openSUSE):

# host -t mx linux.com # host 8.8.8.8

Чтобы отключить ведение журнала DNS , введите еще раз:

# rndc querylog

В Ubuntu для включения ведения журнала потребуется добавить следующий независимый блок (тот же уровень, что и блок опций) в /etc/bind/named.conf :

Logging { channel query_log { file "/var/log/bind9/query.log"; severity dynamic; print-category yes; print-severity yes; print-time yes; }; category queries { query_log; }; };

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

Итоги

В этой статье мы объяснили, как настроить базовый рекурсивный, кеширующий DNS -сервер и как настроить зоны для домена.

Чтобы обеспечить правильную работу вашего DNS -сервера, не забудьте разрешить эту службу в вашем брандмауэре (порт TCP 53), как описано в («Настройка брандмауэра Iptables для включения удаленного доступа к услугам»).

.

Курсы Cisco и Linux с трудоустройством!

Спешите подать заявку! Осталось пару мест. Группы стартуют 22 июля , а следующая 19 августа, 23 сентября, 21 октября, 25 ноября, 16 декабря, 20 января, 24 февраля .

Что Вы получите?

  • Поможем стать экспертом в сетевом администрировании и получить международные сертификаты Cisco CCNA Routing & Switching или Linux LPI.
  • Предлагаем проверенную программу и учебник экспертов из Cisco Networking Academy и Linux Professional Institute, сертифицированных инструкторов и личного куратора.
  • Поможем с трудоустройством и сделать карьеру. 100% наших выпускников трудоустраиваются.

Как проходит обучение?

  • Проводим вечерние онлайн-лекции на нашей платформе или обучайтесь очно на базе Киевского офиса.
  • Спросим у вас об удобном времени для практик и подстроимся: понимаем, что времени учиться мало.
  • Если хотите индивидуальный график - обсудим и осуществим.
  • Выставим четкие дедлайны для самоорганизации. Личный куратор будет на связи, чтобы ответить на вопросы, проконсультировать и мотивировать придерживаться сроков сдачи экзаменов.

А еще поможем Вам:

artem

30.10.2013

10379

Настройка кэширующего DNS-сервера для решения проблемы зависания chan_sip.so.

SIP-модуль Asterisk синхронно разрешает DNS-имена, если DNS-сервер, по каким-либо причинам, перестанет отвечать на запросы, код SIP-модуля прекращает выполнение до наступления таймаута DNS-запроса. Результатом этого является неработаспособность всех клиентов и провайдеров, подключенных по SIP, клиенты не могут регистрироваться и совершать вызовы.
Способы решения проблемы:
1. Не указывать DNS-имена в параметре SIP-пиров ‘host’ и в строках SIP-регистраций, указывать только IP-адреса (позволяет полностью исключить возможность возникновения проблемы, но невозможно с некоторыми провайдерами).
2. Настроить кэширующий DNS-сервер на хосте Asterisk.

В данной статье будет описан способ решения проблемы с помощью DNS-сервера BIND (инструкция верна для CentOS 5-6)

Настройка DNS-сервера BIND

1. Устанавливаем BIND, копируем шаблоны настроек и файлы стандартных зон

yum install bind bind-chroot
cp /etc/localtime /var/named/chroot/etc

cp /usr/share/doc/bind-*/sample/etc/named.root.hints /var/named/chroot/etc
cp /usr/share/doc/bind-*/sample/etc/named.rfc1912.zones /var/named/chroot/etc
cp /usr/share/doc/bind-*/sample/etc/named.conf /var/named/chroot/etc

cp /usr/share/bind-*/sample/var/named/localdomain.zone /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/localhost.zone /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.broadcast /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.ip6.local /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.local /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.root /var/named/chroot/var/named
cp /usr/share/bind-*/sample/var/named/named.zero /var/named/chroot/var/named

2. Правим конфиг BIND /var/named/chroot/etc/named.conf

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

> Добавить в раздел options строчку:

Можно указать свои DNS-серверы. Если не указывать эту строчку, то BIND будет опрашивать корневые DNS-серверы, что медленнее

> Разрешить рекурсивные запросы для view-зоны ‘localhost_resolver’ (заменить ‘recursion no’ на ‘recursion yes’, если этого не сделать, то сам хост не сможет делать рекурсивные запросы через DNS-сервер). Рекурсивные запросы и запросы кэша для остальных зон можно отключить

> Закомментировать или удалить разделы, отвечающие за настройку внутренних зон и DDNS, т.к. их просто не будет

Листинг полученного конфига:

//
// Sample named.conf BIND DNS server ‘named’ configuration file
// for the Red Hat BIND distribution.
// See the BIND Administrator’s Reference Manual (ARM) for details, in:
// file:///usr/share/doc/bind-*/arm/Bv9ARM.html
// Also see the BIND Configuration GUI: /usr/bin/system-config-bind and
// its manual.
options
{
// Those options should be used carefully because they disable port
// randomization
// query-source port 53;
// query-source-v6 port 53;

// Put files that named is allowed to write in the data/ directory:
directory “/var/named”; // the default
dump-file “data/cache_dump.db”;
statistics-file “data/named_stats.txt”;
memstatistics-file “data/named_mem_stats.txt”;
max-cache-size 2097152;

forwarders { 8.8.8.8; 8.8.4.4; };
};
//logging
//{
/* If you want to enable debugging, eg. using the ‘rndc trace’ command,
* named will try to write the ‘named.run’ file in the $directory (/var/named).
* By default, SELinux policy does not allow named to modify the /var/named directory,
* so put the default debug log file in data/ :
*/
// channel default_debug {
// file “data/named.run”;
// severity dynamic;
// };
//};
// All BIND 9 zones are in a “view”, which allow different zones to be served
// to different types of client addresses, and for options to be set for groups
// of zones.
// By default, if named.conf contains no “view” clauses, all zones are in the
// “default” view, which matches all clients.
// If named.conf contains any “view” clause, then all zones MUST be in a view;
// so it is recommended to start off using views to avoid having to restructure
// your configuration files in the future.
view “localhost_resolver”
{
/* This view sets up named to be a localhost resolver (caching only nameserver).
* If all you want is a caching-only nameserver, then you need only define this view:
*/
match-clients { localhost; };
match-destinations { localhost; };
recursion yes;

/* these are zones that contain definitions for all the localhost
* names and addresses, as recommended in RFC1912 – these names should
* ONLY be served to localhost clients:
*/
include “/etc/named.rfc1912.zones”;
};
view “internal”
{
/* This view will contain zones you want to serve only to “internal” clients
that connect via your directly attached LAN interfaces – “localnets” .
*/
match-clients { localnets; };
match-destinations { localnets; };
recursion no;

Allow-query-cache { none; };

// all views must contain the root hints zone:
include “/etc/named.root.hints”;

// include “named.rfc1912.zones”;
// you should not serve your rfc1912 names to non-localhost clients.

// These are your “authoritative” internal zones, and would probably
// also be included in the “localhost_resolver” view above:

//zone “my.internal.zone” {
// type master;
// file “my.internal.zone.db”;
//};
//zone “my.slave.internal.zone” {
// type slave;
// file “slaves/my.slave.internal.zone.db”;
// masters { /* put master nameserver IPs here */ 127.0.0.1; } ;
// // put slave zones in the slaves/ directory so named can update them
//};
//zone “my.ddns.internal.zone” {
// type master;
// allow-update { key ddns_key; };
// file “slaves/my.ddns.internal.zone.db”;
// // put dynamically updateable zones in the slaves/ directory so named can update them
//};
};
//key ddns_key
//{
// algorithm hmac-md5;
// secret “use /usr/sbin/dns-keygen to generate TSIG keys”;
//};
view “external”
{
/* This view will contain zones you want to serve only to “external” clients
* that have addresses that are not on your directly attached LAN interface subnets:
*/
match-clients { any; };
match-destinations { any; };

recursion no;
// you’d probably want to deny recursion to external clients, so you don’t
// end up providing free DNS service to all takers

allow-query-cache { none; };
// Disable lookups for any cached data and root hints

// all views must contain the root hints zone:
include “/etc/named.root.hints”;

// These are your “authoritative” external zones, and would probably
// contain entries for just your web and mail servers:

//zone “my.external.zone” {
// type master;
// file “my.external.zone.db”;
//};
};

3. Запускаем BIND, включаем запуск при старте системы

service named start

Если в синтаксисе конфига допущены ошибки или каких-либо файлов не хватает, сообщение об ошибке будет выведено в консоль и записано в лог /var/log/messages


Автор: Paul Cobbaut
Дата публикации: 24 мая 2015 г.
Перевод: A.Панин
Дата перевода: 11 июля 2015 г.

Глава 4. Вводная информация о серверах DNS

4.3. Кэширующие серверы DNS

Сервер DNS , не обслуживающий зону DNS , но соединенный с другими серверами имен для кэширования запросов, называется кэширующим сервером DNS . Кэширующие серверы DNS не работают с базами данных зон DNS , содержащими ресурсные записи. Вместо этого они соединяются с другими серверами имен и кэшируют соответствующую информацию.

Существует два вида кэширующих серверов DNS. Это серверы DNS, использующие перенаправляющие серверы DNS , а также серверы DNS, использующие корневые серверы DNS .

4.3.1. Кэширующий сервер DNS, не использующий перенаправляющий сервер

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

На иллюстрации ниже показан процесс отправки клиентом запроса информации об IP-адресе для доменного имени linux-training.be. Наш кэширующий сервер соединится с корневым сервером и будет перенаправлен на сервер, обслуживающий домен верхнего уровня.be. После этого он соединится с сервером, обслуживающим домен верхнего уровня.be, и будет перенаправлен на один из серверов имен организации Openminds. Один из этих серверов имен (в данном случае nsq.openminds.be) ответит на запрос, передав IP-адрес сервера с доменным именем linux-training.be. После того, как наш кэширующий сервер передаст данную информацию клиенту, клиент сможет соединиться с рассматриваемым веб-сайтом.

При использовании сниффера tcpdump в процессе разрешения данного доменного имени можно получить следующий вывод (первые 20 символов каждой строки были удалены).

192.168.1.103.41251 > M.ROOT-SERVERS.NET.domain: 37279% A? linux-tr\ aining.be. (46) M.ROOT-SERVERS.NET.domain > 192.168.1.103.41251: 37279- 0/11/13 (740) 192.168.1.103.65268 > d.ns.dns.be.domain: 38555% A? linux-training.\ be. (46) d.ns.dns.be.domain > 192.168.1.103.65268: 38555- 0/7/5 (737) 192.168.1.103.7514 > ns2.openminds.be.domain: 60888% A? linux-train\ ing.be. (46) ns2.openminds.be.domain > 192.168.1.103.7514: 60888*- 1/0/1 A 188.93.155.\ 87 (62)

4.3.2. Кэширующий сервер DNS, использующий перенаправляющий сервер

Кэширующий сервер DNS , использующий перенаправляющий сервер, является сервером DNS, который получает всю необходимую информацию от перенаправляющего сервера (forwarder). В качестве перенаправляющего сервера DNS может выступать, к примеру, сервер DNS интернет-провайдера.

На иллюстрации выше показан сервер DNS в локальной сети компании, который использует предоставляемый интернет-провайдером сервер DNS в качестве перенаправляющего сервера DNS . В том случае, если IP-адресом предоставляемого интернет провайдером сервера DNS является адрес 212.71.8.10, в файле конфигурации named.conf сервера DNS компании должны присутствовать следующие строки:

Forwarders { 212.71.8.10; };

Кроме того, вы также можете настроить ваш сервер DNS для работы с условно-перенаправляющими серверами DNS (conditional forwarders). Описание условно-перенаправляющего сервера DNS в файле конфигурации выглядит следующим образом:

Zone "someotherdomain.local" { type forward; forward only; forwarders { 10.104.42.1; }; };

4.3.3. Итеративный или рекурсивный запрос

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

Сервер DNS, осуществляющий управление зоной DNS, называется авторитативным сервером DNS (authoritative DNS server) для данной зоны. Помните о том, что зона DNS является всего лишь набором ресурсных записей.

Первый авторитативный сервер DNS для зоны DNS называется первичным сервером DNS (primary DNS server). Этот сервер будет работать с копией базы данных зоны DNS , доступной как для чтения, так и для записи. При необходимости повышения сохранности данных в случае сбоев, повышения производительности сервера или балансировки нагрузки вы можете ввести в строй другой сервер DNS , который также будет управлять данной зоной DNS. Этот сервер будет называться вторичным сервером DNS (secondary DNS server).

Вторичный сервер получает копию базы данных зоны DNS от первичного сервера в процессе передачи данных зоны DNS (zone transfer). Запросы осуществления передач данных зон DNS отправляются вторичными серверами через определенные временные интервалы. Длительность этих временных интервалов устанавливаются в рамках ресурсной записи SOA .

Вы можете инициировать принудительное обновление данных зоны DNS с помощью утилиты rndc . В примере ниже инициируется передача данных зоны DNS fred.local , а также выводится соответствующий фрагмент файла системного журнала /var/log/syslog .

root@debian7:/etc/bind# rndc refresh fred.local root@debian7:/etc/bind# grep fred /var/log/syslog | tail -7 | cut -c38- zone fred.local/IN: sending notifies (serial 1) received control channel command "refresh fred.local" zone fred.local/IN: Transfer started. transfer of "fred.local/IN" from 10.104.109.1#53: connected using 10.104.33.30#57367 zone fred.local/IN: transferred serial 2 transfer of "fred.local/IN" from 10.104.109.1#53: Transfer completed: 1 messages, 10 records, 264 bytes, 0.001 secs (264000 bytes/sec) zone fred.local/IN: sending notifies (serial 2) root@debian7:/etc/bind#

При добавлении вторичного сервера DNS в зону DNS вы можете настроить этот сервер таким образом, что он окажется ведомым сервером DNS (slave DNS server) по по отношению к первичному серверу. Первичный же сервер DNS окажется ведущим сервером DNS (master DNS server) по отношению к вторичному серверу.

Чаще всего первичный сервер DNS является ведущим сервером, работающим со всеми ведомыми серверами. Иногда ведомый сервер может являться одновременно и ведущим сервером для ведомых серверов следующего уровня. На иллюстрации ниже сервер с именем ns1 является первичным сервером, а серверы с именами ns2, ns3 и ns4 - вторичными серверами. Хотя ведущим сервером для серверов с именами ns2 и ns3 и является сервер с именем ns1, ведущим сервером для сервера с именем ns4 является сервер с именем ns2.

Ресурсная запись SOA содержит значение частоты обновления данных зоны DNS с именем refresh . В том случае, если это значение устанавливается равным 30 минутам, ведомый сервер будет отправлять запросы на передачу копии данных зоны DNS через каждые 30 минут. Также данная запись содержит значение продолжительности периода ожидания с именем retry . Данное значение используется в том случае, если ведущий сервер не отвечает на последний запрос передачи данных зоны DNS. Значение с именем expiry time устанавливает период времени, в течение которого ведомый сервер может отвечать на запросы от клиентов без обновления данных зоны DNS.

Ниже приведен пример использования утилиты nslookup для чтения данных ресурсной записи SOA зоны DNS (linux-training.be).

Root@debian6:~# nslookup > set type=SOA > server ns1.openminds.be > linux-training.be Server: ns1.openminds.be Address: 195.47.215.14#53 linux-training.be origin = ns1.openminds.be mail addr = hostmaster.openminds.be serial = 2321001133 refresh = 14400 retry = 3600 expire = 604800 minimum = 3600

Передачи данных зон DNS осуществляются лишь в случаях изменения данных в базах данных зон DNS (то есть, тогда, когда происходит добавление, удаление или изменение одной или большего количества ресурсных записей на стороне ведущего сервера). Ведомый сервер осуществляет сравнение номера версии (serial number) собственной копии ресурсной записи SOA с номером версии ресурсной записи SOA соответствующего ведущего сервера. В том случае, если номера версий совпадают, обновления данных не требуется (по той причине, что другие ресурсные записи не были добавлены, удалены или изменены). В том же случае, если номер версии ресурсной записи SOA на стороне ведомого сервера меньше номера версии той же записи на стороне соответствующего ведущего сервера, будет осуществлен запрос передачи данных зоны DNS.

Ниже приведен снимок окна сниффера Wireshark с данными, перехваченными в процессе передачи данных зоны DNS.

4.9. Полные или частичные передачи данных зон DNS

Передача данных зоны DNS может быть как полной, так и частичной. Решение об использовании того или иного режима зависит от объема данных, который необходимо передать для полного обновления базы данных зоны DNS на ведомом сервере. Частичная передача данных зоны предпочтительна в том случае, когда полный объем измененных данных меньше объема всей базы данных. Полные передачи данных зон DNS осуществляются с использованием протокола AXFR , а частичные передачи данных зон DNS - с использованием протокола IXFR .