phoning home

[Paul Vixie]

> From: Jim Reid <jim at rfc1035.com>
> Date: Mon, 13 Jun 2011 10:21:41 +0100
> 
> Well maybe. But who says the QNAME must be related to the BIND version
> that issues this lookup?

i did, because "does my maker now think that i am vulnerable" is the
responsible (public benefit) thing to want to know.

> > How about a zone listing vulnerabilities, linked by NSEC?
> 
> This is a Stunningly Bad Idea.

noting: if possible i'd like the language used on this thread to be less
strident than the above quoted example.

> DNS RDATA is not a good place to implement linked lists, even though
> NSEC provides that capability as a side-effect. What is the client
> expected to do while this "find if I've got any security bugs" quest
> was under way?  How many NSECs would an implementation have to
> traverse before it gave up or decided it didn't have a security hole?

i agree.

> I'm not convinced that getting BIND to phone home (when? how often?)
> is worthwhile.

a week ago <http://www.isc.org/software/bind/advisories/cve-2011-1910>
came out and i realized that it was time for bolder steps.  our installed
base is worldwide and we are the dominant DNS platform.  at some point
the needs of the many (to be protected against the effects and side
effects of these vulnerabilities) outweigh the needs of the few (to avoid
being annoyed by syslog'd vulnerability notices.)

> First the people who need to do something about old, buggy versions
> will not see these warnings or do anything about them. They won't be
> checking their logs. Or know how to switch on this bugfix check. [It
> would be configurable, right?]

i think there are people out there who would notice the syslog message.
yes of course this functionality would be configurable, there's no way
we'd put an information leak into public software without having some
way to turn it on and off.  the decision of what the default ought to be
will be interesting.  (when we added VERSION.BIND in ~1996, a lot of
people asked for a way to override it with a user specified version
string.)

> These guys already don't visit the ISC web site for info about
> vulnerabilities or read any of the lists where announcements get made
> about a security problem. Expecting them to read and act on a message
> in the name server logs seems optimistic and/ or naive. Unless the
> server refuses to run until it gets upgraded.  Which introduces
> another set of nasties...

call me an optimist if you want.  the more compelling argument against this
approach is that it's multigenerational -- we won't be able to get vuln.
checking into currently installed systems until they upgrade.  so there's
a very long time ahead of us during which there will be no public benefit
from a new vulnerability check.  i will not argue that this makes it "not
worth doing", because i'm in this for the long haul.  something that doesn't
benefit the world until after i retire or die still benefits the world.  i
ask you to evaluate this proposal in that light.  for instance, right now
there is no way to automate one's BIND vulnerability checking, one has to
monitor various mailing lists and wait for CERT announcements.  if we add
ways to automate it and some people use them, what will we have *lost*?

> Next, what's to be done about vendors who fold their own tweaks into
> the code? Or mangle the version info to match their own release
> conventions?  Think $LinuxDistro BIND version foo which is actually
> BIND x.y.z with (some of) the BIND x.y.z security patches applied.

i expect that those vendors will change the vulnerability check to be one
that looks to their own domain and uses their own internal version number,
or to add their check after our check.  more likely the former, since the
business model for these vendors is about adding value over "open source".

some vendors will already have a method of doing this kind of vulnerability
checking in their "automatic updates" mechanism and will just turn ours off.

> Maintaining the DNS infrastructure for security-holes.bind.isc.org (or
> whatever) will be a problem. This is probably not a big deal, though
> the long-term consequences could be unpleasant: ISC would be committed
> to sustaining this domain forever.

ISC is committed to sustaining the internet infrastructure forever.  keeping
some domain name immutable for all time is no big deal.

> And what happens when lookups for this domain fail because they get
> blocked at the corporate firewall or when an organisation has an
> internal root?

that would prevent this value from being added.  does this argue for a web
services method instead of a DNS method?  (that would be RESTful XML.)  or
maybe parameterize it so that can be done with an outboard utility whose
command argument is the bind version number and it can do whatever checks
it wants and respond however it wants (like syslogging or stopping named.)