Questions on putting up a new DNS server.

[Guest]

Hello, I'd like to put up a new DNS server in my W2K AD, but I have a few
questions.

Currently my W2K AD (containing a Root domain and a User domain) has three
microsoft DNS servers serving it.

DC_A - is a DC in the User Domain and contains AD intregrated zones for
root, user and is primary for a static zone containing our legacy unix stuff.
site DNS clients are configured to use the server for lookups (configured
as the first entry)
----------------------------------------------------------------------------------
DC_B - is a DC in the User Domain and contains AD intregrated zones for
root, user and is a secondary for a static zone containing our legacy unix
stuff. site DNS clients are configured to use the server for lookups
(second entry)
-----------------------------------------------------------------------------------
Serv_C - is a member server in the User Domain configured as a
forwarder-only. It contains no zone files itself and refers to DC_A and DC_B
for all the answers. a sub-section of the site DNS clients are configured
to use the server for lookups (as the first entry).

The AD zone files list DC_A and DC_B as the zone Name Servers (NS records)
for the zones.

Questions:

1) Which server are AD updates done on. Is this controlled by the NS
entries in the zone files (and if so is order of records important) or by the
server a client contacts, but is so, then how do clients using Serv_C do
updates since it is not a DC. If I put up a new server do I need to make
sure it has an NS record in the user domain for it to do dynamic update work.

2) Right now DC_A and DC_B sit in the user domain. If I put up a new
server, does it need to be in the user domain or can it be in the root
domain. I thought I read cross domain servers were not allowed (at least for
dynamic AD-intregrated zone).

3) As you would expect the root DCs do less work. Would it be better to
have the DNS servers in that domain. and if so, what is the best method to
get the service moved over there from the user domain.

4) This is likely obvious, but I'll ask it anyway, can an non-DC host
AD-intregrated zones (or participate other than how I've done it above, that
is as a forwarder only).

5) I'll be upgrading my W2K AD to W2K3 sometime this summer. Does that have
any effect on the answers to the questions above.

 

[Kevin D. Goodknecht Sr. [MVP]]

Hello, I'd like to put up a new DNS server in my W2K AD, but I have a
few
questions.

Currently my W2K AD (containing a Root domain and a User domain) has
three
microsoft DNS servers serving it.

DC_A - is a DC in the User Domain and contains AD intregrated zones
for
root, user and is primary for a static zone containing our legacy
unix stuff.
site DNS clients are configured to use the server for lookups
(configured
as the first entry).
----------------------------------------------------------------------------------
DC_B - is a DC in the User Domain and contains AD intregrated zones
for
root, user and is a secondary for a static zone containing our legacy
unix
stuff. site DNS clients are configured to use the server for
lookups
(second entry).
-----------------------------------------------------------------------------------
Serv_C - is a member server in the User Domain configured as a
forwarder-only. It contains no zone files itself and refers to DC_A
and DC_B
for all the answers. a sub-section of the site DNS clients are
configured
to use the server for lookups (as the first entry).

The AD zone files list DC_A and DC_B as the zone Name Servers (NS
records)
for the zones.

Questions:

1) Which server are AD updates done on. Is this controlled by the NS
entries in the zone files (and if so is order of records important)
or by the
server a client contacts, but is so, then how do clients using Serv_C
do
updates since it is not a DC. If I put up a new server do I need to
make
sure it has an NS record in the user domain for it to do dynamic
update work.

All AD integrated zones are a master zone and is replicated to other DCs in
the domain through Active Directory Replication. If one DC in a Domain has
an AD zone, all DCs in the domain will get the zone replicated to them.

2) Right now DC_A and DC_B sit in the user domain. If I put up a new
server, does it need to be in the user domain or can it be in the root
domain. I thought I read cross domain servers were not allowed (at
least for
dynamic AD-intregrated zone).

Under Win2k, the DCs for other domains will not get the AD zone replicated
to them, you will need a secondary zone to allow a DC in one domain to
resolve the domain on another DC.

3) As you would expect the root DCs do less work. Would it be better
to
have the DNS servers in that domain. and if so, what is the best
method to
get the service moved over there from the user domain.

