AD/DNS Issue

[Craig Matthews]

We presently have an active directory forest with two domain trees:

Forest's DNS Name: forest.
Forest's NetBIOS Name: FOREST

Domain Trees:
DNS Name: corporation1.com.
NetBIOS Name: CORP1

DNS Name: corporation2.com.
NetBIOS Name: CORP2

Before you say anything, our internal DNS namespace is isolated from the
outside world and our DNS servers are authoritative for the domain "forest."
This is a perfectly valid usage of DNS. In fact, our forest has been
working for two years. By using this DNS name, the only thing I lose is the
ability to establish trusts with other domains via the Internet, which isn't
going to be happening anyway.

All of our domain controllers in the forest have one DNS server configured
in their TCP/IP settings -- the one which is authoritative for our internal
active directory DNS zones "forest." "corporation1.com." and
"corporation2.com."

Recently, we added some new Domain Controllers (which we've done many times
before) to both domain trees. We noticed that the forest level records that
the DCs should register (such as the GC records, also the aliases under
guid.domains._msdcs.forest.) were not registering. The DCs would properly
register their records in their own respective AD zones, but not the
necessary records in the forest zone.

I was using MS DNS for hosting the AD DNS zones. After rebuilding the
forest zone file, trying both AD integrated and standard primary, and
reinstalling MSDNS, (also verified all security settings on the zone,
including trying unsecure and secure dynamic updates), it still wouldn't
work.

We migrated our AD zones to BIND 9, enabled dynamic updates, etc. This
seems to have solved our dynamic update problems. All of our DCs in the
forest are now successfully updating their records in their own domain zones
and in the forest zones.

So that problem is solved. I am, however, experiencing something strange.

When I run a netdiag /test:dns on any DC in the forest zone, I get the
following error:

[WARNING] Cannot find a primary authoritative DNS server for the name
'DC1.FOREST.'. [RCODE_SERVER_FAILURE] The name 'DC1.FOREST.' may not be
registered in DNS.

PASS - All the DNS entries for DC are registered on DNS server '10.0.0.2'
and other DCs also have some of the names registered.

If I /manually/ perform an SOA, NS, or A query on both "DC1.FOREST." and
"FOREST." I receive the correct response indicating the start of authority
is properly configured and the DNS server is properly responding.

C:\Program Files\Support Tools>nslookup
Default Server: ns1.company.com
Address: 10.0.0.2

*** SOA QUERY on Domain Controller that netdiag /test:dns reported an error
on:

set qtype=soa
dc1.forest.

Server: ns1.company.com
Address: 10.0.0.2

forest
primary name server = ns1.company.com
responsible mail addr = hostmaster.company.com
serial = 2003110212
refresh = 1800 (30 mins)
retry = 600 (10 mins)
expire = 5184000 (60 days)
default TTL = 18000 (5 hours)


*** SOA QUERY on forest domain:

forest.

Server: ns1.company.com
Address: 10.0.0.2

forest
primary name server = ns1.company.com
responsible mail addr = hostmaster.company.com
serial = 2003110212
refresh = 1800 (30 mins)
retry = 600 (10 mins)
expire = 5184000 (60 days)
default TTL = 18000 (5 hours)

forest nameserver = ns1.company.com

ns1.company.com internet address = 10.0.0.2
As you can see, DNS is functioning 100% perfectly for this zone "forest.".
Dynamic updates proceed, and DCs are able to be located, etc. Everything is
fine. The only indication to any problem is the netdiag /test:dns error
reporting an inability to find an authoritative DNS server (even though it
can be found just fine).

Any ideas what's going on?


Thanks!

 

[Herb Martin]

Before you say anything, our internal DNS namespace is isolated from the

outside world and our DNS servers are authoritative for the domain "forest."
This is a perfectly valid usage of DNS. In fact, our forest has been
working for two years. By using this DNS name, the only thing I lose is the
ability to establish trusts with other domains via the Internet, which isn't
going to be happening anyway.

Do you actually have a Win2000+ domain named "Forest" -- a one tag name
is a "very bad thing."
Why do you have three trees and not just two? (One for each corporation?)

All of our domain controllers in the forest have one DNS server configured
in their TCP/IP settings -- the one which is authoritative for our internal
active directory DNS zones "forest." "corporation1.com." and
"corporation2.com."

