Зачем bind рабочей станции Centaurus

[Pauli]

Народ, а не подскажет ли кто, зачем вообще потребовался локальный bind и настройка nameserver 127.0.0.1 для рабочей станции Centaurus? Я понимаю, зачем он может пригодиться на сервере. А при варианте установки "рабочая станция" внезапно обнаружилось, что nameserver 127.0.0.1 в /etc/resolv.conf определённо мешает пользователю авторизоваться в Kerberos. Бесконечно долго ждёт, ищет... Достаточно удалить /etc/net/ifaces/lo/resolv.conf и перезапустить сеть, как всё начинает летать. Ведь "настоящий" DNS получается по DHCP, разве нет? Кстати, пока не подключаешься к домену тоже вроде не мешает. В чём же была сермяжная правда запускать на рабочей станции bind и назначать его первичным DNS? Или где об этом можно что-нибудь прочитать?

[Skull]

Kerberos это не мешает, а кэширование запросом DNS-сервера значительно повышает скорость выполнения запросов. При получении вышестоящего DNS по DHCP он через resolvconf прописывается в конфигурацию bind. Так что нужно смотреть конфигурацию сети.

[Pauli]

Проблема в том, что я не знаю что именно смотреть. Все стандартные условия (ping, nslookup) выполнены. То есть имеется и связь, и разрешение имён.
Таймауты идут такого рода (ALT+F12): org.freedesktop.nm_dispatcher: timed out
org.freedesktop.ConsoleKit: timed out
org.freedesktop.UDisks: timed out
org.gnome.SettingsDaemon.DateTimeMechanism: timed out
Две подсети, 192.168.0.x и 192.168.1.x, контроллер домена - посередине, у него два интерфейса. Когда устанавливался сервер, у него был один интерфейс в сети 192.168.0.x, и уже затем, чтобы избежать прохода через маршрутизатор, был добавлен 192.168.1.x. Хост - виртуальный, носитель тоже Centaurus, технология KVM. Может ли это влиять?
Но вот ведь какая штука: переключаешь провод на 192.168.0.x - входит быстро, на 192.168.1.x - входит, с дикими тормозами. На физическую неисправность сети не грешу, в ней ещё куча пользователей, они бы сразу заверещали.

[Pauli]

И ещё такой момент. Регистрация IP рабочей станции в прямой и реверсивной зонах DDNS для нормальной работы - обязательна? Настроить DHCP на обслуживание сразу двух подсетей не позволяет Alterator, и это то ли баг, то ли просто недоделка, пока не разобрался. Но если пользоваться "чужим" DHCP, пусть даже со всеми нужными параметрами, DDNS не работает - чужому DHCP bind не доверяет. 

[Знайка]

Народ, а не подскажет ли кто, зачем вообще потребовался локальный bind и настройка nameserver 127.0.0.1 для рабочей станции Centaurus?

Это болезнь альтов. Ставить то, что только по их мнению необходимо, но реально практически никому не нужно. Кентавр, такое ощущение вообще лепили на скорую руку.

Настроить DHCP на обслуживание сразу двух подсетей не позволяет Alterator,

Так прибейте это убожество и настройте в ручную.

Но если пользоваться "чужим" DHCP, пусть даже со всеми нужными параметрами, DDNS не работает - чужому DHCP bind не доверяет.

Доверяет, если правильно настроен.

[Pauli]

Это болезнь альтов. Ставить то, что только по их мнению необходимо, но реально практически никому не нужно. Кентавр, такое ощущение вообще лепили на скорую руку.

Это ничего. Уверен, что если знать как, использовать можно. Научиться только.

Так прибейте это убожество и настройте в ручную.

Вручную у меня и так всё отлично настроено и работает. Я тестирую конкретно Centaurus, со всеми его достоинствами и недостатками как он есть. Это пилотная сеть, специально для разобраться.

Но если пользоваться "чужим" DHCP, пусть даже со всеми нужными параметрами, DDNS не работает - чужому DHCP bind не доверяет.

Доверяет, если правильно настроен.

Э-э, такой DHCP будет (станет) уже не "чужой", а очень даже "свой".

[Знайка]

Э-э, такой DHCP будет (станет) уже не "чужой", а очень даже "свой".

Не понимаю вашего принципа не деление свой / чужой.

[Pauli]

Э-э, такой DHCP будет (станет) уже не "чужой", а очень даже "свой".

Не понимаю вашего принципа не деление свой / чужой.

А чего тут понимать? Не авторизован - чужой, авторизовался - свой. Всё как в реальной жизни.

Короче, отдельное спасибо manowar за реальную помощь в разбирательстве. В действительности, случилась накладка. По умолчанию Centaurus рассчитан на одну подсеть: через Alterator, в настоящем его виде, можно настроить только одну зону DNS, только одну область DHCP, а у меня подсетей - две. В зоне DNS зарегистрировалось два адреса контроллера домена Centaurus, по одному для каждой подсети, и клиенты повадились обращаться то к одному то к другому по очереди, не получая ответа в 50% случаев. Вот он и таймаут.
Цель: необходимо обеспечить ping на любой из интерфейсов контроллера домена.
Метод раз: сделать контроллер домена шлюзом по умолчанию для обеих подсетей. Проверил, помогает, но делать виртуальную машину маршрутизатором показалось неинтересно.
Метод два: вписать в dhcpd.conf статический маршрут до контроллера. Что-то вроде option static-routes 192.168.1.253 192.168.0.253; где *.253 - адрес интерфейсов самого контроллера.
Результат: ping ldap (кстати, хороший оказался тест) стал срабатывать в 100% случаев, клиенты авторизуются быстро и надёжно. То есть, проблема разрешена. А nameserver 127.0.0.1 действительно можно оставить, он не мешает. Единственно надо иметь в виду, что при случае Alterator вписанную вручную опцию затрёт, но это пока так есть. Потом то ли Alterator научится понимать больше опций, то ли научится не затирать чего не следует. В общем, дело времени.