How many DC/DNS servers are in the Root domain and is there a root DC at
each location?

4) This is likely obvious, but I'll ask it anyway, can an non-DC host
AD-intregrated zones (or participate other than how I've done it
above, that
is as a forwarder only).

Not under Win2k, non DCs will have to use secondary zones.

5) I'll be upgrading my W2K AD to W2K3 sometime this summer. Does
that have
any effect on the answers to the questions above.

It has a big effect on your scenario, Win2k3 introduced conditional
Forwarders, Stub zones, and Forest Wide replication for DNS zones to all
Win2k3 DNS servers; Members and DCs.
If you had Win2k3, you can greatly simplify the setup by using one of these
options.

 

[Herb Martin]

Questions:

1) Which server are AD updates done on.

All of the AD-Integrated DNS servers for a particular
zone can accept changes.

The 'set' of AD-Integrated DNS servers substitute for
the single Primary which is the only DNS server that can
update a traditional DNS system.

Is this controlled by the NS
entries in the zone files (and if so is order of records important) or by the
server a client contacts, but is so, then how do clients using Serv_C do
updates since it is not a DC.

Clients use AD-DNS they are talking to or work their way
upstream from Secondary to Master to one that can accept the
changes if they are using a secondary.

If I put up a new server do I need to make
sure it has an NS record in the user domain for it to do dynamic update

work.

That would be normal, but it wouldn't be absolutely
necessary for clients to be pointed AT that DNS server
in their NIC properties rather than using this server for
general support of the zone.

2) Right now DC_A and DC_B sit in the user domain. If I put up a new
server, does it need to be in the user domain or can it be in the root
domain. I thought I read cross domain servers were not allowed (at least for
dynamic AD-intregrated zone).

Technically, a DNS server does not have to be in any
domain, must less a specific one (unless it is AD-Integrated
and then it must be a DC in a domain.)

In Win2000 this only makes sense if the DC is in the domain
that the zone supports if it corresponds to an AD Domain.

In Win2003 you can actually replicate one AD-DNS zone/domain
across the DC-DNS servers of the entire forest if you configure
it that way.

3) As you would expect the root DCs do less work. Would it be better to
have the DNS servers in that domain. and if so, what is the best method to
get the service moved over there from the user domain.

What matters is that the DNS used by the clients (on their
NIC properties) are the ALL able to return the SAME answers
(and correct answers), then MOST efficient for your client
and server locations relative to you network.

Technically a client can point to ANY DNS server that resolves
the names correctly.

Note that "servers" are also DNS clients too.

4) This is likely obvious, but I'll ask it anyway, can an non-DC host
AD-intregrated zones

No.

Where would it put it? If it has no AD, it cannot store it's
zone in AD (integrated.)

...(or participate other than how I've done it above, that
is as a forwarder only).

A non-DC can be a secondary, a stub (Win2003 only), or
caching only (no zones but used to find the DNS with the
zones.)

Forwarder is largely irrelevant to this -- a forwarder is
USED by another server to do the resolution and so fits
into one of the above categories once reached (Sec, Stub,
Primary, Caching, or AD-Int.)

5) I'll be upgrading my W2K AD to W2K3 sometime this summer. Does that have
any effect on the answers to the questions above.

Gives you more choices about server type for the zone
and for the replication "scope".

 

[Guest]

First, Thanks to both of you for responding. And Herb, it’s good to see you
are still ‘on-board’ I really appreciated the answers you gave me for
questions I submitted last fall.

Below is a summary of my site, relative to the answers you have already
given me.

Root Domain: contains the DC’s Root_X, Root_Y, and Root_Z. however, since
no AD-DNS exists in the root domain itself, none of these DC’s share in the
Root domain AD-zone info. These DC’s however, are clients of the User domain
AD-DNS servers DC_A and DC_B, so therefore they do successfully populate
their ‘serv’ records into the AD-integrated Root domain housed on servers
DC_A and DC_B. There are no other servers or clients in the Root domain.

