Not unless you make Netlogon dependent on DNS in the startup order. That should be a standard practice.
Sincerely,
_____
(, / | /) /) /)
/---| (/_ ______ ___// _ // _
) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/ /)
(/
Microsoft MVP - Directory Services
www.readymaids.com - we know IT
www.akomolafe.com
-5.75, -3.23
Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon
From: [EMAIL PROTECTED]
Sent: Thu 7/13/2006 1:20 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
One point that is nearly always overlooked is the following, if a DC points to itself for DNS name res:
The DNS server service starts *after* NETLOGON, at startup
The DNS server service stops *before* NETLOGON, at shutdown
i.e.
at startup netlogon cannot register DNS records on the local machine until the DNS server starts (record reg may fail or be stalled / time out).
at shutdown or during a demotion netlogon cannot un-register DNS records on the local machine since DNS server has stopped (demotion will leave DC records in tact).
For these reasons alone - I always recommend that a DC points to another (local) DNS server (not necessarily a DC) and then itself as secondary (or maybe even tertiary).
my 2 penneth,
neil
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: 13 July 2006 02:59
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Always point a DC with DNS installed to itself as the preferred DNS server...always?
You don't work at the post office do you? ;)
There are many many many ways to properly configure DNS. One thing that helps is to think of the terms client and server vs. preferred and alternate only. You are configuring a preferred server and an alternate server that you want this DC to be a client of.
DNS is a standard. Windows 2003 DNS follows those standards (comments really, but let's not pick right?) Microsoft has done some enhancements above and beyond that make DNS play very well in the Microsoft sphere[1]. You can however have DNS that is a third party DNS system, such as BIND. Active Directory plays very well with such third party DNS systems. You could have your domain controllers not have any DNS hosted on them at all. You could have it hosted, but as a secondary zone. You could also have it AD integrated meaning that you have a listener for DNS but the data(base) is stored in the active directory.
Something to clarify: what you're talking about is making the DC a *client* to another DNS server that hosts the zones. You're also talking about making dc1 a client of dc2 and vice versa. That's silly, but I'll get to that.
If you have your dns hosted on a third party system such as BIND, you'll have one server as the primary (not best practice, but you get the idea; in practice you'd have multiple for failure tolerance wan traffic optimization) and your DC would be a client of that system.
If you have a traditional DNS hierarchy that has primary and secondary transfers, you would be mimicking BIND topology and again could configure your DC's to be clients of the BIND or Microsoft DNS servers.
If you have the the DNS AD-Integrated, then after initial replication you should have the client configured to use itself as the DNS server. That'd be the best practice. Before 2003 you could have an "island effect" where because you didn't have a full picture of the directory, you might not have all the records needed to fully *see* the entire DNS names list effectively creating an island of a DC. In 2003 some additional code was put in to make sure that doesn't happen. You need to be a client of a working DNS to join the domain and to find the other DC's when you get promoted. After replication completes, you have a full list and there's no need to continue as a client of a server that has the same information you do.
So, what's silly about having your server configured to be a client of a dns server that has the same information? I find it amusing that if the server wants to find something he'll ask his neighbor if he has the information when he could just ask himself. It's brain dead in my opinion and very difficult to troubleshoot. In addition, and more importantly it breaks the idea of a fabric design because now dc1 and dc2 are reliant on each other to be operational. If either is down, both are down and that's ridiculous considering how easy it is to prevent that situation. But wait! you say? He should try the partner first and if that fails use himself right? Yes but. :) He'll try the neigbor first, because that's the preferred. He'll also register there etc. The worst part is that if he tries the partner and the partner is not completely dead, he'll not try himself even if he has the right information.
Now, will it work? Yes. Is it a good idea? Absolutely not and shows a lack of understanding on the part of the folks that deployed it. From the sounds of it, an unwillingness to fix the underlying issues that led them there as well. On the other hand, they're spot on if it's W2K vs. K3 :)
Does that help?
[1] unless you like a granular audit logging. But that's neither here nor there.
On 7/12/06, Victor W. <[EMAIL PROTECTED]> wrote:
Today a conversation at my job came up about setting the preferred DNS server on the NIC of a DC with DNS installed.For as far as I know it's best to point the DC (with DNS installed) to itself for DNS by specifying the internal IP address of the DC as the preferred DNSserver on the NIC.Then I was told that this is not always necessary and this puzzled me a bit.Not everybody was convinced of the above and this got me thinking. Some people are claiming that it doesnt really matter if you set that DC to be the preferred or the alternate DNS server.I was then showed an environment where all DC's in a child domain (all had DNS installed), had the same DNS server set as preferred DNS server.Perhaps an example will make it more clear:a forest root domain with 4 child domains.child domain A, B, C, and D.Names of the Domain Controllers:root domain: DC-A & DC-B & DC-C & DC-Dfor child domain A: DC-A1 & DC-A2for child domain B: DC-B1 & DC-B2for child domain C: DC-C1 & DC-C2for child domain D: DC-D1 & DC-D2DC-A1 has specified DC-A2 as preferred DNS server and has specified DC-A1 (itself) as alternate DNS server.DC-A2 has specified DC-A2 (itself) as preferred DNS server and has specified DC-A1 as alternate DNS serverDC-B1 has specified DC-B2 as preferred DNS server and has specified DC-B1 (itself) as alternate DNS serverDC-B2 has specified DC-B2 (itself) as preferred DNS server and has specified DC-B1 as alternate DNS serverAnd so on for the other child domains.I was told that this was done because this AD environment was not optimal and that by pointing all the dc's in a child domain to the same DNS server, other issues were prevented from occuring.This didnt sound all that good to me to be honoust :-)I am now wondering if there are scenario's thinkable when it would be better not to point a DC with DNS installed as the preferred server on it's NIC.Does the term Island DNS also play a role in this?
PLEASE READ: The information contained in this email is confidential and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and delete your
copy from your system. You must not copy, distribute or take any further
action in reliance on it. Email is not a secure method of communication and
Nomura International plc ('NIplc') will not, to the extent permitted by law,
accept responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence of any virus, worm or similar malicious or disabling
code in, this message or any attachment(s) to it. If verification of this
email is sought then please request a hard copy. Unless otherwise stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely those of
the author and do not necessarily represent those of NIplc; (3) is intended
for informational purposes only and is not a recommendation, solicitation or
offer to buy or sell securities or related financial instruments. NIplc
does not provide investment services to private customers. Authorised and
regulated by the Financial Services Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura group of companies.