isc - a good business

Jimmy Hess mysidia at gmail.com
Tue May 29 00:05:26 UTC 2012


On 5/28/12, Paul Vixie <vixie at isc.org> wrote:
[snip]
> if i thought there was even one isp anywhere who wanted to use nxdomain
> remapping but didn't because bind didn't have that feature, i'd be ready to
> argue the point. but all isc did by not supporting this feature was force

Maybe they would think twice, if they used BIND,  and BIND not only
excluded the feature,
or if activating the feature required loading an "Unsupported"
plugin, external module,  patch, that would periodically generate
syslog warnings about dangerous NXDOMAIN mapping settings, but
documentation also contained a FAQ explaining why the feature "global
wildcards" or "nxdomain remapping" are not officially supported, and
explained some of the serious problems the concept of NXDOMAIN
remapping causes..

There is no point in "denying a feature" that is in demand,  because
that simply means there will then be demand to fork the product, and
provide the users the features they want, that the developer is
denying them for "political reasons".

Also, the cats out of the bag once the feature is provided --
introducing a breaking change that would completely remove an
in-demand existing feature from the userbase would be ill-advised.


> some isp's to not use bind, and: isc is not in the "sour grapes" business.

Other implementations mimic BIND;  the BIND implementation is kind of a leader.
By including the feature,  other implementations are influenced to
include the feature.
It would be best for the BIND developers'  position on the usage of
the feature to be clear.

"Don't turn this on just because it's there... here's why..  oh, by
the way, you need to do this, this, and this other thing, before you
can turn it on"

> meanwhile isc continues to push for ubiquitous dnssec, through to the stub,
> to take this issue off the table for all people and all time. (that's "the
> real fix" for nxdomain remapping.)

It's a good fix,  but the code bits to implement it on major OSes
don't exist today,
and if they are fully implemented by all vendors,  it's still
approximately  3 years before
they make it into a new OS'  release cycle, and then another 10 years before
the functionality gets deployed and enabled by default,  and older
systems get retired.

Discouraging the breakage is a good interim fix,  when ubiqutous
DNSSEC to the stub
is optimistically 15 years out.

> --
> Paul Vixie
--
-JH




More information about the NANOG mailing list