User Domain: servers DC_A and DC_B are the only AD-DNS servers in the user
domain (or really the site). However, the other non-DNS DC’s in the User
domain (DC_D and DC_E) do have copies of the User domain via AD replication
from their AD-DNS counter-parts. Member server Serv_C is a cache_only DNS
server which is set to refer to DC_A and DC_B for answers for Root and User
domain questions. All servers (both DC’s and member) are clients of DC_A and
DC_B. Most desktops are also clients of DC_A and DC_B, however, some
desktops are clients of Serv_C and DC_B (in that order).

Servers DC_A and DC_B and Serv_C are also the WINS servers for the site,
with servers DC_B and Serv_C replicating registrations to/from DC_A All
site servers and desktops are configured to list at least two of these
servers in their Wins configuration.

Please comment on the above summary if I have mis-spoken your responses in
any way.


Additional Questions, based on your previous responses {please correct where
I’m wrong}.

1) Can you {very briefly because you have covered this already} explain how
a desktop uses the above infrastructure (who they talk to) when they need to
do intra-forest DNS work. Basically I'd like to make sure I really
understand how clients work, who they talk with in my situation, for example,
how would a client configured to use DC_A differ from a client configured to
use Serv_C?

2) Since all member Servers are either W2K or W2K3. And 97% (there are
still a handful of 9x machines and samba users) of all Desktops are either
W2K or XP -- when is Wins used in my infrastructure. Should we stop
configuring our servers and desktops with Wins, will this force everything to
use DNS. What about browse groups and network neighborhood – how does this
stuff get populated under a DNS-only environment. Will an W2K3-AD
infrastructure be any different {when is Wins going away).

3) Sounds like I should wait to worry about putting any AD-DNS servers into
my Root domain until after I move to W2K3-AD because then the zones will not
have use domain specific AD-replication. Therefore I'll put the new server
(replacing DC_A) back into the User domain.

4) Right now I only have the default site (location) configured. If I add a
new site location {which will include a remote DC in the Root domain and a
remote DC in the User domain} what are your recommendations for DNS at that
remote site {should it be AD-integrated on one of these new DC’s or
cache-only on a member server, or nothing - no local dns server}.

5) Finally, slightly off the subject, but since I am in the process of
building a new AD-DNS (DC) server, do you believe it is good practice to add
Anti-Virus software to Domain Controllers. If you do believe it is good
policy, do you do so with any caveats.

Thanks in advance for your time and your answers. - Bill

 

[Herb Martin]

First, Thanks to both of you for responding. And Herb, it's good to see you
are still 'on-board' I really appreciated the answers you gave me for
questions I submitted last fall.

My pleasure.

Below is a summary of my site, relative to the answers you have already
given me.

Root Domain: contains the DC's Root_X, Root_Y, and Root_Z. however, since
no AD-DNS exists in the root domain itself, none of these DC's share in the
Root domain AD-zone info.

Why do you mention them if they aren't involved?

These DC's however, are clients of the User domain
AD-DNS servers DC_A and DC_B, so therefore they do successfully populate
their 'serv' records into the AD-integrated Root domain housed on servers
DC_A and DC_B. There are no other servers or clients in the Root domain.

It is not illegal but very odd, and probably not
the more reliable, for you to put the AD-integrated
zone for ONE Domain on a different domains DCs.

Especially in Win2000 where there is no cross domain
replication for DNS.

