up vote 1 down vote favorite
share [g+] share [fb]

I am currently trying to fix a flawed build at my location and want to get some suggestions / ideas about how best to proceed.

The systems (Windows 2003 and RHEL 4) came configured with an alias for each of four subnets:

server1         1.1.1.2  
alias1server1   2.2.2.2  
alias2server1   3.3.3.2  
alias3server1   4.4.4.2

Each of these systems had each others entries in the hosts file, which made them each around 10 pages (in notepad). The first subnet is a public subnet; the other three are private and geared towards server to server communications and backups. Please note, each IP address is configured on a separate physical NIC.

I'm now trying to do the logical thing and setup Active Directory with DNS integration so that I can get rid of the hosts files and make things run a little smoother, get away from hosts files and allow us to better audit and administer our enterprise.

Based on the research that I've done, I have setup my AD server to be single-homed, and only plan on adding in the primary server name as an object in AD. This leads me to the problem: what to do about the aliases and other subnets? Each subnet lacks an FQDN; they are just IP's and a hostname alias.

I have thought of different courses of action, from using the hosts files to allow the servers to look each other up or trying to create dummy A records for the aliases and point them to the different subnets (in reverse-lookup zones). Any suggestions or ideas?

link|improve this question
feedback

1 Answer

up vote 1 down vote

Using Active Directory or not is irrelevant. What you need is an DNS server, and the one in Windows works, but there are many alternatives as well.

First thing is you should make a DNS domain. This should be based on a domain you own on the internet. For example internal.mycompany.com. In this case, you own mycompany.com. internal may or may not exist on the real internet (see: DNS views). FQDN for your systems will be eg, server1.internal.mycompany.com.

Second, you need to make A records within that domain that connect the names to the IPs, eg:

alias1server1    A    2.2.2.2 
alias2server3    A    3.3.3.3

Third, you should set the domain you picked to be the default DNS suffix on all machines. The best place to do this is on your DHCP server, and the other place is in the network configuration on a per-machine basis. This is what allows you to just use server1 and get to server1.

You'll also need to set the DNS for your servers (either via DHCP or network config) to be your new DNS server's IP.

link|improve this answer
1  
Using a made up TLD like .local is bad. You should stick to a domain name that you own, even if it's just for internal use. – MDMarra Nov 22 '11 at 3:17
@MarkM: Alright, according to this article it's bad because it's not a reserved TLD (surprise to me). I'd wager that .local will never get allocated because of it's de-facto use as a TLD (Windows Server uses it by default, I believe), but even so, you're correct, and using a sub-domain you control is much safer. The only real danger is that it gets allocated as a TLD, and you can't access the real internet site called mysite.local from your LAN. – gregmac Nov 22 '11 at 3:28
1  
Windows Server certainly doesn't use .local by default. Old versions of SBS did, but that's a bastard of a product that should never be used as an example for anything. You'll also have a bitch of a time getting a CA to issue certs for a made up TLD, not to mention that the RFCs weren't written to be ignored. – MDMarra Nov 22 '11 at 3:30
@MarkM: Didn't realize it was just SBS that did that. Anyway, +1, you convinced me, I edited my answer. – gregmac Nov 22 '11 at 3:38
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.