Linux dhcp server windows dns server

Can I run a Ubuntu and Windows DHCP / DNS Server together in the same network?

I am just wondering if I can run both windows and Ubuntu DHCP/DNS Server in the same LAN. The Present configuration is Windows 2003 Server AD and Ubuntu DHCP n DNS Server with BINDS. I have proposed to upgrade AD to 2008R2 and wanted to have fail over and was wondering «What IF» Scenario for DCHP and DNS. Any thoughts and insights are much appreciated Thanks

As you’re a reputation 6 user: If one of the answers below helped you, don’t forget to click the grey ☑ at the left of its text, which means Yes, this answer is valid! 😉

2 Answers 2

I will give you some thoughts and some links for further reading. Take them with several grains of salt.

DHCP

It is possible to run multiple DHCP servers on the same LAN. However they must not serve the same address pool. Reason is that DHCP is first-come-first-serve. If both machines hand out the same pool, there is a good chance to assign IPs twice.

The easiest way is to split the scope. Say, one server hands out addresses 192.168.0.1-129 and the other 192.168.0.130-254 . This way no inconsistencies can arise. This is sort of the «cheap» failover way.

The proper failover method would be, if the servers are aware of each other, so that in the event that one becomes unavailable, the other jumps in. For that to work however, they both need to share a lease-file; the failover partner needs to be aware of which IPs the other one handed out before failure. As far as I know this was introduced as late as Windows Server 2012. The common ISC DHCP server supports this readily; I have seen this in action.

Unfortunately I don’t think there is a way to achieve this sort of failover in a heterogeneous environment.

In principle it is no problem running multiple DNS servers. DNS intrinsically supports replication by assigning master/slave roles.

However with ActiveDirectory things become more complex, as AD relies on DDNS updates from the DHCP. I have now read quite some opinions about this topic ranging from «Not a problem» to «huge clusterfuck». See the links below.

It seems to be no problem to substitute BIND9 for Windows DNS in an AD environment. It also seems to be fine, to run BIND as a secondary along the primary Windows DNS. What I’m really skeptical about is, if they both serve DHCP too. I imagine DDNS will not work flawlessly, though dynamic updates of Windows DNS from ISC DHCP seem possible.

Further reading:

• This excellent post on Serverfault about multiple DHCP.
• https://serverfault.com/questions/561449/how-can-i-use-a-linux-bind-dns-server-for-my-active-directory-forest
• https://serverfault.com/questions/6273/how-can-i-get-bind-and-microsoft-dns-to-work-together-well
• http://ubuntuforums.org/showthread.php?t=2110181
• http://www.serverlab.ca/tutorials/linux/network-services/using-linux-bind-dns-servers-for-active-directory-domains/
• https://superuser.com/questions/247560/linux-dns-for-windows-domain
• https://arstechnica.co.uk/civis/viewtopic.php?f=21&t=1135491
• https://www.safaribooksonline.com/library/view/active-directory-cookbook/0596004648/ch18s12.html

Источник

Записки IT специалиста

Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи ISC DHCP

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

В рамках данной статьи мы будем подразумевать, что у вас уже есть настроенные и нормально функционирующие BIND 9 и ISC DHCP и будем в дальнейшем опираться на конфигурации, описанные в статьях:

Перед тем, как продолжать настройку рекомендуем внимательно с ними ознакомиться на предмет расположения файлов и настроек. Все инструкции актуальны для текущих выпусков операционных систем Debian и Ubuntu.

Общая схема сети

Чтобы вам было легче ориентироваться в адресах и настройках мы привели ниже общую схему сети. В ней мы будем использовать диапазон адресов 192.168.72.0/24 и домен interface31.lab. В данной сети у нас развернуты отказоустойчивые конфигурации DNS и DHCP, и мы добавили на схему все важные узлы.

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

Настройка первичного DNS-сервера BIND 9

Прежде всего убедимся, что файлы зоны находятся в /var/lib/bind, это важно, так как AppArmor блокирует для службы named возможность записи в другие расположения. Если это не так, то просто скопируйте файлы зон в /var/lib/bind.

Затем откроем файл /etc/bind/named.conf.local и в самом начале добавим строку:

Она указывает на RNDC-ключ, который нужен для проверки подлинности серверов, имеющих право вносить изменения в зону, данный ключ создается автоматически при установке BIND.

Теперь приведем описания зон к следующему виду. Для прямой:

zone "interface31.lab" type master; 
file "/var/lib/bind/db.interface31.lab"; 
allow-transfer < 192.168.72.9; >; 
allow-update < key rndc-key; >;
>;

