Sergey OrlovПосле этого как все заработает, начинаете изворачиваться, а именно, на контроллере в качестве первичника ставите его реальный ip, а не 127.0.0.1, в качестве вторичника контроллера с ролями PDC и владельца глобального каталога, все остальные контроллеры добавляете ниже..
Dimitry Sibiryakov Максималисты... Может, ещё и винты отформатировать?..
Просто пропиши в свойствах каждого сетевого соединения каждому контроллеру все свои
контроллеры на которых поднята роль DNS сервера в одном и том же порядке. Потом
перерегистрируй в DNS все контроллеры с помощью dcdiag и немного (сутки-двое) подожди.
Т.е. если у тебя DNS-ы на DC1 и DC2, то везде адрес DC1 должен быть прописан как
первичный DNS сервер, а DC2 - как вторичный. Не вздумай прикинуться хитрым и прописать
адрес локального DNS как первичный DNS потому что "он ближе".
Сделаем идеальный майкрософт вариант?... :)
Чувак из ADS Team описал порядок, который они практически везде используют.
Ни разу не пожалел, что использовал эти бест практисы.
Читаем первые три бест практиса.
Question
What is Microsoft's best practice for where and how many DNS servers exist? What about for configuring DNS client settings on DC’s and members?
Answer
It depends on who you ask. :-) We in MS have been arguing this amongst ourselves for 11 years now. Here are the general guidelines that the Microsoft AD and Networking Support teams give to customers, based on our not inconsiderable experience with customers and their CritSits:
1. If a DC is hosting DNS, it should point to itself at least somewhere in the client list of DNS servers.
2. If at all possible on a DC, client DNS should point to another DNS server as primary and itself as secondary or tertiary. It should not point to self as primary due to various DNS islanding and performance issues that can occur. (This is where the arguments usually start)
3. When referencing a DNS server on itself, a DNS client should always use a loopback address and not a real IP address.
4. Unless there is a valid reason not to that you can concretely explain with more pros than cons, all DC’s in a domain should be running DNS and hosting at least their own DNS zone; all DC’s in the forest should be hosting the _MSDCS zones. This is default when DNS is configured on a new Win2003 or later forest’s DC’s. (Lots more arguments here).
5. DC’s should have at least two DNS client entries.
6. Clients should have these DNS servers specified via DHCP or by deploying via group policy/group policy preferences, to avoid admin errors; both of those scenarios allow you to align your clients with subnets, and therefore specific DNS servers. Having all the clients & members point to the same one or two DNS servers will eventually lead to an outage and a conversation with us and your manager. If every DC is a DNS server, clients can be fine-tuned to keep their traffic as local as possible and DNS will be highly available with special work or maintenance. It also means that branch offices can survive WAN outages and keep working, if they have local DC’s running DNS.
7. We don’t care if you use Windows or 3rd party DNS. It’s no skin off our nose: you already paid us for the DC’s and we certainly don’t need you to buy DNS-only Windows servers. But we won’t be able to assist you with your BIND server, and their free product’s support is not free.
(Other things I didn’t say that are people’s pet peeves, leading to even more arguments).
There are plans afoot to consolidate all this info, expand it, and get our message consistent and consolidated. This has started in the Windows Server 2008 R2 BPA for DNS. We also recently released a new namespace planning site that explains and prevents some design pitfalls:
DNS Namespace Planning Solution Center
http://support.microsoft.com/namespace
And we offer this great guide and portal site:
Creating a DNS Infrastructure Design
http://technet.microsoft.com/en-us/library/cc725625(WS.10).aspx
DNS Portal
http://technet.microsoft.com/en-us/network/bb629410.aspx
Now flame on.
