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 System. 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 1.2.3.4 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 1.2.3.4 , 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 IP!! 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 important? 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! facts: 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 above. This MS DHCP/DDNS configuration is very critical and not for the entry level Admin. 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!! <wiskbr...@hotmail.com> wrote in message news:bay133-w543f0f7a46c3153066cf86b4...@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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users