User Domain: servers DC_A and DC_B are the only AD-DNS servers in the user
domain (or really the site). However, the other non-DNS DC's in the User
domain (DC_D and DC_E) do have copies of the User domain via AD replication
from their AD-DNS counter-parts. Member server Serv_C is a cache_only DNS
server which is set to refer to DC_A and DC_B for answers for Root and User
domain questions. All servers (both DC's and member) are clients of DC_A and
DC_B. Most desktops are also clients of DC_A and DC_B, however, some
desktops are clients of Serv_C and DC_B (in that order).

Why are you doing something so complicated? Even the
explanation above is hard to figure out.

Servers DC_A and DC_B and Serv_C are also the WINS servers for the site,
with servers DC_B and Serv_C replicating registrations to/from DC_A All
site servers and desktops are configured to list at least two of these
servers in their Wins configuration.

Please comment on the above summary if I have mis-spoken your responses in
any way.

I would simplify it. Make the DCs in the root domain their
own DNS servers -- integrate them into AD.

Make the DCs in the child domain their own DNS -- integrate
them.

Make the DNS servers in the child domain into DNS Secondaries
for the root. (You have more choices in Win2000 when you finally
upgrade.)

Additional Questions, based on your previous responses {please correct where
I'm wrong}.

1) Can you {very briefly because you have covered this already} explain how
a desktop uses the above infrastructure (who they talk to) when they need to
do intra-forest DNS work.

Well, with my replacement (right above) you can point
child DNS clients at their own DNS where they will find
their own domain info directly and which can find the
parent for them because it will hold a secondary.

Basically I'd like to make sure I really
understand how clients work, who they talk with in my situation, for example,
how would a client configured to use DC_A differ from a client configured to
use Serv_C?

It isn't how clients work, so much as how their DNS
servers work.

Clients ask a DNS Server for resolution -- it is up to
that DNS server to FIND EVERYTHING the client
might ever need:

Domain, child or parent domains, sibling domains, and even
disjoint trees (different names) -- and of course the
Internet for most people.

2) Since all member Servers are either W2K or W2K3. And 97% (there are
still a handful of 9x machines and samba users) of all Desktops are either
W2K or XP -- when is Wins used in my infrastructure. Should we stop
configuring our servers and desktops with Wins, will this force everything to
use DNS.

No, you will need WINS if you have mulitiple subnets.

Almost no one can foregoe NetBIOS resolution, and NetBIOS
resolution requires WINS (practically) for multiple subnets.

What about browse groups and network neighborhood - how does this
stuff get populated under a DNS-only environment.

It does NOT -- you need WINS server.

Will an W2K3-AD
infrastructure be any different {when is Wins going away).

2010 or a bit later probably. <grin>

(It isn't going away for the foreseeable future.)

3) Sounds like I should wait to worry about putting any AD-DNS servers into
my Root domain until after I move to W2K3-AD because then the zones will not
have use domain specific AD-replication. Therefore I'll put the new server
(replacing DC_A) back into the User domain.

If it works you can wait but I don't like it.

It is something of a style issue but I can think of
a bunch of ways it will go bad that aren't necessary
if you clean up the design.

Have the DNS-DCs hold the zones from the same
domain. Have the other domain(s) hold secondaries
for all other zones they cannot reach by recursion.

With multiple DNS trees every DNS server must also
hold EACH tree root as a Secondary -- if you wish to
forward or recurse the Internet.

4) Right now I only have the default site (location) configured. If I add a
new site location {which will include a remote DC in the Root domain and a
remote DC in the User domain} what are your recommendations for DNS at that
remote site {should it be AD-integrated on one of these new DC's or
cache-only on a member server, or nothing - no local dns server}.

This is the reason that I want you to simplify -- DNS on DC from
same domain. If you need a local DC, you need it to have DNS
(and on it is the generally best place.)

5) Finally, slightly off the subject, but since I am in the process of
building a new AD-DNS (DC) server, do you believe it is good practice to add
Anti-Virus software to Domain Controllers. If you do believe it is good
policy, do you do so with any caveats.

If you can do it without messing them up, AND it is
even remotely possible that a DC would become
infected (which it is in almost all cases.)

Thanks in advance for your time and your answers. - Bill

You could call me if you get confused.... phone on web site:
LearnQuick.Com

 

[Guest]

Thanks for the additional reply Herb,

The reason I have the current DNS structure is that when I converted my NT
domain structure to W2K AD – summer 2003, that was how we did it per the
advice/help we got from other administrators who had already gone though the
NT-to-AD migration. Evidently they didn’t understand the cross-domain issues
either…

Anyway, after reading your responses I want to go through a couple of
scenarios with you.

First the Root domain.

If I read you right, I need to install the DNS service on one of my existing
Root DCs and point the others to this DNS server so that they register their
service records with that dns server. Then create a secondary zone for this
new Root AD-integrated zone on the original User domain AD-DNS servers so the
Root domain information is still shared with the User domain clients.

