T
troy
Does a domain need it's own DNS or can it use the DNS on
another domain?
thanks
another domain?
thanks
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
C
CJ
You can even use an ISP's DNS servers.
We used our ISPs DNS servers with our old WinNT domain system, but I wouldnt
recommend it with Active Directory. I would use forwarding with no
recursion with AD.
We used our ISPs DNS servers with our old WinNT domain system, but I wouldnt
recommend it with Active Directory. I would use forwarding with no
recursion with AD.
G
Guest
Our company has an internal domain which has a DNS. I
need to make another domain for our production environment
and am being pushed to use their DNS server. I'm not sure
if I should make a child domain, another tree in a forest
or a totally separate domain and I don't understand all
the nuancese of each. Any suggestions as to which type of
domain I should establish and where/how the DNS should be.
thanks!
need to make another domain for our production environment
and am being pushed to use their DNS server. I'm not sure
if I should make a child domain, another tree in a forest
or a totally separate domain and I don't understand all
the nuancese of each. Any suggestions as to which type of
domain I should establish and where/how the DNS should be.
thanks!
H
Herb Martin
troy said:Does a domain need it's own DNS or can it use the DNS on
another domain?
It depends on the precise meaning of your question so....
An AD domain needs it's own corresponding DNS ZONE,
but that zone does not necessarily have to be on any particular
machine (in the domain or not, Windows or even BIND.)
That DNS zone must (for all pratical purposes) be DYNAMIC.
Now, it is normal and usually easier to actuall use Windows
DNS, put the DNS on (some of) the DCs, and have these DNS
servers be in the same domain.
You will do better by following the last paragraphy but it is
not a technical requirement. (In other words, don't fight it
and don't swim upstream.)
--
DNS
1) Dynamic for the zone supporting AD
2) All internal DNS client NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
Restart NetLogon on any DC if you change any of the above that
affects a DC.
A
Ace Fekay [MVP]
In
As Herb mentioned, you can use any DNS server (that supports SRVs) to host
the AD zone name, no matter what domain it is, same domain or different
domain, same forest or different forest.
Desiging Active Directory is a whole different ballgame. It needs to be
discussed with reasons why one would take one path in a design and not
another, along with justification, logistics, management concerns, etc. Its
a whole topic in itself. Its so flexible and diverse, it really depends on
your company needs.
If you use their DNS servers for the domain, that can be good and bad. If
you want to make it a child domain of your domain, and you don't have
control over THEIR DNS, then that can be bad and will cause problems in the
long run. A child domain in AD needs to have acces to the parent domain and
back again. Usually we setup a delegatiojn to the child domain DNS (if you
use theirs) then setup a forwarder from theirs back to the parent domain's
DNS. This allows them to control DNS, but still allows cross domain, trees
and forest communication.
An AD domain is a security boundary, not a physical one. A tree has a
contigous name space, such as your domain.com and all your child domains (if
you have any), A Forest is a collection of trees. In many cases, we usually
just see one tree.
All domains in a tree or forest have one thing in common, the forest root.
The root holds the schema, the Enterprise Admin (EA) and Schema Admin
account. The EA account gives you carte blache throughout the forest. You
can administer all your child domains and other trees in the forest with
that one EA account alone, if you choose to do so. You can give others
Domain Admin accounts in those SPECIFIC domains to administer only that
domain. But you have central control, so to speak, but keep in mind that you
would create a child domain if the need for separate control or
administration or different security settings (eg. password lengths) are
required . Usually in other cities or countries you would see this, or just
to break it down into different departments (departments are not the norm).
You can have one HUGE domain where you can create an OU for each location
and you would only delegate certain administrators to ONLY that OU. That
would be a real tight and secure ship.
Some would design AD with an empty forest root domain and have all their
divisions as child domains to protect the EA and Schema admin account. But
there are loopholes around that, such as access to ADSIEdit, where a domain
admin in a domain other than the forest root domain can actually
inadvertenly alter forest data.
You would have a separate tree if you have two namespaces under the one
company, say if Nike bought Reebok, they would want Reebok under Nike's
forest, so we create a new domain in a new tree tree called reebok.com in
the existing forest.
You would usually have different forests in a case where different companies
are co-existing or they have separate Schema requirements.
For all the above I can use one DNS server that can handle everything and
that is not part of any of these structures, but it wouldn't probably
physically be up to the task! That's where designing your infrastructure to
handle all of this falls into place... and if you have different
administrators in different areas, such as I assume in your case, you'll
need to work together.
--
Regards,
Ace
Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.
This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.
Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Active Directory
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
Our company has an internal domain which has a DNS. I
need to make another domain for our production environment
and am being pushed to use their DNS server. I'm not sure
if I should make a child domain, another tree in a forest
or a totally separate domain and I don't understand all
the nuancese of each. Any suggestions as to which type of
domain I should establish and where/how the DNS should be.
thanks!
As Herb mentioned, you can use any DNS server (that supports SRVs) to host
the AD zone name, no matter what domain it is, same domain or different
domain, same forest or different forest.
Desiging Active Directory is a whole different ballgame. It needs to be
discussed with reasons why one would take one path in a design and not
another, along with justification, logistics, management concerns, etc. Its
a whole topic in itself. Its so flexible and diverse, it really depends on
your company needs.
If you use their DNS servers for the domain, that can be good and bad. If
you want to make it a child domain of your domain, and you don't have
control over THEIR DNS, then that can be bad and will cause problems in the
long run. A child domain in AD needs to have acces to the parent domain and
back again. Usually we setup a delegatiojn to the child domain DNS (if you
use theirs) then setup a forwarder from theirs back to the parent domain's
DNS. This allows them to control DNS, but still allows cross domain, trees
and forest communication.
An AD domain is a security boundary, not a physical one. A tree has a
contigous name space, such as your domain.com and all your child domains (if
you have any), A Forest is a collection of trees. In many cases, we usually
just see one tree.
All domains in a tree or forest have one thing in common, the forest root.
The root holds the schema, the Enterprise Admin (EA) and Schema Admin
account. The EA account gives you carte blache throughout the forest. You
can administer all your child domains and other trees in the forest with
that one EA account alone, if you choose to do so. You can give others
Domain Admin accounts in those SPECIFIC domains to administer only that
domain. But you have central control, so to speak, but keep in mind that you
would create a child domain if the need for separate control or
administration or different security settings (eg. password lengths) are
required . Usually in other cities or countries you would see this, or just
to break it down into different departments (departments are not the norm).
You can have one HUGE domain where you can create an OU for each location
and you would only delegate certain administrators to ONLY that OU. That
would be a real tight and secure ship.
Some would design AD with an empty forest root domain and have all their
divisions as child domains to protect the EA and Schema admin account. But
there are loopholes around that, such as access to ADSIEdit, where a domain
admin in a domain other than the forest root domain can actually
inadvertenly alter forest data.
You would have a separate tree if you have two namespaces under the one
company, say if Nike bought Reebok, they would want Reebok under Nike's
forest, so we create a new domain in a new tree tree called reebok.com in
the existing forest.
You would usually have different forests in a case where different companies
are co-existing or they have separate Schema requirements.
For all the above I can use one DNS server that can handle everything and
that is not part of any of these structures, but it wouldn't probably
physically be up to the task! That's where designing your infrastructure to
handle all of this falls into place... and if you have different
administrators in different areas, such as I assume in your case, you'll
need to work together.
--
Regards,
Ace
Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.
This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.
Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Active Directory
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.