Архив форумов ЦИТФорума

[Vladimir Vasutinsky]

Hi, милые и добрые люди.

падает мне в лог такое вот сообщение
"Jun 10 11:19:37 r3 named[250]: denied update from [192.168.x.x].4341 for x.168.192.in-addr.arpa"

и есть у меня почти уверенность, что эту бяку
шлют мне W2KServ коих 6 штук, и это 80% сообщений, оставшиеся 20% это W2KProf...
Грешу я на AD.(DNS не на одном не запущен)

Подскажите, pls,: так ли это и если да, то
как с этим бороться?

С уважением, Владимир.

[ilyasov]

Я в своей сети особо не вникал (ибо DNS на такие действия просто плюет). Но клиентам сказал, что отключу их кусок сети. В результате -они все повырубали на W2K, остатвив только TCP/IP как таковой. Проблема и решилась.
А в качестве совета -оставить на W2K только TCP/IP, a затем подключать то, что нужно и смотреть в log файлы.

[and3008]

-

[Dmitry.Karpov http://www.]

Сначала (во времена WfWG'3.11) Билл Гейтс решил, что список машин в сетИ юудет вести одна случайно выбранная машина (обычно это первая включенная). Эта система использует широковещательные сообщения и поэтому не работает через IP-роутер. Если бы она работала сквозь роутер, то в "Сетевом окружении" показывались почти все Windows-машины, подключенные к Internet.

Затем был придуман WINS, но он тоже плохо работал, как и любая технология, придуманная Биллом Гейтсом.

Теперь Билл Гейтс придумал DDNS - это некое дополнение к DNS, при котором машина при включении сама сообщает DNS-серверу свои имя и IP-адрес, а он должен подправить содержимое соотвествующей DNS-зоны.
Эта система в корне противоречит идее DNS как распределенной базы данных - дело в том, что инерционность (время полного обновления кэшей) составляет сутки по де-факто, а так следы старых записей могут жить в кэшах аж неделю; при этом система DDNS предполагает обновление при каждом включении и выключении машин, а это происходит как минимум раз в день (гарантированный период обновления у броадкастного просмотра и у WINS составляет 45 минут, в течении которых существующая машина может отсутствовать в "Сетевом окружении" или выключенная машина может там оставаться, что тоже непомерно много).

Почему Unix-DNS ругается на попытки обновления? Дело в том, что у Unix подход собачий, а у Windows - кошачий (собака думает, что раз хозяин ее кормит и дает кров - он бог: кошка демает, что раз хозяин ее кормит и дает кров - значит, это она бог): Unix никогда не будет делать по указаниям других машин то, чего ему явно не сказал делать админ, считая чужие машины потенциально враждебными; Windows же считает, что вокруг нее одни дружественные Windows, и потому готова принять от соседних машин любые рукаоводящие указания - и поправки в DNS-зонах, и указания об IP-маршрутах, и много чего еще. Рекомендую почитать на http://www.pi2.ru/prof статью о локальных и глобальных сетях для лучшего понимания предмета.
Так вот, Unix-DNS не будет принимать на веру просьбы машин о внесении их в DNS-зоны, если админ явно не прикажет. Как это сделать - см. 'man named.conf', я в него глянул, но еще не разобрался. Первое, что надо сделать - сформировать ACL из машин, которым можно обновлять зону, а потом разрешить этому списку дополнять зону.

[ilyasov]

Любое несанционированное вмешательство в работу сети, которое может (даже потенциально) повлечь за собой отказ нужно пресекать безоговорочно! Документация тут вовсе не при чем. Разбираться с особенностями поведения криво настроенной клиентской машины администратор не должен (да и не сможет, если в сети машин за 150 штук). Динамическое обновление DNS баз в принципе штука весьма маразматическая. Хотя бы потому, что данные DNS кешируются и обновляются с очень приличной задержкой.

[Lex_]

Dc` очень просто - на мастдайной машине нужно в настройках TCP/IP убрать флажок "Регестрировать данное подключение в ДНС", и пока не уберут - банить нещадно, ибо нефиг %)

[ilyasov]

Да, DNS позволяет изменять динамически базы данных, это даже включено в DHCP, но по сути таковые действия никому не нужны. Дело как раз в инертности DNS и в самой сути вопроса. Зачем обновлять данные, которыми по сути дела никто воспользоваться не может?

[Dmitry.Karpov http://www.]

Честно говоря, я так и не понял, почему Биллу Гейтсу не удалось заставить WINS работать без глюков - по идее, там тот же алгоритм, что и в DDNS: регистрация каждой машины на заранее назначенном сервере.
Есть и немного другие механизмы - и DHCP-сервер, и WINS-сервер могут при регистрации в них машины дать команду на изменение DNS-зоны.

В принципе, DDNS должен работать стабильнее и надежнее, чем WINS и тем более BroadCast-Browsing; важно только понимать, что ни в коем случае нельзя выставлять DDNS-зону наружу (или что то же самое - динамически регистрироваться в зонах, доступных извне) - механизмы динамического отслеживания могут работать только в локальных сетях.
И не забудьте, что необходимо производить синхронные изменения и в прямой, и в реверсной DNS-зонах.

Но самое умное - предусмотреть статическое распределение IP-адресов и статическое же прописывание их в DNS. Иные модели поведения не имеют права на жизнь, т.к. чреваты разными малоприятными последствиями типа конфликта одинаковых имен на разных машинах.

[and3008]

Болл понял всю убогость и плохую масштабируемость имен NetBIOS. Поэтому Windows 2000 может вообще работать без NetBIOS, т.к. хитрый Билл все заметил на DNS-серверах.
Дабы оставить юзверям досточтимое "Сетевое окружение" и потребовалось как-то отказаться от WINS (в силу его плохой масштабируемости), но сделать так, чтоб юзвери увидели в "сетевом окружении" свои компы.

WINS, а вслед за ним и NetBIOS ограничен пределами локальной сети. Да и небезопасен он. Он кроме IP компа регистрирует и IP и имя юзверя. Кулхацкерам подарок.

DDNS снимает такие ограничения, поэтому так и сделали. Другое дело, что у многих админов это вызвало недовольство, но дело уже сделано. Мдя...

[anthony]

-

[Dmitry.Karpov http://www.]

По историческим причинам сложилось так, что в Windows основным протоколом/API оказался NetBIOS, работающий поверх NetBEUI, IPX и IP; и лишь позднее пришел WinSock (аналог Sockets в Unix). В Unix же изначальным был Berkley Sockets (разработан в BSD), а NetBIOS реализован программой Samba (в ядре и в библиотеках, поставляемых с дистрибутивом, нет такого API; Samba тоже не дает такого API, там ELF-файлы без библиоотек.so) и только поверх IP.

Сокетные протоколы предполагают резолвинг имен на уровне программы (т.е. программа сначала делает вызов IP_номер=gethostbyname(доменное_имя), и затем уже открывает сокет по IP_номеру. NetBIOS открывает соединение или посылает сообщение по имени (резолвинг происходит внутри). В частности, это означает, что имена NetBIOS остаются немасштабируемыми даже при переходе к DDNS - пространство имен осталось прежним, но имена теперь мапируются на заданную DNS-зону. Впрочем, нас явно ожидают многочисленные переделки сервиса имен в попытке приспособить технологии, разработанные для маленьких локальных сетей к большим и к глобальным сетям (отсылаю на http://www.pi2.ru/prof к статье о локальных и глобальных сетях). Лично я ожидаю появление в "Сетевом окружении" имен в стиле DNS - с точками.

Кстати, можно ли как-то разделить список NetBIOS-имен по группам? У нас используется домен, в поле "Имя группы" приходится писАть имя домена, поэтому все сто с лишним машин болтаются в одном списке, упорядоченном по алфавиту, а удобнее было бы рассортировать по отделам.

[and3008]

Упорядочить по группам - хорошая идея, но по моему не реальная. Есть один способ. Вввести ScopeID на компах. Тогда они увидят только те компы, у которых ScopeID одинаковый. Этакий аналог VLAN.
Только вот с серверами может быть загвоздочка. Комп должен иметь какой-то ScopeID, и два или три сразу их быть не может.

[Dmitry.Karpov http://www.]

Как я понял из сбивчивых объяснений кого уже не помню в ныне покойной HelpSelf, ScopeID вообще не позволяет компьютерам иметь доступ друг к другу, т.е. в сетИ м.б. несколько машин с одинаковыми именами и разным ScopeID. Соответственно, машины будут не сгруппированы, а просто разделены между собой и доступны только по IP-адресу, т.к. при указании \\компьютер\шара нельзя указать конкретный ScopeID. (smbclient из Samba под Unix, вроде, это может делать, но это же Unix...)