For redundancy I should likely also install the DNS service on a second DC
in the Root domain? And of course that leads to the question, as to whether
I should also put it on the last DC in that domain?

I then need to either add a secondary zone for the User domain onto these
Root DNS servers or point them to the existing User domain AD-DNS servers for
forwarding (lookups).

Since the current User domain AD-DNS servers already look to our parent unix
DNS servers for Internet resolution, just pointing the Root domain DNS
servers to the User domain DNS servers is likely the most obvious choice.


Now back to the User domain.

After I move the Root AD-integrated zone to the Root AD-DNS servers. I need
to remove it from the User AD-DNS servers, but as I said before give it back
into the User domain AD-DNS servers as a secondary zone, so they still have
the Root domain info.

That should clean up the DNS structure and make it more consistent with what
you indicate are good practices.



Client resolution.

The reason I keep harping on this is I don’t really understand how
AD-integrating my zones is useful to DNS operations. I do very much
understand DNS - the old static zone file way. I just don’t get how NON-dns
DCs which have copies of the zone(s) files via AD-replication are useful to
my DNS clients. Since they are not configured within the client DNS
configuration page - how do DNS clients ever use them.

The reason I care is that with AD, I now have the ability to
upgrade/downgrade DC functionality to/from any existing machine. I can also
move the DC roles around (five within the Root domain, three within the User
domain) from DC to DC (great flexibility). Makes disaster recovery and
upgrades (rolling in new hardware, replacement servers) much, much easier.

However, since both DNS and WINS services need to be HARD configured within
each client configuration. If I want to replace server DC_A (a current
DNS/WINS configured server) with new hardware for 1000 existing DNS/WINS
clients. I always have to maintain a DNS/WINS service running on the IP
address that is hard coded into our clients (we don’t use DHCP to configure
our clients) even if I move/remove DC functionality/role to another machine.

I know that your first comment will be that if we weren’t using DHCP to
configure our clients that this would not be an issue, but no point in going
there, static config’s are what we use even for desktop clients.

 

[Herb Martin]

Thanks for the additional reply Herb,

The reason I have the current DNS structure is that when I converted my NT
domain structure to W2K AD - summer 2003, that was how we did it per the
advice/help we got from other administrators who had already gone though the
NT-to-AD migration. Evidently they didn't understand the cross-domain issues
either.

Well remember it is technical feasible and not "wrong" to
do it their way.

Anyway, after reading your responses I want to go through a couple of
scenarios with you.

First the Root domain.

If I read you right, I need to install the DNS service on one of my existing
Root DCs and point the others to this DNS server so that they register their
service records with that dns server.

Yes, but I would start by making this a Secondary of
the existing zone for the domain -- zone transfer the
records from the child DNS domain DNS. Now change
parent to AD-integrated and the child to a secondary.

Remember to fixup the clients (especially of the parent
domain) to reference this root server.

....And then (after DC replication) I would make
the second DC a DNS server -- AD-integrated both.

Now either can do down and the domain and clients
will continue to function.

Then create a secondary zone for this
new Root AD-integrated zone on the original User domain AD-DNS servers so the
Root domain information is still shared with the User domain clients.

Actually you have those zones -- so I would downgrade
it to secondaries as soon as I pulled the zone data to
the new DNS AD-integrated in the root.

For redundancy I should likely also install the DNS service on a second DC
in the Root domain? And of course that leads to the question, as to whether
I should also put it on the last DC in that domain?

Put it on all DCs in such a small domain as AD-integrated.

I then need to either add a secondary zone for the User domain onto these
Root DNS servers or point them to the existing User domain AD-DNS servers for
forwarding (lookups).

The root should DELEGATE to the child domain if it
doesn't already.

I didn't mention that because I was assuming you had done
that -- but since both zones have been on the same server
it would have worked without that delegation so you need
to double check (and delegate if necessary) from parent DNS
to child on other servers.

You could also add a secondary on the parent for the child,
but unless you see a specific need that isn't likely necessary.

