Настройка DNS сервера BIND9

Для начала поговорим немного о том, для чего это нужно и как оно работает. DNS оччень важен для работы Интернета, так как для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. Что-бы мы могли использовать такие удобные имена как sebeadmin.ru, а не адрес вида 91.204.74.143, была давным давно придумана Domain Name System или сокращенно DNS (Система Доменных Имен). В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-серверы, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла hosts, который составлялся централизованно и автоматически рассылался на каждую из машин в своей локальной сети. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS. Хотя этот файл можно использовать и сейчас, он имеет больший приоритет при получении IP адреса чем DNS, те сначала идет обращение в DNS кэш, потом в файл hosts и в самом конце на сервер DNS.
DNS обладает следующими характеристиками:
Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации. Те нельзя так просто взять и отключить целый домен.
Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности и (возможно) адреса корневых DNS-серверов. Сервера отвечают только за свою зону или часть зоны.
Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.

Рассмотрим принцип работы рекурсивного DNS сервера.
Предположим, мы набрали в браузере адрес www.sebeadmin.ru. Наш DNS клиент спрашивает у первого (который указан в настройках подключения к сети) сервера DNS: «какой IP-адрес у www.sebeadmin.ru»? Однако, сервер DNS может ничего не знать не только о запрошенном имени, но даже обо всём домене sebeadmin.ru. В этом случае сервер может обратиться к серверу ответственному за зону ru. или корневому серверу — например, 198.41.0.4 Предположим этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону ru.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону sebeadmin.ru.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.
Структура имен напоминает дерево, где корень (root) это его верх, а зоны его ветки, выглядит это вот так

Из-за существовавших в прошлом ограничений на размеры DNS-пакета (512 байт) в DNS-ответ могло быть помещено всего 13 серверов (от A до M — тринадцатой буквы в алфавите), сейчас за этими 13 именами стоят более 200 серверов. Ближайший (к пользователю) адрес «зеркала» корневого сервера выбирается автоматически благодаря IP AnyCast. Так, при обращении к K.root-servers.net, пользователь из Новосибирска скорее всего обратится к новосибирскому серверу (в NSK-IX).
Опровержение распространённых заблуждений:
Не весь интернет-трафик проходит через корневой сервер;
Не каждый DNS-запрос обрабатывается корневым сервером;
Корневые серверы обслуживаются не добровольцами в качестве хобби, а профессионалами, и хорошо финансируются;
Ни одна организация (коммерческая или правительственная) не контролирует всю систему.

Так-же есть несколько типов DNS-записей:
Запись A (address record) или запись адреса связывает имя компьютера или сервера с адресом IP. Например, запрос A-записи на имя referrals.icann.org вернет его IP адрес — 192.0.34.164
Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернет его IPv6 адрес — 2001:7fd::1
Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя. Например www.sebeadmin.ru на sebeadmin.ru
Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена. Серверов может быть несколько, для каждого можно выставить приоритет, чем ниже цифра, тем он приоритетнее по сравнению с остальными. По умолчанию 10
Запись NS (name server) указывает на DNS-сервера для данного домена.
Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в reverse форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP-сессии.
Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов.
SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber (альтернатива ICQ) и Active Directory (групповое администрирование пользователей)
На этом мы ограничимся и перейдем к практике.
Установка и настройка bind9
Теперь давайте настроим свой DNS сервер для локального домена, например home вы можете выбрать любой, но учтите что она не должена пересекаться с настоящими доменами, тк вы не сможете потом обратиться к настоящим сайтам, те создав зону com и в ней запись о сайте vk.com вы не сможете обратиться к настоящему сайту, если конечно не укажите там правильную информацию. Рекомендую использовать выдуманную зону, как например home или office. Тк. cамым популярным *NIX сервером DNS является Bind, мы тоже будем использовать его. Установим его на наш сервер, для этого выполним команду apt-get install bind9 так-же будет установлен пакет bind9utils. Если все прошло хорошо, то сразу после установки сервера он запустится, о чем будет сообщено в терминале.
* Starting domain name service… bind9 [OK]
Теперь приступим к его настройке. Перейдем в его каталог командой cd /etc/bind/ и создадим файл с именем myzones.conf, для этого выполним команду touch myzones.conf и откроем его nano myzones.conf Впишем туда такую строку: zone «home» {type master; file «/etc/bind/db.home»;}; эта запись значит что для нашей зоны home данный сервер будет главным (master), а вcя информация о зоне хранится в файле /etc/bind/db.home который нам нужно будет создать чуть позже. Сохраняем этот файл и открываем файл named.conf командой nano named.conf в конец файла дописываем include «/etc/bind/myzones.conf»; и тоже сохраняем. Эта надпись подключит при запуске сервера файлик myszones.conf в котором мы указали наши зоны (домены).
Приступим к созданию файла зоны о котором писалось чуть выше, для этого выполним команду nano db.home и впишем туда следующее:

$TTL 86400
@ IN SOA ns1.home. root.home. (
2013090900 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400) ; Negative Cache TTL
;
@ IN NS ns1.home.
ns1 IN A 127.0.0.1
* IN CNAME @
server IN A 192.168.0.254
comp1 IN A 192.168.0.1
comp2 IN A 192.168.0.2
comp3 IN A 192.168.0.3