Presumably you are misusing (as many people) do the word authoritative'
since
the Primary AND all Secondary servers are 'authoritative' for the zones
which
they hold.

It is a good idea to add a client ALTERNATE for times when the Preferred DNS
server is down.

I was using MS DNS for hosting the AD DNS zones. After rebuilding the
forest zone file, trying both AD integrated and standard primary, and
reinstalling MSDNS, (also verified all security settings on the zone,
including trying unsecure and secure dynamic updates), it still wouldn't
work.

Don't flail around (e.g., AD integrated vs. Primary, rebuilding zones)
trying to solve
a problem that is not understood. A "set" of AD Integrated Servers should
largely
be thought of as a substitute for the Single Primary. In terms of setup
they are
basically interchangable (an AD integrated SET offers some additional
features
and efficiency.)

Secure vs. non-Secure is only an issue for NON-forest/domain machines (e.g.,
Unix,
Macintosh etc) and of course "visitors".

[WARNING] Cannot find a primary authoritative DNS server for the name
'DC1.FOREST.'. [RCODE_SERVER_FAILURE] The name 'DC1.FOREST.' may not be
registered in DNS.

You really should use DCDiag to test all DCs.

For fixing this you should likely use a single Primary or Single AD
integrated (temporarily);
make sure it is set for Dynamic on the zone; point all DCs at that single
DNS server.
Restart all DC NetLogon service.

ReRun DCDiag on ever DC, saving the output to a file, and search for FAIL,
WARN, ERROR.
Fix each problem.

Check you Sites and Services for full replication connectivity and that DCs
are properly
listed in each Subnet.

Use RepAdmin or ReplMon to make sure you have replication of all DCs.

After you get it working (consider forcing replication with ReplMon or
RepAdmin), then
you can add more AD-integrated and even point DCs to themselves PLUS an
alternate.

 

[Craig Matthews]

Do you actually have a Win2000+ domain named "Forest" -- a one tag name
is a "very bad thing."
Why do you have three trees and not just two? (One for each corporation?)

The forest is not called "FOREST" and the DNS name for the forest is not
"forest." It is something else, as I changed the names to generic names for
posting on this newsgroup. There is nothing wrong with using "oneword." as
a domain name. This is just as valid as "forestdomain.com." The fact that
"forest." is not a valid TLD on the public Internet is a non-issue as my
network is isolated and my DNS servers are authoritative for the zone and
domain "forest."

We do not have three trees. We have two domain trees within the forest.
The architecture of active directory (our decisions as to tree structure and
forest) is irrelevent. A forest with two domain trees within it is a normal
configuration. Each tree is one corporation (as explained in my post), with
our forest acting as a "resource" domain for things such as IT staff
workstations, servers, accounts, etc.

Presumably you are misusing (as many people) do the word authoritative'
since
the Primary AND all Secondary servers are 'authoritative' for the zones
which
they hold.

A name server that is "authoritative" for a zone means that the name server,
whether primary or slave, does not look anywhere else except itself for
queries against that zone. Hence, if you query a name server for
"dc1.forest." and the nameserver is authoritative for the zone "forest."
(meaning it is either a primary, slave, or active directory integrated name
server for the zone), it will not look to other name servers to find the
answer. It has the information itself, and returns it. This is what an
"authoritative name server" is. In this case, the nameserver which is
configured in the TCP/IP configuration of the DC that I am running netdiag
/test:dns on is an "authoritative" name server for the DNS domain name
"forest." <-- which again, is a perfectly valid DNS domain name unless
Microsoft has changed the DNS protocol. This means that the nameserver will
not look elsewhere to look for "forest." because that name server already
has that information.

It is a good idea to add a client ALTERNATE for times when the Preferred DNS
server is down.

It is Microsoft's recommendation that when using a single master replication
topology for DNS (i.e. Bind) that domain controllers should have only one
DNS entry in it's TCP/IP configuration. Certainly, it does not hurt to have
a second name server listed in case the first name server is down, but that
is irrelevent to this issue because it is not down. It is, in fact,
functioning properly.