Since the current User domain AD-DNS servers already look to our parent unix
DNS servers for Internet resolution, just pointing the Root domain DNS
servers to the User domain DNS servers is likely the most obvious choice.

No, for Internet resolution I would use the same method.

While Forwarding to a Forwarder which Forwards to a Forward
is possible, a chain that becomes too long may cause problems so
leave out UNNECESSARY extra forwarding steps.

Typical is:

Internal DNS fowards direct to ISP DNS or Firewall/DMZ DNS.

I prefer:

Internal DNS fowards direct Firewall/DMZ DNS forwarding to ISP DNS.

 

[Guest]

Herb, I'm sure you're getting tired of this stream so I'll try to finish it
up here...

Fyi: our internal DNS name spaces are dis-contiguous not parent-child.
(root.local and user.local _not_ root.local and user.root.local) that’s why
I keep calling them just Root and User. They are in the same forest but not
related for DNS purposes (contiguous). Why have two. Well the books I read
indicated that the schema should be in its own domain, thus we have the Root
domain just for schema maintenance, but all the real work is done only in the
User domain. Therefore I don’t believe delegation is necessary
here...(yes/no)?

Just one more follow-up question.

You didn’t answer the bottom section of my last response (likely because you
found it rambling and confusing).

I understand that AD-integrated zones allow the non-DNS configured DCs to
have a copy of the zone (kind of like having automatic secondaries). I just
don’t understand how they can be used, be useful in a real environment.

If dns clients can’t be configured to use non-DNS domain DCs (because they
have no DNS service listening on port 53). How are they useful in my AD
forest? I know it’s obvious but I just don’t get it. – bill.

 

[Herb Martin]

Herb, I'm sure you're getting tired of this stream so I'll try to finish it
up here...

That's ok.

Fyi: our internal DNS name spaces are dis-contiguous not parent-child.
(root.local and user.local _not_ root.local and user.root.local) that's why
I keep calling them just Root and User.

It is better to just state the relationship.

Root implied the relatioship was child. In DNS this would
be true always and DNS was the context.

In AD this is also implied for a single name tree.

Only in AD domains (separate from DNS) are the individual
tree "tops" termed "tree root domains."

They are in the same forest but not
related for DNS purposes (contiguous).

Then they are separate trees.

The choice of delegation from the root is now gone (the
other is not a child).

So you must hold what I term "cross secondaries" ---
Root DNS servers hold secondaries for User, while User
does the same for Root.

Also note: The really points out that there is NO such thing
as a "Root DNS" server except in the sense that it might be
the only zone held on that server -- DNS servers can hold
many zones.

Why have two.

There are many reasons, but they all resolve to the fact
that you need two (internal) DNS names to represent
resources.

Well the books I read
indicated that the schema should be in its own domain, thus we have the Root
domain just for schema maintenance, but all the real work is done only in the
User domain.

I disagree with that advice (but understand it), however it
has nothing to do with having two different NAMES.

A parent and child is the usual way to deal with that "advice".

Still nothing wrong with doing what you did -- except it grossly
complicates you DNS, and requires the extra domain controllers.

Therefore I don't believe delegation is necessary
here...(yes/no)?

Not only unnecessary but impossible. <grin>

Cross secondaries are the method (generally) required
in Win2000.

(Conditional forwarding and Stub zones MAY be better
in Win2003.)

Just one more follow-up question.

You didn't answer the bottom section of my last response (likely because you
found it rambling and confusing).

I understand that AD-integrated zones allow the non-DNS configured DCs to
have a copy of the zone
Yes.

...(kind of like having automatic secondaries).

I wouldn't describe it that way -- but it doesn't sound like
you misunderstand.

There are quite different from secondaries since if running
DNS server they are ALL "masters" and can make changes
to the zone.

If not running DNS server the information is not (immediately)
useful -- just passively in AD.

I just
don't understand how they can be used, be useful in a real environment.

Your AD-integrated DNS servers are ALL (together) a substitute
for a single Primary.

They can all resolve the zone and they can all accept changes
(if the zone is dynamic as it should be.)

