OpenLDAP + Bind

День добрый. Возникла необходимость поднять ЛДАП на машинке с центосью 5.7
Сделал по хаутушке с форума http://linuxforum.ru/viewtopic.php?id=7689.
При попытке добавиться в домен с удалённой машинки система ругается на отсутствующую srv-запись.
Добавил в зону бинда возможность динамического обновления с локалхоста

zone "_msdcs.ldap.local" {
        type master;
        allow-update {127.0.0.1;};
        check-names ignore;
        file "dynamic/_msdcs.ldap.local";
};

Реакции ноль, логи чисты. Проблема в том, что я не совсем понимаю логику, по которой ЛДАП должен обновлять зону. Схема зоны должна в нём хранится?
Как победить систему? Стоит-ли напрямую прописать в зону ручками соответствующую srv-запись?

А DNS на удаленной машинке вкурсе где где ldap+samba стоит?

P.S. Была необходимость опять поднять домен, но CentOS 5.7 как бы староват оказался. На CentOS 6.2 все поменялось и с наскока не завелось. Сейчас без проблем работает samba4 на Ubuntu. Там уже в автомате добавляется SRV запись в bind и встроенный openldap. Админится все через виндузовые приблуды Windows Server 2003.

P.S.S. Статья писалась для пробы, на попробовать. Машинки в домен включались, а вот с удаленки не тестировалась.

Во что нашел

This example is taken from the OpenLDAP site and allows a simple discovery process of the LDAP server for the zone by interrogation of the DNS.

$ORIGIN example.com.
.........
; defines an ldap service available at the host jim.example.com
_ldap._tcp.example.com. SRV 0 0 389 jim
; if the service (LDAP) were hosted by another organization
; the reference could be external
; in this case the host ldap.example.net hosts the LDAP service for
; example.com
_ldap._tcp.example.com. SRV 0 0 389 ldap.example.net.

OpenLDAP publish an SRV RR which may be obtained by issuing an SRV query to _ldap._tcp.openldap.org.

http://www.zytrax.com/books/dns/ch8/srv.html

Вот для примера как описывает зоны samba4

xlin@smb:/var/lib/samba/private/dns$ cat smb.mgkb1.local.zone
; -*- zone -*-
; generated by provision.pl
$ORIGIN smb.mgkb1.local.
$TTL 1W
@               IN SOA  smb   hostmaster (
                                2011120417   ; serial
                                2D              ; refresh
                                4H              ; retry
                                6W              ; expiry
                                1W )            ; minimum
                        IN NS   smb
            IN A    192.168.2.82
;
smb        IN A    192.168.2.82
gc._msdcs               IN A    192.168.2.82
222dc04b-8971-46e9-a827-4ebda0e6159b._msdcs     IN CNAME        smb
;
; global catalog servers
_gc._tcp                IN SRV 0 100 3268       smb
_gc._tcp.Default-First-Site-Name._sites IN SRV 0 100 3268       smb
_ldap._tcp.gc._msdcs    IN SRV 0 100 3268       smb
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs     IN SRV 0 100 3268 smb
;
; ldap servers
_ldap._tcp              IN SRV 0 100 389        smb
_ldap._tcp.dc._msdcs    IN SRV 0 100 389        smb
_ldap._tcp.pdc._msdcs   IN SRV 0 100 389        smb
_ldap._tcp.04c11e9a-37ee-4aa3-bab8-909dbc0cb2de.domains._msdcs          IN SRV 0 100 389 smb
_ldap._tcp.Default-First-Site-Name._sites               IN SRV 0 100 389 smb
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs     IN SRV 0 100 389 smb
;
; krb5 servers
_kerberos._tcp          IN SRV 0 100 88         smb
_kerberos._tcp.dc._msdcs        IN SRV 0 100 88 smb
_kerberos._tcp.Default-First-Site-Name._sites   IN SRV 0 100 88 smb
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs IN SRV 0 100 88 smb
_kerberos._udp          IN SRV 0 100 88         smb
; MIT kpasswd likes to lookup this name on password change
_kerberos-master._tcp           IN SRV 0 100 88         smb
_kerberos-master._udp           IN SRV 0 100 88         smb
;
; kpasswd
_kpasswd._tcp           IN SRV 0 100 464        smb
_kpasswd._udp           IN SRV 0 100 464        smb
;
; heimdal 'find realm for host' hack
_kerberos               IN TXT  SMB.MGKB1.LOCAL

Спасибо за помощь :)
Извиняюсь, не уточнил сразу. Бинд расположен на одной с ЛДАПом машине. Меня интересует вот что, а по какому механизму вообще происходит обновление ЛДАПом зоны бинда? При динамическом ДНС в случае с DHCP мне в конфиге ДХЦП ручками надо было вбивать соответствующий зоне rndc-ключ, дабы бинд знал кого пускать. А тут, получается, ЛДАП ломится "анонимно" и ограничения реализуются средствами самой диррективы бинда "разрешать обновления только с ххх.ххх.ххх.ххх" ?

Попробовал сейчас ручками SRV-запись прописать по приложенному примеру, подогнав под себя. Ребутнул зону. Получаю тот-же отлуп.
Вопрос - в примере для самбы4 явно в "А" зоне объявлен только "gc._msdcs" не требуется-ли объявить и " _ldap._tcp.dc._msdcs"? бо сейчас
[console][adm@ldap ~]# host -t SRV _ldap._tcp.dc._msdcs.ldap.local
Host _ldap._tcp.dc._msdcs.ldap.local not found: 3(NXDOMAIN)[/console]

off:
Через месяц приезжает новая железка в серверную. Думаю вплотную заняться виртуализацией сервисов и вынести ЛДАП на отдельный виртуальный инстанс. Сейчас, к сожалению, все железки заняты и менять центось на что-либо (или даже обновлять версию) не вариант ни разу. Можно поподробнее про текущую схему с убунтой и 4ой самбой? Как всё прошло, были-ли какие подводные камни?

CATMAN написал:

Меня интересует вот что, а по какому механизму вообще происходит обновление ЛДАПом зоны бинда?

А почему LDAP должен обновлять зоны бинда? Зоны же не находятся в дереве лдапа.

CATMAN написал:

Можно поподробнее про текущую схему с убунтой и 4ой самбой? Как всё прошло, были-ли какие подводные камни?

Все прошло гладко,, но это если юзать Ubuntu Server. Хотел все сделать на CentOS 6.2, но из-за времени не успел разобраться. Хотя есть на оф. сайте хорошая ховтушка.

Вот еще что? В /etc/resolv.conf все прописано.. Типо

domain smb.mgkb1.local
search smb.mgkb1.local
nameserver 192.168.2.82
nameserver 192.168.1.77
nameserver 192.168.3.223

Только после этого работает. А у вас там в примере без точки в конце? Опечатка?
[console]root@smb:/home/xlin# host -t SRV _ldap._tcp.dc._msdcs.smb.mgkb1.local.
_ldap._tcp.dc._msdcs.smb.mgkb1.local has SRV record 0 100 389 smb.smb.mgkb1.local.[/console]