Sign in with
Sign up | Sign in
Your question

Questions on putting up a new DNS server.

Tags:
  • Domain
  • DNS Server
  • DNS
  • Servers
  • Windows
Last response: in Windows 2000/NT
Share
Anonymous
April 8, 2005 7:01:03 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

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.

--
Bill

More about : questions putting dns server

Anonymous
April 8, 2005 11:00:50 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

Bill-MT wrote:
> 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.



--?
Best regards,
Kevin D4 Dad Goodknecht Sr. [MVP]
Hope This Helps
===================================
When responding to posts, please "Reply to Group"
via your newsreader so that others may learn and
benefit from your issue, to respond directly to
me remove the nospam. from my email address.
===================================
http://www.lonestaramerica.com/
===================================
Use Outlook Express?... Get OE_Quotefix:
It will strip signature out and more
http://home.in.tum.de/~jain/software/oe-quotefix/
===================================
Keep a back up of your OE settings and folders
with OEBackup:
http://www.oehelp.com/OEBackup/Default.aspx
===================================
Anonymous
April 9, 2005 10:30:49 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

> 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".
Related resources
Anonymous
April 10, 2005 11:29:02 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

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
Anonymous
April 11, 2005 2:00:06 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

"Bill-MT" <BillMT@discussions.microsoft.com> wrote in message
news:CECB098B-0AC2-4F8C-87EF-6407079A5FDD@microsoft.com...
> 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
Anonymous
April 11, 2005 4:04:04 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

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.
Anonymous
April 11, 2005 6:37:26 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

"Bill-MT" <BillMT@discussions.microsoft.com> wrote in message
news:3DA3F416-FEDB-4712-B184-16355FF0E49E@microsoft.com...
> 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.
>
> 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.
>
>
>
Anonymous
April 11, 2005 6:38:03 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

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.
Anonymous
April 11, 2005 10:02:21 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

"Bill-MT" <BillMT@discussions.microsoft.com> wrote in message
news:CEBD056B-9EB9-41F6-BB00-6B1A9B73546E@microsoft.com...
> 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.)
Anonymous
April 11, 2005 10:02:22 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

"Herb Martin" wrote:
> 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.
Anonymous
April 12, 2005 1:51:03 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

"Bill-MT" <BillMT@discussions.microsoft.com> wrote in message
news:CB19EE02-7910-4171-83C6-900D6835067E@microsoft.com...
> "Herb Martin" wrote:
> > 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).

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.
Anonymous
April 12, 2005 1:09:11 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

"Herb Martin" wrote:
> > So does that mean that you recommend installing the DNS service on ALL or
> > least most DCs in a domain when using AD-integrated zones - to make more
>
> 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.
Anonymous
April 12, 2005 4:16:57 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

--
Herb Martin


"Bill-MT" <BillMT@discussions.microsoft.com> wrote in message
news:E19E3E2A-0CA4-4736-BF76-358291481240@microsoft.com...
> "Herb Martin" wrote:
> > > So does that mean that you recommend installing the DNS service on ALL
or
> > > least most DCs in a domain when using AD-integrated zones - to make
more
> >
> > Yes.

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.

The problem with answering simply is the word 'always'. <grin>

> 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.
Anonymous
April 12, 2005 4:32:36 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

Herb - Thanks for your time and effort!
I've now got all the background info I need to proceed with this task. -
bill.
Anonymous
April 13, 2005 12:43:43 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

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

--
Herb Martin


"Bill-MT" <BillMT@discussions.microsoft.com> wrote in message
news:CE3FCE6F-683C-4C92-B12D-063E3DF8B502@microsoft.com...
> Herb - Thanks for your time and effort!
> I've now got all the background info I need to proceed with this task. -
> bill.
Anonymous
April 16, 2005 3:51:47 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

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.
Anonymous
April 16, 2005 11:04:31 PM

Archived from groups: microsoft.public.win2000.dns (More info?)

<alvinalf1@yahoo.com> wrote in message
news:1113677507.688904.203120@z14g2000cwz.googlegroups.com...
> 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.
Anonymous
April 17, 2005 3:09:40 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

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
Anonymous
April 17, 2005 3:10:39 AM

Archived from groups: microsoft.public.win2000.dns (More info?)

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
!