Secondaries are Read-Only copies. They cannot accept updates.
(They are updated through zone transfers.)

If dns clients can't be configured to use non-DNS domain DCs (because they
have no DNS service listening on port 53). How are they useful in my AD
forest?

They are not -- and they are NOT called AD-Integrated DNS
servers unless the DNS server is running on them and the zone
is defined.

I know it's obvious but I just don't get it. - bill.

You went crossways on the terminology, probably due to
someone explaining that all DCs will have a copy of the
zone if it is AD-integrated.

If it is not a DNS server, that information is practically
worthless. (It is just a bunch of records in AD.)

 

[Guest]

You went crossways on the terminology, probably due to
someone explaining that all DCs will have a copy of the
zone if it is AD-integrated.

If it is not a DNS server, that information is practically
worthless. (It is just a bunch of records in AD.)

So does that mean that you recommend installing the DNS service on ALL or at
least most DCs in a domain when using AD-integrated zones - to make more of
them useful (from a DNS point of view).

Assuming that you say yes to the question above...

Then should the admin configure more (say five or six) DNS servers in each
"client" DNS configuration (instead of just two or three).

Do you think there is there more of a benefit or a penalty for having lots
of DNS servers available to the clients. For example more machines to
answer, but more replication traffic between them. More services to maintain
but more fail-over of service. etc. etc.

 

[Herb Martin]

So does that mean that you recommend installing the DNS service on ALL or at
least most DCs in a domain when using AD-integrated zones - to make more of
them useful (from a DNS point of view).

Yes.

AD is at best handicapped without DNS and at worst
broken without DNS.

In a small domain that is likely the right answer.

It is worth considering installing it on each DC,
and there may not be a reason not to do that, although
I would not automatically say "all" of them must have
it.

With only a few DCs the odds of having all but one "down"
are pretty high, so without DNS you domain won't work
anyway so that means likely having DNS on ever DC.

(As long as you are using AD-integrated anyway, you already
have the records.)

Assuming that you say yes to the question above...

Then should the admin configure more (say five or six) DNS servers in each
"client" DNS configuration (instead of just two or three).

Maybe, but this is likely not as critical.

But I would say 2-4 sounds right.

Do you think there is there more of a benefit or a penalty for having lots
of DNS servers available to the clients.

Benefit for having ONE that works. Fault tolerance will
eventually meet ease of management.

But for the first 2-4 it is likely fault tolerance that should
win the argument.

For example more machines to
answer, but more replication traffic between them.

What replication traffic?

In Win2000, AD integrated DNS replicates to ALL
DCs of the domain anyway.

Even in Win2003 where the scope of replication can
be set to only "DNS-DCs" you still have efficient
Internet vs. rapid Intranet replication due to sites.

More services to maintain
but more fail-over of service. etc. etc.

Yes, and that is the reason you might eventually reach
some practical diminishing returns.

But notice -- it takes about 30 seconds to setup that DNS
server on the DC (and 25 seconds of that is finding the
tool.)

Also note, that you must setup the DC anyway, which is
semi-worthless if it's DNS is unavailable so the extra
few minutes to make it a DNS server is pretty good
insurance.

 

[Guest]

Yes.

As far as configuring the "DNS client" on the DNS servers themselves.
I need one more piece of advice.

Should DNS servers alway point to themselves as the FIRST entry in their DNS
config page. Or should you use another server as the first entry because
that machines's network stack will come up before it's DNS service is
initialized.

btw, I once read that DNS servers should always be configured to hit
127.0.0.1 as the first entry (I guess because the loopback address is
available sooner in the stack?). What do you think of configuring the DNS
client of a DNS server using it's loopback address.

 

[Herb Martin]

--
Herb Martin



Just in case anyone reads this (out of the context of the previous
messages) I qualified that above "yes" which has been trimmed.

Yes, for only a few DCs.

As far as configuring the "DNS client" on the DNS servers themselves.
I need one more piece of advice.
Sure....

Should DNS servers alway point to themselves as the FIRST entry in their DNS
config page.

Or should you use another server as the first entry because
that machines's network stack will come up before it's DNS service is
initialized.

