vixie at isc.org
Tue Jun 14 00:38:47 UTC 2011
> From: Rick Jones <rick.jones2 at hp.com>
> Date: Mon, 13 Jun 2011 15:43:20 -0700
> > on the other hand...
> > if we digitally sign an rrset at "vulnerabilities.bind9.software.isc.org"
> > which is a bunch of TXT RRs of the form "9.3.4-P5" "188.8.131.52-P3" (yes,
> > that's two segments in one TXT payload) then they'd probably all fit in
> > a 512 byte response even with an RRSIG. this is worth considering, since
> > the querier could just do string compares, not greater/lesser compares.
> How do you know when you can cull from the "known to be vulnerable to
> something" list? Can it take as long as "Until 9.4 (et al) is no longer
> supported" without the list getting too large? Does it have to go longer
> than that?
probably we'd time it out after five or ten years. my experience has been
that someone who hasn't upgraded in that amount of time will never upgrade.
> Presumably the "not known to be vulnerable" list would be shorter and
> more readily culled? And as an added benefit, one could, presumably,
> remove something from the "not known to be vulnerable" list once that
> version was no longer supported, as an added inducement to upgrades...
> And if there is simply a workaround, how does BIND know it has the
> workaround in place when it still sees its version in the list of the
> vulnerable? (Or does not see its version in the not known to be
> vulnerable list?)
the workaround problem is not as interesting to me; if someone knows they
are vulnerable then they should upgrade as soon as possible and should "red
flag" that installation until the upgrade is complete. workarounds don't
necessarily "stick", another operator may come later and revert the config.
More information about the bind-workers