One of the fun things about running stuff at home, once you have something working remotely well you sure don't want to change it. As such I have setup Bind 9 with DHCP and it works pretty good with a bunch of scripts I have to handle various dynamic adding and removing from my running system. Every system in this house works off of this base, very stable system. This works pretty well and there in comes the issue. I am attempting to bring up an Active Directory Domain for testing a variety of products and as is typical MS, as long as you give all your money to MS, everything works great. The minute you step out of that paradigm the documentation and functionality tends to falter a bit.

In order to setup Windows 2008 Active Directory domain, the system basically expects you to use MS DNS/DHCP services. I have no desire to tear down a perfectly functional environment and make it work now with MS DNS. After a significant amount of digging I found some good webpages on how to setup Bind to work with AD. None of them worked right though.


So plan D at this point was reading some of the docs on Active Directory and DNS on technet and then turning up named logging and watching for what the future DC was asking for. Create the domain without passing the network tests and then just run dcdiag /test:DNS a couple dozen times added in each entry as you need to. Add this into /etc/named.conf and then run service named restart.

logging {

category "default" { "debug"; };
category "general" { "debug"; };
category "database" { "debug"; };
category "security" { "debug"; };
category "config" { "debug"; };
category "resolver" { "debug"; };
category "xfer-in" { "debug"; };
category "xfer-out" { "debug"; };
category "notify" { "debug"; };
category "client" { "debug"; };
category "unmatched" { "debug"; };
category "network" { "debug"; };
category "update" { "debug"; };
category "queries" { "debug"; };
category "dispatch" { "debug"; };
category "dnssec" { "debug"; };
category "lame-servers" { "debug"; };
channel "debug" {
file "/tmp/namedebug" versions 2 size 50m;
print-time yes;
print-category yes;
};


After watching this log file and trying to promote a machine to a DC a couple dozen times and testing this, I found the following DNS entries in your zone are needed.

If my DC is going to have a DNS name of DC.home.here.org with an IP of 192.168.1.4 and the domain is HOME, then these are the entries needed.

home.here.org A 192.168.1.4
DC.home.here.org A 192.168.1.4
UID #1 - the subkey in HKLMSoftwareMicrosoftCryptographyAutoEnrollmentAEDirectoryCache
UID #2 - I don't know where this comes from. I think it is something Domain related. It isn't in the registry.
(These UID based DNS entries might not be needed - not sure)

$ORIGIN _msdcs.home.here.org.
(UID #1 - might not be needed) CNAME DC.home.here.org.

$ORIGIN _tcp.Default-First-Site-Name._sites.dc._msdcs.home.here.org.
_kerberos SRV 0 0 88 DC.home.here.org.
_ldap SRV 0 0 389 DC.home.here.org.

$ORIGIN _tcp.dc._msdcs.home.here.org.
_kerberos SRV 0 0 88 DC.home.here.org.
_ldap SRV 0 0 389 DC.home.here.org.

$ORIGIN _msdcs.home.here.org.
_ldap._tcp.(UID#2 - might not be needed).domains SRV 0 0 389 DC.home.here.org.
gc A 192.168.1.4

$ORIGIN gc._msdcs.home.here.org.
_ldap._tcp.Default-First-Site-Name._sites SRV 0 0 389 DC.home.here.org.
_ldap._tcp SRV 0 0 389 DC.home.here.org.

$ORIGIN _msdcs.home.here.org.
_ldap._tcp.pdc SRV 0 0 389 DC.home.here.org.

$ORIGIN _tcp.Default-First-Site-Name._sites.home.here.org.
_gc SRV 0 0 3268 DC.home.here.org.
_kerberos SRV 0 0 88 DC.home.here.org.
_ldap SRV 0 0 389 DC.home.here.org.

$ORIGIN _tcp.home.here.org.
_kerberos SRV 0 0 88 DC.home.here.org.
_kpasswd SRV 0 0 464 DC.home.here.org.
_ldap SRV 0 0 389 DC.home.here.org.

$ORIGIN home.here.org.
_kerberos._udp SRV 0 0 88 DC
DC A 192.168.1.4


Enter all these and then try creating your domain again. This got me up and running. It would be nice in the spirit of openness to give me an option from dcdiag to dump all the DNS entries the system is looking for and testing.