Mark Minasi's Windows Networking Newsletter
Issue #30 January 2003

What's Inside

  • News: 
    • XP Support Seminars: Philly in January, Kansas City in April!
    • Windows Server 2003 Seminars in DC and LA in 2003
  • Tech Section
    • Errata:  Matt Kruse's Calendar Perl Script Has Moved
    • The Complete Guide To Split-Brain DNS
  • Conferences
  • Bring a Seminar to Your Site


Hello all —

This month, I've got what I hope is The Description To End All Descriptions of how to set up DNS for Active Directory so that you end up with the least possible hassle.  I'm inclined to call it "Split-Brain DNS for Dummies," but then I don't have any dummies in my readership.  Perhaps "Split-Brain for the Intelligent But Busy And Tired..." yeah, that kinda works.  I really think it'll be a useful guide.

XP Support Seminars:  DC, LA and NY Later in 2003

If your company is making the move from Wintendo (Win 9x), NT 4.0 or Windows 2000 Pro to XP Professional, then we've got the seminar for you!  "XP Professional for Support Professionals" shows your desktop support techies how to deploy, network, manage, support and troubleshoot XP Professional, in just two days.  This seminar is packed with demonstrations and a course guide filled with step by step procedures.  As always, I try my best to make explaining entertaining so come join us in 2003 in LA, DC or New York.  Visit for schedule specifics or for the course outline.  Seats are $895 apiece — or, if you have ten or more people from your company, consider our volume discount program featuring $600 seats.  With even more, you might want to bring me to your site, where I can tailor the class to your company's needs.  

Windows .Server 2003 Seminars in DC and LA and NY in 2003

Our very successful two-year run of our seminar on how to plan for, install, manage and troubleshoot Windows 2000 Server is over; we won't be running any more public 2000 Server seminars.

In February, we'll inaugurate a brand-new class on planning, installing, managing and troubleshooting Windows .NET Server 2003!  Okay, I'm kidding a bit.  Yes, there will be a new seminar starting in February.  But it won't be an earth-shaking change from the Windows 2000 Server class simply because despite the drastic-sounding name change, Windows .NET 2003 Server isn't that different from Windows 2000 Server.  Not that there's nothing new to learn, not by any means.  But where Windows 2000 Server was a major change from NT 4.0, .NET Server is more of a "Windows 2000 Server version 1.1."  Many of the concepts will remain unchanged from the first course — but naturally .NET Server adds some new goodies, and we'll cover them in the class.  But you'll still learn a lot... Server 2003 doesn't always change what Server can do, but it often changes how you make it do something.

Our next Server 2003 class will be in Los Angeles (downtown, at the Biltmore), then DC and NY.  I hope you'll join me for a seminar that will fill your brain with knowledge and share a few laughs in the process.  Seats are $1000 or, if you have ten or more people, look into our $650 discount program.

NOTE that every attendee gets the Mastering Windows .NET Server 2003 book (once the book is published).

Tech Section

Errata: Matt Kruse's Calendar Perl Script Has Moved

The Server book includes a step-by-step example of running a Perl script on your Web server, and that script has moved.

Matt Kruse has a site with a few neat tools, and his CalendarScript is one.  It's a nice, neat, basic online Web calendar and I suggested it as a first project in installing a Perl application on an IIS Web server.  As is so often the case, though, he's moved his site and the old URL no longer works.  I hadn't noticed this, until I started getting about two e-mails a day asking where to find it.  I didn't know, but I Googled for "Matt Kruse" and "Calendar" and the first hit was, the new home of Matt's calendar.  Unfortunately he's charging for it now.  You can download it, install and use it all you like, but he then asks that you send him $85 once your happy with it.  But if you only want to get a working Perl script that you can then use to practice installing Perl apps on your IIS server, then there's no reason why you couldn't get the thing up and running and only pay him, as he suggests, if you use it.  It is a new version of his script, so I can't vouch for whether or not it runs under IIS.

Steps To Assembling The Perfect Split-Brain DNS System For Your Active Directory

As anyone who's done or studied Active Directory knows, you simply cannot get AD to work without a proper DNS foundation.  Active Directory domains, of course, use a DNS-like naming structure and at least one (and hopefully more) DNS servers to hold the server location information.

