DNS naming question

  • Thread starter Thread starter Jeff
  • Start date Start date
J

Jeff

I've inherited a WIN2K network and the domain name of the internal network
(dyndns.org) is obviously already registered by "the" dyndns.org DNS hosting
company. My company has a registered domain on the Internet and, if I'm not
mistaken, wouldn't it be better if our internal domain matched our
registered Internet name? If so, what major changes would I need to make to
DNS/AD to change the domain name on our network.
 
Jeff said:
I've inherited a WIN2K network and the domain name of the internal network
(dyndns.org) is obviously already registered by "the" dyndns.org DNS hosting
company. My company has a registered domain on the Internet and, if I'm not
mistaken, wouldn't it be better if our internal domain matched our
registered Internet name?
Yes. You really shouldn't use someone else's (registered) name.

You should like use your registered name OR a child of that name OR a
completely
private name (all have minor advantages and disadvantages). Generally if
you have
to ask, the "safest" generic answer is "child of a registered name" but all
are viable
and not that much different when you really think about it.
If so, what major changes would I need to make to
DNS/AD to change the domain name on our network.

Create the appropriate zone.

But there is an implicit assumption in your posting here: IF there is an AD
Domain
involved that matches this DNS zone you cannot easily rename that domain and
therefore are -- for now -- stuck with it.
 
In
Jeff said:
I've inherited a WIN2K network and the domain name of the internal
network (dyndns.org) is obviously already registered by "the"
dyndns.org DNS hosting company. My company has a registered domain on
the Internet and, if I'm not mistaken, wouldn't it be better if our
internal domain matched our registered Internet name? If so, what
major changes would I need to make to DNS/AD to change the domain
name on our network.

In addition to Herb's post and Scott's links, there are other issues not
addressed in the links, if you have chosen to use the same name domain.
It's the consensus these days, after years of feedback and issues that have
arisen from it, to NOT use the same name zone internally and externally.
There are additional adminstrative overhead associated with it, such as:

1. Not being able to get to external website, which is an easy fix by ether
creating a www record internally or delegating the www zone.

2. The LdapIpAddress (the blank domain FQDN). Some folks want to be able to
get to http://yourdomain.com. Then you would need to make some reg changes
to stop the LdapIpAddress from registering and create your own with the
external website address. This reg entry must be done on ALL the DCs. Then
that would cause an issue with GPOs applying since the GetGpoList function
of the client side extension connects to the sysvol by:
\\domain.com\sysvol\domain.com\policies. Now if you changed that
LdapIpAddress, it may just query your website for the GPOs...

3. Manually creating other external resource records as needed.

Hope that helps...


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
"Ace Fekay [MVP]"
message > In addition to Herb's post and Scott's links, there are other
issues not
addressed in the links, if you have chosen to use the same name domain.
It's the consensus these days, after years of feedback and issues that have
arisen from it, to NOT use the same name zone internally and externally.
There are additional adminstrative overhead associated with it, such as:

I disagree with the above, specifically that there is a consensus and
that the administrative overhead is obtrusive. There are however
issues....
1. Not being able to get to external website, which is an easy fix by ether
creating a www record internally or delegating the www zone.

You really need to accept the Shadow domain solution if you use the
same name and that isn't implemented until you add ALL (desired)
external names to the internal version.

This is the only actual extra admin required. And even with a child
zone or distinct zones (different solutions) you must perform other
administrative tasks due to these separate zones.
2. The LdapIpAddress (the blank domain FQDN). Some folks want to be able to
get to http://yourdomain.com. Then you would need to make some reg changes
to stop the LdapIpAddress from registering and create your own with the
external website address. This reg entry must be done on ALL the DCs. Then
that would cause an issue with GPOs applying since the GetGpoList function
of the client side extension connects to the sysvol by:
\\domain.com\sysvol\domain.com\policies. Now if you changed that
LdapIpAddress, it may just query your website for the GPOs...

Not being able to get to the website BY THE BARE DOMAIN name,
e.g., LearnQuick.Com RATHER than www.LearnQuick.com which
works just fine.

