DNS на Ubuntu Server 9.04

[73]

ОГРОМНОЕ СПАСИБО user8557 и его сообщению
https://forum.ubuntu.ru/index.php?topic=29295.msg204466#msg204466
У меня схожая проблема была с etc/apparmor.d/usr.sbin.named.
Жаль, что раньше не нашёл и не прочитал эту тему.
Я с Linux недавно знаком, не более 2-х месяцев, и поэтому мат.часть знаю еще плохо.
Использую его на виртуальных машинах в учебных целях.

Пару слов для тех, кто настраивает динамическое обновление DNS или DDNS впервые.
Смотрите сообщения в /var/log/syslog У меня там были записи "denied" для зон,
из-за того, что не было прав на запись в /etc/bind, где у меня хранятся конфиги и
файлы зон и соответственно не возможно было вносить изменения.

Я создал пустые файлы журналов  .jnl самостоятельно, но этого делать не нужно. При правильных настройках система их создаст  сама после перезагрузки машины. Перезагрузка bind и dhcp3 серверов здесь не поможет.

Мной на директорию /etc/bind, файлы зон (прямой и обратной) были даны права на запись для других пользователей, но система 
после правильных настроек все сама отрегулировала
и убрала эти настройки для этих файлов зон, т.е. тех в которые вносились изменения и соответственно такие же права для файлов журналов для этих зон.
Правильность настроек конфигурационных файлов named.conf, named.conf.local, named.conf.options, файлов зон db.  проверял с  помощью программы для удаленного администрирования Webmin.

Настройка в файле dhcpd.conf
ddns-host name  - означает имя рабочей станции, а не имя сервера, т.е. все ПК,
которые получаю свой IP динамически через этот сервер DHCP3, будут иметь указанное имя.
server-identifier  мне лично тоже не понадобилась.
При использовании этой настройки в параметрах WINDOWS машины (ОС Server 2003 с Active directory) , например ipconfig /all, ip-адрес DHCP-сервера был 127.0.1.1 .

Для протоколирования работы сервера я использовал настройки logging, которые указаны в man dhcpd.conf и в использованой мной  статье (не единственной) "Настройка DNS + DHCPD" на www.unixdoc.ru .
Директория, в которой Вы собираетесь хранить логии, должна быть в настройках /etc/apparmor.d/usr.sbin.named.
Я вместо /var/log/, указанной в статье, перебросил файлики в /var/cashe/bind/, которая
была в моем файле настроек usr.sbin.named с правами 'rw'.

Последние приключения в Linux сети.
-----------------------------------
Поскольку у меня была WINDOWS-машина с Windows Server 2003 и Active Directory, которая выполняла роль котроллера домена, dns, dhcp и др. сервера, то я решил поэкспериментировать и включить её в сеть с моим Linux сервером.
Но забыл отключить DHCP и DNS службы сервера на ней.

На Win-машине другой домен- «world», отличный от того за который отвечает сервер на Ubuntu.
Поэтому решил добавлять ещё одну зону в named.conf.local.
После добавления новой зоны, DNS сервером для которой стал LINUX, из-за работающей службы DNS на 2003 в syslog появились  сообщения о невозможности разрешить некоторую инфо необходимую для работы Active Directory (AD).
Я отключил DHCP и DNS службы сервера на 2003-й и перезагрузил Linux, но сообщение gc.msdcs.доменAD bad owner name  (check-names) в syslog не исчезло и давило на моё возбужденное подсознание.
Решил убрать (перенести в др. директорию) журналы зон и изменить настройки на старые в зонах (для домена local , обратной зоны, зоны world для Windows), но не тут то было. Не, всё прошло нормально, но новые журналы не хотели создаваться. Bind не  понравилось, что нет слова "$ORIGIN  .", которое я убрал из файла зон вместе с записями "А" и "PTR", оставив только записи  для сервера Ubuntu. В общем, мама не узнала сына, после моей хирургической операции . Добавил строки с $ORIGIN в зоны, но  некоторые нехорошие слова в syslog не перестали появляться. Хотя после того, как перезагрузился в очередной раз и видимо из-за внесенных изменений в named.conf , named.conf.local, dhcpd.conf появились журналы, но только не для домена за который отвечал  Linux. В общем этот “мазохизм” продолжался до тех пор, пока я не закомментировал в named.conf.local настройки зон, убрав их тем  самым из сети, не перенес файлы аренды ip-ков dhcpd.leases и файл named-update.log, который создавался при обновлении в  настройках named.conf BIND в др. директории (для страховки), потом перезагрузился reboot , расскомментировал зоны, снова reboot и после этого включил в сеть др. виртуальные машины. Они получили "новенькую форму с блестящими пуговицами в ряд" в виде  ip-адресов, создались dhcpd.leases со словами дружбы с ddns, файл логов named-update.log, журналы зон .jnl, были внесены  изменения в сами зоны с адресами и именами "проживающих" в сети ПК. На этом приключения и закончились, пока .
Пользователь решил продолжить мысль 01 Июля 2009, 18:55:58:Из последних сводок с фронта .
Мной были внесены изменения в файлы зон (поменял серийный номер, шоб красивше и правильней ГГГГММДД№№, т.е. 2009063001), named.conf.local, named.conf.options, dhcp.conf .
После перезагрузки никаких обновлений в DNS не произошло. Перед этим все записи в файлах зон в связи с отсутствием в сети вирт. машин стерлись ( сообщения в логах подтверждают).
В syslog появились ругательства от named относительно того, что journal roolforward failed:  journal out of sync with zone и от dhcpd тоже – unable to add reverse (forward) map from … to… timed out
После удаления журналов .jnl, лога обновлений named-update.log , файлов аренды ip и перезагрузки reboot изменения появились, но обновление произошло только для файла обратной db.20.100.192 и прямой зоны db.world для одного компьютера, того на котором установлена ОС Windows Server 2003. Он остался у меня контроллером домена “world” с AD. Причем эта машина также получала ip адрес от моего Linux сервера.
А КД Windows Server 2003 по серьезному разошёлся, всякую всячину виде «SRV» записей в основном и пару “CNAME” пихает (обновляет) в журналы, кроме записей типа «А» и “PTR”. пока я писал это сообщение.
Кстати «ЗЕК» и «PTR» одно и тоже , но в разной раскладке.
Машины на Linux Ubuntu Desktop 9.04 из другого домена “local”, который является  доменом по умолчанию при выдаче ip, никаких записей в файлы зон db.local, db.20.100.192 и лог обновлений не пишут , хотя арендуют адреса нормально.
Смотрю дальше syslog.
Снова ругательства от named относительно того, что client 127.0.0.1#номер update …..in-addr.arpa denied и от dhcpd тоже, что и было – unable to add reverse (forward) map from … to… timed out .
Ага, всё-таки решилось.
Догадался внести изменения (вернуть всё в зад) в dhcpd.conf, которые перед этим всем сделал. Вот что получилось:

Код: [Выделить]

…
zone local. { primary 192.100.20.10;}
zone 20.100.192.in-addr.arpa.{ primary 192.100.20.10; }
Перед этим было 127.0.0.1.
Дальше серверы dhcp и bind restart. Отключаю/подключаю к сети раб. станции и всё заработало, недостающие файлики журналов зон появились, обновляются и зоны, в логи всё пишется.
Да, может кто дочитал сей опус до конца и подскажет, что то видимо у меня с настройками для 127.0.0.1. Не знаете часом, где подправить?

Время на сервере по команде date и время в файле аренды dhcp.leases разное, на 5 часов отличается. Как поправить?

Буду признателен за ответы.

P.S. Ругательства “rndc:connect failed: 127.0.0.1#953: connection refused” о которых писал раньше при /etc/init.d/bind9 reload исчезли.
Проблема на WINDOWS-машине с nslookup "DNS request timed out.
timed out was 2 seconds" при “непонятных” на тот момент видимо вопросах, тоже решилась видимо после правильной настройки.
После включения Linux-сервера, а потом др. вирт. машин снова вылезло сообщение в syslog для Windows машины с ОС Server2003 “named: zone world gc.msdcs.world /A : bad owner name  (check-names)”

После применения ключа DHCP_UPDATER для обновления файлов зон в syslog появилось сообщения named: client 192……: signer ‘dhcp_updater’ approved (т.е. одобрен, принят). Хочу обратить ВНИМАНИЕ, что в настройках dhcpd.cong ключик должен быть БЕЗ кавычек, т.е. secret XXXXXXXXX ;
В named.conf  же он должен быть С кавычками. Вот так:  secret “XXXXXXXXX”; Алгоритм шифрования я писал HMAC-MD5, а то в интернете в статьях встречал еще и
HMAC-MD5.sig-alg.reg.int. .
Если Вы ошибетесь с ключом, то появится сообщение в syslog от dhcpd  : unable to add reverse (forward) map from … to… bad DNS key.
Кстати, в syslog и логе обновления были такие записи от named:
файл зоны - allows updates by IP address, which is insecure.
Вылечилось после применения ключа для обновления.

После операций с ключами появилось сообщение в syslog от named :  client 192….. update world /IN (или ……192.in-addr-arpa/IN) : denied. Я так полагаю, что Windows не может из-за ключа провести обновления. Или я ошибаюсь?
С зоной local всё в порядке. Проверил её, включив в сеть ПК с Win XP и с Linux, всё нормально, обновления проходят зон (add reverse (forward) map), ключик approved.
Из этого делаю вывод, что Active Directory не может работать с ключом обновления DHCP_UPDATER и не может внести свои SRV, A, TXT записи.

Из-за применения ключа и перезагрузок, отсоединения/присоединения к сети раб. станций в файле обратной зоны db. ….192.in-addr.arpa застряла запись для одного из ПК на Linux, т.е. теперь есть 2-записи PTR с разными ip адресами одинаковым именем . Как поправить? Файлы аренды, журналы, логи снова грохнуть, чтобы всё заново воссоздалось? Если руками, то снова может быть рассинхронизация с журналом зоны.

