Linux update dynamic dns

Безопасное динамическое обновление записей на MS DNS из Linux

В процессе настройки клиентов службы AD под управлением ОС Ubuntu Linux, я столкнулся с несвоевременным обновлением записей на DNS сервере средствами Samba, а также с некорректной работой команды «net ads dns register». Что вызывает сопуствующие проблемы при работе с доменными компьютерами.

Например, наличие двух DNS серверов в dhclient.conf приводит к появлению ошибки «ERROR_DNS_GSS_ERROR» после выполнения «net ads dns register -P».

В поисках решения этой проблемы я перечитал много статей и баг-репортов, и наткнулся на статью Warlock_ua «Безопасное динамическое обновление DNS записей в Windows домене из Linux (GSS-TSIG)». Идея показалась мне интересной. Но мне не понравилось решение с созданием отдельной учетной записи пользователя домена, которая имеет права на изменение всех записей DNS-зоны. Во-первых, это потенциально небезопасно. Во-вторых, в Windows уже существуют готовое решение: каждая учетная запись компьютера имеет право изменять свою запись на DNS. Почему бы этим не воспользоваться?

За основу я взял скрипт learn-address.sh от Warlock_ua, и доработал его с учетом своих нужд.

Об инфраструктуре

Имеем службу AD под управлением Windows Server 2008 R2 Standard, а также MS DNS сервер. Ими заведуют администраторы Windows. DHCP-сервер реализован на базе Cisco. Этим заведуют администраторы сети. Что так, для меня все это где-то в облаке, и немного похоже на черный ящик. Также у нас есть клиенты под управлением ОС Ubuntu 14.04 (Trusty), с установленным ПО Samba 4.1.6, isc-dhcp-client. Это по моей части.

Скрипт для обновления записей на DNS

Всю процедуру ввода в домен AD компьютеров под управлением Ubuntu я в описывать не буду, т. к. это выходит за рамки статьи. Опишу только ключевые моменты.

Компьютер, который будет обновлять свою запись на DNS, должен быть введен в домен. Т.е. у него должна быть учетная запись в домене. Для начала нужно будет получить пароль для учетной записи компьютера из Trivial DataBase. Сделать это можно с помощью утилиты tdbdump:

sudo tdbdump -k SECRETS/MACHINE_PASSWORD/DOMAIN /var/lib/samba/private/secrets.tdb | sed 's/\\\00$//' 

После этого нужно создать keytab-файл с учетными данными машины с помощью утилиты ktutil:

kinit -k -t $keytab_file $user 

И можно обновлять запись на DNS для конкретной учетной записи компьютера.

Обзор nsupdate-gsstsig

Листинг nsupdate-gsstsig

#!/bin/bash ### ### Объявляем переменные и читаем параметры скрипта ### dnsserver=dc1 fwdzone=domain.local # Зоны обратного просмотра у нас не используются. # Кому надо, может самостоятельно раскомментировать соотвествующие строки. #revzone=115.70.10.in-addr.arpa ttl=300 op=$1 addr=$2 #revaddr=`echo $addr | sed -re 's:(7+).(3+).(7+).(6+):4.3.2.1.in-addr.arpa:'` cn=$3 fqdn=$cn.$fwdzone addfile=add_$addr delfile=del_$addr # Подразумевается, что имя учетной записи компьютера в AD, # CNAME и имя компьютера совпадают user=$cn keytab_file=./machine_krb5.keytab ### ### Получаем пароль учетной записи компьютера ### MPAS=`sudo tdbdump -k SECRETS/MACHINE_PASSWORD/DOMAIN /var/lib/samba/private/secrets.tdb | sed 's/\\\00$//'` ### ### Экспортируем keytab-файл ### ktutil $addfile gsstsig server $dnsserver zone $fwdzone update delete $fqdn a update add $fqdn $ttl a $addr send EOF #zone $revzone #update delete $revaddr ptr #update add $revaddr $ttl ptr $fqdn #send #EOF cat $delfile gsstsig server $dnsserver zone $fwdzone update delete $fqdn a send EOF #zone $revzone #update delete $revaddr ptr #send #EOF nsupdate -v $addfile rm -f $addfile rm -f $delfile > delRecord() < kinit -k -t $keytab_file $user nsupdate -v $delfile rm -f $delfile >case $op in add|update) addRecord ;; delete) delRecord ;; *) echo "Unable to handle operation $op. Exiting" exit 1 esac rm $keytab_file

Запуск скрипта

Для удобства запуска я разместил скрипт в /bin/nsupdate-gsstsig.
Чтоб информация в DNS обновлялась автоматически, я создал скрипт regdns и поместил его в /etc/network/if-up.d/.

Листинг regdns

#!/bin/sh # Помещаем имя компьютера в переменную SHOST=`cat /etc/hostname` # Помещаем IP-адрес не lo интерфейса в перменную IP=$(ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '< print $1>') # Обновляем запись на DNS-сервере nsupdate-gsstsig update $IP $SHOST

Источник

Записки 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 часов практики и доступ навсегда.

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

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

Источник