Mark Minasi's Windows Networking Newsletter
Issue #30 January 2003
- 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
- Bring a Seminar to Your Site
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 www.minasi.com/pubsems.htm
for schedule specifics or www.minasi.com/xpsupport.htm
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).
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 http://www.mattkruse.com/scripts/calendar/,
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
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 bigfirm.biz and you receive e-mail at
firstname.lastname@example.org and you've got a Web site named www.bigfirm.biz... how does
all of this relate to the workstations, member servers and domain controllers in
bigfirm.biz? 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 bigfirm.biz (Web and mail) as
you would for the internally-visible needs of bigfirm.biz (workstations, member
servers and domain controllers). But how to keep them separate? By
creating two completely separate set of DNS servers for bigfirm.biz 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 bigfirm.biz would be directed to those
external DNS servers. The other set of bigfirm.biz servers exist in your
intranet; they also hold zones purporting to be THE zones for bigfirm.biz and
any systems asking those DNS servers for info on bigfirm.biz will get their
version of the bigfirm.biz info, rather than the information on the external
bigfirm.biz 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 bigfirm.biz 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 bigfirm.biz domain.
- 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 bigfirm.biz and huge-isp.com hosts a DNS zone for
bigfirm.biz, then go ahead and build your own bigfirm.biz 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.Ē
- 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.
- 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.
- 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."
- Every server must be either primary or secondary for bigfirm.biz. Make
one of your DNS servers the primary DNS server for bigfirm.biz. Make all of the
other internal DNS servers secondary DNS servers for bigfirm.biz. If you leave
any internal DNS servers without a local copy of the bigfirm.biz zone, then any
systems querying that server for bigfirm.biz 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 bigfirm.biz. 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 bigfirm.biz 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
- Copy any external records to the internal zone. There are probably things in the external bigfirm.biz zone Ė the one
that huge-isp.com 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
- 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.
- 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
- 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 bigfirm.biz information would end up at the DNS server at huge-isp.com,
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 bigfirm.biz
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 www.techmentorevents.com/neworleans.
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 http://windowsdecisions.techtarget.com/
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 www.winconnections.com
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 www.minasi.com/w2koutln.htm,
mail our assistant at Assistant@Minasi.com,
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 http://www.minasi.com/gethelp and
please join us at the Forum with technical questions at www.minasi.com/forum.
To subscribe, visit http://www.minasi.com/nwsreg.asp.
To change e-mail, format, etc., link to http://www.minasi.com/edit-newsletter-record.htm.
To unsubscribe, link to http://www.minasi.com/unsubs.htm.
Visit the Archives at http://www.minasi.com/archive.htm.
Please do NOT reply to this mail; for comments, please link to http://www.minasi.com/gethelp.
All contents copyright 2003 Mark Minasi. You are encouraged to quote this
material, SO LONG as you include this entire document; thanks.