Linux dhcp server windows dns

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

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

Дополнительным плюсом это будет автоматическое создание прямой и обратной DNS зоны, для клиентских устройств локальной сети. Аналогичный процесс используется в сетях под управлением MS Windows в среде Active Directory. Там службы DNS и DHCP тесно интегрированы между собой т.е клиентский ПК подключившись к сети и получивший IP адрес автоматически получает DNS запись вида hostname.domainname.tld это добавляет удобства в случае необходимости подключения по имени а не по IP-который дтуднее запомнить, дополнительным плюсом является создание обратной зоны которая позволяет проводить обратный процесс -разрешение имени по IP, что может быть полезно в случае поиска устройсва если известен его IP адрес, то узнав его имя можно сразу понять о ком идет речь.
Собственно, подобную схему мы и реализуем, основной идеей всего этого будет полная автоматизация данного процесса для IT специалиста т.к. DHCP сервер будет создавать прямую и обратную зоны-автоматически.

Предполагается что:

1) Операционная система Ubuntu 12.04 установлена, хотя на Debian будет также работать ничуть не хуже.
2) Сервер настроен в качестве шлюза по статье: Настройка шлюза локальной сети, на базе Ubuntu 12.04
3) Также на указанном сервере настроена служба DHCP по статье: Настройка DHCP
сервера под управлением Ubuntu 12.04

Первым делом, нам необходимо удалить пакет dnsmasq — который был установлен по статье, Настройка шлюза локальной сети, т.к надобность в нем отпадает, вместо него у нас будет использоваться Bind9.

Поднимаем права до root:

sudo su

aptitude purge dnsmasq

Установка DNS сервера

Установим Bind:

aptitude install bind9

Теперь генерируем ключ, для обновления DNS записей:

dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DHCP_UPDATER

Проверим что у нас получилось:

cat Kdhcp_updater.*.private|grep Key

Нам выдаст нечто подобное (у вас ключ получится другим)

Key: cYqlx8g/jLcIxXFDpqrxZw==

Его нам необходимо записать, т.к. он нам еще пригодится.

Переходим к настройкам Bind9, для начала отредактируем файл name.conf.option:

nano /etc/bind/named.conf.options

Туда добавляем следующие строки:

forwarders {
        8.8.8.8;
     };

    listen-on {
      127.0.0.1;
      192.168.10.1;
    };

Рассмотрим более подробно то что мы написали:

В пункте forwarders мы указали, вышестоящие DNS сервера, куда будет передаваться запрос в случае если информации о запрошенном URL не будет найдено в собственной базе, в нашем случае, это DNS сервер google, но можно указать те которые нужны вам, например DNS сервер вашего провайдера.
В пункте listen-on указываем IP адреса, которые будет обслуживать наш DNS сервер, это localhost и интерфейс по которому подключена наша локальная сеть 192.168.10.1, запросы на другие IP адреса обслуживаться не будут, эту функцию можно рассматривать как дополнительную возможность по снижению нагрузки на наш сервер т.к. запросы из вне-не обслуживаются.

Переходим к редактированию файла name.conf.local:

nano /etc/bind/named.conf.local

Добавми туда следующее:

key DHCP_UPDATER {
        algorithm HMAC-MD5.SIG-ALG.REG.INT;
        secret "cYqlx8g/jLcIxXFDpqrxZw==";
};
 
zone "example.net" IN {
        type master;
        file "/var/lib/bind/forward.db";
        allow-update { key DHCP_UPDATER; };
};
 
zone "10.168.192.in-addr.arpa" IN {
        type master;
        file "/var/lib/bind/reverse.db";
        allow-update { key DHCP_UPDATER; };
};

Рассмотрим написанное, более подробно:

