Since some weeks I am in the act of moving services from my virtual Windows 2000 server to my Ubuntu 12.04 machine. The first step was moving all files out of it so they are saved on my Ubuntu machine.
This post is about moving the Active Directory integrated DNS zones from Windows 2000 to bind9. First, a little bit about my current setup: 192.168.1.1, named speedy, offers DHCP and DNS services, while 192.168.1.2, named gspdc, offers Active Directory services and therefore also acts as a DNS server. Requests belonging the AD integrated domain (greatsoft.local) are forwarded from speedy to gspdc. This KB article from Microsoft shows an easy way to get all AD integrated DNS zones in files so that they could be processed by bind9. The easy trick is to simply convert those zones to "primary zone files": Afterwards, they are saved in the default DNS directory (that is normally %WINDIR%\System32\DNS). To get them to Ubuntu, I use SMB, so I first activated sharing the directory as "dns". On Ubuntu, I mounted the share:
root@speedy:/mnt # mount -t cifs //192.168.1.2/dns temp -o username=Administrator
Then I copied the files to /etc/bind9:
root@speedy:/mnt # cp -v temp/*dns /etc/bind
To make the database file names compliant with the standard of bind9, I renamed all of them and gave them a "db." prefix like all other database files have.
Until that moment, I used forwarding in bind9 to get DNS requests for *.virtual, *.greatsoft.local (AD integrated) and reverse DNS requests belonging 192.168.0.0/16 being resolved by Windows 2000.
root@speedy:/etc/bind # cat named.conf.gspdc
zone "greatsoft.local" {
type forward;
forwarders { 192.168.1.2; };
};
zone "virtual" {
type forward;
forwarders { 192.168.1.2; };
};
zone "168.192.in-addr.arpa" {
type forward;
forwarders { 192.168.1.2; };
};
That's not necessary any more: now the zone files are available in /etc/bind. In that directory, I edited named.conf and commented out the reference to named.conf.gspdc. The replace these zones, I created three files: named.conf.greatsoft.local, named.conf.virtual and named.conf.192.168.1.x.subnet which have contents like the following:
root@speedy:/etc/bind # cat named.conf.greatsoft.local
zone "greatsoft.local" {
type master;
file "/etc/bind/db.greatsoft.local.dns";
};
In contrast to the previous situation, I now have separate files for every /24 of 192.168.0.0/16, so reverse DNS queries for 192.168.1.0/24 are resolved by a different file than those for 192.168.2.0/24. I think that's easier to manage, because otherwise the zone database file could get too large.
Next task it to add those new named.conf.* files to the main configuration file, named.conf:
include "/etc/bind/named.conf.192.168.1.x.subnet";
include "/etc/bind/named.conf.greatsoft.local";
include "/etc/bind/named.conf.virtual";
Now it's time to restart bind9 by "service bind9 restart" and troubles finally begin. A simple "nslookup www.mkcs.at.virtual 192.168.1.1" just returns "** server can't find www.mkcs.at.virtual: SERVFAIL". But a "host -t TXT test.virtual" returns the text that I entered for it once (just for test purposes, as the name suggests), the same is true for my test entries for "test.test.virtual" (type A) and "eee1.test.virtual" (type AAAA). Using "grep named /var/log/syslog | tail -30" I found an interesting line:
/etc/bind/greatsoft.local.dns:33: gc._msdcs.greatsoft.local: bad owner name (check-names)
That is line 33 of file greatsoft.local.dns:
gc._msdcs 600 A 192.168.1.2
It's yet unclear to me why this causes an error. However, that entry was used by Active Directory, which I am about to deactivate, so I can relinquish entries like that. After uncommenting this line and the following lines that belong to that entry "gc._msdcs", I use
service bind9 reload
to tell bind9 it should reload its configuration and voilà, it works (tested from a client PC in my network):
michael@michimain1404:~$ host -t A www.mkcs.at.virtual
www.mkcs.at.virtual is an alias for w3mkcs.greatsoft.local.
w3mkcs.greatsoft.local has address 192.168.1.64
That's it! The final steps in deactivating that old (virtual) system will be shutting it down, (finally!) uninstalling VMware and then move it to a safe place in case I still need some data from it.
If anyone has suggestions for me how to improve that process, just let me know, I'd be curious!
