Setting up split DNS

Topic

New Reply

Hi everyone. I have an associate who owns a small business. He has only seven users on his network and he has one SBS 2003 server. He’s utilizing Exchange 2003 and SQL Server 2005. His server also hosts the primary application his company uses including his time and billing data. His SBS server is around 10 years old now and he’s finally ready to replace it. To that end he’s purchased a new HP server. He has a Microsoft Action Pack subscription so he has access to Windows Server 2012 and Exchange 2013. So he’s all set to make the move.

His current Active Directory (AD) and DNS environment are working fine. However, his internal domain is company.local and as we all know you won’t be able to get SSL certs with an internal only domain name around 2 years from now. As small as his setup is it wouldn’t be a problem to setup his new server with his current public domain name (company.com) to avoid the SSL cert issue coming in around 2 years. However, the time and billing package he uses can’t be moved to a new server at this time.

So what I’m thinking of doing is joining the 2012 server to the SBS 2003 domain, adding AD and DNS to it (but letting the SBS 2003 server continue holding the FSMO roles so it won’t freak out), and move everything BUT the time and billing software to the new server (including e-mail). The issue, of course, is that the new server will be joining a .local domain and we won’t be able to change that later on without completely rebuilding the entire system.

So I was thinking maybe we could use split DNS to solve this issue. I’ve been reading up on it and it sounds like it would be one way to resolve the issue heading our way 2 years from now. We’ll get a SAN cert with mail.company.com and autodiscover.company.com and use split DNS to ensure that, even though the Exchange server will be in the company.local domain, it’ll be able to use the cert and serve e-mail internally and externally.

Thoughts?

Reply | Quote

Replies

The standard for domain naming is company.com with your internal PCs/servers on ad.company.com. Obviously ad.company.com would have no external DNS records.
Setting up the new server in this domain and then migrating your users is the easiest solution, but it’s still a lot of work. You then add a domain trust to allow access to the old server / domain.
Exchange should only ever have the external domain, company.com, as the mailbox domain. The same for the public facing web site.
Your external firewall would then pass only specific requests / ports to Exchange and the web server.

cheers, Paul

Reply | Quote

Okay, so from what I’ve read we should configure the internal and external URL’s to point to the external URL addresses – mail.company.com and autodiscover.company.com – and setup split brain DNS on the internal DNS server. So his DNS will have company.local as well as company.com. I’ve looked at the information at the following link – http://www.petenetlive.com/KB/Article/0000830.htm – and am wondering if this is all I need to do in order to setup split brain DNS so it will work with my friend’s situation?

Reply | Quote

You should have an external DNS and an internal one. The internal one is part of AD and is authoritative for company.com and ad.company.com, as shown in your link. The external one contains only company.com addresses that you want external people to see, mail, www etc and is hosted by an external DNS hosting company – usually your domain registrar. Do not host your own internet facing DNS as there is a chance of your internal addresses being discovered.

As there is no upgrade path from server 2003 to server 2012 you need to use a new internal AD domain to allow you to transfer the users to the new server, ad.company.com.

cheers, Paul

Reply | Quote

Hi Paul. Thanks for the reply. So what we were thinking might work is to join the 2012 server to the 2003 domain, add the AD and DNS roles to the 2012 box, also get Exchange 2013 up on the 2012 box (yes, we know you should have Exchange and AD/DNS on the same box), and move everything but the time and billing package to the new server and leave all of this up as long as is necessary. Once he’s able to put the time and billing package on the new server we transfer the fsmo roles and decommission the sbs 2003 box. The domain will still be a .local, but if we use split DNS it sounds like this could work. What do you think?

Reply | Quote

Exchange should never be on the same box as AD/DNS. Then you can recover one without trashing the other.

A 2003 domain is not a 2012 domain and you cannot move FSMO roles from one to the other. Create the 2012 server as a new domain, add Exchange and migrate your users and data.

Back to your original post. There is no issue with SSL certificates and .local domains because you use SSL certificates on the internet and you can’t use a .local domain on the internet. If the certificate is to be used internally create a self signed certificate and advise your users to trust it – although I can’t see why you’d want one internally.

cheers, Paul

Reply | Quote

Thanks Paul. The problem with the whole thing is that the 2003 box has to remain up and the users have to be able to access it so they can continue using a single application that’s not ready to be used on the 2012 server. That’s the only reason why we can’t move everyone and everything off the old server and onto the new one. That was the original plan until my associate realized that the one application issue existed. So I have to have these two servers living side by side with the users being able to access the old application all day every day for a while. Using the 2 user terminal services license that the SBS box has by default (since it’s a server) isn’t an option. I’m just trying to come up with an easy way for the two servers to live side by side on the same domain. Any ideas because I was thinking the split DNS idea would work.

Reply | Quote

You have to use a new domain and a domain trust.

cheers, Paul

Reply | Quote

But SBS doesn’t support domain trusts…

Reply | Quote

This MS page shows migration from SBS2003 to server 2012, but I haven’t read the detail to know if you can still run the app on SBS2003. If that won’t work you may have to go the new domain and persuade your users to log into the SBS box separately, or use a generic server login if the app has its own user management.

cheers, Paul

Reply | Quote

Thanks. I think I’ll rebuild the 2012 box, join it to the SBS 2003 domain and then install Exchange 2013 and go from there.

Reply | Quote

I doubt you will be able to join a 2012 server to a 2003 domain.

cheers, Paul

Reply | Quote

You actually can join a 2012 server to a 2003 funcational level forest/domain and Exchange 2013 will run in that functional level forest/domain as well.

Reply | Quote