Пытаюсь настроить связку win2k3+bind 9.3.0,
делал по доке
http://babs.its.yale.edu/yalead/ddns.asp10.1.0.6 - freebsd 5.4 primary dns
10.1.0.162 - win2k3 ADклиенты получают от dhcp сервер имен 10.1.0.6
проблема: после настройки, не отрабатывает nslookup (значит зона не делегируется?)
# nslookup
> _msdcs.domen.ru
Server: dns.domen.ru
Address: 10.1.0.6*** dns.domen.ru can't find _mscds.domen.ru: Non-existent domain
С ad01.domen.ru всё отрабатывает, соответственно не поменяв на клиенте днс сервер с 10.1.0.6 на 10.1.0.41 в домен не пускает....
Если поставить в named.conf recursion false; или убрать forwarders,
То nslookup c клиентов отрабатывает> set type=ns
> _udp.domen.ru
Server: dns.domen.ru
Address: 10.1.0.6_udp.domen.ru nameserver = ad01.domen.ru
ad01.domen.ru internet address = 10.1.0.162
> _msdcs.domen.ru
Server: dns.domen.ru
Address: 10.1.0.6_msdcs.domen.ru nameserver = ad01.domen.ru
ad01.domen.ru internet address = 10.1.0.162
Почему запросы уходят на forwarders, а не на делегируемую зону?
как быть?
конфиги:named.conf
key "rndc-key" {
algorithm hmac-md5;
secret "*********";
};controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};acl "net" { 10.1.0.0/16; 127.0.0.1; };
acl "ad" {10.1.0.162; };options {
directory "/etc/namedb";
version "NONE OF YOUR BUSINESS";
allow-query { "net"; };
forwarders { xxx.xxx.xxx.xxx; };zone "." {
type hint;
file "named.root";};
zone "0.0.127.in-addr.arpa" {
type master;
file "master/localhost.rev";
notify no;};
zone "domain.ru" {
type master;
file "master/domen.ru";
check-names ignore;
allow-transfer { net; };};
zone "1.10.in-addr.arpa" {
type master;
file "master/10";
allow-transfer { net; };};
файл зоны..
$TTL 86400
@ IN SOA dns.domen.ru. admin.domen.ru. (
2005120704 ; serial, todays date + todays serial
3600 ; refresh, seconds
900 ; retry, seconds
3600000 ; expire, seconds
3600 ) ; minimum, seconds
IN NS dns.domen.ru.
IN NS bind.domen.ru.
_msdcs IN NS ad01.domen.ru.
_tcp IN NS ad01.domen.ru.
_udp IN NS ad01.domen.ru.
_sites IN NS ad01.domen.ru.
ForestDNSZones IN NS ad01.domen.ru.
DomainDNSZones IN NS ad01.domen.ru.
MX 10 mail.domen.ru.
localhost IN A 127.0.0.1
ad01 IN A 10.1.0.162
dns IN A 10.1.0.6
bind IN A 10.1.0.7
mail IN A 10.1.0.25
в файле зоны зона называется domain.ru, а в записи СОА domen.ru =)
zone "domain.ru"
@ IN SOA dns.domen.ru. admin.domen.ru. (
> в файле зоны зона называется domain.ru, а в записи СОА domen.ru
>=)
>zone "domain.ru"
>@ IN
> SOA dns.domen.ru. admin.domen.ru. (
Сорри это просто описка, в конфиги везде domen.ru.
Есть еще мысли? :)
>Почему запросы уходят на forwarders, а не на делегируемую зону?
Если настроен forwarder, то все запросы для неавторитетных зон (а делегирование не делает его авторитетным для этих зон) перенаправляются на forwarder. Насколько я помню, в bind можно настроить forwarder для зоны.
zone _msdcs.domen.ru {
type forward;
forwarders { 10.1.0.162; };
forward only;
};
>zone _msdcs.domen.ru {
> type forward;
> forwarders { 10.1.0.162; };
> forward only;
>};
спасибо
а файлы зоны, для этого случая, обязательно создавать?
помоему в моём случае проще закоментировать forwarders (серваки провайдера) в options, ,благо на скорости обработки запросов это не сильно повлияло :)
>а файлы зоны, для этого случая, обязательно создавать?
Нет.
>помоему в моём случае проще закоментировать forwarders (серваки провайдера) в options, ,благо
>на скорости обработки запросов это не сильно повлияло :)
ИМХО в Вашем случае лучше вообще убрать BIND и делать все на родном Microsoft DNS. Назовите хоть одну реальную причину для сохранения BIND?
>ИМХО в Вашем случае лучше вообще убрать BIND и делать все на
>родном Microsoft DNS. Назовите хоть одну реальную причину для сохранения >BIND?
В ближайшем будушем собираемся перетаскивать зону с провайдера на себя и выставлять днс наружу, а выставлять винду наружу, по моему не есть хорошо,патчить её постоянно, да и вообще помоему это муветон, практически не встречал внешних днс на мурософте, а вот для локалки можно конечно и перетащить всё на винду, но зачем это делать если можно просто создать зону для виндовых машин для их авторизации и работы в АД, и оставить струтуры сети.
а разрешать теже динамически обновления, когда практически любой юзер взяв
nsupdate может натворить много зла....
Microsoft предлагает четыре варианта, "как быть", был выбран 2ой,
выдержка из статьи http://babs.its.yale.edu/yalead/ddns.asp
A Microsoft white paper (and other information) documents four models for managing Active Directory DNS information in the presence of BIND name servers:1. Run the BIND servers in dynamic mode. All dynamic functions are enabled so the AD performs in much the same way is if the DNS servers were Windows 2000 machines. Typically, only a specific set of machines (usually the W2K domain controllers) are allowed to make changes to the DNS records because secure update is not supported. BIND versions 4.9 and higher support dynamic update.
2. Use a combination of BIND and W2K DNS servers. In this model, the BIND servers are in static mode and the Windows 2000 servers are dynamic. The BIND ervers remain the authoritative name servers for theorganization. Records of type NS ("delegation" records) are used so that the Windows servers handle all AD-specific traffic and BIND servers handle the rest. This is also somewhat more secure because the W2K servers can run in "secure" mode so that changes to the DNS information must be authenticated.
3. Move all Active Directory activity into a separate DNS zone. All machines that participate in the AD are moved into a DNS zone of their own, usually under the main DNS zone for the organization. For example, an organization might make a DNS zone called "ad.company.com" under their main "company.com" DNS zone. The Active Directory is then "rooted" at "ad.company.com". This created a dichotomy between the DNS structure of the company and its AD structure in many cases, which has the potential for confusion.
4. Manually manage DNS information by hand-editing DNS tables to include SRV records for the critical services. In this model, the DNS entries that would normally have been made automatically by the servers to register their functions with the AD are entered by hand into a static name server. Since a single DC can make 30 or more entries in the DNS system, this quickly becomes a huge amount of work. Also, since the information is dynamic, the AD loses some of its fault tolerance because the DNS system can not be updated automatically to reflect changes in the environment such as a server that is out of action or a role change. This model would work in a very small domain that is extraordinarily stable, but is impractical for most real-world operations.
>В ближайшем будушем собираемся перетаскивать зону с провайдера на себя и выставлять
>днс наружу, а выставлять винду наружу, по моему не есть хорошо,патчить
>её постоянно, да и вообще помоему это муветон, практически не встречал
>внешних днс на мурософте,
Полностью согласен.
>а вот для локалки можно конечно и
>перетащить всё на винду, но зачем это делать если можно просто
>создать зону для виндовых машин для их авторизации и работы в
>АД, и оставить струтуры сети.
>а разрешать теже динамически обновления, когда практически любой юзер взяв
>nsupdate может натворить много зла....
DNS интегрированный в AD поддерживает безопасные обновления (ACL).
>Microsoft предлагает четыре варианта, "как быть", был выбран 2ой,
>выдержка из статьи http://babs.its.yale.edu/yalead/ddns.asp
ИМХО удобнее сделать внешний сервер на BIND, а внутренний на MS DNS (держит всю зону domen.ru) с forward на BIND. Хотя конечно дело Ваше.
Еще не забудьте тогда после внесения изменения в
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RegisterDnsARecords
добавить статические записи на MS DNS:
domen.ru IN A 10.1.0.162
gc._msdcs.domen.ru IN A 10.1.0.162
>ИМХО удобнее сделать внешний сервер на BIND, а внутренний на MS DNS >(держит всю зону domen.ru) с forward на BIND. Хотя конечно дело Ваше.
Согласен,логично, может в итоге даже так и будет, пока только тестируем связку :)>Еще не забудьте тогда после внесения изменения в
>HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RegisterDnsARecords
>добавить статические записи на MS DNS:
>domen.ru IN A 10.1.0.162
Первые два пункта уже сделаны :)
>gc._msdcs.domen.ru IN A 10.1.0.162
А для чего эта запись? и нужно ли для них обратку прописывать?> DNS интегрированный в AD поддерживает безопасные обновления (ACL).
Листы кому можно обновлять ?
где бы почитать про это? или в двух словах в моей данной схеме это требуется?
Просто Если с Unixom я знаком более менее хорошо, то серверную винду только изучаю, и то потому что босы сказали хотим блин Виндовую сетку вместо Новеловой :)
Пардон. Эту запись нужно сделать на BIND
domen.ru IN A 10.1.0.162
а эту на MS DNS
gc._msdcs.domen.ru IN A 10.1.0.162
>А для чего эта запись? и нужно ли для них обратку прописывать?
Определяет Глобальный каталог (GC). Достаточно важная запись. После правки параметра реестра контроллер перестает ее обновлять. Полный список записей можете посмотреть на контроллере домена в файле
%systemroot%\system32\config\netlogon.dns
>> DNS интегрированный в AD поддерживает безопасные обновления (ACL).
>Листы кому можно обновлять ?
Кому разрешите, тот и будет. Например, разрешить только учетным записям компьютеров в домене. При чем компы смогут менять только свои записи, но не чужие.
>где бы почитать про это?
В инете полно инфы, книг тоже.
>или в двух словах в моей
>данной схеме это требуется?
Зависит от задач, политики и т.п. Решать только Вам.
>Пардон. Эту запись нужно сделать на BIND
>domen.ru IN A 10.1.0.162а разве не "ad01.domen.ru IN A 10.1.0.162" ?
>а эту на MS DNS
>gc._msdcs.domen.ru IN A 10.1.0.162
>>А для чего эта запись? и нужно ли для них обратку прописывать?
>Определяет Глобальный каталог (GC). Достаточно важная запись. После правки параметра реестра контроллер
>перестает ее обновлять. Полный список записей можете посмотреть на контроллере домена
>в файле
>%systemroot%\system32\config\netlogon.dns
>>> DNS интегрированный в AD поддерживает безопасные обновления (ACL).
>>Листы кому можно обновлять ?
>Кому разрешите, тот и будет. Например, разрешить только учетным записям компьютеров в
>домене. При чем компы смогут менять только свои записи, но не
>чужие.
Спасибо, будем разбираться.
>а разве не "ad01.domen.ru IN A 10.1.0.162" ?
Нет. Именно
domen.ru IN A 10.1.0.162
>>а разве не "ad01.domen.ru IN A 10.1.0.162" ?
>Нет. Именно
>domen.ru IN A 10.1.0.162
А исходя из каких соображений?
в доках вроде написано
"You also need to make sure that a normal internet "A" record is in place on the static name server which maps your machine's name to its correct ip number."
>>В ближайшем будушем собираемся перетаскивать зону с провайдера на себя и выставлять
>>днс наружу, а выставлять винду наружу, по моему не есть хорошо,патчить
>>её постоянно, да и вообще помоему это муветон, практически не встречал
>>внешних днс на мурософте,
>Полностью согласен.
>>а вот для локалки можно конечно и
>>перетащить всё на винду, но зачем это делать если можно просто
>>создать зону для виндовых машин для их авторизации и работы в
>>АД, и оставить струтуры сети.
>>а разрешать теже динамически обновления, когда практически любой юзер взяв
>>nsupdate может натворить много зла....
>DNS интегрированный в AD поддерживает безопасные обновления (ACL).
>>Microsoft предлагает четыре варианта, "как быть", был выбран 2ой,
>>выдержка из статьи http://babs.its.yale.edu/yalead/ddns.asp
>ИМХО удобнее сделать внешний сервер на BIND, а внутренний на MS DNS
>(держит всю зону domen.ru) с forward на BIND. Хотя конечно дело
>Ваше.
Немного не согласен - кроме того бинд лучше сделать секондарем для зоны АД - ИМХО так красивше и резолвиться все отовсюду и есно все заацлить :)
>Немного не согласен - кроме того бинд лучше сделать секондарем для зоны
>АД - ИМХО так красивше и резолвиться все отовсюду и есно
>все заацлить :)
В чем преимущество вторичной зоны на BIND перед интегрированной в AD на двух контроллерах домена? Аргумент "красивше" оставьте для девушек :)
>>Немного не согласен - кроме того бинд лучше сделать секондарем для зоны
>>АД - ИМХО так красивше и резолвиться все отовсюду и есно
>>все заацлить :)
>В чем преимущество вторичной зоны на BIND перед интегрированной в AD на
>двух контроллерах домена? Аргумент "красивше" оставьте для девушек :)А в том что с уникса имена в домене тоже разрешаться будут.
>А в том что с уникса имена в домене тоже разрешаться будут.
Сори, но детский сад.
>>А в том что с уникса имена в домене тоже разрешаться будут.
>Сори, но детский сад.Какова типа? Что не так - чем расстроил?
>Какова типа? Что не так - чем расстроил?
Хотите сказать, что если DNS от Microsoft, то с unix имена в домене разрешаться не будут?
еще вопросик в тему...на какие грабли я могу наступить в дальнейшем если уберу галочку у виндовых станций "регситрировать это подключение в ДНС"?
А то в логи вываливаются постоянные попытки это проделать как самим сервером так и клиентами:
Dec 8 15:19:06 dns named[82442]: client 10.1.1.86#1872: update '1.10.in-addr.arpa/IN' denied
Dec 8 15:43:58 dns named[82442]: client 10.1.0.162#1067: update 'domen.ru/IN' denied
Dec 8 15:43:58 dns named[82442]: client 10.1.0.162#1067: update 'domen.ru/IN' denied
Dec 8 15:43:58 dns named[82442]: client 10.1.0.162#1067: update '1.10.in-addr.arpa/IN' denied
>еще вопросик в тему...на какие грабли я могу наступить в дальнейшем если
>уберу галочку у виндовых станций "регситрировать это подключение в ДНС"?
>А то в логи вываливаются постоянные попытки это проделать как самим сервером
>так и клиентами:
>Dec 8 15:19:06 dns named[82442]: client 10.1.1.86#1872: update '1.10.in-addr.arpa/IN' denied
>Dec 8 15:43:58 dns named[82442]: client 10.1.0.162#1067: update 'domen.ru/IN' denied
>Dec 8 15:43:58 dns named[82442]: client 10.1.0.162#1067: update 'domen.ru/IN' denied
>Dec 8 15:43:58 dns named[82442]: client 10.1.0.162#1067: update '1.10.in-addr.arpa/IN' deniedНу тебе нужно чтобы машины всегда пинговылись своим Винь-именем и резолвились через обратную зону или нет?
>Ну тебе нужно чтобы машины всегда пинговылись своим Винь-именем и резолвились через
>обратную зону или нет?
врятли, зачем обычным клиентским тачкам резолвится через обратную зону
и пинговаться по вин имени.
>еще вопросик в тему...на какие грабли я могу наступить в дальнейшем если
>уберу галочку у виндовых станций "регситрировать это подключение в ДНС"?
Не готов сейчас сказать о возможных проблемах, но клиенты работать будут. В Вашем случае тогда лучше делегировать еще зону clients.domen.ru на MS DNS, изменить клиентам доменных суффикс на clients.domen.ru и убрать галку "Изменять доменный суффикс при смене домена" (вроде так называется). Ну или руками заносить все записи.
>>Какова типа? Что не так - чем расстроил?
>Хотите сказать, что если DNS от Microsoft, то с unix имена в
>домене разрешаться не будут?ХА! Если Бинд ухом не ведет что есть внутренняя зона на сервере DNS от Microsoft то "ДА!" :)))))))))))
А если добавить в бинд униховый секондари зоны для домена АД или зоны пересылки на Винь-ДНС то будут.
>ХА! Если Бинд ухом не ведет что есть внутренняя зона на сервере
>DNS от Microsoft то "ДА!" :)))))))))))
>А если добавить в бинд униховый секондари зоны для домена АД или
>зоны пересылки на Винь-ДНС то будут.
Я Вам про Фому, Вы мне про Ерему... Речь о том, что для этого неважно, на чем работает DNS. У нас стоят linux и все работают через MS DNS интегрированный в AD. А то, что у Вас не работает на unix разрешение внутренних имен без вторичной зоны на BIND - Ваши личные интимные проблемы и непродуманный план внедрения службы DNS организации.
>>ХА! Если Бинд ухом не ведет что есть внутренняя зона на сервере
>>DNS от Microsoft то "ДА!" :)))))))))))
>>А если добавить в бинд униховый секондари зоны для домена АД или
>>зоны пересылки на Винь-ДНС то будут.
>Я Вам про Фому, Вы мне про Ерему... Речь о том, что
>для этого неважно, на чем работает DNS. У нас стоят linux
>и все работают через MS DNS интегрированный в AD. А то,
>что у Вас не работает на unix разрешение внутренних имен без
>вторичной зоны на BIND - Ваши личные интимные проблемы и непродуманный
>план внедрения службы DNS организации.офф-топик - обсуждается конкретная ситуация
>офф-топик - обсуждается конкретная ситуация
Так вот именно в этой конкретной ситуации после прописывания зон типа forward на BIND или удаления forwarders (о чем и писал Saler) все будет работать и без вторичной зоны. Другое дело, если внешнее и внутреннее имена не совпадают (domen.ru и domen.local, соответственно). Но и здесь можно обойтись без вторичной зоны. Просто прописать на сервере с BIND в resolv.conf адрес внутреннего MS DNS и будут разрешаться как внутренние имена, так и внешние. А можно вообще не указывать, поскольку не вижу реальной необходимости внешнему DNS серверу разрешать внутренние имена.
>>офф-топик - обсуждается конкретная ситуация
>Так вот именно в этой конкретной ситуации после прописывания зон типа forward
>на BIND или удаления forwarders (о чем и писал Saler) все
>будет работать и без вторичной зоны. Другое дело, если внешнее и
>внутреннее имена не совпадают (domen.ru и domen.local, соответственно). Но и здесь
>можно обойтись без вторичной зоны. Просто прописать на сервере с BIND
>в resolv.conf адрес внутреннего MS DNS и будут разрешаться как внутренние
>имена, так и внешние. А можно вообще не указывать, поскольку не
>вижу реальной необходимости внешнему DNS серверу разрешать внутренние имена.Жжжешь!!!
0. Как следует из конфигурации Saler-а Вы вообще не понимаете чего пишишьте или просто _Вам_ уперлось поспорить со мной или я _Вам_ не нравлюсь :)
1. Совпадает-не совпадает - бред сразу - читать split dns
2. Если Уних бут сначала слать ДНС на МС, а тот форвардить обратно на него - очень неоптимально все будет.
3. Это не совсем внешний DNS как видно из пункта 0 - опять читать split dnsКакой-то неоптимальный Вы "батюшка" ;))) Надеюсь хоть Saler все понял %)
>0. Как следует из конфигурации Saler-а Вы вообще не понимаете чего пишишьте
Я абсолютно понимаю, что пишу.
>или просто _Вам_ уперлось поспорить со мной или я _Вам_ не
>нравлюсь :)
Ничего личного :)
>1. Совпадает-не совпадает - бред сразу - читать split dns
Бред, если Вы не учитываете это при планировании DNS для AD.
>2. Если Уних бут сначала слать ДНС на МС, а тот форвардить
>обратно на него - очень неоптимально все будет.
Он будет работать (резолвер униха, а не BIND) как все клиенты локальной сети и использовать кэш уже разрешенных имен на внутреннем DNS, что ускорит работу и уменьшит количество запросов в Инет. Гораздо неоптимальней будет настраивать вторичную зону и возможность раскрытия внутренних имен при компрометации BIND-а. Да и о какой конкретно зоне Вы говорите в случае Saler?
>3. Это не совсем внешний DNS как видно из пункта 0 -
>опять читать split dns
Вы невнимательно читаете. Saler сказал, что "В ближайшем будушем собираемся перетаскивать зону с провайдера на себя и выставлять днс наружу". Т.е. это будет внешний сервер.
>Какой-то неоптимальный Вы "батюшка" ;))) Надеюсь хоть Saler все понял %)
Saler меня прекрасно понял. Неоптимально устанавливать и настраивать то, без чего можно спокойно обойтись. К сожалению, от Вас пока только слова и никакой конкретики.
Не ссортесь...
Я понял что рассмотреть стоит два варианта, ну и конечно почитать побольше про винду :)
Спасибо.