Don't flail around (e.g., AD integrated vs. Primary, rebuilding zones)
trying to solve
a problem that is not understood. A "set" of AD Integrated Servers should
largely
be thought of as a substitute for the Single Primary. In terms of setup
they are
basically interchangable (an AD integrated SET offers some additional
features
and efficiency.)

Secure vs. non-Secure is only an issue for NON-forest/domain machines (e.g.,
Unix,
Macintosh etc) and of course "visitors".

These were troubleshooting steps that were being taken to determine why all
of the sudden the domain controllers in separate domain trees stopped
properly dynamically updating the forest zone. Each step was taken
independently and tested. I am not "flailing" around with my configuration.
I understand Active Directory, Sites (irrelevent here as well), and I most
certainly understand DNS.

[WARNING] Cannot find a primary authoritative DNS server for the name
'DC1.FOREST.'. [RCODE_SERVER_FAILURE] The name 'DC1.FOREST.' may not be
registered in DNS.

You really should use DCDiag to test all DCs.

DCDIAG reports that everything is configured properly. Domain controllers
are registering their records properly. Name lookups work properly. The
only thing that is reporting an error is netdiag /test:dns. netdiag
/test:dns is apparently erroniously reporting an error.

"Cannot find a primary authoritative DNS server for the name 'DC1.FOREST.'
[RCODE_SERVER_FAILURE] is an erronious error when nslookup clearly is
capable of finding an SOA record (This means "Start of Authority", hence
Authoritative DNS server) when queried against the same name server that the
DC is properly sending dynamic updates to.

 

[Enkidu]

The forest is not called "FOREST" and the DNS name for the forest is not
"forest." It is something else, as I changed the names to generic names for
posting on this newsgroup. There is nothing wrong with using "oneword." as
a domain name. This is just as valid as "forestdomain.com." The fact that
"forest." is not a valid TLD on the public Internet is a non-issue as my
network is isolated and my DNS servers are authoritative for the zone and
domain "forest."

Yes, there are AD server location problems with single-level Domain
Names. Microsoft do not recommend using them.:

http://www.jsiinc.com/SUBI/tip4200/rh4260.htm

We do not have three trees. We have two domain trees within the forest.
The architecture of active directory (our decisions as to tree structure and
forest) is irrelevent. A forest with two domain trees within it is a normal
configuration. Each tree is one corporation (as explained in my post), with
our forest acting as a "resource" domain for things such as IT staff
workstations, servers, accounts, etc.

You do have three trees. You have a forest root domain called "forest"
and two tree root domains.

Cheers,

Cliff

 

[Craig Matthews]

This knowledge base article has resolved the issue.

To clarify, Microsoft's recommendation to not use single name domains is not
a technical issue. It is an adminstrator competance issue. Microsoft
changed the default behavior in service pack 4 to prevent administrators who
do not know how DNS works from creating name collisions or overloading root
servers. There are no "issues" with using single name domains except
administrator incompentance in not isolating their namespace from the
Internet.

The problem I was having was a result in a change of behavior of the DNS
client in Service Pack 4 (Side note: Microsoft has, up until this point,
claimed that the DHCP client is solely responsible for sending dynamic
updates to a name server, not the DNS client). Apparently, Microsoft, in
Service Pack 4, defaulted Windows so that it would not send dynamic updates
to single name domains. This was not the behavior pre service pack 4. In
fact, the pre service pack 4 behavior is valid. The fact that Microsoft
changed this behavior does not mean that the use of single name domains is
not valid or non compliant. It simply means that Microsoft recommends that
people don't use them. Which is fine advice for those that don't know what
they're doing. The only technical reason Microsoft could possibly have,
other than administrator incompetance, to recommend such a thing is if their
software is not treating top level domains the same as any other domains,
even though they are functionally the same on an isolated non-Internet
connected network. And if that's the case, Microsoft is not following the
protocol at all.

Craig Matthews

 

[Herb Martin]

We do not have three trees. We have two domain trees within the forest.

If you have (something like) Domain1, DomainX.com, and DomainY.com
you do (by definition) have three trees.



--
Herb Martin

/test:dns on is an "authoritative" name server for the DNS domain name

You now seemt to understand authoritative -- "an authoritative" implies
something different from "the authoritative" a common misunderstanding
in fact.

"forest." <-- which again, is a perfectly valid DNS domain name unless

