Domain Controller

[Dave]

Hi all,

My brand new AD domain controller is making regular DNS
queries to two WAN IPs belonging to our ISP. [The requests
are being blocked and logged by our firewall.] We operate
our own internal DNS servers (forwarding enabled on the
DC), so I can't imagine what the DC is looking for outside
of our subnet.

Any ideas what would cause this?

Thank you!

Dave

 

[Herb Martin]

Hi all,

My brand new AD domain controller is making regular DNS
queries to two WAN IPs belonging to our ISP. [The requests
are being blocked and logged by our firewall.] We operate
our own internal DNS servers (forwarding enabled on the
DC), so I can't imagine what the DC is looking for outside
of our subnet.

Any ideas what would cause this?

Couple of things, one serious and the other mildly annoying;
both preventable.

1) You must have internal DNS clients set to STRICTLY
use the Internal DNS server (set) that supports your dynamic
zone corresponding to the domain. It's going to try to register
itself in that zone and use it a lot.

DCs are DNS clients too.

Setting external servers on the client NIC is wrong, and
having a having a mixture is almost as bad but more unpredictable.

2) Not having reverse zones -- this won't really hurt anything,
but the DC is likely to try to register it's reverse zones too.

If you are using locally administered address ranges then just
created the reverse zones (even can make them dynamic if you
wish) and this will short-circuit the attempts by your DC to
find and register itself outside.

 

[Dave]

Thank you, Herb.

I'm guessing it's the reverse-lookup issue you describe.
Upon inspection, I see that my domain controller has no
reverse-lookup zone for our AD-integrated zone.

But how do I add a reverse-lookup zone for a "private" TLD
(e.g., mycompany.local)? When I select "Add Zone," I get a
wizard which automagically inserts "in.addr.arpa" to the ip
range when, in fact, we both know that ARPA has no
knowledge of the ".local" TLD.

Any recommendations are greatly appreciated.

Dave

-----Original Message-----

Hi all,

My brand new AD domain controller is making regular DNS
queries to two WAN IPs belonging to our ISP. [The requests
are being blocked and logged by our firewall.] We operate
our own internal DNS servers (forwarding enabled on the
DC), so I can't imagine what the DC is looking for outside
of our subnet.

Any ideas what would cause this?

Couple of things, one serious and the other mildly annoying;
both preventable.

1) You must have internal DNS clients set to STRICTLY
use the Internal DNS server (set) that supports your dynamic
zone corresponding to the domain. It's going to try to register
itself in that zone and use it a lot.

DCs are DNS clients too.

Setting external servers on the client NIC is wrong, and
having a having a mixture is almost as bad but more unpredictable.

2) Not having reverse zones -- this won't really hurt anything,
but the DC is likely to try to register it's reverse zones too.

If you are using locally administered address ranges then just
created the reverse zones (even can make them dynamic if you
wish) and this will short-circuit the attempts by your DC to
find and register itself outside.


.

 

[Herb Martin]

Thank you, Herb.

I'm guessing it's the reverse-lookup issue you describe.
Upon inspection, I see that my domain controller has no
reverse-lookup zone for our AD-integrated zone.

Technically there is no such thing -- Reverse zones are
not related to forward zones in DNS, and can themselves
be AD-integrated if you so wish.

The relationship between reverse zones and the forward
zones is only in the minds of us admins. (Really)

But how do I add a reverse-lookup zone for a "private" TLD
(e.g., mycompany.local)? When I select "Add Zone," I get a
wizard which automagically inserts "in.addr.arpa" to the ip

That would be in-addr.arpa.

range when, in fact, we both know that ARPA has no
knowledge of the ".local" TLD.

It matters not at all -- there is nothing special about "arpa"
here except that it is the artificially chosen suffix for ALL
reverse zones.

Any recommendations are greatly appreciated.

Just create the zone(s) -- and consider making dynamic.

BTW, there is NO downside to having the zone cover
the entire private range, and in fact having them for all
three private ranges is a good idea.

If you ever use those numbers in the future, the problem
will not suddenly return -- and they are NOT going to
resolve on the Internet anyway.

 

[Kevin D. Goodknecht Sr. [MVP]]

In

Thank you, Herb.

I'm guessing it's the reverse-lookup issue you describe.
Upon inspection, I see that my domain controller has no
reverse-lookup zone for our AD-integrated zone.

But how do I add a reverse-lookup zone for a "private" TLD
(e.g., mycompany.local)? When I select "Add Zone," I get
a wizard which automagically inserts "in.addr.arpa" to
the ip range when, in fact, we both know that ARPA has no
knowledge of the ".local" TLD.

You are under the assumption that reverse zones are in direct relationship
with forward zones, they aren't.
If you create the zone for example 168.192.in-addr.arpa. (for 192.168.x.x
subnets) set the zone to allow dynamic updates, any client that supports
DDNS will register their own PTR records using their host name and primary
DNS suffix.

 

[Ace Fekay [MVP]]

Thank you, Herb.

I'm guessing it's the reverse-lookup issue you describe.
Upon inspection, I see that my domain controller has no
reverse-lookup zone for our AD-integrated zone.

But how do I add a reverse-lookup zone for a "private" TLD
(e.g., mycompany.local)? When I select "Add Zone," I get a
wizard which automagically inserts "in.addr.arpa" to the ip
range when, in fact, we both know that ARPA has no
knowledge of the ".local" TLD.

Any recommendations are greatly appreciated.

Dave

Just to point out, if you were to upgrade to Win2003, the SPNEGO is the PTR
for the SPN records that Kerberos uses for each DC identity. It literally
looks for a PTR in the reverse zone for each DC. If one is missing, it
generates a 40961 Event log error. Win2000 doesn't use this record (as far
as I know).


--
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

Paramount: What's up with taking Enterprise off the air??
Infinite Diversities in Infinite Combinations.
=================================