If you use an internal domain that is able to be registered publicly, then try to ensure that you do. That will also save headaches down the track.
That all said, split brain scenarios can be implemented even when the internal AD domain *doesn't* match the external domain. That is why there is no direct relationship between having the same internal/external domain, and split brain. Split-brain has some management overhead (the potential need to keep disparate systems in-sync). Having the same domain internally and externally (and also having, at the same time, to implement split brain) is something that has no obvious reasons to recommend it, and has a number of downsides. It might be implemented because of business constraints, but if starting from scratch, there is no way I would recommend it. There are few people who would recommend it who've worked in a large number of large customers. Cheers Ken -----Original Message----- From: Raper, Jonathan - Eagle [mailto:jra...@eaglemds.com] Sent: Wednesday, 3 March 2010 8:14 PM To: NT System Admin Issues Subject: RE: Probably a stupid DNS question, but I can't figure it out. +1 External USED to be eaglephysicians.com Now it is eaglemds.com, but they are considering changing our public dmain name once again... SOOO glad I chose eagle.com for our internal when we setup AD back in 2001! Jonathan L. Raper, MCSE Sent from my Windows Mobile (r) enabled Smartphone. Please excuse brevity & any misspellings. ________________________________ From: Andrew S. Baker <asbz...@gmail.com> Sent: Wednesday, March 03, 2010 6:50 AM To: NT System Admin Issues <ntsysadmin@lyris.sunbelt-software.com> Subject: Re: Probably a stupid DNS question, but I can't figure it out. Imagine these two scenarios: Company 1: (Typical split-brain DNS scenario) -- External domain: MyOwnCorp.com -- Active Directory domain: MyOwnCorp.com Company 2: -- External domain: MyOwnCorp.com -- Active Directory domain: SomeInternalDomain.tld Scenario #1 is what the OP is facing. AD requires certain entries to point to certain systems, so everything that has to be reached on the outside must be maintained in two places. Also, if for some reason his company splits and needs to change the domain name, it *will* impact his internal AD domain as well. In scenario #2, administrators can choose to manage an internal subset of the external zone at their own discretion. Or not. If there are resources that they want to access with a single name, but from a different IP depending on where the user is, then they have the option of adding the external zone or setting up a stub zone, or routing it through the external network interfaces, or some other arrangement, thereby gaining all of the advantages of the first scenario. If there is a merger, acquisition, divestiture, corporate re-branding, or some other corporate activity that causes them to lose access to, or ownership of, the primary external domain, there will likely be ZERO impact to their AD domain in this scenario, and far less complications ongoing. If you've never had the joy of having a company spin-off a division, with the smaller entity keeping the old domain names, then you don't know what you're missing. :) -ASB: http://xeesm.com/AndrewBaker On Wed, Mar 3, 2010 at 3:37 AM, Juma, Lumumba <lcj...@icipe.org<mailto:lcj...@icipe.org>> wrote: We have done split DNS because of Outlook anywhere and other applications that have to be accessed off the network. -----Original Message----- From: Ken Schaefer [mailto:k...@adopenstatic.com<mailto:k...@adopenstatic.com>] Sent: Wednesday, March 03, 2010 11:19 AM To: NT System Admin Issues Subject: RE: Probably a stupid DNS question, but I can't figure it out. ??? All the below can be accomplished with/without using the same domain internally & externally or requiring split-brain DNS. Cheers Ken -----Original Message----- From: Carl Houseman [mailto:c.house...@gmail.com<mailto:c.house...@gmail.com>] Sent: Wednesday, 3 March 2010 10:00 AM To: NT System Admin Issues Subject: RE: Probably a stupid DNS question, but I can't figure it out. +1. The advantage I see is keeping it simple - users don't have to determine "which domain name do I use?" depending on where they are working, or whether or not a VPN connection is active, etc. And a single mail profile for Outlook RPC over https. Carl -----Original Message----- From: Kurt Buff [mailto:kurt.b...@gmail.com<mailto:kurt.b...@gmail.com>] Sent: Tuesday, March 02, 2010 7:16 PM To: NT System Admin Issues Subject: Re: Probably a stupid DNS question, but I can't figure it out. Absolutely true. I was just questioning the idea that setting up split brain DNS is a 'mistake'. IMHO, giving up resolving the bare domain 'example.com<http://example.com>' to 'www.example.com<http://www.example.com>' is at worst a very small, extremely tiny annoyance, which unfortunately some folks allow to bloom into a major political battle, and I hope that's not what you're experiencing.. I still think it's an excellent way of setting up DNS, for many/most situations. Kurt On Tue, Mar 2, 2010 at 15:49, Andrew S. Baker <asbz...@gmail.com<mailto:asbz...@gmail.com>> wrote: > But OP doesn't want to have to use www on the inside, hence the problem. > > > -ASB: http://xeesm.com/AndrewBaker > Sent from my Verizon Smartphone > > -----Original Message----- > From: Kurt Buff <kurt.b...@gmail.com<mailto:kurt.b...@gmail.com>> > Date: Tue, 2 Mar 2010 12:54:08 > To: NT System Admin > Issues<ntsysadmin@lyris.sunbelt-software.com<mailto:ntsysad...@lyris.s > unbelt-software.com>> > Subject: Re: Probably a stupid DNS question, but I can't figure it out. > > I don't think OP has the same *zone file* for both. That would be a > poor decision indeed. > > However, at $WORK we use the same domain name both internally and > externally (example.com<http://example.com>, no subdomains internally > or externally), and aside from needing to put in 'www' while inside > the perimeter, we've seen no issues, after moving away from an IPSec > VPN to an SSL web-based VPN. Forcing all traffic over the IPSec tunnel > is a major PITA from both a speed perspective and a client-management > perspective. > > > Kurt > > On Mon, Mar 1, 2010 at 18:00, Ken Schaefer > <k...@adopenstatic.com<mailto:k...@adopenstatic.com>> wrote: >> I wouldn't call it an "excellent decision" In fact, I'm aware of no-one that >> uses the same DNS namespace for their primary internal domain, and also the >> primary external domain. >> >> Split-brain DNS is fine, but using the same DNS zone isn't an "excellent >> decision" IMHO. I'm sure it can be justified in certain situations, but I >> wouldn't use it as a the rule-of-thumb. >> >> Cheers >> Ken >> >> -----Original Message----- >> From: Kurt Buff >> [mailto:kurt.b...@gmail.com<mailto:kurt.b...@gmail.com>] >> Sent: Tuesday, 2 March 2010 3:33 AM >> To: NT System Admin Issues >> Subject: Re: Probably a stupid DNS question, but I can't figure it out. >> >> It's *not* a mistake. It is, IMHO, an excellent decision, but it does have a >> cost, as ASB and others have noted. >> >> I don't know what's involved in re-jiggering your domain, aside from >> standing up a new one and migrating all of your machines over, but it would >> probably be worth your while to investigate that before you do it. >> >> I'm sure there's more to it than I'm aware of. >> >> Kurt >> >> On Mon, Mar 1, 2010 at 07:53, Chyka, Robert >> <bch...@medaille.edu<mailto:bch...@medaille.edu>> wrote: >>> >>> yes I realize the mistake we made over 10 years ago when we created the >>> domain. I will change the structure when we go to 2008 R2 next month. >>> >>> Thanks..Bob >>>________________________________ >>> From: Ken Schaefer >>>[mailto:k...@adopenstatic.com<mailto:k...@adopenstatic.com>] >>> Sent: Monday, March 01, 2010 10:44 AM >>> To: NT System Admin Issues >>> Subject: RE: Probably a stupid DNS question, but I can't figure it out. >>> >>> Erm - OP is talking about internal name resolution. For an internal AD >>> domain: domain.whatever is going to resolve to DCs. This one reason not to >>> use the same domain for external and internal name resolution. Externally >>> use medaille.edu<http://medaille.edu>. Internally use >>> corp.medaille.edu<http://corp.medaille.edu> or something. >>> >>> >>> >>> Cheers >>> >>> Ken >>> >>> >>> >>> From: Karl Bickmore >>> [mailto:k...@ccnsconsulting.com<mailto:k...@ccnsconsulting.com>] >>> Sent: Monday, 1 March 2010 11:41 PM >>> To: NT System Admin Issues >>> Subject: RE: Probably a stupid DNS question, but I can't figure it out. >>> >>> >>> >>> Put in a host (A) record on the domain name with no name details, but >>> still point it to the public ip. >>> >>> >>> >>> >>> >>> >>> >>> Karl Bickmore >>> >>> 6613 N Scottsdale Road, Suite 101 >>> >>> Scottsdale AZ, 85250 >>> >>> 480-553-9967 X100 >>> >>> k...@ccnsconsulting.com >>> >>> >>> >>> Please remember CCNS is a referral based business. If you have a friend or >>> colleague in need, we are happy to help. Feel free to pass along our >>> contact information to anyone you think we can help. Thanks! >>> >>> >>> >>> From: Chyka, Robert >>> [mailto:bch...@medaille.edu<mailto:bch...@medaille.edu>] >>> Sent: Monday, March 01, 2010 8:37 AM >>> To: NT System Admin Issues >>> Subject: Probably a stupid DNS question, but I can't figure it out. >>> >>> >>> >>> Hello, >>> >>> >>> >>> We have a Active Directory 2003 Domain with Microsoft integrated DNS >>> running for our company. If I want to add a DNS record to get to our >>> webserver, but want it to resolve without the www, what type of record do i >>> use? i was trying to put a CNAME record in, but it already has our domain >>> name in there by default and you cant change it and i cant leave the input >>> field blank for the hostname. We want medaille.edu<http://medaille.edu> in >>> a browser to redirect to www.medaille.edu<http://www.medaille.edu> >>> internally. We have it working with our ISP on the internet public side. >>> >>> >>> >>> Thanks! Bob >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ________________________________ Any medical information contained in this electronic message is CONFIDENTIAL and privileged. It is unlawful for unauthorized persons to view, copy, disclose, or disseminate CONFIDENTIAL information. This electronic message may contain information that is confidential and/or legally privileged. It is intended only for the use of the individual(s) and/or entity named as recipients in the message. If you are not an intended recipient of this message, please notify the sender immediately and delete this material from your computer. Do not deliver, distribute or copy this message, and do not disclose its contents or take any action in reliance on the information that it contains. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