[73]

Всем привет!
Не уже ли никто не дочитал до конца ?
Или все "гуру"   сейчас на отдыхе ?

[garbals]

у меня вопрос
с чего начать настройку DNS для поддержки сайта и почтовика 

[admin4ek]

на счет dnsmasq, у меня он пашет на серваке как часы уже как год, просто ставишь, в качестве днс сервера на клиенте указываешь айпи уже своей машины (не забудь /etc/resolv.conf прописать айпи модема в твоем случае)
Пользователь решил продолжить мысль 14 Июля 2009, 10:21:00:вот по подробнее

Если dnsmasq обслуживает локальных клиентов, содержит локальную зону и осуществляя форвардинг в Интернет, то  он должен быть закрыт от запросов из внешнего мира одним из двух способов:
1.пакетным фильтром на уровне операционной системы;
2, исключением сетевого интерфейса, глядящего во внешний мир, из списка обслуживаемых на уровне сервиса.

Второй вариант проще и надёжнее; для его поддержки в dnsmasq.conf   
/etc/dnsmasq.conf
имеются параметры interface, except-interface, listen-address и крайне полезный bind-interfaces. Если же на компьютере имеется всего одна сетевая карта и один логический сетевой интерфейс с одним IP-адресом, селекция по сетевому интерфейсу становится невозможна и используется первый вариант, отсекающий запросы к сервису по IP-адресу отправителя.

Чтобы иметь доступ к DNS-серверу, адрес которого сообщается динамически PPP или DHCPC (DHCP client), dnsmasq будет напрямую отслеживать файл, заданный в /etc/sysconfig/dnsmasq параметром PPP_RESOLV_CONF - по умолчанию /etc/ppp/resolv.conf. PPP записывает сюда свои сведения при включённой в /etc/ppp/options опции usepeerdns. В случае с DHCPC файлом для слежения через PPP_RESOLV_CONF должен быть сделан /etc/dhcpc/resolv.conf.
При инсталляции сетевых сервисов принято по умолчанию разрешать к ним доступ только с того компьютера, на котором они запущены. Подразумевается, что администратор, произведя настройку сервиса, расширит доступ к нему до требуемого уровня. В /etc/sysconfig/dnsmasq за это отвечают параметры listen-address=127.0.0.1 и bind-interfaces. Типичной ошибкой многих начинающих администраторов является полное отключение данной настройки вместо её аккуратного редактирования. Таким образом в сети появляются прокси-серверы, доступные любому желающему, общедоступные файловые архивы с закрытым коммерческим ПО и Веб-серверы, на которых можно получить полный список пользователей в организации. Хотя dnsmasq не хранит столь важную информацию и не замечен в уязвимостях, как минимум не следует давать к нему доступа из внешней сети

Минимальная настройка сервера DHCP в dnsmasq.conf сводится к одной директиве, dhcp-range, которая задаёт диапазон IP-адресов для назначения клиентам. Прочие сообщаемые клиенту параметры - маска сети, имя DNS-домена, имя DNS-сервера, адрес маршрутизатора - формируются тем же образом, что и настройки сервера DNS, то есть читаются из общесистемных настроек. В дополнение к dhcp-range существует ещё несколько директив с общим префиксом dhcp-, позволяющих, во-первых, задавать дополнительные параметры для передачи клиентам (например, адрес TFTP-сервера и имя файла с ядром Linux для бездисковой сетевой загрузки) и во-вторых, создавать группы параметров для передачи отдельным клиентам или группам клиентов.

Поскольку два сервера, DNS и DHCP, объединены в одной программе, не возникает проблем с обменом сведениями между ними -- что знает один, немедленно узнаёт и второй. Например, как только DHCP назначает клиенту IP-адрес, данный адрес немедленно появляется в таблице сервера DNS. И наоборот, если запрашивающий DHCP-настройки клиент имеет имя, присутствующее в таблице имён DNS, ему сообщается IP-адрес, указанный для этого имени в таблице.

Если вместо встроенного в dnsmasq DHCP-сервера запущен отдельный сервер DHCP, а dnsmasq является только сервером DNS, то для обновления таблицы имён вместо вместо связывания двух серверов через сокет или именованный канал используется более простой трюк: dnsmasq следит за изменениями в файле /var/lib/dhcpd/dhcpd.lease, куда DHCP-сервер в текстовом виде записывает копии настроек, назначенных клиентам. Читая этот файл, dnsmasq на лету обновляет свою таблицу. Примитивно? Зато надёжно и просто.

Безусловно, у такого варианта есть ограничения, пусть и незначительные. Во-первых, обе программы требуется запускать на одном и том же компьютере, чтобы они видели один и тот же файл. Во-вторых, файл dhcpd.lease не является чем-то стандартным и генерируется всего одной известной программой-сервисом DHCP - ISC DHCP Daemon. Которая, впрочем, не имеет в большинстве ОС никакой альтернативы. В-третьих, автономный DHCP-сервер имеет отдельные настройки, которые придётся поддерживать в соответствии общесистемным вручную.