BIND Based Appliances.

[Jeff A. Earickson]

On Sat, 4 Oct 2008, Larry Fahnoe wrote:
> The fundamental reasons that I chose to use Infoblox in this
> application were the need for a bullet proof GUI with logging and fine
> grained access control for less experienced admins to use when making
> DNS and DHCP changes, and the integrated database underneath BOTH bind
> and dhcpd.  The need for the bullet proof GUI and appliance style
> deployment seems to be the original question that sparked this
> conversation, but to me the fact that Infoblox has implemented these
> features on top of an integrated, distributed database with a
> full-featured API to talk to it is the key differentiator between

How much do you use the API?   Someone else noted that their perl API 
was not so hot.

> Infoblox and other bind integrators.  This in my opinion represents an
> architectural enhancement to bind and dhcpd.  A significant side
> benefit of the integrated database is the IP network and address
> management that comes along for the ride.

In the course of evaluating a demo Infoblox box, I've also wondered
how difficult it would be to get one's data *out* of their appliance
if one wished to change to another product.  Integrated database may
translate to "hidden data" on an appliance.

>
> For all the good that I see in the Infoblox way of doing things, they
> are far from perfect.  For those who see that it is an ISC bind/dhcpd
> based appliance and therefore expect to simply import the config and
> data files without a hitch, well, you're in for a bit of a hurdle.

Yup, I found that out right away.  It totally choked on my DHCP conf
file.  Their data import wizard did point out a few mistakes and typos
in our DNS setup that I had to fix (thank you), but it also had major
problems importing my data and could not do it.  An infoblox engineer
called up to "help out", ie take my DNS and DHCP files and massage them
so that the wizard can import them.  I will be interested to see what
changes get made to them.

I did notice that their wizard did not recognize the LOC DNS directive,
which we use to denote latitude, longitude, altitude of our ntp server.

The engineer said that they do not integrate their import wizard with
their gui manager because it changes so rapidly.  Hmmm.  Still in 
development?

> Infoblox has chosen to bolt the two protocol engines on top of their
> own database which means that they don't use the same config/data
> files as the original protocol engines.  I was (and still am) a bit
> frustrated by this, but it makes sense to me: their view of the world
> is different, therefore the way I need to feed them data is also
> different.  The current Infoblox java import tool is a good first
> step, but doesn't always get it right.  Once I run data through the
> import tool, I sometimes have to make additional modifications using
> the API or the GUI to get things set the way I want them.  This is a
> hassle, and I know that Infoblox continues to be open to customers who
> have suggestions for enhancements.  However, once the data is
> imported, it has been a rock solid and easy to manage environment.
>
> --Larry

I'm going to take a look at the Men and Mice solution, which (I hope)
will just overlay my existing ISC DNS and DHCP setup without hassle.
I want something to manage the data I've got, without taking away any
of the underlying functionality or locking me into something.

Jeff Earickson
Colby College