in addition to many public comments (cc'd to nanog or just sent there), i received a number of private replies. here's a representative sample:
problem is if the default is off you will probably not catch the clueless folk that you want to target, better would be default on and the clueful world can choose to ignore it...
btw, my impression of the vulns in earlier binds was that everyone who mattered had upgraded and perhaps only corporates were left on old version, of course you prolly know more than me on that.
pv: (the roots and most tld servers always update, and the vendors always have patches, but by no means everyone who matters always upgrades.)
I'd certainly consider using a service offered by ISC on this basis for any servers for which I have any responsibility.
pv: (four other people said the same; thanks for your enthusiasm! one added:)
... However, since the problem applies to multiple software packages, perhaps it is worth the effort developing a unified standard for this kind of purpose (RFC, something similar) and passing it on to package maintainers, distribution maintainers, etc? Creating a universal "versioning system" would solve a lot of problems with keeping software updated.
i think that's true, but beyond the scope of ISC's resources, and also likely to take a very long time to settle. interestingly, since it's a protocol, the ietf should care, but since it's about software, the ietf probably won't care.
In my experience people are perfectly capable of shutting their eyes for the need to upgrade. Harrassment by e-mail won't change much there.
pv: (this is interesting, since it represents the prevalent view here that just because people want the functionality that some software provides, does not imply any commitment to keeping it from being used as an entry point for an attack nor launch point for attacks on others. this should have been obvious but i'd never thought about it that way before today.)
1. I have another idea though, during setup of the server ask for email address of list administrator, but keep that on the server itself. 2. Setup some dns server that provides dns record if there are necessary updates (here is one example in reverse dns notation...: 1.2.9.bind.updates.isc.org and set it to particular ip or particular MX or whatever to show if update is needed). Possibly have this special update dns recorb be HINFO to url where more information on update is available. 3. When bind starts if the record in #2 exists and shows that update is necessary, have bind server email to address entered in 1 and with abscense of that have it email to postmaster@computername.com and if HINFO exists, it can take that and enter this as custome email.
pv: (alas, in most bind installations, there is no script that's run to install the software or generate a config, and where this is done, it's platform/vendor specific, i.e., not written by ISC even if we had one. as to #2, there's a lot more value in MIM'ing the response to a query than there is in MIM'ing the reporting of a version:hostname:email tuple, and i don't thing we should create new attack vectors. as to #3, not every bind server host has the ability to send e-mail at all.)
This idea could be taken further, with a service offering that vendors and/or users support. Instead of having the server only answer for BIND, it could answer for any number of products. Vendors would have to supply the details on the latest software versions and patches, hopefully funding the listings (in the case of software sold for dollars, open source would have to be supported in another way, such as by user subscription).
pv: (i love this idea, and if somebody else leads, ISC would try to follow.)
I think the key to getting people to upgrade may be one of:
1) provide an automated audit tool which can look at an existing installation and flag known issues, and do pre-installation checks for required supporting packages which may also need to be installed -- sort of an automated mentoring system. Given the problems with misconfigured software in some remote parts of the world, it would probably be worth building that code in a way that facilitates internationalization from the get go...
2) have the application periodically check for updated versions, and nag/nudge admins when appropriate (or possibly even auto-update)
Yes, I know, neither of these should be necessary, and yes, I know that automation of installation tasks poses its own set of problems but we live in the time of Windows Update and "system admins" who aren't what they used to be, I'm afraid.
pv: (i suspect that something like this, as an outboard tool capable of running on a NOC machine, is the right short term approach. it'll need the ability to scan for BIND instances in the local address space, keep track of their version numbers, and download (via https:// i guess) a file from some central repository indicating version availability and safety, and to send mail at various junctures. i wish i had this for NTP as well, now that i think of it. maybe this should be a NOCOL thing.)