Пункт key DHCP_UPDATER содержит информацию о ключе, который мы генерировали в самом начале.
Пункт zone «example.net»-зона, которую обслуживает наш DNS сервер, в нашем случае example.net (многие советуют использовать зону .local, я этого делать не рекомендую т.к. avahi daemon с данными зонами не работает, да и Microsoft также крайне не рекомендует использовать зону local, в своей, свежей, документации к Windows 2k8 )
Также там описывается тип зоны- master и путь к файлу где будут храниться данные зоны, последний пункт разрешает обновление данного файла, только с использованием ключа.
Пункт zone «10.168.192.in-addr.arpa» отвечает за создание зоны обратного просмотра, назначение остальных пунктов, думаю, вы уже поняли.

Теперь нам необходимо создать сами файлы, в которых будут храниться данные зоны example.net.
Они будут располагаться в /var/lib/bind/ сделано это по одной постой причине-группа bind не имеет права на запись в /etc/bind/, а начинать менять права на системные директории, не очень хорошая идея.

Переходим с созданию файла настроек зоны, для начала, создадим зону прямого просмотра назовем его forward.db:

nano /var/lib/bind/forward.db

С содержимым:

$TTL 86400      ;       1 day
example.net.    IN      SOA     srv01.example.net. admin.example.net. (
                                20110103        ; Serial
                                10800           ; Refresh
                                3600            ; Retry
                                604800          ; Expire
                                86400           ; Minimum TTL
                        )

                IN      NS      srv01.example.net.
                IN      A       192.168.10.1
localhost       IN      A       127.0.0.1
srv01           IN      A       192.168.10.1

Из содержимого понятно что наша зона example.net, в которой присутствует DNS сервер (он же шлюз) с именем srv01, который имеет IP адрес 192.168.10.1. Других записей делать не будем т.к. их будет добавлять DHCP сервер автоматически.
Если вдруг вам понадобится создать запись в ручную, то достаточно добавить строку с именем и IP адресом узла локальной сети.

Теперь создадим файл зоны обратного просмотра, чтобы не выдумывать ничего, назовем его reverse.db

nano /var/lib/bind/reverse.db

С содержимым:

$TTL 86400      ;       1 day
10.168.192.in-addr.arpa. IN SOA srv01.example.net. admin.example.net. (
                        20110104        ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        3600 )          ; Minimum

        IN      NS      srv01.example.net.
1       IN      PTR     example.net.
1       IN      PTR     srv01.example.net.

Выходим и перезапускам bind

/etc/init.d/bind9 restart

Теперь нам необходимо проверь работоспособность нашего сервера локально.
Проблема заключается в том что наш сервер по умолчанию использует DNS настройки которого по получил по сети и соответственно он ничего не знает о локальном DNS сервере, которые крутится на нем же-это нам необходимо исправить.
Если мы полезем, править resolv.conf то в Ubuntu 12.04 нас поджидает большой сюрприз в виде надписи:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND — YOUR CHANGES WILL BE OVERWRITTEN

Которая говорит нам о том что: resolv.conf нельзя редактировать и что он создается динамически, а все внесенные в него изменения будут перезаписаны!
В общем его править нельзя, мы будем править сам шаблон этого файла, который находится в /etc/resolvconf/resolv.conf.d/ нас интересует файл head, вот его мы и будем править:

nano /etc/resolvconf/resolv.conf.d/head

Добавляем в него:

domain example.net
search example.net
nameserver 127.0.0.1

Более опытные уже догадались что это ничто иное как DNS суффикс и домен для поиска по умолчанию, а также IP адрес локального DNS сервера.
У данной схемы есть еще одно преимущество- если настройки сети получаются нашим шлюзом от DHCP сервера провайдера, то DNS сервер провайдера добавляется в конце списка, после строки nameserver 127.0.0.1, таким образом, наш локальный DNS всегда является приоритетным, а в случае выхода его из строя, запросы начинают идти к DNS провайдера, автоматически!
Перезапустим сеть:

/etc/init.d/networking restart

Пробуем определить наш DNS сервер:

