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:
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:)
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.)
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.)
pv: (i love this idea, and if somebody else leads, ISC would try to follow.)
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. ;-) 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 using. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
participants (2)
-
E.B. Dreger
-
Paul Vixie