zone "72.168.192.in-addr.arpa" type master; 
file "/var/lib/bind/db.192.168.72"; 
allow-transfer < 192.168.72.9; >; 
allow-update < key rndc-key; >;
>;

Обращаем внимание на опцию allow-update, которая разрешает обновлять зоны предъявителю RNDC-ключа и опцию file, которая обязательно должна указывать на расположение файлов зон в /var/lib/bind.

Проверяем отсутствие ошибок в конфигурации:

И перезапускаем службу DNS-сервера:

Более никаких настроек DNS-сервера не требуется.

Настройка DHCP-серверов ISC DHCP

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

Прежде всего скопируем с первичного DNS-сервера файл RNDC-ключа /etc/bind/rndc.key и поместим его в /etc/dhcp, затем установим на него следующие права:

chown root:root /etc/dhcp/rndc.key
chmod 640 /etc/dhcp/rndc.key

После этого откроем /etc/dhcp/dhcpd.conf и найдем в нем опцию ddns-update-style, которую заменим следующим блоком:

ddns-updates on;
ddns-update-style interim;
ignore client-updates;
update-static-leases on;

Данные опции включают динамическое обновление DNS и предписывают делать это в том числе и для статических записей. Это общие настройки сервера, сохраняем изменения и входим.

Теперь будем настраивать непосредственно область, настройки которой в нашем случае хранятся в файле /etc/dhcp/dhcpd.d/subnet.conf. Прежде всего добавим в самое его начало строки:

include "/etc/dhcp/rndc.key";

zone interface31.lab. primary 192.168.72.8; 
key rndc-key;
>

zone 72.168.192.in-addr.arpa. primary 192.168.72.8; 
key rndc-key;
>

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

Ниже, в секцию subnet добавляем следующие опции:

option domain-name "interface31.lab"; 
option domain-search "interface31.lab";

Проверяем конфигурацию на ошибки:

dhcpd -t -cf /etc/dhcp/dhcpd.conf

И перезапускаем DHCP-сервер:

systemctl restart isc-dhcp-server

Затем выполняем аналогичные настройки на втором сервере.

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

Либо с явным указанием DNS-сервера, которому направляем запрос:

 nslookup WIN10LAB 192.168.72.9

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Регистрация Linux в DNS Windows 2008 R2

При необходимости иметь AD, службы DNS и DHCP проще использовать стандартные в поставке Windows Server. Практически не нуждается в настройке, разве что авторизацию DHCP в DNS включить. А автоматическая регистрация хостов работает «из коробки».

Однако Linux машины обслуживаемые тем же DHCP, что и Windows машины, автоматически не регистрируются в DNS. Да и в DHCP имя хоста пустое.

В случае с Debian, решение проблемы не сложное, скорее всего в других дистрибутивах действия будут аналогичными.

Настройка Dibian

В /etc/dhcp/dhclient.conf добавить строку:

send host-name «hostname«;

где hostname — имя Linux хоста

Или автоматически получить имя хоста:

send host-name = gethostname();

Согласно man’у имя может как содержать имя домена, так и не содержать его, с рекомендацией указывать только имя машины, без домена.

option host-name string;
This option specifies the name of the client. The name may or may not be qualified with the local domain name (it is preferable to use the domain-name option to specify the domain name). See RFC 1035 for character set restrictions. This option is only honored by dhclient-script(8) if the hostname for the client machine is not set.

Этим мы заставим DHCP Client при запросе IP адреса передавать имя хоста. Этого более чем достаточно, чтобы в оснастке DHCP сервера появилось полное доменное имя хоста. Мне лишь не понятно, почему указание имени машины при DHCP запросах не является настройкой по-умолчанию, ну да ладно.

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

Настройка Windows Server

В оснастке DHCP сервера уже видно полное доменное имя хоста, который мы настраиваем.

Но в DNS новых записей не появилось, хотя DHCP настроен на обновление DNS (я надеюсь, что вы выполнили эту настройку еще когда поднимали AD, впрочем это не сложно сделать и в любое другое время).

Тут есть два пути. Либо разрешить Nonsecure Dynamic Updates для доменной зоны, либо попросить DHCP сервер обновить DNS. Второй вариант мне кажется более безопасным, а для его настройки нужно поставить аж одну галочку.

В свойствах DHCP сервера, или более локально, в свойствах Scope, на закладке DNS включите:

Dynamically update DNS A and PTR records for DHCP clients that do not request updates (for example, clients running Windows NT 4.0).

На этом всё. При следующем запросе IP адреса у DHCP произойдет регистрация в Windows DNS.

Источник