Private DNS Root

[DavidM]

I have a standalone W2K DNS server that I'm setting up for a few webservers
that we access internally along wtih our customers over their private frame
circuit to us.

We have our own AD DNS server for all internal clients. This works fine.

We currently access these internal web servers via IP address.

Our customers, too, access the internal web server via IP address thru their
frame circuit to us.

To eliminate customers and our internal users from having to use IP
addresses and putting our customers on our AD DNS server, I would like to
create a standalone DNS root server that will only be used internally.

It is my understanding that I can do this within W2K DNS.

From the DNS console, I created a master root domain called . (period).

From this I created another subdomain called (for simplicity) .fubar.

Then I created another subdomain called companyname.

The FQDN for my private domain is companyname.fubar.

This is my plan:

1) If customers currently have their own DNS server, I want them to add a
forward lookup to my internal DNS server.

2) If customers do not have DNS, then they will need to add the IP address
of my primary and secondary to their client PCs.

I'm assuming my logic here will work. I have created the root domain and
subdomains under it within my test lab. It appears to work.. although I
noticed NSLOOKUP returns non-existant domain when I try and lookup
companyname.fubar. Using a hostname such as www.companyname.fubar works
fine. I'm guessing because I created the subdomains on the root server
instead of delegating the subdomain (fubar in this case) to another DNS
server. I'm assuming that if I had done this and then did an NSLOOKUP from
the DNS that has the zone for fubar, it would fine the domain.

Opinions?

 

[Herb Martin]

I have a standalone W2K DNS server that I'm setting up for a few webservers
that we access internally along wtih our customers over their private frame
circuit to us.

We have our own AD DNS server for all internal clients. This works fine.

If you only have one, consider two -- both as backup and
to keep running while rebooting etc.

We currently access these internal web servers via IP address.

AD requires IP, but it also requires (Dynamic DNS).

Our customers, too, access the internal web server via IP address thru their
frame circuit to us.

To eliminate customers and our internal users from having to use IP
addresses and putting our customers on our AD DNS server, I would like to
create a standalone DNS root server that will only be used internally.

Ok, but you don't really need a root as much as you should
have a server holding the ZONE(s) that correspond to your
AD domain name and perhaps your customers.

It is my understanding that I can do this within W2K DNS.

With AD, you really should be doing it already.

From the DNS console, I created a master root domain called . (period).

That's fine but mostly irrelevant -- especially if you don't
have multiple DNS trees (e.g., Tree1.com & Tree2.com )

From this I created another subdomain called (for simplicity) .fubar.

Yes, since it is internal you MAY call it anything you
wish but politeness and future compatibility suggest
Local is best, but your DNS zones really do need to
include your AD Domain name (which should be at least
TWO tags, e.g., Domain.Com and not just Domain or Fubar.)

Then I created another subdomain called companyname.

Yes. Domain.local is fine, but it needs to be the same as
you have already named AD.

The FQDN for my private domain is companyname.fubar.

You probably don't need all that cruft above companyname.fubar

This is my plan:

1) If customers currently have their own DNS server, I want them to add a
forward lookup to my internal DNS server.

That would be a Secondary DNS server for the forward
zone that you use (companyname.fubar)

2) If customers do not have DNS, then they will need to add the IP address
of my primary and secondary to their client PCs.

That makes sense if they will resolve you DNS ONLY.

It will not work if they must resolve other DNS -- their
own zones or even the Internet. In that case only the
Secondary for your zone (from your choices) will work.

I'm assuming my logic here will work. I have created the root domain and
subdomains under it within my test lab. It appears to work.. although I
noticed NSLOOKUP returns non-existant domain when I try and lookup
companyname.fubar.

There is a bogus error returned IMMEDIATELY by
NSLookup when you don't have a reverse zone for it,
but that is irrelevant.

If you cannot resolve the ACTUAL name in companyname.fubar
then this indicates that either your DNS client is not using the
right DNS server (set) or perhaps you never added that record.

Again, AD really needs a Dynamic DNS server and you ought
to just fix that.

You can have those "." and top level (fubar) zones but from
everything you have said they are just a waste of time.

Using a hostname such as www.companyname.fubar works
fine. I'm guessing because I created the subdomains on the root server
instead of delegating the subdomain (fubar in this case) to another DNS
server. I'm assuming that if I had done this and then did an NSLOOKUP from
the DNS that has the zone for fubar, it would fine the domain.

Opinions?

Did you add a blank A-host record to the zone for the bare
zone name itself?

And if that is all you wanted, it works better to put that info
first -- of course then you would have found out your DNS
for AD is all screwed up.

DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

....or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /serverC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]

 

[Ace Fekay [MVP]]

In

I have a standalone W2K DNS server that I'm setting up for a few
webservers that we access internally along wtih our customers over
their private frame circuit to us.

We have our own AD DNS server for all internal clients. This works
fine.
We currently access these internal web servers via IP address.

Our customers, too, access the internal web server via IP address
thru their frame circuit to us.

