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

[wiskbroom at hotmail.com]

Thanks for the reply.  My DMZ, or external lookups, are all performed via one of six BIND-9 servers.

The product that we use is based on BIND-8, though they've recently come out with a BIND-9 version.

If I "split" my lookups and have internal lookups pointed at the MS DNS servers, and non-authoritative lookups to my external servers (running BIND-9), then shouldn't this address the issues you spoke of?

How are you able to allow for the windoze boxes to automatically add entries? In other words, a strong case they made is that they must presently maintain two databases, AD *and* DNS.  With MS DNS, they say, this is not the case whereby when you add an entry or join a host, that entry is automatically added in DNS.  

In there a way to do this in BIND?

Thanks again,

.vp


----------------------------------------
> Subject: RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices For Coexisting
> Date: Fri, 6 Feb 2009 09:49:42 -0500
> From: jlightner at water.com
> To: wiskbroom at hotmail.com; bind-users at lists.isc.org
>
> I don't see why it is either/or.
>
> Here we have Windoze DNS servers for internal lookups and Linux/BIND 9
> DNS servers for external lookups. The internal servers refer all
> queries they aren't authoritative for to the external ones which in turn
> refer all queries for domains we don't own to the root servers.
>
> The only "gotcha" is that we have some domains that we want to present
> different IPs for internally (10.x.x.x) or externally (12.x.x.x). On
> the Windoze DNS servers they have our primary domain with those internal
> addresses and on the BIND DNS servers we have those external addresses.
>
>
> Of course you could do it all with just BIND servers running views but
> this is the way I inherited the BIND servers here.
>
> We don't seem to have the headaches your Windoze team is moaning about.
> Hopefully you are running redundant (master/slave) BIND servers?
>
> Also I'd suggest upgrading to BIND 9 once you've got all the rest of
> this quieted down.
>
> -----Original Message-----
> From: bind-users-bounces at lists.isc.org
> [mailto:bind-users-bounces at lists.isc.org] On Behalf Of
> wiskbroom at hotmail.com
> Sent: Friday, February 06, 2009 9:25 AM
> To: bind-users at lists.isc.org
> Subject: Case For Microsoft DNS v. BIND 9 - Or Best Practices For
> Coexisting
>
>
>
> 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 lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
> Please consider our environment before printing this e-mail or attachments.
> ----------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
> ----------------------------------