DNS Cache Snooping?

Jeff Lightner jlightner at water.com
Thu Jun 26 16:02:29 UTC 2008


Well there's support and support.

You "support" Fedora by hosting/publishing/updating but won't accept
calls from users about it.

You "support" RHEL by having users pay for "subscriptions" and "customer
support calls".

For most large commercial customers I doubt Fedora "support" would be
considered an option.  They pay for the subscriptions and customer
support specifically because they want recourse to the vendor.  Those
that don't want that may use something like Ubuntu or Slackware and do
their own updates.

You're correct that to a certain extent customers don't want to do
"automatic" updates.   That doesn't mean that on occasion customers
don't want to get updates to fit specific needs.  However the same
customers that want that RHEL type of support are not likely to go get
things that aren't vetted by RedHat or by a 3rd party to whom they also
pay support (e.g. Oracle) for specific products.

Supportability matrixes have been a big issue everywhere I've worked
(including Fortune 500 and Fortune 100 companies).   More than once I've
seen a project stopped dead in its track simply because one of the
vendors said "We won't say it doesn't work but we don't support that
configuration."

Having RedHat certify something like BIND 9.4 and offer a channel to get
the vetted (i.e. officially supported) build especially for packages
like bind-chroot allows people like me to sell the idea of upgrading to
management more easily.   

-----Original Message-----
From: Adam Tkac [mailto:atkac at redhat.com] 
Sent: Thursday, June 26, 2008 11:45 AM
To: Paul Vixie
Cc: Jeff Lightner; bind-users at isc.org
Subject: Re: DNS Cache Snooping?

On Thu, Jun 26, 2008 at 02:30:27PM +0000, Paul Vixie wrote:
> > I for one would be really upset if RHEL overwrote supposedly default
> > configurations as I noted in my Sun patch to st.conf email
yesterday.
> 
> can you offer some guideance here, then, for ISC and for RH?  the
default
> ACL for allow-query was *wrong* and had to be fixed for the good of
the
> internet.  we did this with a lot of soul searching and some fanfare.
we
> put it into a new major release, since we knew it was an
incompatibility.
> and, since it was a new major release, we also put other things into
it,
> including some things that RHEL users might benefit from.

You are absolutely right. Let me explain why we don't update to 9.4

Vast majority of our customers are not interested in newer version
of software which is faster, it supports new features etc. They simply
want install system, run it 10 years without reboot and they don't
want perform any updates because if something works as they want update
doesn't help, it might only break something.

Different situation is on Fedora field (statement written above is
about RHEL). This system is for people who want go with latest news
and improvements so you can find newest versions of software there.

> how should RH and ISC cause these new features to reach these
customers?

This is big problem. As I wrote above big number of customers are not
interested. It would be nice to get same information from other big
Linux distributors (I can't remember when I saw person with @suse or
@debian here) but I'm affraid they won't tell here something
different.

Make sure we don't want stop improvement. We support (= RH) two OSs
whose have pretty different goals. If you think RHEL contains too old
software you can use Fedora.

Adam

-- 
Adam Tkac, Red Hat, Inc.
----------------------------------
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.
----------------------------------


More information about the bind-users mailing list