DNS (Domain Name System) – важный и довольно сложный в настройке компонент, необходимый для работы веб-сайтов и серверов. Многие пользователи обращаются к DNS-серверам, которые предоставляет их хостинг-провайдер, однако собственные DNS-серверы имеют некоторые преимущества.
В данном мануале вы узнаете, как установить Bind9 и настроить его как кэширующий или перенаправляющий DNS-сервер на сервере Ubuntu 14.04.
Требования
- Понимание базовых типов DNS-серверов. Ознакомиться с подробностями можно в .
- Две машины, из которых хотя бы одна работает на Ubuntu 14.04. Первая машина будет настроена как клиент (IP-адрес 192.0.2.100), а вторая – как DNS-сервер (192.0.2.1).
Вы научитесь настраивать клиентскую машину для отправки запросов через DNS-сервер.
Кэширующий DNS-сервер
Серверы этого типа также называются определителями, поскольку они обрабатывают рекурсивные запросы и, как правило, могут выполнить поиск данных DNS не других серверах.
Когда кэширующий DNS-сервер отслеживает ответ на запрос клиента, он возвращает ответ клиенту, а также сохраняет его в кэше в течение периода времени, разрешенного значением TTL соответствующих DNS-записей. Затем кэш можно использовать в качестве источника ответов на последующие запросы, чтобы ускорить общее время обработки запроса.
Почти все DNS-серверы в вашей сетевой конфигурации будут кэширующими. Кэширующий DNS-сервер – хороший выбор для многих ситуаций. Если вы не хотите полагаться на DNS-серверы вашего хостинг-провайдера или другие общедоступные DNS-серверы, настройте собственный кэширующий DNS-сервер. Чем меньше расстояние от DNS-сервера к клиентским машинам, тем меньше время обслуживания запросов DNS.
Перенаправляющий DNS-сервер
С точки зрения клиента перенаправляющий DNS-сервер будет выглядеть почти идентично кэширующему серверу, но механизмы и рабочая нагрузка у них совершенно разные.
Перенаправляющий DNS-сервер имеет те же преимущества, что и кэширующий сервер. Однако на самом деле он не выполняет ни одного рекурсивного запроса. Вместо этого он перенаправляет все запросы на внешний разрешающий сервер, а затем кэширует результаты для последующих запросов.
Это позволяет перенаправляющему серверу обслуживать запросы из своего кэша, не обрабатывая при этом рекурсивных запросов. Таким образом, этот сервер обрабатывает только одиночные запросы (перенаправленные запросы клиента), а не всю процедуру рекурсии. Это может быть преимуществом в средах с ограниченной внешней пропускной способностью, в которых необходимо часто менять кэширующие серверы, и в ситуациях, когда нужно перенаправить локальные запросы на один сервер, а внешние – на другой.
1: Установка Bind на DNS-сервер
Пакет Bind можно найти в официальном репозитории Ubuntu. Обновите индекс пакетов и установите Bind с помощью менеджера apt. Также нужно установить пару зависимостей.
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc
После этого можно начать настройку сервера. Конфигурацию кэширующего сервера можно использовать в качестве шаблона для настройки перенаправляющего сервера, поэтому сначала нужно настроить кэширующий DNS-сервер.
2: Настройка кэширующего DNS-сервера
Сначала нужно настроить Bind в качестве кэширующего DNS-сервера. Такая конфигурация заставит сервер рекурсивно искать ответы на клиентские запросы на других DNS-серверах. Он будет последовательно опрашивать все соответствующие DNS-сервера, пока не найдет ответ.
Конфигурационные файлы Bind хранятся в каталоге /etc/bind.
Большую часть файлов редактировать не нужно. Главный конфигурационный файл называется named.conf (named и bind – два названия одного приложения). Этот файл ссылается на файлы named.conf.options, named.conf.local и named.conf.default-zones.
Для настройки кэширующего DNS-сервера нужно отредактировать только named.conf.options.
sudo nano named.conf.options
Этот файл выглядит так (комментарии опущены для простоты):
options {
directory "/var/cache/bind";
dnssec-validation auto;
listen-on-v6 { any; };
};
Чтобы настроить кэширующий сервер, нужно создать список контроля доступа, или ACL.
Нужно защитить DNS-сервер, обрабатывающий рекурсивные запросы, от злоумышленников. Атаки DNS-усиления особенно опасны, поскольку могут вовлечь сервер в распределенные атаки на отказ в обслуживании.
Атаки DNS-усиления – это один из способов прекращения работы серверов и сайтов. Для этого злоумышленники пытаются найти общедоступные DNS-серверы, которые обрабатывают рекурсивные запросы. Они подделывают IP-адрес жертвы и отправляют запрос, который вернет DNS-серверу очень объемный ответ. При этом DNS-сервер возвращает на сервер жертвы слишком много данных в ответ на небольшой запрос, увеличивая доступную пропускную способность злоумышленника.
Для размещения общедоступного рекурсивного DNS-сервера требуется тщательная настройка и администрирование. Чтобы предотвратить возможность взлома сервера, настройте список IP-адресов или диапазонов сети, которым сервер сможет доверять.
Перед блоком options добавьте блок acl. Создайте метку для группы ACL (в данном мануале группа называется goodclients).
acl goodclients {
};
options {
. . .
В этом блоке перечислите IP-адреса или сети, у которых будет доступ к этому DNS-серверу. Поскольку сервер и клиент работают в подсети /24, можно ограничить доступ по этой подсети. Также нужно разблокировать localhost и localnets, которые подключаются автоматически.
acl goodclients {
192.0.2.0/24;
localhost;
localnets;
};
options {
. . .
Теперь у вас есть ACL безопасных клиентов. Можно приступать к настройке разрешения запросов в блоке options. Добавьте в него такие строки:
options {
directory "/var/cache/bind";
recursion yes;
. . .
Блок options явно включает рекурсию, а затем настраивает параметр allow-query для использования списка ACL. Для ссылки на группу ACL можно также использовать другой параметр, например allow-recursion. При включенной рекурсии allow-recursion определит список клиентов, которые могут использовать рекурсивные сервисы.
Однако если параметр allow-recursion не установлен, Bind возвращается к списку allow-query-cache, затем к списку allow-query и, наконец, к спискам по умолчанию localnets и localhost. Поскольку мы настраиваем только кэширующий сервер (он не имеет собственных зон и не пересылает запросы), список allow-query всегда будет применяться только к рекурсии. Это самый общий способ определения ACL.
Сохраните и закройте файл.
Это все настройки, которые нужно добавить в конфигурационный файл кэширующего DNS-сервера.
Примечание : Если вы хотите использовать только этот тип DNS, переходите к проверке конфигураций, перезапустите сервис и настройте свой клиент.
3: Настройка перенаправляющего DNS-сервера
Если вашей инфраструктуре больше подходит перенаправляющий DNS-сервер, вы можете немного откорректировать настройку.
На данный момент файл named.conf.options выглядит так:
acl goodclients {
192.0.2.0/24;
localhost;
localnets;
};
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
Можно использовать тот же список ACL, чтобы ограничивать DNS-сервер конкретным списком клиентов. Однако при этом необходимо немного изменить конфигурацию, чтобы сервер больше не пытался выполнять рекурсивные запросы.
Не меняйте значение recursion на no. Перенаправляющий сервер все-таки поддерживает рекурсивные сервисы. Чтобы настроить перенаправляющий сервер, нужно создать список кэширующих серверов, на которые он будет перенаправлять запросы.
Это делается в блоке options {}. Сначала нужно создать в нем новый блок forwarders, где будут храниться IP-адреса рекурсивных серверов имен, на которые нужно перенаправлять запросы. В данном случае это будут DNS-серверы Google (8.8.8.8 и 8.8.4.4):
. . .
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
forwarders {
8.8.8.8;
8.8.4.4;
};
. . .
В результате конфигурация выглядит так:
acl goodclients {
192.0.2.0/24;
localhost;
localnets;
};
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
forwarders {
8.8.8.8;
8.8.4.4;
};
forward only;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
Последнее изменение касается параметра dnssec. При текущей конфигурации и в зависимости от настройки DNS-серверов, на которые перенаправляются запросы, в логах могут появиться такие ошибки:
Jun 25 15:03:29 cache named: error (chase DS servers) resolving "in-addr.arpa/DS/IN": 8.8.8.8#53
Jun 25 15:03:29 cache named: error (no valid DS) resolving "111.111.111.111.in-addr.arpa/PTR/IN": 8.8.4.4#53
Чтобы избежать их, нужно изменить значение параметра dnssec-validation на yes и явно разрешить dnssec.
. . .
forward only;
dnssec-enable yes;
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
. . .
Сохраните и закройте файл. Настройка перенаправляющего DNS-сервера завершена.
4: Проверка настроек и перезапуск Bind
Теперь нужно убедиться, что настройки работают должным образом.
Чтобы проверить синтаксис конфигурационных файлов, введите:
sudo named-checkconf
Если в файлах нет ошибок, командная строка не отобразит никакого вывода.
Если вы получили сообщение об ошибке, исправьте ее и повторите проверку.
После этого можно перезапустить демон Bind, чтобы обновить настройки.
sudo service bind9 restart
После нужно проверить логи сервера. Запустите на сервер команду:
sudo tail -f /var/log/syslog
Теперь откройте новый терминал и приступайте к настройке клиентской машины.
5: Настройка клиента
Войдите на клиентскую машину. Убедитесь, что клиент был указан в группе ACL настроенного DNS-сервера. В противном случае DNS-сервер откажется обслуживать запросы этого клиента.
Отредактируйте файл /etc/resolv.conf, чтобы направить сервер на сервер имен.
Изменения, внесенные здесь, будут сохраняться только до перезагрузки, что отлично подходит для тестирования. Если результаты тестовой настройки вас удовлетворят, вы сможете сделать эти настройки постоянными.
Откройте файл с помощью sudo в текстовом редакторе:
sudo nano /etc/resolv.conf
В файле нужно перечислить DNS-серверы, которые будут использоваться для разрешения запросов. Для этого используйте директиву nameserver. Закомментируйте все текущие записи и добавьте строку nameserver, указывающую на ваш DNS-сервер:
nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3
Сохраните и закройте файл.
Теперь можно отправить тестовый запрос, чтобы убедиться, что он разрешается правильно.
Для этого можно использовать ping:
ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms
Настройка кеширующего DNS сервера
Устанавливаем службу DNS сервера Bind9 , командой:
sudo apt-get install bind9При установке сервера Bind9 система может потребовать от вас вписать свое согласие Yes , а не просто нажать кнопку Y .
Генерируем ключ для обновления DNS записей, следующей командой:
dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DHCP_UPDATERПоказать этот ключ можно командой:
cat Kdhcp_updater.*.private|grep KeyОтобразится ключ вида вида sWAQagEOVTtRQpCekhNsJQ== , данный ключ понадобится нам позже. Либо скопируйте данный ключ, либо запомните команду отображения ключа.
Ununtu Server: Установка DNS сервера Bind9 и генерация ключа обновления записей
Открываем файл конфигурации Bind9, командой:
sudo nano /etc/bind/named.conf.optionsИменно в этом файле прописываются внешние DNS сервера, к которым будет обращаться наш локальный сервер.
forwarders — вы можете установить сервера своего провайдера, или DNS сервера компании Google (8.8.8.8 и 8.8.4.4 . в некоторых случаях они работают стабильней или снимают ограничения вашего провайдера) .
Так как я настраиваю сервер школы, я буду использовать «семейные» DNS сервера компании Яндекс ().
Это будет самым первым уровнем защиты и первым фильтром контента школы.
listen-on — адреса через которые будет обслуживаться наш DNS сервер.
Закомментируем строку dnssec-validation auto .
Перед последней закрывающей скобкой в файле конфигурации Bind9 вставляем следующий текст:
forwarders {
77.88.8.7
;
77.88.8.3
;
};
listen-on {
127.0.0.1
;
192.168.137.1
;
};
Ununtu Server: Конфигурирование DNS сервера используя Яндекс DNS
Перезапускаем службу DNS, командой:
sudo service bind9 restart sudo nano /etc/resolvconf/resolv.conf.d/tailВносим в него следующие значения, для нашей сети.
domain school.loc
search school.loc
nameserver 127.0.0.1
Ubuntu Server: Настройка DNS сервера, файл resolv.conf
Сохраняем и закрываем файл. Перезагружаем DNS сервер, командой:
sudo service bind9 restartПроверяем работу нашего DNS сервера, командой:
dig ubuntu.comПосле чего повторно вводим эту же команду:
dig ubuntu.comНас интересует поле Query time (Время запроса) обеих команд, если время выполнения второго запроса уменьшилось, значит наш DNS сервер работает нормально.
Ubuntu Server: Проверка командой dig работы DNS сервиса
Для проверок используйте менее популярные домены, чем mail.ru, ya.ru, google.com.
Перезагрузите сервер (команда reboot ) и выполните проверку еще раз (необязательно, но поможет диагностировать на каком этапе настройки появилась ошибка)
Создание зон прямого и обратного просмотра
Указываем зоны прямого и обратного просмотра и прописываем их в файле конфигурации.
Создаем зону прямого просмотра.
Копируем образец файла по адресу /etc/bind/
db.local
в наше расположение, одновременно переименовывая его в /var/lib/bind
/prime_zone
:
и открываем его:
sudo nano /var/lib/bind/prime_zoneИзменяем файл, приводя к следующему виду, не забывая вставлять свои значения (если название сервера, домена и IP адресация отличается от моего примера):
Ubuntu Server: Файл конфигурации зоны прямого просмотра
Внимание: Linux очень «нежная» ОС, пропущенная или удаленная точка в файле конфигурации, приведет к ошибкам.
Создаем зону обратного просмотра.
Так же копированием и переименованием файла образца, командой:
sudo cp /etc/bind/db.127 /var/lib/bind/reverse_zoneОткрываем его:
sudo nano /var/lib/bind/reverse_zoneПриводим файл к виду:
Ubuntu Server: Файл конфигурации зоны обратного просмотра
Внимание: Любой файл зоны, должен оканчиваться пустой строкой.
В файле конфигурации Bind9 указываем зоны просмотра (используемый мною в этом примере ключ, отличается от созданного в начале статьи, ваш отличаться не должен) :
sudo nano /etc/bind/named.conf.localkey DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
};
zone «school.loc
» {
type master;
file «/var/lib/bind/prime_zone
«;
};
//reverse zone
zone «137.168.192
.in-addr.arpa» {
type master;
file «/var/lib/bind/reverse_zone
«;
allow-update { key DHCP_UPDATER; };
};
Где:
secret
— указываем ключ обновления DNS записей, созданный ранее
zone
«school.loc
«
— название вашего домена с указанием пути до файла конфигурации зоны прямого просмотра
zone
«137.168.192
.in-addr.arpa»
— зона обратного просмотра (обратите внимание, адресация указывается «задом наперёд») с указанием пути до файла конфигурации зоны.
Перезапускаем службу Bing9 сервер, командой:
Проверяем работу созданных зон, зоны прямого просмотра (преобразования имен):
nslookup gate.school.locЕсли зона настроена правильно, то будет отображен следующий результат:
Ubuntu Server: Правильная работа зоны прямого просмотра
И проверяем зону обратного просмотра:
nslookup 192.168.137.1Если обратная зона настроена правильно, то будет отображен следующий результат:
Ubuntu Server: Правильная работа зоны обратного просмотра
DNS сервер — настроен.
Дополнительно и полезно:
named-checkzone school.loc /var/lib/bind/prime_zone — проверка корректности работы зоны прямого просмотра;
named-checkzone 137.168.192 .in-addr.arpa /var/lib/bind/reverse_zone — проверка корректности работы зоны обратного просмотра;
Поиск проблем в Bind9: После попытки рестарта сервиса командой sudo /etc/init.d/bind9 restart , выполните команду tail /var/log/syslog для просмотра возможных ошибок;
Команды службы Bing:
- sudo service bind9 start — запуск службы
- sudo service bind9 stop — остановка службы
- sudo service bind9 status — статус службы (с выводом имеющихся ошибок)
- sudo service bind9 restart — перезапуск службы
Настройка динамического обновления зон DHCP сервером
Настроим автоматизацию создания прямых и обратных зон DNS для клиентов, с помощью DHCP.
Открываем конфигурационный файл DHCP, командой:
sudo nano /etc/dhcp/dhcpd.confЗакомментируем в файле строку:
#ddns-update-style none;
Добавляем в наш конфигурационный файл следующие строки:
ddns-update-style interim;
update-static-leases on;
key DHCP_UPDATER {
algorithm hmac-md5;
secret «c0fLwUnt918/w5F+a1xrqQ==
«;
}
zone school.loc
. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
zone 137.168.192
.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
Перезапускаем службы DNS и DHCP:
sudo /etc/init.d/bind9 restart sudo /etc/init.d/isc-dhcp-server restartС клиентского ПК с названием teacher проверим работу прямой и обратной зоны, командами nslookup:
Ubuntu Server: Проверка корректной работы зоны прямого и обратного просмотра с клиентского ПК
Если получен отклик, как на скриншоте, то на этом эту часть настройки Ubuntu Server будем считать законченной.
Переходим к следующей части настройки Ubuntu Server — .
Большинство «не работает» вызвано невнимательностью! Внимательно проверяйте команды и не допускайте в файлах конфигурации лишних символов.
От автора:
Если проблема решена, один из способов сказать «Спасибо» автору — .
Если же проблему разрешить не удалось и появились дополнительные вопросы, задать их можно на нашем , в специальном разделе.
Служба доменных имен (DNS) это сервис интернет, который ставит IP адреса и полностью квалифицированные доменные имена (FQDN) в соответствие одно другому. Поэтому DNS облегчает проблему запоминания IP адресов. Компьютеры, на которых запущен DNS , называются серверами имен (name servers). Ubuntu поставляется с BIND (сервис интернет имен Беркли), наиболее распространенную программу, используемую для управления серверами имен под Линукс.
5. Теперь перегружаем BIND9 для применения изменений:
Sudo service bind9 restart
Теперь вы можете увидеть файл /var/log/query.log, заполненный информацией о запросах. Это простейший пример использования опций журналирования BIND9.
Ссылки
Общие типы записей
Этот раздел покажет некоторые наиболее общие типы записей DNS .
1. A запись: Эта запись указывает IP адрес для сетевого имени (hostname).
Www IN A 192.168.1.12
2. CNAME запись: Используется для создания псевдонима (alias) на A запись. Вы не можете создавать CNAME запись, указывающую на другую CNAME запись.
Web IN CNAME www
3. MX запись: Используется для определения куда должна посылаться электронная почта (email). Должна указывать на A запись, не на CNAME .
IN MX 1 mail.example.com. mail IN A 192.168.1.13
4. NS запись: Используется для определения какие сервера поддерживают копии зоны. Должна указывать на A запись, не на CNAME . Ею определяются первичные и вторичные сервера зоны.
Существует много способов настроить BIND9. Наиболее распространенные конфигурации - это кэширующий сервер имен, первичный мастер и вторичный мастер.
Когда BIND9 настроен как кэширующий сервер, он ищет ответы на запросы имени и запоминает ответ на случай, если запрос придет повторно.
В качестве первичного мастера BIND9 читает данные зоны из локального файла и является ответственным за эту зону.
В качестве вторичного мастера BIND9 получает данные по зоне (целиком) с другого сервера имен, отвечающего за эту зону.
Обзор
Файлы настройки DNS сохраняются в каталоге /etc/bind. Основной файл конфигурации - это /etc/bind/named.conf.
Строки include определяют имена файлов, которые содержат DNS опции. Строка directory в файле /etc/bind/named.conf.options говорит DNS где искать файлы. Все файлы, используемые BIND, будут относительными к этому каталогу.
Файл с именем /etc/bind/db.root описывает корневые сервера имен в мире. Сервера со временем меняются, поэтому файл /etc/bind/db.root должен обслуживаться сейчас и потом. Обычно это происходит в качестве обновления к пакету bind9 . Секция zone определяет мастер сервер и она сохранена в файле, определяемой опцией file .
Существует возможность настроить один сервер как кэширующий сервер имен, первичный мастер и вторичный мастер одновременно. Сервер может быть началом авторизации (SOA) для одной зоны, при этом предоставляя вторичный сервис для другой. И при всем этом предоставлять кэширующий сервис в локальной сети (LAN).
Кэширующий сервер имен
По умолчанию конфигурация настраивается на работу кэширующим сервером. Все что для этого требуется - это добавить IP адреса DNS серверов вашего интернет провайдера. Просто раскомментируйте и исправьте следующее в /etc/bind/named.conf.options:
Forwarders { 1.2.3.4; 5.6.7.8; };
Замените 1.2.3.4 и 5.6.7.8 на актуальные IP адреса серверов имен.
Теперь перегружаем DNS сервер для применения новой конфигурации. Наберите в терминале:
Sudo service bind9 restart
Многие администраторы предпочитают использовать дату последнего редактирования в качестве Serial зоны в виде 2012010100, что соответствует формату yyyymmddss (где ss - Serial Number [за день]).
Как только вы произвели изменения в файле зоны, требуется перегрузить BIND9 для применения изменений:
Sudo service bind9 restart
Файл обратной зоны
Теперь, поскольку зона создана и разрешает имена в IP адреса, требуется создать также обратную зону. Обратная зона позволяет DNS определять имя по IP адресу.
Редактируем /etc/bind/named.conf.local и добавляем следующее:
Zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192"; };
Замените 1.168.192 на первые три октета адресов сети, которую вы используете. Также соответственно назовите файл зоны /etc/bind/db.192. В нем должен совпадать первый октет вашей сети.
Теперь создаем файл /etc/bind/db.192:
Sudo cp /etc/bind/db.127 /etc/bind/db.192
; ; BIND reverse data file for local 192.168.1.XXX net ; $TTL 604800 @ IN SOA ns.example.com. root.example.com. (2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800) ; Negative Cache TTL ; @ IN NS ns. 10 IN PTR ns.example.com.
Serial Number в обратной зоне также требуется увеличивать при каждом изменении. Для каждой A записи, которую вы настроите в /etc/bind/db.example.com на другой адрес, вы должны создать запись PTR в /etc/bind/db.192.
После создания файла обратной зоны перегрузите BIND9:
Sudo service bind9 restart
Вторичный мастер
Поскольку первичный мастер настроен, требуется вторичный мастер для того, чтобы поддерживать домен при недоступности первичного мастера.
Для начала на первичном мастере надо разрешить передачу зоны. Добавьте опцию allow-transfer к определениям прямой и обратной зон в /etc/bind/named.conf.local:
Zone "example.com" { type master; file "/etc/bind/db.example.com"; allow-transfer { 192.168.1.11; }; }; zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192"; allow-transfer { 192.168.1.11; }; };
Замените 192.168.1.11 на IP адрес вашего вторичного сервера имен.
Перезапустим BIND9 на первичном мастере:
Zone "example.com" { type slave; file "db.example.com"; masters { 192.168.1.10; }; }; zone "1.168.192.in-addr.arpa" { type slave; file "db.192"; masters { 192.168.1.10; }; };
Замените 192.168.1.10 на IP адрес вашего первичного сервера имен.
Перегружаем BIND9 на вторичном мастере:
Sudo service bind9 restart
В /var/log/syslog вы сможете увидеть нечто похожее на (некоторые строки разделены для соответствия формату документа):
Client 192.168.1.10#39448: received notify for zone "1.168.192.in-addr.arpa" zone 1.168.192.in-addr.arpa/IN: Transfer started. transfer of "100.18.172.in-addr.arpa/IN" from 192.168.1.10#53: connected using 192.168.1.11#37531 zone 1.168.192.in-addr.arpa/IN: transferred serial 5 transfer of "100.18.172.in-addr.arpa/IN" from 192.168.1.10#53: Transfer completed: 1 messages, 6 records, 212 bytes, 0.002 secs (106000 bytes/sec) zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 5) client 192.168.1.10#20329: received notify for zone "example.com" zone example.com/IN: Transfer started. transfer of "example.com/IN" from 192.168.1.10#53: connected using 192.168.1.11#38577 zone example.com/IN: transferred serial 5 transfer of "example.com/IN" from 192.168.1.10#53: Transfer completed: 1 messages, 8 records, 225 bytes, 0.002 secs (112500 bytes/sec)
Обратите внимание, что передача зоны произойдет только если Serial Number на первичном сервере больше значения на вторичном. Если вы хотите, чтобы первичный мастер DNS сообщал вторичному DNS серверу об изменении зоны, вы можете добавить also-notify { ipaddress; }; в /etc/bind/named.conf.local как показано в примере ниже: zone "example.com" { type master; file "/etc/bind/db.example.com"; allow-transfer { 192.168.1.11; }; also-notify { 192.168.1.11; }; }; zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192"; allow-transfer { 192.168.1.11; }; also-notify { 192.168.1.11; }; };
Сегодня мы поговорим о настройке, пожалуй, самого популярного DNS сервера bind9 . Следуйте инструкции, и у Вас всё получится, в этом нет ничего сложного. В этом примере Вы увидите как формируются файлы зон и проследите процесс простой настройки, не вдаваясь при этом в подробности. Это лишь небольшое HowTo , призванное помочь Вам понять принцип работы DNS сервера. Если же Вы настраиваете DNS сервер на шлюзе в сегменте Вашей локальной сети, то в конце статьи Вы увидите как сделать Ваш DNS сервер кэширующим , что позволит существенно сократить время повторного запроса к NS серверам, ведь посещённые адреса будут браться из Вашего локального кэша. Ну что ж, приступим.
Если у Вас ещё не установлен bind9, проделаем это:
Отредактируем файл /etc/init.d/sysklogd, он должен выглядеть следующим образом:
Теперь непосредственно создадим наш файл зоны сайт в той же папке /etc/bind:
1 | $ORIGIN сайт. |
Где 192.168.0.1 — IP Вашего сервера, MX запись нам нужна если Вы поднимаете на своем сервере почтовый сервер. ns1.сайт — наш DNS сервер. Так как для функционирования DNS сервера требуется помимо master ns сервер и slave , прописываем его — ns2.bla-bla-bla.com . Естественно у Вас он должен быть на стороннем сервере, либо если у Вас есть ещё выделенный IP для Вашего сервера, то задача упрощается. Для сервера, находящегося в локальной сети и выдающего имена только в локальную сеть (к примеру у Вас установлен web-сервер, обслуживающий Вашу сеть и настроены виртуальные хосты), достаточно лишь прописать ns1, т.е. адрес Вашего DNS сервера. 2008082859 — смените на текущую дату.
Выставим нужные права на файл зоны сайт :
chown bind:bind /etc/bind/сайт
Отредактируем файл конфигурации bind /etc/bind/named.conf, включив в него конфигурацию для наших зон, добавим в конец файла:
Ну и обновим конфигурацию bind командой:
Если у Вас DNS сервер установлен на шлюзе в Вашей локальной сети, сделаем его кэширующим. Открываем файл /etc/bind/named.conf.options и раскомментируем следующую строку:
forwarders { |
Добавим в неё IP адреса DNS серверов к которым будет обращаться наш сервер, с большой долей вероятности у Вашего провайдера есть свои DNS сервера, укажем их первыми, тем самым экономя трафик:
При настройке на slave сервере myzones.conf примет такой вид:
На этом всё, настройка закончена. ;) Удачи!