That should not matter. As long as no service tries
to actually USE the DNS server before it is ready.
(And even then it will just switch back in a bit.)

The reason for having the server use ANOTHER DNS
SOMETIMES is to make sure it gets properly registered
when you are having DNS/AD replication problems --
and this includes the first few hours or days or a new
AD Domain.

Get all DCs registered with ONE DNS server, before you
try to use multiple DNS servers when configured as AD-
Integrated DNS.

Otherwise, since AD is always dependent on DNS you
will have a dependency loop that is broken.

First, one correct DNS servers (primary or AD-integrated),
get AD replicated, then you can have more AD-DNS servers.

Each DNS-DC can point to itself.

General case: DNS servers point to themselves FIRST.

btw, I once read that DNS servers should always be configured to hit
127.0.0.1 as the first entry (I guess because the loopback address is
available sooner in the stack?).

No, it is not and I always use the actual address(es).

Both should work, but IIRC there was some bizarre (not
very likely) case where the actual IP worked better.

I use the real IP and it works.

What do you think of configuring the DNS
client of a DNS server using it's loopback address.

I avoid it (but cannot recall if it really matters). I know
the real address works.

Also note: Using the real address requires that you update
it if you change the DNS IP -- but that is the least of your
problems in that case since ALL clients using that IP need
changing, not just the "same server" client settings.

 

[Guest]

Herb - Thanks for your time and effort!
I've now got all the background info I need to proceed with this task. -
bill.

 

[Herb Martin]

You are welcome. Let me (or someone) know if you need
more help.

 

[alvinalf1]

Hi!,
I'm also in the process of setting up a 2nd DNS sever on a
single-domain site with 1st DC's DNS as AD-Intregrated..

Kinda confused now cos the below article suggest that we place the IP
of DC1 instead of pointing to itself....

Anyone can comment?

Thanks

------------------------
http://support.microsoft.com/kb/291382/

Question: How do I set up DNS for other domain controllers in the
domain that are running DNS?

Answer: For each additional domain controller that is running DNS, the
preferred DNS setting is the parent DNS server (first domain controller
in the domain), and the alternate DNS setting is the actual IP address
of network interface.

 

[Herb Martin]

Hi!,
I'm also in the process of setting up a 2nd DNS sever on a
single-domain site with 1st DC's DNS as AD-Intregrated..

Kinda confused now cos the below article suggest that we place the IP
of DC1 instead of pointing to itself....

That is a common misundstanding that has turned into
a naive 'recommendation' -- the misunderstanding stems
from the fact that during EARLY setup or when fixing
some DNS problems (due to improper configuration) we
might NEED to do this at least temporarily.)

Anyone can comment?

The reason we point (ALL) the DNS Server(s) to the same
'central' DNS is to get them ALL registered in a consistent
database -- later we can point each to the most efficient
DNS server, almost always itself.

 

[alvinalf1]

Hi!

So does that mean for each DNS servers, we point it to themselves only
(no alternative DNS) and being AD-integrated, they will handle the
replication automatically.

Also, for the remainging non-DNS DCs and member severs, we include both
DNS servers ip addresses as preferred and alternative.

thanks

 

[alvinalf1]

Hi!

So does that mean for each DNS servers, we point it to themselves only
(no alternative DNS) and being AD-integrated, they will handle the
replication automatically.

This wont cause any of those 'island DNS' problem right?

Also, for the remainging non-DNS DCs and member severs, we include both
DNS servers ip addresses as preferred and alternative.



thanks

 

[Herb Martin]

Hi!

So does that mean for each DNS servers, we point it to themselves only
(no alternative DNS)

I would actually put in an alternate but this is
mostly a matter of style -- I like the idea that
I can shut down DNS without shutting down
the DC and it will continue to work.

and being AD-integrated, they will handle the
replication automatically.
Yes.

Also, for the remainging non-DNS DCs and member severs, we include both
DNS servers ip addresses as preferred and alternative.

With the "closest" DNS listed as preferred -- in a
separate site, we will encourage the DNS clients
to use the local DNS first.