To eliminate customers and our internal users from having to use IP
addresses and putting our customers on our AD DNS server, I would
like to create a standalone DNS root server that will only be used
internally.
It is my understanding that I can do this within W2K DNS.

From the DNS console, I created a master root domain called .
(period).
From this I created another subdomain called (for simplicity) .fubar.

Then I created another subdomain called companyname.

The FQDN for my private domain is companyname.fubar.

This is my plan:

1) If customers currently have their own DNS server, I want them to
add a forward lookup to my internal DNS server.

2) If customers do not have DNS, then they will need to add the IP
address of my primary and secondary to their client PCs.

I'm assuming my logic here will work. I have created the root domain
and subdomains under it within my test lab. It appears to work..
although I noticed NSLOOKUP returns non-existant domain when I try
and lookup companyname.fubar. Using a hostname such as
www.companyname.fubar works fine. I'm guessing because I created the
subdomains on the root server instead of delegating the subdomain
(fubar in this case) to another DNS server. I'm assuming that if I
had done this and then did an NSLOOKUP from the DNS that has the zone
for fubar, it would fine the domain.
Opinions?

Problem with this logic is if the customer wants to resolve to something
else other than your companyname.fubar namespace, that server won't be able
to handle the lookup sincve you created a Root zone (the period). Putting
another DNS address in the client's machine will not help either, since the
local DNS client service does not work by looking at each one until it find
as answer. If it asks yours first, it wll get an NXDOMAIN response, and
therefore will not look elsewhere (because the NXDOMAIN response, meaning a
"No response", means it got a response, but it was a negative response). The
idea with DNS settings in a client is that all DNS addresses must be able to
resolve to the same namespace or have the same data (such as a corporate
scenario). If you mix and match, results will be mixed as well. The best way
I see it is to delete that Root zone, and have your clients only use your
DNS, re-create the zone as companyname.fubar, create a www record under it
and provide the IP of the webserver, and set a forwarder to your ISP's DNS.
This way, without the Root zone, your server will respond to your
compayname.fubar queries, as well as outside queries by forwarding the query
to the ISP's. If the Root zone exists, it cannot forward, nor will it
recurse other queries for zones other than what's created on the machine.


--
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 - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.

 

[DavidM]

Thanks for the feedback, Herb.

You constantly mentioned AD and I do not want this new DNS to know anything
about our internal AD DNS server other than having a forward lookup to it to
resolve anything it can't find.

I'm not sure why I would not want a root. Because I definitely don't want
my customers using my DNS server and it trying to go out to Internet to
resolve some higher level domains.

I'm confused.

I have a standalone W2K DNS server that I'm setting up for a few webservers
that we access internally along wtih our customers over their private frame
circuit to us.

We have our own AD DNS server for all internal clients. This works fine.

If you only have one, consider two -- both as backup and
to keep running while rebooting etc.

We currently access these internal web servers via IP address.

AD requires IP, but it also requires (Dynamic DNS).

Our customers, too, access the internal web server via IP address thru their
frame circuit to us.

To eliminate customers and our internal users from having to use IP
addresses and putting our customers on our AD DNS server, I would like to
create a standalone DNS root server that will only be used internally.

Ok, but you don't really need a root as much as you should
have a server holding the ZONE(s) that correspond to your
AD domain name and perhaps your customers.

It is my understanding that I can do this within W2K DNS.

With AD, you really should be doing it already.

From the DNS console, I created a master root domain called . (period).

That's fine but mostly irrelevant -- especially if you don't
have multiple DNS trees (e.g., Tree1.com & Tree2.com )

From this I created another subdomain called (for simplicity) .fubar.

Yes, since it is internal you MAY call it anything you
wish but politeness and future compatibility suggest
Local is best, but your DNS zones really do need to
include your AD Domain name (which should be at least
TWO tags, e.g., Domain.Com and not just Domain or Fubar.)

Then I created another subdomain called companyname.

Yes. Domain.local is fine, but it needs to be the same as
you have already named AD.

The FQDN for my private domain is companyname.fubar.

You probably don't need all that cruft above companyname.fubar

This is my plan:

1) If customers currently have their own DNS server, I want them to add a
forward lookup to my internal DNS server.

That would be a Secondary DNS server for the forward
zone that you use (companyname.fubar)

2) If customers do not have DNS, then they will need to add the IP
address
of my primary and secondary to their client PCs.

That makes sense if they will resolve you DNS ONLY.

It will not work if they must resolve other DNS -- their
own zones or even the Internet. In that case only the
Secondary for your zone (from your choices) will work.

I'm assuming my logic here will work. I have created the root domain and
subdomains under it within my test lab. It appears to work.. although I
noticed NSLOOKUP returns non-existant domain when I try and lookup
companyname.fubar.

There is a bogus error returned IMMEDIATELY by
NSLookup when you don't have a reverse zone for it,
but that is irrelevant.

If you cannot resolve the ACTUAL name in companyname.fubar
then this indicates that either your DNS client is not using the
right DNS server (set) or perhaps you never added that record.