dig srv01

В ответ получаем нечто подобное:

; <<>> DiG 9.8.1-P1 <<>> srv01
;; global options: +cmd
;; Got answer:
;; ->>HEADER<< — opcode: QUERY, status: NXDOMAIN, id: 56977
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;srv01. IN A

;; AUTHORITY SECTION:
. 812 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2012080300 1800 900 604800 86400

;; Query time: 44 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 3 13:28:45 2012
;; MSG SIZE rcvd: 98

Значит ответы присылаются, это хорошо.
Проверим самоопределение имени нашего сервера:

nslookup srv01

В ответ получим

Server: 127.0.0.1
Address: 127.0.0.1#53

Name: srv01.example.net
Address: 192.168.10.1

Эту операцию, также, можно выполнить и через host, сделав запрос вида:

host srv01

Если имя преобразовано в IP значит зона прямого просмотра работает нормально.
Теперь проверим зону обратного просмотра:

nslookup 192.168.10.1

Нам выдаст:

Server: 127.0.0.1
Address: 127.0.0.1#53

1.10.168.192.in-addr.arpa name = srv01.example.net.
1.10.168.192.in-addr.arpa name = example.net.

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

Настраиваем динамическое обновление зон DHCP сервером.

Если вы настраивали DHCP сервер, по моему руководству, ссылка на которое есть в начале этой статьи, то у вас в конфигурационном файл должна присутствовать запись:

subnet 192.168.10.0 netmask 255.255.255.0 {
range 192.168.10.10 192.168.10.254;
option domain-name-servers 192.168.10.1;
option domain-name "example.net";
option routers 192.168.10.1;
option broadcast-address 192.168.10.255;
default-lease-time 604800;
max-lease-time 604800;
}

Мы ее немного подправим, а именно заменим option domain-name на example.net
перед диапазоном адресов нашего DHCP сервера, добавляем следующее:

nano /etc/dhcp/dhcpd.conf

За одно добавим строку update-static-leases on; которая отвечает за автоматическое создание прямой и обратной зоны для клиентов с зарезервированным IP, без нее записи придется создавать в ручную, а мы этот процесс автоматизируем.

ddns-update-style interim;
update-static-leases    on; 
key DHCP_UPDATER {
algorithm hmac-md5;
secret "cYqlx8g/jLcIxXFDpqrxZw==";
}
 
zone example.net. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
 
zone 10.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
}

В результате всех действий, у вас должен получиться конфигурационный файл вида:

ddns-update-style interim;
update-static-leases    on;
key DHCP_UPDATER {
algorithm hmac-md5;
secret "cYqlx8g/jLcIxXFDpqrxZw==";
}
 
zone example.net. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
 
zone 10.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
}

subnet 192.168.10.0 netmask 255.255.255.0 {
range 192.168.10.10 192.168.10.254;
option domain-name-servers 192.168.10.1;
option domain-name "example.net";
option routers 192.168.10.1;
option broadcast-address 192.168.10.255;
default-lease-time 604800;
max-lease-time 604800;
}

Остальные настройки, оставляем как они были представлены в руководстве по настройке DHCP сервера.

Перезапустим DNS и DHCP сервер:

/etc/init.d/bind9 restart
/etc/init.d/isc-dhcp-server restart

Подключаем наш клиентский ПК к локальной сети, предположим что его имя test01 он получит IP от нашего DHCP сервера, а DHCP сервер создаст DNS запись вида test01.example.net.
Пробуем выполнить запрос по имени

nslookup test01

нам должен возвращаться IP адрес который получила клиентская машина от DHCP сервера.
Ну и преобразование IP адреса в имя, также должно работать.
Во время работы данной связки, у нас будут создаваться файлы в директории /var/lib/bind с расширением .jnl, они создаются автоматически, создавать или удалять их не нужно.
Выглядеть это будет так как на скриншоте:

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