Case For Microsoft DNS v. BIND 9 - Or Best Practices For Coexisting

steve at steve at
Sun Feb 8 15:21:18 UTC 2009

Microsoft DNS can work well, HOWEVER....   much time needs to be spent 
understanding its operations.

This is a VERY long winded post, so I hope no one gets upset, I realize this 
is not the MS DNS group LOL

I am going to assume, that you are running an Active Directory Domain that 
includes these servers, as this IS the year 2009  =P

MS DNS Servers on an Active Directory Domain, are "Integrated" into the 
directory, they can and usually do operate in DDNS Mode. This can "Allow" a 
machine to register its records in DNS.
A machine that is a Domain member, is given the ability to register its 
records based on the "SID" it aquires when joining the domain, and that is 
very important, because the machine must maintain that SID to update those 
records on a day to day basis, the default TTL for this is 22 hours on an MS 
So.. what I described above is the bare bones basics of it, sounds great 
huh?  not even close lol, read on

First off, the TTL I spoke of (22 hours), is a "Client" configuration, the 
server knows nothing about this timing.
The server, relies on something called "Scavenging and Ageing" to remove 
"Stale" and "Orphaned" records. The defaults for this, are 7 Days MIN and 14 
Days MAX, Scavening/Aging can be configured seperatley for each domain an MS 
server is managing. This is configurable on the front end only, meaning, you 
can reduce the 7 days to say one day, but the 14 days is a hard set limit.
So what does that mean you say?  well, let me detail that.
A machine registers itself in MS DDNS, then it goes offline for say 9 days, 
well, at day 7, the server SHOULD remove the record after attempting to 
verify nothing is on that IP. This is important now, the Record INDEX in the 
DDNS Database, is the machine NAME, and NOT the IP, still sounds ok?  read 
more lol.

Now things get sticky....  all of the above, ASSUMES, the administrator has 
properly configured Scavenging and actually turned it on!  you can not 
believe how many do NOT!

Now follow this,
Scenario one:
Machine A - gets a DHCP lease from DHCP server on Monday, this is a VERY 
heavily loaded DHCP Scope, only a few spare addresses, it registers IP with DNS, then the machine goes home for the day, and will not 
return until next monday
Machine B - gets a DHCP lease on Tuesday, because the scope is out of 
addresses, it give out the address that Machine A had yesterday , 
andf Machine B now registers itself with DDNS.

NOW your problems are starting, as I said, the INDEX is the machine name in 
MS DDNS, so now, you have 2 NAME records in DDNS, that both have the same 

Scenario two:
A machine is renamed for who knows what reason, and of course, has to aquire 
a new Domain SID, when it is rebooted with the new name, it requests and 
gets the same IP from DHCP based on MAC addy, then registers itself in MS 
DDNS, again, we now have 2 NAME records with the same IP

Scenario three:
A machine has an OS failure, and the OS is reinstalled, the machine has the 
SAME NAME, but now has a new SID. The old DDNS NAME entry, can only be 
updated using the old SID, hmm so now a machine can not even update its own 
records!!  another orphaned record!  remember above when I said the SID is 

oh boy, this is not right! well first off, it CAN and DOES happen, all the 
time. Despite having Scavenging enabled like a good administrator, you can 
see how the problems are just begining, all caused by the DHCP scope not 
having enough free DNS records?  or some Deskside technician doing his job 
and reinstalling the OS for a customer? well, not completely, it is sort of 
the nature of DDNS in the MS world.

My scenarios above, are very real, I got up early this Sunday morning to do 
some work on a client, that due to Misconfiguration/lack of managment, has 
over 5,000 duplicate/orphan records in their DDNS, spread across and 
replicated across 40 some odd Inregrated Active Directory DDNS servers, what 
a headache!

If you must use MS DDNS in a large environment, you must also use MS DHCP, 
and configure DDNS updates to come from the DHCP server and NOT from the 
Client machine (notice my scenarios are all stemming from the MACHINE doing 
the updates to DDNS), this is the only way to prevent what I described 
This MS DHCP/DDNS configuration is very critical and not for the entry level 

MS DDNS/DHCP can work very very well, but...  take what I said above, and go 
forth and read!  lol.
Pay close attention, to the fact that Microsoft does DNS "Their" way to 
support what their systems need, and in many cases, they are not following 
RFC specs.

One example in closing for ya, go try and get an RFC complient Bind server 
to respond to a request for name resoloution on a host that has an _ 
(underscore) in the name, MS allows this, and a zone transfer of this kinda 
stuff between and MS Server and a Bind server, can give you MUCH grief!

Good luck!!

<wiskbroom at> wrote in message 
news:BAY133-W543F0F7A46C3153066CF86B4C10 at phx.gbl...
> Hello;
> My site is presently using a product derived from BIND-8 for internal DNS 
> only.
> For years our Windows team has been arguing that they want to be 
> non-dependent on the non-MS DNS servers; which they say causes them much 
> grief on firmwide shutdown/bootups.
> Well, their concerns have fallen on ears of those who can make that 
> decision and it now appears as though we must either come up with good 
> reasons why we should retain BIND, or a BIND derived product, or simply a 
> plan to allow MSDNS and BIND to coexist at all.
> Can anyone provide me, or point me at, any good docs on this subject, I am 
> certain that their a tons of stuff out there, I need simple, to the point 
> type of stuff.
> Also, can anyone think of any good reason why our internal, non-public 
> accessible network, should not just be allowed to run either a mixed 
> BIND/MS-DNs setup?  The slave/cache/whatever-but not master, would have to 
> be BIND.
> The case the windows team made was ease of adding entries, you simply add 
> into the MMC, or even easier, when you join a host into a domain, it adds 
> itself.
> Thanks all,
> .vp
> _______________________________________________
> bind-users mailing list
> bind-users at

More information about the bind-users mailing list