Reason: The DCs ALL register themselves using the bare domain name.

But I don't think I would ever prevent the DCs from registering this; but
rather instruct internal users to use the full www-name or setup referrel
pages on the DCs if this really bugged me.
3. Manually creating other external resource records as needed.

Only those you would create externally anyway.

The above is NOT an argument for this solution, but merely to put
it into perspective: It ain't that hard -- but it doesn't happen
automatically.
 
In
Herb Martin said:
"Ace Fekay [MVP]"
message > In addition to Herb's post and Scott's links, there are
other issues not

I disagree with the above, specifically that there is a consensus and
that the administrative overhead is obtrusive. There are however
issues....


You really need to accept the Shadow domain solution if you use the
same name and that isn't implemented until you add ALL (desired)
external names to the internal version.

This is the only actual extra admin required. And even with a child
zone or distinct zones (different solutions) you must perform other
administrative tasks due to these separate zones.


Not being able to get to the website BY THE BARE DOMAIN name,
e.g., LearnQuick.Com RATHER than www.LearnQuick.com which
works just fine.

Reason: The DCs ALL register themselves using the bare domain name.

But I don't think I would ever prevent the DCs from registering this;
but rather instruct internal users to use the full www-name or setup
referrel pages on the DCs if this really bugged me.


Only those you would create externally anyway.

The above is NOT an argument for this solution, but merely to put
it into perspective: It ain't that hard -- but it doesn't happen
automatically.

Herb, have you tried to connect to \\domain.com\sysvol\domain.com\policies
after you've altered those reg entries that I've discussed (that is if the
users of a company have wanted to connect using without the www name?


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
The above is NOT an argument for this solution, but merely to put
Well, of course not since I will not -- have not -- ever altered those
values.

The inability to connect (internal machines) to the bare domain name is
largely irrelevant to me.

This is a minor argument against "same name".
 
In
Herb Martin said:
Well, of course not since I will not -- have not -- ever altered those
values.

The inability to connect (internal machines) to the bare domain name
is largely irrelevant to me.

This is a minor argument against "same name".

It may be irrelevant to you, but the blank host must point to Domain
Controllers if you expect group policies to be applied properly.
 
In
Herb Martin said:
Well, of course not since I will not -- have not -- ever altered those
values.

The inability to connect (internal machines) to the bare domain name
is largely irrelevant to me.

This is a minor argument against "same name".

Minor? Irrelevant?

Just as Kevin said, client side GetGPOlist function uses that...

I guess you don't use GPOs.


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
The inability to connect (internal machines) to the bare domain name
It may be irrelevant to you, but the blank host must point to Domain
Controllers if you expect group policies to be applied properly.

The "it" here is "the ability to connect to external hosts with the bare
name",
not the DC issues which usurp that name. I have no problem with letting
the DCs have the name.

The issue of using the name for OTHER purposes is minor.
 
Just as Kevin said, client side GetGPOlist function uses that...
I guess you don't use GPOs.

Then you guessed wrong.

The MINOR problem is having to use WWW or some other differentiation
for web sites (this only affects internal users so it isn't an issue for
advertising.)
 
In
Herb Martin said:
Then you guessed wrong.

The MINOR problem is having to use WWW or some other differentiation
for web sites (this only affects internal users so it isn't an issue
for advertising.)

You're the one that originally said that sysvol connectivity is a minor
issue, and not the www record. I was just commenting on that. Here's what
you originally said...
The inability to connect (internal machines) to the bare domain name
is largely irrelevant to me.

This is a minor argument against "same name".


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
You're the one that originally said that sysvol connectivity is a minor
issue, and not the www record. I was just commenting on that. Here's what
you originally said...

Go back and look; I never said ANYTHING about "Sysvol connectivity"
much less THAT being a minor issue.

I said that bare domain name for WEB connectivivity by internal users was
not a big deal.
 
In
Herb Martin said:
Go back and look; I never said ANYTHING about "Sysvol connectivity"
much less THAT being a minor issue.

I said that bare domain name for WEB connectivivity by internal users
was not a big deal.

You said "irrelevant" ...

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
Back
Top