next gen h2n

[Kevin Darcy]

Barry Margolin wrote:

> In article <38CD521F.8312D86B at daimlerchrysler.com>,
> Kevin Darcy  <kcd at daimlerchrysler.com> wrote:
> >Lars Hecking wrote:
> >
> >> > > I am looking for a tool that will do sth. like what h2n does but comply
> >> > > better with bind 8 and nicer in multiple domain handling.
> >> > > Could anyone send me a pointer?
> >> > > I am trying to run this tool mainly with Solaris 2.6+ environment.
> >> >
> >> > I think you're asking too much from a utility that appears to have been
> >> > primarily created as a hosts-to-DNS migration tool. Consider taking the
> >> > plunge and making DNS your "master" name database. There are numerous
> >> > tools out there that can help maintain zonefiles. If you have some broken
> >> > software in your environment which (temporarily) *requires* a hosts file,
> >> > it should be quite easy to write an "n2h" script which would periodically
> >> > generate one from the zonefiles.
> >>
> >>  There's nothing intrinsically "broken" with hosts files.
> >
> >You apparently misread what I wrote. I characterized as "broken" software
> >which *requires* a hosts file, i.e. goes directly to the hosts file to do
> >lookups instead of using the default resolver configuration of the machine.
> >I never said hosts files were "broken" _per_se_, although their practicality
> >is IMO quite limited (see below).
>
> I don't think people use h2n because they're using systems that require
> hosts files to be distributed.  They use it because hosts files are a
> simpler file format.  If you edit zone files directly there are more
> opportunities to screw up (e.g. messing up the serial number, not keeping
> the forward and reverse zones in sync, messing up indentation).  Editing a
> hosts file and then using h2n is a simple system that many admins prefer.

I agree that hand-editing zonefiles sucks. That's why I recommended using a tool
to manage the zonefiles. Having said that, though, I'll note that having to run
h2n all the time to generate the zonefiles is also an inconvenience, and although
much more automatable, still subject to error/failure.

As for the general question of "when do I wean the organization off the hosts
file?", the original poster was talking about trying to get h2n to handle multiple
domains better. As a rough rule of thumb, I think organizations which are large
enough to even *want* to have multiple internal domains (or to know that it is
possible :-) probably also could benefit from some of the other advantages of
centralizing on DNS, e.g. faster propagation of changes (don't have to wait for
the h2n job to run), round-robin records, flexible MX-based routing, etc.. That's
why I suggested that they consider taking the plunge and centralizing their
name-resolution infrastructure on DNS. While this isn't a good fit for
*all* environments of course, the multiple-domain requirement was an indicator to
me that perhaps it was a good fit for the poster's organization.


- Kevin