Первое что нужно знать при редактировании файла зоны, это то, что при каждом внесении изменении нужно увеличивать serial, общепринято и правильно это делать в таком виде YYYYMMDDRR, где YYYY текущий год, MM месяц, DD день, RR номер правки за текущий день. Например сегодня 9 сентября 2013г. это будет наша первая правка зоны за день, получаем serail равный 2013090900, тк в программировании счет начинается с ноля, первая правка будет иметь номер 00, вторая 01 и тд. Хотя это не принципиально в данном случае, главное что-бы цифра была хотя-бы на единицу больше.
Строка @ IN NS ns1.home. гласит что для текущей зоны сервер DNS имеет имя ns1.home, далее строкой ns1 IN A 127.0.0.1 мы указываем что у сервера ns1 IP-адрес 127.0.0.1 (те он находится на этом сервере). Что-бы добавить новую запись о имени хоста добавим строку server IN A 192.168.0.254 где server это имя хоста (компьютера), а 192.168.0.254 его IP-адресc, те. компьютер с этим IP-адресом будет иметь имя server.home. Таких записей может быть сколько угодно, так-же можно назначать несколько имен для одного IP, это бывает необходимо если нам нужно настроить несколько виртуальных web серверов. Сохраняем этот файл. Для того что-бы DNS сервер принял настройки его нужно перезапустить, для этого используется такая команда /etc/init.d/bind9 restart Если конфигурация оказалась без ошибок, мы увидим следующее
* Stopping domain name service… bind9 [ OK ]
* Starting domain name service… bind9 [ OK ]
Если сервер не смог запустится, проверьте конфигурационные файлы которые мы редактировали.
Внимание: основная причина ошибок это пропущенные символы вроде точки, двоеточия или точки с запятой. Проверьте синтаксис написания, так-же заметьте что после все имен, кроме названия хостов, в файле db.home стоят точки, это важно.
Если все запустилось, проверим правильно ли работает наш сервер, для этого воспользуемся утилиткой nslookup, она есть в каждой ОС, для этого выполним на сервере в командной строке команду nslookup
далее введем команду server 127.0.0.1 это укажет что мы хотим использовать сервер находящийся по адресу 127.0.0.1, после напишем имя какого-нибудь хоста, который мы указали в нашей зоне, например server.home вот-так должен выглядеть правильные ответы сервера.
root@CoolServ:/etc/bind# nslookup
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> server.home
Server: 127.0.0.1
Address: 127.0.0.1#53
server.home canonical name = home.
Если все совпадает, значит все работает правильно. Теперь можно использовать этот сервер для работы. Если не совпадает, проверьте настройки, возможно служба не запустилась или не удалось найти зону, те она была указана с ошибкой.
Можно указать его IP в файле /etc/resolv.conf что-бы использовать его на своем сервере. Для этого запустим nano /etc/resolv.conf и впишем в самом начале файла строку nameserver 127.0.0.1 и на следующей строке nameserver 8.8.8.8 Первая строка укажет нашему серверу что по умолчанию нужно использовать DNS сервер на локальном хосте, в случае если он перестанет отвечать на запросы, использовать DNS по адресу 8.8.8.8 (это IP публичного DNS сервера Google). Сохраняем файл и на этом настройка DNS окончена.
Использование ресурсов провайдера/другой сети через свой DNS
Может возникнуть задача использовать ресурсы провайдера или имена из другой «серой» сети которые невозможно получить через всемирные DNS, для ее решения нужно подредактировать конфигурацию нашего сервера. Предположим нужно получить доступ к зоне lan Интернет провайдера. Для этого в файл myzones.conf допишем такую строку zone «lan» IN { type forward; forward only; forwarders { 10.0.0.1; 10.0.0.2;}; }; где lan название зоны, а 10.0.0.1 и 10.0.0.2 DNS сервера провайдера или другой сети. Теперь при запросе к этой зоне он будет обращаться непосредственно к ним, а не искать их в Инете.
Настройка альтернативного (slave) DNS
Пришлось мне однажды настраивать slave сервер что-бы поддержать друга в его начинаниях.
Slave сервера нужны для обеспечения отказоустойчивости зоны, например если с главным сервером что-то случится (он «упадет», повреждение Интернет магистрали и другие неприятные вещи) зона будет продолжать работать дальше пока главный сервер не начнет нормально функционировать. Для этого на альтернативном сервере нам потребуется написать вот такую строку в файле /etc/bind9/myzones.conf
zone «home.» IN { type slave; file «/etc/bind/slave/mirror.home»; masters { 192.168.0.254; }; }; где 192.168.0.254 наш первичный DNS сервер, а /etc/bind/slave/mirror.home файл в котором будет хранится копия зоны основного сервера, так-же нужно создать папку командой mkdir /etc/bind/slave/ и передать ее пользователю bind, для этого выполним chown bind:bind /etc/bind/slave/
Здесь меня ждал подводный камень тк до этого мне не приходилось сталкиваться с такими серверами, я никак не предполагал что сервер не сможет писать временный файл в эту папку даже с полными правами. На анализ логов и поиск решение ушло почти пол ночи, было пролистано пол поисковика, пока на каком-то англоязычном форуме я не наткнулся на такое решение. Нужно открыть файл nano /etc/apparmor.d/usr.sbin.named найти строку /etc/bind/zones/** r, и заменить ее на /etc/bind/zones/** rw, те дописать атрибут w что-бы bind мог писать в эту директорию. Перезапустить /etc/init.d/apparmor reload и /etc/init.d/bind9 restart и после этого сервер сразу заработал как нужно.

Написано мной специально для sebeadmin.ru