Bind/win2k3 issue driving me crazy 1

[Jalapeno]

I got Win2k3 AD setup and working just fine in our testbed with Bind DNS on Fedora core 1.

I copied the zone files and conf file to our production DNS and fired up our new win2k3 AD server.

But it's not working and it's driving me crazy.

I'm not even showing anything in the DNS logs to show that the AD server is even trying to register it's DNS entries. However, DNS itself is working fine, just the dynamic updates don't work.

See anything wrong?

Win2k3 Domain controller setup
DNS - Prefered DNS server - Linux DNS server
secondary - none
DNS is installed on this server and only has secondary zones.
Register this connection in DNS is checked

Linux DNS server
Bind is installed and working. The only thing not working is dynamic updates. Zones are being transfered to MS DNS on the AD server just fine.
Conf file:
acl ADservers {
10.10.1.10;
};

options {
directory "/var/named";
pid-file "/var/run/named.pid";
statistics-file "/var/run/named.stats";
listen-on { 10.10.1.40;127.0.0.1; }; //believe req to listen for updates
};
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
};
key "rndc_key" {
algorithm hmac-md5;
secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
zone "." {
type hint;
file "root.hints";
};
zone "blah.com" {
type master;
file "blah.com";
allow-transfer{ 10.10.44.2;10.10.70.40;10.10.44.4;10.10.1.10; };
allow-update {ADservers;};
};

zone "1.10.10.in-addr.arpa" {
type master;
file "10.10.1";
allow-transfer{ 10.10.1.40;10.10.70.40;10.10.44.4;10.10.1.10; };
allow-update {ADservers;};
};

zone "0.0.127.in-addr.arpa" {
type master;
file "pzz/127.0.0";
};

//Special AD zones required for blah.com
zone "_msdcs.blah.com" {
type master;
file "_msdcs.blah.com";
// allow-transfer{10.10.1.40;10.10.1.10; };
allow-update {ADservers;};
};

zone "_sites.blah.com" {
type master;
file "_sites.blah.com";
allow-transfer{10.10.1.40;10.10.1.10; };
allow-update {ADservers;};
};

zone "_tcp.blah.com" {
type master;
file "_tcp.blah.com";
allow-transfer{10.10.1.40;10.10.1.10; };
allow-update {ADservers;};
};

zone "_udp.blah.com" {
type master;
file "_udp.blah.com";
allow-transfer{10.10.1.40;10.10.1.10; };
allow-update {ADservers;};
};

zone "ForestDnsZones.blah.com" {
type master;
file "ForestDnsZones.blah.com";
allow-transfer{10.10.1.40;10.10.1.10; };

Zone file:
$ORIGIN .
$TTL 3600
blah.com IN SOA blah.com. blah.blah.com. (
2005100701 ; serial
10800 ; refresh
3600 ; retry
604800 ; expire
400 ; default_ttl
)
IN NS dns.blah.com.
IN NS win2k3.blah.com.
$ORIGIN blah.com.
$TTL 400
IN MX 10 pop3
IN MX 20 mail01
;localhost A 127.0.0.1
server1 IN A 10.10.1.7
server2 IN A 10.10.1.55
server3 IN A 10.10.1.52

 

[ITPangaeaArchitect]

secondary zones cannot accept the dynamic updates...or any updates for that matter...they get their info from the primary DNS zone that its replicating...so if Linux won;t allow dynamic registration, then neither will Windows...you should however be logging some netlogon and possibly DnsApi warnings and errors indicating failure to dynamically update the records...unless the NIC is set to not register this connections addresses in DNS...which turns off dynamic updates at teh NIC level....

The DNS config is wrong for AD anyway...I pasted a template I use for my customers....althoug hyou may not be at a point to be able to do this method....I would think the best way would be to make the secondary zone for the domains name (internal domain)..allow zone replication to occur...change the scope of the zone in MS DNS to be AD integrated (assuming these are DCs), and adjust clients and/or servers (especially DCs) to use MS DNS for preferred..once this is done, go into the zone properties and change the zone updates to be allow unsecure and secure or secure only..this should allow your dynamic updates...you can still constrain all internet traffic to where it all goes through Linux DNS by use of forwarders....

just keep in mind....BIND and QIP DNS both are bears/do not work well when it comes to AD....

with teh MS DNS you will automatically have the _msdcs items created and all will be good for the most part...


DNS configuration (if you are running Windows 2000 and do not use this configuration, you may experience issues anywhere from replication to authentication of users, 2003 can also experience same issues):

**Note: I have included a custom method I use that I refer to as standardization. The standardization technique has the potential to decrease the frequency of “business down” issues that are caused by name resolution by approximately 80-90% (assuming long term downage here…examples are file replication, and user logons). The standardization method does take more time to initially set up/configure, but the downtime saved is easily worth the extra effort. To use the standardization method, you must take inventory of all DCs in your domain. Meaning, you will need the IP address, as well as the AD site they belong to. It is easiest to write this information down into a word or text document and then rearrange them in site order (this way you can go site by site instead of searching a list for site members). I would also make a mark by the PDCe so as to not confuse anything (example below). In the recommendations below, the standardization method will always be the method to follow the “-OR-“ (which follows the simple, acceptable method).
EX (servername – IP – sitename; PDC will be servername-PDC-IP-sitename)---
DOM1DC1 – PDC – 10.0.1.2 – Dallas
DOM1DC2 – 10.0.1.3 – Dallas
DOM1DC3 – 10.0.1.4 – Houston
DOM1DC4 – 10.0.1.5 – Houston

**this should make it substantially easier to go through the process without losing your place. It also has the additional benefit of creating DC documentation for later reference.

Standardization method PROS/CONS---
PROS:
-Has potential to decrease major issues caused by name resolution almost in their entirety (I have not seen any name resolution related problems whatsoever any of the times myself, or a customer I recommended the method to, performed this method). This method allows us to maintain DNS name resolution site by site because, for example, if a failure on the PDCe occurs, all members in the PDCe site, since they point to the same alternates in the same order, will fail back to the same DNS server, and begin registering there instead…if that replica DC fails, the same still goes…each time we have a failure all members of the site will fail to the same DNS server, thereby maintaining DNS name resolution almost indefinitely. I do not guarantee no failures at all, but it would substantially decrease the chances of them occurring at all.
CONS:
-Takes longer to configure
-If roles are transferred (specifically the PDC role), complete reconfiguration is required enterprise wide to reflect the new PDCe (this is a step that should be taken whether using standardization or simple method)


*****

Default advanced TCP/IP properties (settings should match these)---
DNS server address is listed
Append primary and connection specific DNS suffixes is marked (radio button)
Append the parent suffix of the primary DNS suffix is checked (checkbox)
Register this connections addresses in DNS is checked (checkbox)
Everything else should be blank
Ensure NetBIOS over TCP/IP is enabled and not set to default (mainly for Win2003)

Domain controllers---
PDCe faces itself and itself only for DNS, with defaults in advanced tcp/ip properties
Replica DCs in the enterprise (all sites) point to the PDCe for preferred DNS, and themselves as alternate, with defaults in advanced tcp/ip properties
-OR-
All replica DCs in site with the PDCe point to the PDCe for preferred, and all the same replica DCs in the same order beginning with the replica DCs in the site with the PDCe, and then out of site replicas (you choose alternate DNS order based on preference and site membership, there is no certain way you need to do this, although I would stick to site by site method…I normally base off of machine performance…such as a 3ghz processor w/ 4GB RAM would be listed before a 2ghz w/ 4GB RAM). Replica DCs in different sites than the PDCe should use the same methods, using the PDCe as preferred, and then the same order for alternates, beginning with replica DCs in the same site as first alternates, then moving to replica DCs in other sites.
EX (using server names and info from example above and adding on complexity):
DOM1DC1 – PDC – 10.0.1.2 – Dallas
DOM1DC2 – 10.0.1.3 – Dallas
DOM1DC5 – 10.0.1.6 - Dallas
DOM1DC3 – 10.0.1.4 – Houston
DOM1DC4 – 10.0.1.5 – Houston
DOM1DC6 – 10.0.1.7 - Houston


P: = preferred DNS A: = alternate DNS
DOM1DC1 – Dallas site - P: 10.0.1.2 & A: None
DOM1DC2 – Dallas site - P: 10.0.1.2 & A: 10.0.1.3, 10.0.1.6, 10.0.1.4, 10.0.1.5, 10.0.1.7
DOM1DC5 – Dallas site - P: 10.0.1.2 & A: 10.0.1.3, 10.0.1.6, 10.0.1.4, 10.0.1.5, 10.0.1.7
DOM1DC3 – Houston site – P: 10.0.1.2 & A: 10.0.1.4, 10.0.1.5, 10.0.1.7, 10.0.1.3, 10.0.1.6
DOM1DC4 – Houston site - P: 10.0.1.2 & A: 10.0.1.4, 10.0.1.5, 10.0.1.7, 10.0.1.3, 10.0.1.6
DOM1DC6 – Houston site - P: 10.0.1.2 & A: 10.0.1.4, 10.0.1.5, 10.0.1.7, 10.0.1.3, 10.0.1.6


Domain members (servers and workstations) in site with PDCe:
Face PDCe as preferred DNS, and replica DCs as alternates in the same order specified on replica DCs in that site
EX:
DOM1DC1 – PDC – 10.0.1.2 – Dallas
DOM1DC2 – 10.0.1.3 – Dallas
DOM1DC5 – 10.0.1.6 - Dallas
DOM1DC3 – 10.0.1.4 – Houston
DOM1DC4 – 10.0.1.5 – Houston
DOM1DC6 – 10.0.1.7 - Houston

WORKSTATION1 – Dallas (PDCe) site - P: 10.0.1.2 & A: 10.0.1.3, 10.0.1.6, 10.0.1.4, 10.0.1.5, 10.0.1.7


Domain members (servers and workstations) outside of PDCe site:
Choose a replica DC in that site to act like the PDCe’s DNS role for DCs (there is no special way to go about this…i.e.; if we choose DOM1DC3 to be preferred for all clients is fine, on the same note, so is choosing DOM1DC7 if we wanted). The top alternates will be replica DCs from the local site, then other sites replica DCs. The reason for not doing the same DNS config on clients outside of site of PDCe as we did on replica DCs in that remote site is to save time and bandwidth for DNS name resolution.
EX:
DOM1DC1 – PDC – 10.0.1.2 – Dallas
DOM1DC2 – 10.0.1.3 – Dallas
DOM1DC5 – 10.0.1.6 - Dallas
DOM1DC3 – 10.0.1.4 – Houston
DOM1DC4 – 10.0.1.5 – Houston
DOM1DC6 – 10.0.1.7 - Houston

WORKSTATION2 – Houston site – P: 10.0.1.4 & A: 10.0.1.5, 10.1.0.7, 10.0.1.2, 10.0.1.3, 10.0.1.6



keep in mind that reverse lookup zones are always stored in MS DNS...the main zone may not be...it could be in DomainDnsZones, ForestDnsZones, or MS DNS inside of AD...depending on the settings used.


-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there

 

[Jalapeno]

I've already resolved the issue. However, this is alot of great information and I will definately use it. thanks!

 

[ITPangaeaArchitect]

glad to hear it bud.....and never a problem

-Brandon Wilson
MCSE00/03, MCSA:Messaging, MCSA03, A+
almost got a paragraph there