What throws people is the fact that their Active Directory now has a DNS infrastructure; how does it relate to their existing DNS names?  For example, if your domain is named and you receive e-mail at and you've got a Web site named how does all of this relate to the workstations, member servers and domain controllers in  If you want the AD to have the same name as the names of the machines' DNS names, then doesn't this cause a collision?  Would the Active Directory use the same DNS servers as the publicly-visible Web and mail servers?

In general the answer to the last question is no, you would not use the same DNS servers for the externally-visible needs of (Web and mail) as you would for the internally-visible needs of (workstations, member servers and domain controllers).  But how to keep them separate?  By creating two completely separate set of DNS servers for — the external and the internal.  That's not a standard usage of DNS, but it works.  (Think of it as being something like keeping two sets of financial books, except there are no ethical issues here.)  This is called split-brain or split-horizon DNS.  Basically one set of DNS servers holds a zone containing the things that the outside world can see; anyone on the public Internet looking for information about would be directed to those external DNS servers.  The other set of servers exist in your intranet; they also hold zones purporting to be THE zones for and any systems asking those DNS servers for info on will get their version of the info, rather than the information on the external DNS servers.  This way, you can set up the internal DNS servers with dynamic DNS without worrying about outside systems registering on the DNS servers, and you needn't worry about outsiders querying your internal DNS servers about the domain controllers for and retrieving information about your domain that you wouldn't want the outside world to have access to.