Again, AD really needs a Dynamic DNS server and you ought
to just fix that.

You can have those "." and top level (fubar) zones but from
everything you have said they are just a waste of time.

Using a hostname such as www.companyname.fubar works
fine. I'm guessing because I created the subdomains on the root server
instead of delegating the subdomain (fubar in this case) to another DNS
server. I'm assuming that if I had done this and then did an NSLOOKUP from
the DNS that has the zone for fubar, it would fine the domain.

Opinions?

Did you add a blank A-host record to the zone for the bare
zone name itself?

And if that is all you wanted, it works better to put that info
first -- of course then you would have found out your DNS
for AD is all screwed up.

DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

...or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /serverC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]

 

[Herb Martin]

Thanks for the feedback, Herb.

You constantly mentioned AD and I do not want this new DNS to know anything
about our internal AD DNS server other than having a forward lookup to it to
resolve anything it can't find.

You seem to be saying you had AD without DNS.

That is unsupported and will never work seemlessly.

If you are wishing to provide resolution for limited
(not full domain/AD) resources then you should setup
a COMPLETE separate DNS zone for that.

This will look (and be configured) much as you would
with a Public/Private pair of zones for the Internet/Internal
even though the "public" version in your case will have
a (very) limited audience.

This (latter) configuration is called "Shadow DNS" (aka
Split DNS.)

I'm not sure why I would not want a root. Because I definitely don't want
my customers using my DNS server and it trying to go out to Internet to
resolve some higher level domains.

The root is unnecessary if you only wish to resolve one
zone/domain. It adds nothing.

If you are worried about it recursing or forwarding then
you can just disable those (in Advanced).

Note: You cannot expose TWO versions of the zone
(AD and External-Custerom) on the SAME MS DNS
server.

You can do that with BIND, but then it probably isn't
as suitable for supporting the AD.

--
Herb Martin

I'm confused.

I have a standalone W2K DNS server that I'm setting up for a few webservers
that we access internally along wtih our customers over their private frame
circuit to us.

We have our own AD DNS server for all internal clients. This works

fine.

If you only have one, consider two -- both as backup and
to keep running while rebooting etc.

We currently access these internal web servers via IP address.

AD requires IP, but it also requires (Dynamic DNS).

Our customers, too, access the internal web server via IP address thru their
frame circuit to us.

To eliminate customers and our internal users from having to use IP
addresses and putting our customers on our AD DNS server, I would like to
create a standalone DNS root server that will only be used internally.

Ok, but you don't really need a root as much as you should
have a server holding the ZONE(s) that correspond to your
AD domain name and perhaps your customers.

It is my understanding that I can do this within W2K DNS.

With AD, you really should be doing it already.

From the DNS console, I created a master root domain called . (period).

That's fine but mostly irrelevant -- especially if you don't
have multiple DNS trees (e.g., Tree1.com & Tree2.com )

From this I created another subdomain called (for simplicity) .fubar.

Yes, since it is internal you MAY call it anything you
wish but politeness and future compatibility suggest
Local is best, but your DNS zones really do need to
include your AD Domain name (which should be at least
TWO tags, e.g., Domain.Com and not just Domain or Fubar.)

Then I created another subdomain called companyname.

Yes. Domain.local is fine, but it needs to be the same as
you have already named AD.

The FQDN for my private domain is companyname.fubar.

You probably don't need all that cruft above companyname.fubar

This is my plan:

1) If customers currently have their own DNS server, I want them to add a
forward lookup to my internal DNS server.

That would be a Secondary DNS server for the forward
zone that you use (companyname.fubar)

2) If customers do not have DNS, then they will need to add the IP
address
of my primary and secondary to their client PCs.

That makes sense if they will resolve you DNS ONLY.

It will not work if they must resolve other DNS -- their
own zones or even the Internet. In that case only the
Secondary for your zone (from your choices) will work.

I'm assuming my logic here will work. I have created the root domain and
subdomains under it within my test lab. It appears to work.. although I
noticed NSLOOKUP returns non-existant domain when I try and lookup
companyname.fubar.

There is a bogus error returned IMMEDIATELY by
NSLookup when you don't have a reverse zone for it,
but that is irrelevant.

If you cannot resolve the ACTUAL name in companyname.fubar
then this indicates that either your DNS client is not using the
right DNS server (set) or perhaps you never added that record.

Again, AD really needs a Dynamic DNS server and you ought
to just fix that.

You can have those "." and top level (fubar) zones but from
everything you have said they are just a waste of time.

Using a hostname such as www.companyname.fubar works
fine. I'm guessing because I created the subdomains on the root server
instead of delegating the subdomain (fubar in this case) to another DNS
server. I'm assuming that if I had done this and then did an NSLOOKUP from
the DNS that has the zone for fubar, it would fine the domain.

Opinions?

Did you add a blank A-host record to the zone for the bare
zone name itself?

And if that is all you wanted, it works better to put that info
first -- of course then you would have found out your DNS
for AD is all screwed up.

DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

...or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /serverC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]