summary (Re: how to get people to upgrade?)

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

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

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

This got me to thinking... there's no reason a centralized,
automated database would need to be "yea/nay". Perhaps it's time
for a "vulnerability info" RRTYPE. Of course, DNS might not be
the protocol of choice; focus on concept and ignore details. :wink:

One of the fields could be severity. Let minor things be logged,
moderate troubles cause nagging, and major issues (e.g., worm
spreading via known exploit) trigger a shutdown.

Note that BIND could be written so any given instantiation knows
what subsystems (TSIG, recursive queries, etc.) it's actually