Third Party DNS in an AD environemnt

  • Thread starter Thread starter richard6121
  • Start date Start date
R

richard6121

Specifically Infoblox DNSone, which appears to be a "sealed box" BIND
implementation.

Anyone running it? Anyone regretting it?

RM
 
Specifically Infoblox DNSone, which appears to be a "sealed box" BIND
implementation.
Anyone running it? Anyone regretting it?
Click to expand...

I run a BIND server (but not that one) but not to support my
AD or clients.

Depends on 1) does it work and 2) what's it's purpose?

BIND servers can certainly be secondaries to Win2000+ DNS
servers (check version requirements but we are pretty much past
that problem except on MCSE exams <grin>).

BIND servers can certainly be forwarders for internal DNS servers.
(That's what I use my BIND server for.)

A BIND server can even be your Primary DNS to support AD but it's
not worth the trouble or loss of functionality.
 
I do indeed own a dozen DNSone appliances (six high availability pairs
of which one pair is sitting on a shelf for future use, one pair is
used for development, one pair is for pre-production testing, and the
other three pairs are production boxes) and have never regretted the
decision. I am using them exclusively for DNS and DHCP services
within a 5,000 node AD environment and am looking at rolling them to
the rest of a 20,000 node network. I'm not sure what the comment
about "not worth the trouble or loss of functionality" means but there
is nothing that I have not been able to do with these units.

Bob
 
Active directory integration (and all of it's benefits to
replication, multi-mastered, replication, and security of
both replication and DYNAMIC Registration) is the
most important.
 
At the risk of sounding like a troll (which I hope I do not as I do
believe that MS DNS/DHCP does have its place) I would argue the
opposite. In a large enterprise (and this is an important
distinction) there are a number of disadvantages to AD integrated DNS,
not the least of which is the dependence upon AD replication for
propogation of DNS tables. When you are looking at inter-site
replication, the time frames involved for the replication of DNS
changes become troublesome. Additionally, as you look at the delays
involved with AD replication, you also add additional risk by creating
a multi-master environment. If strict change control is not
exercised, it would relatively easy to envision quite a few situations
where conflicting changes are made. As another point, you also lose
the functionality of serial numbers. In a BIND-style environment you
can track changes across the network by the serial number of the zone
files. In AD intregrated environments, this is no longer a tool that
is of any use to you since the serial number is only locally
significant.

A few final points:

AD is dependent upon DNS for proper operation, not the other way
around. I don't think I want to put my DNS data in a directory
structure that is dependent on the validity of that data. Were DNS
used by nothing by AD, it probably wouldn't be an issue but you are
putting a lot of faith in the health of your AD environment to keep
Unix, Web, and other systems running.

Microsoft has yet to provide any real type of access control for the
administration of DNS and DHCP. Without being able to control who
makes changes with appropriate auditing of those changes, there can be
no accountability unless you place the administration of this
environment in the hands of only two or three people. This might work
for smaller environments but for large enterprises this poses a
significant issue.

AD integrated DNS is fine as long as you are aware that every DNS
server must also be a domain controller. Personally, and this is only
my opinion, this is one of the greatest drawbacks.

I am curious as to why multi-master environment is considered
valuable. In my mind, I fail to see the relevance that this has on
anything. The only real benefit that I see to AD-integrated zones is
the security of the zone transfers and dynamic updates, but there are
ways to address this outside of Microsoft solutions.

Bob
 
Bob Adamson said:
At the risk of sounding like a troll (which I hope I do not as I do
believe that MS DNS/DHCP does have its place) I would argue the
opposite. In a large enterprise (and this is an important
distinction) there are a number of disadvantages to AD integrated DNS,
not the least of which is the dependence upon AD replication for
propogation of DNS tables.
Click to expand...

Then you are always free to use a Secondary, but this sounds more
like a poorly setup replication schedule than a problem with AD or
DNS.

One of the key benefits to AD integrated DNS is LOCAL dynamic
registration when you have such distributed sites.
a multi-master environment. If strict change control is not
exercised, it would relatively easy to envision quite a few situations
where conflicting changes are made. As another point, you also lose
Click to expand...

This is a virtually insignificant problem unless you are dealing
with (nearly willfully) incompetent admins -- and too many of
them at that.
I am curious as to why multi-master environment is considered
Click to expand...

Imagine a world wide network using a single zone (or multiple but
let's just consider one of them at a time.)

With single master, all dynamic (and static too) registrations must
be sent to the central headquarters and then propagated back out
before reaching the local DNS servers.

With multi-mastered registration the local registrations are
immediately available where they are most likely needed, and
then propagate FROM that location to other sites where they
MIGHT be needed.

I have heard of a few companies adopting AD JUST to acquire
this capability.

A properly setup AD has no trouble replicating, multi-mastered
and all.
 
In
Herb Martin said:
Then you are always free to use a Secondary, but this sounds more
like a poorly setup replication schedule than a problem with AD or
DNS.

One of the key benefits to AD integrated DNS is LOCAL dynamic
registration when you have such distributed sites.


This is a virtually insignificant problem unless you are dealing
with (nearly willfully) incompetent admins -- and too many of
them at that.


Imagine a world wide network using a single zone (or multiple but
let's just consider one of them at a time.)

With single master, all dynamic (and static too) registrations must
be sent to the central headquarters and then propagated back out
before reaching the local DNS servers.

With multi-mastered registration the local registrations are
immediately available where they are most likely needed, and
then propagate FROM that location to other sites where they
MIGHT be needed.

I have heard of a few companies adopting AD JUST to acquire
this capability.

A properly setup AD has no trouble replicating, multi-mastered
and all.
Click to expand...


I can see Bob's point about replication lag with AD Integrated zones. One of
my clients has 6 locations and I setup Sites for him because he mainly
wanted printer location tracking feature enabled (which requires, among
other things, Sites created). But he wasn't too happy with the latency,
even after I chopped it down to 15 minutes. I told him either live with it
or I can choose one of the machines to be a Primary and secondary everything
else... he chose to deal with it....

Plus there's SOA version number differences between zones as well. Can get
confusing, but I just ignore it, as long as it's not critical or creating
any problems.


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS-IS" with no warranties and confers no
rights.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
BA> As another point, you also lose the functionality of
BA> serial numbers.

That's a red herring. One doesn't lose any functionality because there was
never any functionality there to lose in the first place. The meanings of
most of the fields in "SOA" resource records are dependent from the exact DNS
database replication mechanism in use. The fields are employed differently,
and sometimes not at all, by different replication mechanisms. There's no
justification for assuming that serial numbers mean _anything_ when one is
using Active Directory DNS database replication, because Active Directory
replication doesn't use the serial numbers. There's no justification for
assuming that they mean the same as they do for "zone transfer" database
replication, or (again) even anything at all, with other database replication
mechanisms, either.
 
Back
Top