intranet hostname lookup only
Barry Margolin
barmar at alum.mit.edu
Sat May 6 01:36:12 UTC 2006
In article <e3gi9v$14fp$1 at sf1.isc.org>,
Kevin Darcy <kcd at daimlerchrysler.com> wrote:
> Barry Margolin wrote:
>
> >In article <e3dvi9$2iri$1 at sf1.isc.org>,
> > Kevin Darcy <kcd at daimlerchrysler.com> wrote:
> >
> >
> >
> >>Um, OK, and neither of those constitute "setup [of] bind9" as the
> >>original poster requested.
> >>
> >>
> >
> >So? We're not allowed to infer the higher-level goal, and must answer
> >based on his misunderstanding of client-side and server-side behavior?
> >
> Infer whatever you want. But, once inferred, unless one believes that
> fostering shortname resolution is a good idea, one might nevertheless
> prefer to hold back and answer the question exactly as asked. After all,
> it's an even "higher-level goal" to nudge novice administrators towards
> practices that will serve their infrastructure and their user community
> well in the long term, isn't it?
>
> Maybe you've never actually had to deal with a user community that is
> addicted to shortnames and refuses to change their ways, demanding
> instead that you tie your DNS infrastructure into pretzels to
> accommodate their practices. So maybe you don't see the "higher-level
> goal" here. But, for those of us who have to deal with these
> consequences almost daily, telling someone how to facilitate shortname
> resolution, where they've never had it before, is like giving a drink to
> an alcoholic, giving a loaded shotgun to a suicide risk, or whatever
> your favorite metaphor happens to be. As patronizing as it sounds,
> sometimes one has to be cruel to be kind. Sometimes a useless answer is
> the *best* answer, in the long run.
That's a whole different issue. Telling them *not* to do it at all is
independent of whether you give a client- or server-based answer.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
More information about the bind-users
mailing list