I have written quite a bit on the subject of split-brain DNS, but no matter how much I write on this subject, I keep getting requests for more and more specific information from people who are setting up a pilot or test Active Directory.  So for this first newsletter of the year, I wanted to offer some very specific advice on building split-brain DNS systems.  I'm hoping it will either forestall questions or provide a good reference to refer people to on the subject.  I should stress that this is just a short article and there's lots more to say — I just finished the DNS chapter for the .NET Server book and it's trifle over 200 pages.  But hereís a review of the essential steps and concepts to making split-brain DNS work in a hypothetical domain.

  1. If someone else hosts your domain, leave it that way. This is a concept that many people stumble on. Assuming that you already have an externally-visible DNS server for your zone, that's great; don't do anything with it. Leave it non-dynamic. Heck, let an ISP host it. If your companyís DNS domain name is and hosts a DNS zone for, then go ahead and build your own zone on an internal DNS server. Thatís the way that split-brain is supposed to work. That way, external visitorsí queries are handled by the zone on the huge-isp.comís DNS servers, which know nothing of your internal network. Remember, as the security experts say, ďsecurityÖ through obscurity.Ē
  2. Plan and document your servers. Decide how many DNS servers you'll have on your intranet, including what their names and IP addresses will be. Keep that information documented and up to date on a text file, spreadsheet, database, whatever works for you.
  3. Install the software on the servers. As you can read in any of the Server books (or in the online help), install the DNS service on each one.
  4. Point every DNS server to itself. Configure every DNS server to point to itself as a preferred DNS server. No alternate DNS servers, just itself.  Note the italics on "every."
  5. Every server must be either primary or secondary for Make one of your DNS servers the primary DNS server for Make all of the other internal DNS servers secondary DNS servers for If you leave any internal DNS servers without a local copy of the zone, then any systems querying that server for information will cause the DNS server to search the public Internetís DNS hierarchy, and the system will end up getting an answer from the externally-hosted DNS server Ė which will almost certainly produce the wrong info. This is an important step Ė every internal DNS server must be primary or secondary for Once you build your Active Directory then you have the option to make the zone AD-integrated. When youíve done that, then any of the DNS servers that are also domain controllers for can become primaries even if they were secondaries before, as AD-integrated allows for multiple primary DNS servers on a zone. If you go AD-integrated but have DNS servers that are not domain controllers then thatís no problem, but they can only act as secondary DNS servers.
  6. Copy any external records to the internal zone.  There are probably things in the external zone Ė the one that runs Ėthat you need people inside the network to see to the internal. For example, the www and MX records. People ask me how to automate this and while Iím sure thereís a way Ė one could probably do some scripting to do this Ė there isnít an automatic method that I know of. Remember that this split-brain stuff is a trifle underhanded as far as DNS is concerned, so we canít expect too much automatic help if we decide to swim against the current.
  7. Set up two or more external forwarders. These are the servers outside of the firewall that all of your internal DNS servers will forward through. You really want these systems to be simple and easily hardened. These do not have to be NT-based systems at all and I can think of at least one fairly good argument against it: license costs. If you just want a DNS server ďappliance,Ē something that only queries the public Internetís DNS servers and holds no zones of its own, then itís kind of expensive to buy a whole Windows .NET Server 2003 license just for that. Iíve set up Linux boxes with BIND, and they offer three benefits. First, thereís the obvious cost factor. Second, you can do it with cast-off hardware. For example, I recently decommissioned a 300 MHz server that had 128 MB of RAM and had worked fine as a backup domain controller and print server. Thatís not really enough hardware for Server 2003, but itís a fine platform for RedHat, provided I donít install the GUI. Third, you can, with a little work, strip a Linux box pretty clean, basically removing everything but the BIND DNS software.  No zones, no dynamic — just a simple caching-only DNS server.
  8. Slave the internal DNS servers to the external forwarders. This way, the internal DNS servers never show their faces to the public Internet. Be sure to increase the timeout value from its default of five seconds to a more reasonable minute or so Ė experiment to find whatís best.  (Read the book for more specifics if you're unsure about "slaving" and "forwarding.")
  9. Configure every single machine inside the intranet to use only internal DNS servers. Every machine inside the intranet must point to one or more of the internal DNS servers. Configure every workstation and server to point to one of your internal DNS servers as its preferred DNS server and another as the alternate DNS server. Never point a machine to an external DNS server, even as an alternate DNS server. If you do, then any queries to the external DNS server for information would end up at the DNS server at, and thatís not what you want to see happen.  Again, note the italics — they must all point to an internal DNS server that holds a zone.

Follow these steps and youíll have a perfectly-running DNS system.  (One more note, however:  if you're going to run Active Directory-integrated zones then read issue #31 as well, about "island DNS.")


I hope you'll join me for a seminar but if you can't attend a class then please consider attending another show:

TechMentor New Orleans April 8-12

A terrific show, headed for a great location.  Great sessions and even better speakers make this real deal.  Industry experts like Bill Boswell, Roberta Bragg, Brian Komar and Jeremy Moskowitz (to name but a few) make this a reliably information-packed event.  Even better, it's located this April in the Wonderful Food Capital of America, New Orleans.  Or, if you're just coming to work, work, work, then you'll like the fact that you can take Microsoft certification tests at half price.  Info at

I will be keynoting with my new talk "The .NET Report Card."  .NET will be on the eve of shipping so it'll be very timely.  If you can make it then I surely hope to see you there!

Windows Decisions Chicago May 14-16

Once again TechTarget delivers a Windows 2000/XP/.NET conference with excellent content... free.  Last year's show featured a whole bunch of great speakers on a wide variety of topics and, of course, the price is right, if you qualify.  Visit to apply and we'll see you in Chicago!

Windows Magazine Live! May 18-21 in Phoenix

Psst... don't tell anybody, but I've got some inside information that I wanted you guys to be the first to know.  The magazine that I write for, Windows and .NET Magazine, is about to announce its next conference, Windows Magazine Live! in Phoenix.  More details when I get them, but for now I can say that I'll be doing three talks, including two new ones:  "How To Troubleshoot Any Network Problem" and "The .NET Report Card," as well as my "Tuning XP, 2000 and .NET Server" talk.  Watch for more info.  The Phoenix site is always great, don't miss it.

Bring Mark to your site to teach

I'm keeping busy doing Windows .NET Server seminars and writing, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into 2000 and/or .NET techies.  To join the large educational, pharmaceutical, agricultural, aerospace, utility, banking, government, transportation, and other organizations that I've assisted, either take a peek at the course outline at, mail our assistant at, or call her at (757) 426-1431 (only between 9-5 Eastern time, weekdays, please).

Until Next Month...

Have a quiet and safe month.     

Please share this newsletter; I'd like very much to expand this newsletter into a useful source of NT/2000/.NET Server/XP information.  Please forward it to any associates who might find it helpful, and accept my thanks.  We are now at over 24,000 subscribers and I hope to use this to get information to every single Mastering XP, NT and 2000 Server reader. Thanks for letting me visit with you, and take care — the economy's coming back soon, I'm sure of it!  Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews.  As always, I'm at and please join us at the Forum with technical questions at

To subscribe, visit To change e-mail, format, etc., link to  To unsubscribe, link to Visit the Archives at Please do NOT reply to this mail; for comments, please link to

All contents copyright 2003 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.