phoning home

[Lars-Johan Liman]

Paul Vixie wrote:
>> i think bind needs something like this, but maybe it's an information
>> leak?

eivind at aminor.no:
> I'm not worried about it being information leak really, as long as it just
> puts it into the regular logs anyway. But I'm not sure how much good it
> really would do. Any sysadmin that cares enough to check her logs would
> most likely also be able to keep on top of BIND version numbers. The ones
> that really could do with being told "Oi, your BIND is too old! Sort it,
> git!" probably won't check their logs anyway and won't notice anything.
> Unless BIND starts replacing answers to all queries with a CNAME to
> bind-too-old.isc.org :-)

> Also - how would such a check work? For example, some vendors like to
> patch and package their modified versions of software - how would BIND
> 9.7.3-2.el6_1.P1.1:32.x86_64 know whether an upgrade to BIND 9.8.0-P2 is
> needed or not, if the major security fixes has been backported to the
> vendor provided version of BIND? I'll admit that's really more an issue
> for the vendor to sort out though, but still.

> So, in short: I'm not opposed to a version check like this, it won't do me
> any harm - I'm just not sure it would actually be useful.

I think most of you are barking up the wrong tree here. Eivind is
pointing you in the right direction.

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.

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.

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.
;-)

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 ... ? ;-)

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;
};

;-).

				Cheers,
				  /Liman
#----------------------------------------------------------------------
# Lars-Johan Liman, M.Sc.               !  E-mail: liman at netnod.se
# Senior Systems Specialist             !  Tel: +46 8 - 562 860 12
# Netnod Internet Exchange, Stockholm   !  http://www.netnod.se/
#----------------------------------------------------------------------