phoning home

[Paul Vixie]

> From: Lars-Johan Liman <liman at autonomica.se>
> Date: Tue, 14 Jun 2011 10:05:25 +0200
> 
> I think the right path to achive universally updated code, is to talk
> to the OS vendors, and make sure they have easy and automatic ways to
> update their operating systems of which BIND often is a part; and to
> ensure that _they_ are following the BIND development as close as
> possible. Encourage them to create automatic OS updating systems along
> the lines of Apple's Software Update, or Microsofts Windows Update
> that run periodically.

while i'm not sure that OS vendors generally want to hear this kind of
advice from their DNS freeware supplier, we can certainly try.

> The minuscule fraction of nameds out there that are maintained locally,
> are maintained by people who know their trade, and who know to upgrade
> when they believe it's necessary.

the facts as i know them regarding "miniscule" and "know their trade" are
very different than what i've quoted just above.  it's worth remembering
that when commercial software goes EOL then the automatic updates stop,
and that ISC's target audience is "the public" not just "our customers",
and that "the public" who is endangered by old unupgraded vulnerable BIND
installations is much larger than the set of server operators themselves.

> An improved version of the vulnerability matrix would be a commendable
> effort, and possibly an external script that automates the fetch-
> compile- install cycle, which automagically looks up and retrieves the
> most recent version, and which can take _my_ local ./configure options
> as input (possibly also adding my local patches), and just make it
> work. Coming to think of it, I should probably write one for myself.
> ;-)

BIND is open source and your code contributions would be welcomed.  i've
been very happy with the way DCC (an open source anti-spam system) does
its cron-based automatic updates, if you're looking for an example here.

> But that's all web stuff. BIND is already showing signs of "Christmas
> tree" overloading as it is. (What happened to the Unix approach of small
> utilities that each do one thing well ... ? ;-)

we call our small-modules name server "BIND 10" and i encourage anyone
who doesn't know about it to look at http://bind10.isc.org/ and consider
(a) running it if the early release has the features you need, (b)
testing it no matter what, (c) joining the mailing list and giving us
your feedback from running/testing, (d) consider sponsoring this activity
with money or people or both, (e) add features and fix bugs and send us
patches.

> But if you decide to go for your idea, I _strongly_ advocade a version
> with the following capabilities:
> 
> 1) Can be left out of the code by ./configure --without-et-phone-home.
> 
> 2) Is "off" by default.
> 
> 3) Is configured (as proposed) with specific query to be posed to
>    specific host.
> 
> 4) Can be checked (as proposed) by specific rndc command (but not by
>    default! I very much don't want "rndc status" to generate network
>    traffic. (It will typically hang if the remote server is
>    unreachable.)
> 
> As can be deduced from my comments, I'm strongly opposed to software
> that performs transactions behind the curtain by default. Automagic is
> fine - but only by clear instruction (as in
> 
> options {
> 	fully-automagic-christmas-tree-mode yes;
> };

to be clear, is this approach something you want for yourself, or is it
something you want for everybody else?  because if your concern is that
you yourself could be inconvenienced, your (1) would seem to trump your
(2), (3), and (4).  whereas if you want it for everybody else... "why?"

> ;-).

as always.