Для организации DDNS обычно пользуют внешние сервисы — ибо это проще, как правило. Например, при использовании того же DynDNS не требуется заводить свой домен.
Но давайте представим, что домен у организации уже есть и есть потребность в DDNS. Но пользоваться чужими услугами для этого не хочется — они или платные, или нифига не гарантированные (как в случае с DynDNS), или банально не имеют клиента для необходимой ОС. Так или иначе, наша цель — это настроить DDNS сервер и DDNS клиента на базе всего встроенного в Linux Debian, без установки софта сбоку и пользуясь только своими мощностями.
Данная записка ориентирована на ОС Linux Debian, однако с минимальными изменениями все это же действительно для других ОС, как, например, CentOS/RedHat
ПАРАМЕТРЫ
В данном примере будут использованы следующие параметры — это всего-лишь пример:
Адрес мастер-DNS сервера: ns1.example.com
Адрес DDNS зоны, которая будет обновляться: dynamic.example.com
Адрес, собственно, зоны: example.com
Интерфейс на клиенте с выходом в WAN: eth0
TTL динамической зоны: 120 (2 минуты)
КЛИЕНТ
Как ни странно, но начнем мы, пожалуй, все-же с клиента.
1) Устанавливаем необходимые пакеты (они не идут из коробки).
$ sudo apt-get install bind9utils
Действо данное нам необходимо ради получения утилитки под названием nsupdate.
2) Генерируем ключ TSIG.
Данный ключ будет позволять производить на сервере DNS изменение необходимой зоны DNS при заранее неизвестном IP адресе клиента.
$ sudo dnssec-keygen -b 512 -a HMAC-MD5 -v 2 -n HOST example.com
здесь вместо example.com введите название ключа (желательно, чтобы оно все-же совпадало с названием зоны). Причем название это потребуется в дальнейшем.
Данная процедура создаст два файла, называющихся примерно так:
Kexample.com.+157+49437.key
Kexample.com.+157+49437.private
Файлы эти лежат там, где Вы находитесь в данное время (pwd). Причем их местоположение не важно — можете хранить их хоть у себя в домашнем каталоге.
3) Создаем скрипт для автообновления адреса
Например, назовем его ddnsupdate и положим в /usr/local/bin:
#!/bin/sh
IFACE="eth0«
TTL=120
SERVER=ns1.example.com
HOSTNAME=dynamic.example.com
ZONE=example.com
KEYFILE=/path/to/tsig/Kexample.com.+157+49437.private
new_ip_address=`ifconfig $IFACE | grep «inet addr:» | awk ’{print $2}’ | awk -F «:» ’{print $2}’`
nsupdate -v -k $KEYFILE << EOF
server $SERVER
zone $ZONE
update delete $HOSTNAME A
update add $HOSTNAME $TTL A $new_ip_address
send
EOF
Здесь:
IFACE="eth0« : Это название сетевой карты, с которой снимать данные о текущем IP адресе (например, для ADSL это будет, скорее всего, ppp0);
TTL=120 : Это время жизни данной зоны в кеже других серверов DNS и конечных компьютеров. Много ставить не надо — а то придется долго ждать, прежде чем новый IP адрес станет доступным после изменения;
SERVER=ns1.example.com : Это FQDN адрес Вашего DNS сервера, который будет выступать в роли и DDNS сервера;
HOSTNAME=dynamic.example.com : Это название зоны, IP адрес (A-запись) которой и будет обновляться через DDNS;
ZONE=example.com : Это название родительсвой зоны (т.е. если dynamic.example.com — это часть зоны example.com — то здесь пишем example.com);
KEYFILE=... : Это путь к файлу ключа, созданного в п.2.
4) Делаем этот файл исполняемым:
$ chmod +x /usr/local/bin/ddnsupdate
5) Открываем файл Kexample.com.+157+49437.private (или как он у Вас называется):
Private-key-format: v1.3
Algorithm: 157 (HMAC_MD5)
Key: vHBX3cjxtS8lM37KZwfnpXFldl9QB/8vs67Rw/xCH+yGXJ9gmj5BVHY87NQMD/vmjHZc8oz38PgINGAYRMrdAA==
Bits: AAA=
Created: 20120216073642
Publish: 20120216073642
Activate: 20120216073642
Видите строчку «Key:.......»? Вот нам надо скопировать в буфер обмена все, что находится после «Key:» (опустив пробел, конечно). Это ключ, который понадобится для конфигурирования сервера.
СЕРВЕР
Теперь приступим к настройке сервера. Предполагается, что DNS сервер BIND уже установлен и работает. На всякий случай — вот статья по его установке на Debian: ссылка.
Итак, у Вас есть обычная статическая DNS-зона. Например, она выглядит вот так:
$ORIGIN .
$TTL 3600 ; 1 hour
example.com IN SOA ns1.example.com. root.example.com. (
2012021602 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS ns1.example.com.
NS ns2.example.com.
A 111.222.111.222
MX 10 mail.example.com.
$ORIGIN example.com.
mail A 111.222.111.225
www CNAME example.com.
На самом деле в файле описания зоны делать ничего не надо — она так и остается — какая есть.
1) Создаем (если нет) или дописываем в (если есть) файл keys.conf. Положим этот файл в директорию остальных конфигов bind (для не-chroot-ового BIND Debian — это /etc/bind).
Файл будет иметь вот такой вид:
key example.com {
algorithm hmac-md5.sig-alg.reg.int;
secret vHBX3cjxtS8lM37KZwfnpXFldl9QB/8vs67Rw/xCH+yGXJ9gmj5BVHY87NQMD/vmjHZc8oz38PgINGAYRMrdAA==;
};
Заметили строчку «secret»? Сюда мы как раз ложим скопированный с клиента ключ — всю строку.
А еще заметили название ключа «example.com»? Вот оно должно быть точно таким-же, как и то название, которое мы указывали в качестве параметра «HOST» в п.2
2) Изменяем конфигурацию DNS-зоны example.com (ну конечно вместо example.com — название Вашей зоны).
Например, исходно она выглядит вот так:
zone «example.com» {
type master;
file "/etc/bind/master/example.com«;
};
Теперь дописываем опцию «allow-update» с указанием ключа, после чего конфиг зоны будет выглядеть примерно так:
zone «example.com» {
type master;
file «/etc/bind/master/example.com»;
allow-update {
key example.com;
};
};
3) Дописываем в файл named.conf директиву загружать ключи из keys.conf:
...
include "/etc/bind/keys.conf«;
4) Убеждаемся, что процесс bind сможет изменять файл зоны и писать файлы рядом с ним. Дело в том, что DNS-сервер создаст рядом файл журнала, в котором будет вести лог изменений через DDNS, а также будет самостоятельно время от времени менять файл зоны, внося в него изменения в соответствии с принимаемыми от клиента данными.
Для этого делаем пользователя bind в группе bind владельцем директорий master и dynamic:
$ sudo chown -R bind:bind /etc/bind/master
$ sudo chown -R bind:bind /etc/bind/dynamic
Без этого, если сервер не сможет изменять файлы в директории, где лежит зона, он будет просто возвращатьSERVFAIL в качестве ответа на ddnsupdate.
5) Перезагружаем конфиг сервера DNS:
$ sudo rndc reload
Все, настройка сервера закончена.
СНОВА НА КЛИЕНТЕ
Снова возвращаемся к клиенту. Запускаем скрипт ddnsupdate и глядим, чтобы все прошло шоколадно.
Если не шоколадно:
Если вызалит «NOTZONE»: проверьте, что Вы правильно указали в ddnsupdate параметры ZONE и HOSTNAME. Например, параметр HOSTNAME будет включать в себя все то, что написано в ZONE (например, ZONE=example.com, HOSTNAME=dynamic.example.com).
Если вызалит «NOTAUTH(BAD_KEY)»: проверьте правильность копирования ключа с клиента на сервер и то, что название ключа точно соответствует как на клиенте, так и на сервере. Смысл в том, что нужно плясать с бубном возле ключа. И, кстати, не стоит копировать ключ из файла с расширением .key — на самом деле записи в нем и в .private могут легко отличаться — как это было у меня.
Если вылазит «SERVFAIL»: проверьте, что демон bind имеет права на запись везде, где только возможно в директории конфигов сервера (в нашем случае: /etc/bind).
Если же шоколадно — то смело добавляйте запуск скрипта ddnsupdate по расписанию через редактрование/etc/crontab.
ЗЫ. Если вылазит ошибка ddnsupdate — дополните запуск nsupdate ключем -d или -D — в консоль будет вываливаться отладочная информаия (-d) или куча отладочной информации (-D).
