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-сервера BIND для нужд подходящих малой организации или небольшого провайдера.
1. Файл конфигурации BIND named.conf:
Расположение файла настройки BIND
может меняться в зависимости от ОС. К примеру во FreeBSD он хранится в /etc/namedb/named.conf. Chroot-директория: /var/named/.
# Ключ идентификации.
key "rndckey" {
algorithm hmac-md5;
secret "945Gа8BNiQ+NvPeklas+Bu==";
};options {
# Указываем какие IPv6-адреса будет слушать сервер. В данном примере “none;” – не слушать IPv6.
listen-on-v6 { none; };
# Указываем какие IPv4-адреса будет слушать сервер.
# 127.0.0.1 – Loopback
# 192.168.0.1 – Интерфейс локальной сети. На него будут обращаться локальные клиенты.
# 100.100.100.100 – Внешний интерфейс. На нем будут обрабатываться запросы из глобальной сети.
listen-on port 53 { 127.0.0.1; 192.168.0.1; 100.100.100.100; };
# Какие запросы обрабатывать. В данном примере “any;” – обрабатываются любые запросы.
# При необходимости можно указать сети или конкретные узлы чьи запросы допускается обрабатывать. К примеру указав “192.168.0.1/24; 127.0.0.1;” мы разрешили бы обвечать клиентам только из подсети 192.168.0.1/24 и себе серез loopback интерфейс.
allow-query { any; };
# Куда переадресовывать запросы. При необходимости можно переадресовать запросы к DNS серверу своего провайдера к примеру для экономии трафика. В данном примере используется только в корневой зоне.
forwarders { };
# Запрещаем изменение (обновление) таблиц зон.
allow-update { none; };
# Дополнительные параметры. Расположение рабочей директории, PID-файла, дамп файла и файла статистики. При необходимости можно изменить. Все пути относительно Chroot-директории.
directory “/etc/namedb”;
pid-file “/var/run/named/pid”;
dump-file “/var/dump/named_dump.db”;
statistics-file “/var/stats/named.stats”;
# Скрываем версию нашего BIND сервера.
version “0”;
};# Access Control List – списки контроля доступа
# ACL “user” – наши локальные клиенты.
acl “user” { 192.168.0.0/24; 127.0.0.1; };
# ACL “inet” – все те, кто не входит в ACL “user”
acl “inet” { !user; };# View – представления
# Мы будем использовать ACL для разграничения доступа к разным представлениям.# View “all” – представление для всех запросов.
view “all” {
# Указываем, что данное представление только для всех клиентов.
match-clients { any; };
# Запрещаем рекурсивные запросы.
recursion no;# Мастер зона test.com
zone “test.com” {
# Тип зоны “slave” – это вторичный DNS сервер для доменной зоны “test.com”.
# Можно использовать “stub”. В этом случае таблицы зон храниться не будут (будут храниться только NS записи), а запросы будут перенаправляться на объявленные DNS сервера.
type slave;
# Файл таблицы зоны.
file “slave/test.com.hosts”;
# Указываем первичный DNS сервер доменной зоны “test.com”.
masters { 100.100.100.201; };
};# DynDNS зона dyn.example.com.
zone “dyn.example.com” {
# Тип зоны “master” – это первичный DNS сервер для этой доменной зоны.
type master;
file “dynamic/dyn.example.com.hosts”;
# Разрешаем изменение (обновление) таблицы зон по ключу.
allow-update { key “rndckey”; };
};# Обратная зона для глобальной подсети “100.100.100.100/24”.
zone “100.100.in-addr.arpa” {
type master;
file “master/100.100.rev.hosts”;
};
}# View “user” – представление для наших локальных клиентов.
view “user” {
# Указываем, что данное представление только для клиентов входящих в ACL “user”
match-clients { user; };
# Разрешаем локальным клиентам рекурсивные запросы.
recursion yes;# Описываем зоны для View “user”
# Зона “localhost”.
zone “localhost” in {
type master;
file “master/localhost.hosts”;
};# Мастер зона example.com.
zone “example.com” {
type master;
file “master/user/example.com.hosts”;
};# Обратная зона для локальной подсети “192.168.0.0/24”.
zone “0.168.192.in-addr.arpa” {
type master;
file “master/user/192.168.0.rev.hosts”;
};# Обратная зона для “localhost”.
zone “0.0.127.in-addr.arpa” {
type master;
file “master/127.0.0.rev.hosts”;
};# Корневая зона DNS.
zone “.” {
# Тип зоны “hint” – кеширующий сервер. Не хранит никаких таблиц зон.
type hint;
file “named.root”;
# Переадресовываем запросы на DNS сервер провайдера (100.100.100.201 – DNS сервер провайдера).
forwarders { 100.100.100.201; };
};
};# View “inet” – представление для запросов из глобальной сети.
view “inet” {
match-clients { inet; };
# Запрешаем рекурсивные запросы.
recursion no;
notify no;# Мастер зона example.com.
zone “example.com” {
type master;
file “master/inet/example.com.hosts”;
};
};2. Таблица зоны example.com для представления «user»:
$ttl 38400
2011101101 ; Serial - серийный номер зоны в формате YYYYMMDDNN.
; YYYY - год, MM - месяц, DD - день, NN - порядковый номер изменения таблицы за текущий день.
10800 ; Refresh - Время указывающее, как часто необходимо проверять таблицу мастер сервера на необходимость сделать update.
3600 ; Retry - время указывающее, как скоро делать повторную попытку при неудачном соединении с мастер сервером.
604800 ; Expiry - время устаревания таблицы, по истечению этого времени таблица считается устаревшей и считывается заново.
38400 ; TTL - время указывающее, как долго хранить таблицу в кеше. По истечению этого времени сервер перечитывает таблицу заново.
); Указываем Name-сервера данной зоны.
example.com. IN NS ns.example.com.
; “прямая” (преобразует имя в адрес) запись.
ns.example.com. IN A 100.100.100.100
# “почтовая” (указывает на почтовые серверы домена) запись. 10 – очередность.
; Используем локальные адреса для прямой записи хоста example.com.
example.com. IN A 192.168.0.2
sip.example.com. IN A 192.168.0.3
mx.example.com. IN A 192.168.0.4; Указываем что www.example.com это синоним example.com
www.example.com IN CNAME example.com.; Указываем расположение сервисов на примере SIP телефонии.
; _sip._udp – тип сервиса;
; SRV – тип записи;
; 0 – приоритет записи;
; 0 – нагрузка которую могут обработать системы (не обязательный параметр);
; 5060 – номер порта, по которому SIP сервер принимает запросы;
; sip.example.com – имя хоста SIP сервера.Sip._udp.sip.example.com. SRV 0 0 5060 sip.example.com.
3. Таблицы зоны example.com для представления «inet» (внешние клиенты к SIP телефонии доступа не имеют)
$ttl 38400
example.com. IN SOA ns.example.com. root.example.com. (
2011101101 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expiry
38400 ; TTL
)example.com. IN NS ns.example.com.
example.com. IN NS ns.r01.ru.
example.com. IN MX 10 mx.example.com.ns.example.com. IN A 100.100.100.100
; Используем внешние адреса для прямой записи хоста example.com.
example.com. IN A 100.100.100.101
mx.example.com. IN A 100.100.100.102www.example.com IN CNAME example.com.
4. Таблица обратных зон для локальной подсети «192.168.0.0/24»
$ttl 38400
0.168.192.in-addr.arpa. IN SOA ns.example.com. root.example.com. (
2011101101 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expiry
38400 ; TTL
0.168.192.in-addr.arpa. IN NS ns.example.com.
; "обратная" запись (преобразует адрес в имя)
1.0.168.192.in-addr.arpa. IN PTR ns.example.com.
2.0.168.192.in-addr.arpa. IN PTR www.example.com
3.0.168.192.in-addr.arpa. IN PTR sip.example.com.
4.0.168.192.in-addr.arpa. IN PTR mx.example.com.Заключение
Остальные таблицы зон, создаются аналогично представленным в примере.
И в заключении хотелось бы сказать: «Это легче, чем кажется на первый взгляд» . Настройка BIND завершена.Список используемых источников:
subnets.ru/blog/?p=38
dlc.sun.com/osol/docs/content/SYSADV5/dnsref-13.html
sshd.su/pages/viewpage.action?pageId=5210143
ulsu-is.narod.ru/lab08.htm
Сегодня невозможно представить себе интернет без DNS. Однако многие администраторы не уделяют время настройке этой службы на своих серверах, поэтому не используют всю ее мощь даже на треть.
Итак, планы на сегодня!
- Настройка зоны мастер.
- Подключение зон в слейве.
- Каждому свое. Настраиваем параметры в зависимости от адреса клиента, с которого пришел запрос.
- Подключаем внешний DNS-фильтр.
Интро
Когда я устроился на работу, количество сервисов в нашей сети можно было пересчитать по пальцам одной руки. Время шло, число сервисов росло. Обслуживающий DNS-сервер был один и выступал мастером для одной зоны (назовем ее xak.ru). Все остальные запросы он просто пересылал на DNS-сервер Google (8.8.8.8). А, чуть не забыл добавить: сервер этот был виртуальным. Потом в один прекрасный день сервер рухнул физически. После замены систему подняли, виртуализацию прикрутили. Поставили свежеустановленный Debian и к нему BIND 9. Присвоили тот же IP, что был у DNS-сервера до падения. Настройки восстановили из бэкапа. После успешного старта стали думать, как «закручивать болты».
Параллельно с этой работой был установлен хостинг, который держал на себе зону (например) xaker.ru. Само собой, центральный DNS должен о ней знать, а еще лучше быть slave DNS-сервером для этой зоны. Далее возникла необходимость перенаправлять DNS-запросы от центрального сервера к редиректору в зависимости от того, из какой сети пришел запрос. Делалось это ради подключения внешних DNS-фильтров, но не для всех. А только для тех, кому надо, а именно образовательных городских сетей - территории образовательных учреждений! Обо всем этом и пойдет речь ниже.
Немного теории
Если хочешь познакомиться с «новым» BIND, то рекомендую к чтению . В двух словах: версия 9 была последней, с 10-й версии права передают сообществу, и это ПО ныне известно как Bundy.
Быстрая установка, или еще раз об одном и том же
Итак, как установить BIND 9 в Debian/Ubuntu, в Сети очень и очень много материала. Так что быстро пройдемся по этому пункту, не вдаваясь в подробности. Для начала необходимо установить BIND 9 в систему. Для пользователей MS Windows есть версия BIND 9 под их платформу.
$ sudo apt install bind9
Для других дистрибутивов руководств по сборке из исходных кодов на просторах Сети предостаточно, забирай быстрее, переписывай в блокноты, пока новый «суперполезный» закон не накрыл весь интернет или пока тебя не отругали за то, что ты ходишь или ходил на сайт с запрещенной литературой. 😉
После установки переходим в каталог /etc/bind9/ и видим там основной файл конфигурации named.conf , внутри подключены остальные файлы named.conf.* . Как настраивать мастер-зону, опустим, поскольку в Сети информация изложена очень подробно. Добавим в файл named.conf строку
Include "/etc/bind/named.conf.acl";
чем подключим новый файл в конфиг для правил подсетей. Далее создаем файл /etc/bind/named.conf.acl и добавляем правила:
Acl "lan" { 192.168.181.0/24; }; acl "do" { 10.0.0.0/24; 192.168.253.0/24; }; acl "srv" { 192.168.254.0/24; }; acl "alls" { 10.10.0.0/16; }; acl "dou" { 192.168.201.0/24; 192.168.202.0/24; 192.168.203.0/24; 192.168.204.0/24; 192.168.205.0/24; }; acl "school" { 172.16.0.0/24; };
Здесь мы разделили сети на группы для дальнейшей обработки. Прежде чем продолжим, уточню один момент. Для корректной обработки зон необходимо в каждую группу правил добавлять все зоны. Можно это делать в одном файле или вынести настройки зоны в отдельный файл и потом просто подключать в нужных местах. Итак, в файл /etc/bind/named.conf.local вносим изменения:
View "edu" { match-clients { school; }; recursion yes; allow-query { school; }; forwarders { 77.88.8.7; }; zone "xaker.ru" { type master; file "/etc/bind/xaker.ru_loc"; }; zone "254.168.192.in-addr.arpa." { type master; file "/etc/bind/xaker.rev"; }; zone "zone2.ru" { type slave; file "/etc/bind/db.zone2.ru"; masters { 192.168.254.5; }; }; };
Здесь мы обозначаем группу, с которой будет работать BIND. Добавляем сюда клиенты из правил, которые мы определили выше. Назначаем вышестоящий сервер, на который будут пересылаться запросы, пришедшие из сетей, согласно описанным правилам. Здесь это единственная группа адресов School. В качестве вышестоящего DNS задал DNS-сервер Яндекс, который фильтрует «плохой» контент. Можно аналогично использовать другие DNS-сервисы, такие как SkyDNS.
Продолжение доступно только подписчикам
Вариант 1. Оформи подписку на «Хакер», чтобы читать все материалы на сайте
Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов.
В сети очень много статей на тему установки и настройки DNS-сервера Bind9. Они разные. Некоторые написаны просто и доступно, но нет пояснений зачем и почему. В других материал подан очень подробно, но новичкам такой материал осилить сложно. Я же попытаюсь совместить достоинства способов подачи материала, нащупать ту золотую середину, которая подойден большинству. Но опять таки, я не претендую на истину в последней инстанции и готов принять конструктивную критику.
Итак, вступление закончено, приступим к самой статье. Я как приверженнец Debian, буду описывать процесс установки и настройки именно на этой ОС. Дано Debian 8 «Jessie» установленный вот с такими параметрами (Ну разве кроме пункта web server
, он пригодится тем, кто в дальнейшем будет работать с веб-сервером Apache):
Настройки сети:
Теперь необходимо настроить файл конфигурации Bind9:
Расшифровка:
acl - создает ACL (Access control list
) - так называемый список контроля доступа, с помощью которого мы ограничиваем диапазон адресов которые могут запрашивать зоны с нашего сервера. В данном примере это разрешено подсети 192.168.1.0/24 . и локальному хосту .
allow-query { mynetwork; }; - список тех, кто имеет право запрашивать информацию. Можно ограничить с помошью acl
либо установить allow-query { any; }; - что будет означать, что запросы разрешенмы всем.
forwarders {192.168.1.1; 8.8.8.8; }; - это DNS провайдера, или любые другие, у которых можно получить информацию о доменах неизвестных вашему серверу.
listen-on-v6 { none; } - запрещает работать с IPv6.
Настройка зон
Для начала покорректируем файл локальной конфигурации Bind9:
| 1 | vim /etc/bind/named.conf.local |
Этот файл содержит локальную конфигурацию DNS-сервера, в нем объявляются зоны, связанные с доменами этого сервера. Добавляем в него файлы наших зон (зону прямого просмотра и зону обратного просмотра):
Со следующим содержимым:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | ; ; Зона прямого просмотра ; $TTL 30 $ORIGIN nixway.loc. @ IN SOA ns1.nixway.loc. admin.nixway.loc. ( 2015050101 ; Serial 1d ; Refresh 1h ; Retry 1w ; Expire 2h ; Negative Cache TTL ) @ IN NS ns1.nixway.loc. @ IN NS ns.provider.org. @ IN A 192.168.1.10 ns1 IN A 192.168.1.10 nixway.loc IN A 192.168.1.10 www IN CNAME nixway.loc. |
В конце этого файла нужно обязательно оставить пустую строку!
Расшифровка:
$ORIGIN - оригинальное имя зоны
ns1.nixway.loc. - Наш DNS-сервер (точка в конце обязательна).
admin.nixway.loc. - email администратора сервера, где вместо символа @ используется точка.
Serial - серийный номер зоны в формате ГГГГММДД и номер текущего изменения за этот день. (Важно, при каждом изменении, нужно редактировать этот номер увеличивая его в большую сторону) Пример: 2015020301.
Refresh - период времени с которым вторичный сервер днс обращается к основному.
Retry - период с которым вторичный сервер будет повторять попытки при неудачном обновлении.
Expire - максимальное время использования данных на вторичном сервере, после которого делается обязательное обновление.
Negative Cache TTL - время актуальности данных в кэше запросов.
Зона обратного просмотра
Зона обратного просмотра, выполняет преобразование IP-адреса в доменное имя. Создадим файл для зоны обратного просмотра:
В этом файле должны быть только записи типа PTR . В конце этого файла так же должна быть пустая строка. Число 10 - это последний октет в IP адресе нашего сервера.
Например, можно добавить в файл зоны прямого просмотра строку:
Тогда по адресу router.nixway.loc в браузере будет открываться web-интерфейс роутера (эквивалентно 192.168.1.1 ), но только внутри локальной сети.
Сегодня поговорим о создании локальной доменной зоны внутри локальной сети. Для чего нужна локальная доменная зона и DNS-сервер? Чтобы расшарить (сделать доступными) свои локальные сайты для всех пользователей сети.
Я создам сеть, где все устройства моей локальной сети смогут пользоваться ресурсами формата site.lan. В моем случае устройства локальной сети подключаются к интернету через роутер. Серверная машина - на Linux Mint (desktop), клиенты: ПК под управлением Windows, Linux, телевизор со Smart TV, а также смартфоны и планшет. Для начала убедитесь, что в роутере для сервера (машины, на которой будет установлен DNS сервер) зарезервирован статический внутренний IP адрес. Это очень важно, чтобы потом указать всем сетевым устройствам, где именно находится наш DNS сервер.
Установка DNS неймсервера:
Для начала необходимо установить пакет Bind:
Sudo apt-get install bind
Кроме того, для нормальной работы веб-сайтов нам потребуется LAMP (Linux Apache MySQL PHP). О том как установить LAMP в Ubuntu читайте в моей статье . А также по ссылке внизу статьи можете настроить локальный сайт. Единственное, что не прописывайте в /etc/hosts адрес сайта, т.к. этими вопросами будет заниматься неймсервер. На этом этап подготовки окончен.
Настройка Bind
Входим в директорию Bind и делаем резервные копии конфигурируемых файлов:
Cd /etc/bind/ cp named.conf.local named.conf.local.back cp named.conf.options named.conf.options.back
Создаём локальную доменную зону.lan:
Nano named.conf.local
И дописываем в конец файла следующие строки:
Zone "lan" { type master; file "/etc/bind/db.lan"; };
Теперь создаем соответствующий файл для доменной зоны.lan и открываем его на редактирование:
Touch db.lan nano db.lan
Наполняем его содержимым:
@ IN SOA lan. root.lan. (201605019 ;Serial 4h 1h 1w 1d @ IN NS ns1.lan. @ IN A 192.168.0.100 ns1 IN A 192.168.0.100 slicks IN A 192.168.0.100 site IN A 192.168.0.100 * IN CNAME @
Обратите внимание на Serial 201605019. Это значение нужно увеличивать каждый раз при редактировании файла доменной зоны. Я пишу YY-MM-DD + наращиваю порядковый номер на 1. 192.168.0.100 - IP адрес сервера. Запись формата "slicks IN A" означает, что в зоне.lan существует доменное имя slicks и что этот сайт расположен по IP адресу 192.168.0.100. В apache2 создан, соответственно веб-сайт с ServerName slicks.lan . Если бы сайт располагался на ином IP, чем DNS сервер, то запись бы имела вид slicks IN A _IP-ПК-с-сайтом_ Редактируем named.conf.options :
Nano named.conf.options
В него нужно дописать выделенные строки:
Acl "home" {192.168.0.0/24; 127.0.0.1;}; options { directory "/var/cache/bind"; dnssec-validation auto; allow-recursion {127.0.0.1/32; 192.168.0.0/24; 192.168.1.0/24; }; allow-transfer { none; }; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { none; }; allow-query {"home";}; };
Первая строка создаёт локальную DNS группу home, с диапазоном IP адресов от 192.168.0.0 до 192.168.0.255, а также 127.0.0.1. Вторая добавляемая строка содержит параметр allow-query (разрешить запросы) и мы указываем, что нужно разрешить запросы от группы home. С конфигурацией закончили, можем перезапустить сервер
Sudo /etc/init.d/bind9 restart
Указываем локальный DNS в роутере
Чтобы не было нужды редактировать сетевое подключение на каждом клиенте и вручную прописывать DNS-сервер, мы можем указать IP локального DNS в настройках маршрутизатора. И все запросы пользователей сети будут отправляться последним сперва на локальный DNS, а потом уже уходить в Интернет. У меня:
- Модель роутера: Dir-615;
- Internet Connection Type: Dynamic IP (DHCP);
Для указания локального DNS сервера в моем случае я вхожу в Setup -> Network Settings -> Manual Internet Connection Setup и в поле Primary DNS Address прописываю IP адрес сервера локальной доменной зоны 192.168.0.100, он же будет теперь выступать основным DNS сервером в локальной сети. А в качестве Secondary DNS адреса пишем 8.8.8.8. Это адреса DNS Google. На скрине у меня Primary и Secondary DNS адреса ведут на мой сервер. Почему-то вначале казалось, что роутер не перенаправлял запросы на мой DNS и прописал так. Вторым DNS лучше указать гугловский сервер, чтобы в случае если локальный сервер 192.168.0.100 будет выключен - не пропадал интернет у всех остальных устройств!
Проверка работоспособности
Запускаю клиентский ПК под управлением Windows Xp и тестирую подключение. Первым делом нужно очистить DNS кеш. Заходим в командндую строку виндовс и пишем:
Ipconfig /flushdns
1. Теперь уже проверяю видимость в сети сервера DNS, ping 192.168.0.100 :
C:\\Documents and Settings\\www>ping 192.168.0.100 Обмен пакетами с 192.168.0.100 по 32 байт: Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Статистика Ping для 192.168.0.100: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь), Приблизительное время приема-передачи в мс: Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
Проверяю локальный сайт: nslookup slicks.lan :
C:\\Documents and Settings\\www>nslookup slicks.lan *** Can"t find server name for address 192.168.0.1: Non-existent domain *** Default servers are not available Server: UnKnown Address: 192.168.0.1 Name: slicks.lan Address: 192.168.0.100
ping slicks.lan :
C:\\Documents and Settings\\www>ping slicks.lan Обмен пакетами с slicks.lan по 32 байт: Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Статистика Ping для 192.168.0.100: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь), Приблизительное время приема-передачи в мс: Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
Наслаждаемся результатами!