I agree it is a valid DNS name -- and you have already run up against
Microsoft's
issue with your using this -- and apparently fixed the problem by following
the
"single tag" procedures.

I will not argue whether Microsoft should have done this or recommended it;
but single tags names are a bad idea for both reasons.

To whit, your problems in using a single tag name.

These were troubleshooting steps that were being taken to determine why all
of the sudden the domain controllers in separate domain trees stopped

No, as described, it was flailing.

 

[John]

We are using a single label domain name and after updating our 2000
servers to sp4, We had a problem where our dhcp clients were updating
the dns fine but our static clients were not and as a result our dc's
stopped replicating properly. We were able to fix it by following
Microsoft's article 300684. Maybe this could help you out.

We presently have an active directory forest with two domain trees:

Forest's DNS Name: forest.
Forest's NetBIOS Name: FOREST

Domain Trees:
DNS Name: corporation1.com.
NetBIOS Name: CORP1

DNS Name: corporation2.com.
NetBIOS Name: CORP2

Before you say anything, our internal DNS namespace is isolated from the
outside world and our DNS servers are authoritative for the domain "forest."
This is a perfectly valid usage of DNS. In fact, our forest has been
working for two years. By using this DNS name, the only thing I lose is the
ability to establish trusts with other domains via the Internet, which isn't
going to be happening anyway.

All of our domain controllers in the forest have one DNS server configured
in their TCP/IP settings -- the one which is authoritative for our internal
active directory DNS zones "forest." "corporation1.com." and
"corporation2.com."

Recently, we added some new Domain Controllers (which we've done many times
before) to both domain trees. We noticed that the forest level records that
the DCs should register (such as the GC records, also the aliases under
guid.domains._msdcs.forest.) were not registering. The DCs would properly
register their records in their own respective AD zones, but not the
necessary records in the forest zone.

I was using MS DNS for hosting the AD DNS zones. After rebuilding the
forest zone file, trying both AD integrated and standard primary, and
reinstalling MSDNS, (also verified all security settings on the zone,
including trying unsecure and secure dynamic updates), it still wouldn't
work.

We migrated our AD zones to BIND 9, enabled dynamic updates, etc. This
seems to have solved our dynamic update problems. All of our DCs in the
forest are now successfully updating their records in their own domain zones
and in the forest zones.

So that problem is solved. I am, however, experiencing something strange.

When I run a netdiag /test:dns on any DC in the forest zone, I get the
following error:

[WARNING] Cannot find a primary authoritative DNS server for the name
'DC1.FOREST.'. [RCODE_SERVER_FAILURE] The name 'DC1.FOREST.' may not be
registered in DNS.

PASS - All the DNS entries for DC are registered on DNS server '10.0.0.2'
and other DCs also have some of the names registered.

If I /manually/ perform an SOA, NS, or A query on both "DC1.FOREST." and
"FOREST." I receive the correct response indicating the start of authority
is properly configured and the DNS server is properly responding.

C:\Program Files\Support Tools>nslookup
Default Server: ns1.company.com
Address: 10.0.0.2

*** SOA QUERY on Domain Controller that netdiag /test:dns reported an error
on:

set qtype=soa
dc1.forest.

Server: ns1.company.com
Address: 10.0.0.2

forest
primary name server = ns1.company.com
responsible mail addr = hostmaster.company.com
serial = 2003110212
refresh = 1800 (30 mins)
retry = 600 (10 mins)
expire = 5184000 (60 days)
default TTL = 18000 (5 hours)


*** SOA QUERY on forest domain:

forest.

Server: ns1.company.com
Address: 10.0.0.2

forest
primary name server = ns1.company.com
responsible mail addr = hostmaster.company.com
serial = 2003110212
refresh = 1800 (30 mins)
retry = 600 (10 mins)
expire = 5184000 (60 days)
default TTL = 18000 (5 hours)

forest nameserver = ns1.company.com

ns1.company.com internet address = 10.0.0.2
As you can see, DNS is functioning 100% perfectly for this zone "forest.".
Dynamic updates proceed, and DCs are able to be located, etc. Everything is
fine. The only indication to any problem is the netdiag /test:dns error
reporting an inability to find an authoritative DNS server (even though it
can be found just fine).

Any ideas what's going on?


Thanks!