phoning home

Rick Jones rick.jones2 at
Mon Jun 13 22:43:20 UTC 2011

On Mon, 2011-06-13 at 22:20 +0000, Paul Vixie wrote:
> > From: Rick Jones <rick.jones2 at>
> > Date: Mon, 13 Jun 2011 15:11:49 -0700
> > 
> > BIND ostensibly knows its major, minor and even fix revision right?
> > Just how many major.minor releases are there? Just return the entire
> > list of *latest* security related releases let BIND sort it out?  I
> > would think that all you need is the  initial "you are behind" signal,
> > and any greater "intelligence" can come from the administrator (sure,
> > that may be optimistic but you said you were an optimist right?)
> > 
> > Major  Minor  Fix (?)  Date (UTC I presume)
> you're right, or you should be right, and you may yet be right.  it's
> not always possible given our currently somewhat hairy version numbering
> scheme to compute "greater than or lesser than" for two version numbers.
> also, it's not necessarily the case that a vulnerability in some version
> is also present in other versions whose numbers are "greater than" that
> version.

I was thinking that the BIND code would find its matching
Major.Minor(.Fix) and then compare date codes.  It would ignore any
Major.Minor(.Fix) that did not match its own.

> and, it's not always the case that "you are behind" is useful information.
> the only thing i can be sure is of public benefit is a notification that
> "you are vulnerable".

I guess I was thinking that at the time the vulnerability was announced
there would be a fix, but I suppose it may only be a workaround.  Still,
even if there is no fix, if there is a way to manually update a running
BIND's "datecode" then presumably, first there would be the "you are
behind" signal that gets the admin to the workaround, said admin also
updating the datecode after implementing the workaround, and then later
there would be a second "you are behind" signal when the actual fix was
available (or yet another workaround was required).

> therefore my expectation has been that we'd have a specific domain name
> corresponding to every version we ship, and that when that version wants
> to know what its maker thinks, it will make a specific query to "there".
> which is why i worry that this would be an information leak.
> on the other hand...
> if we digitally sign an rrset at ""
> which is a bunch of TXT RRs of the form "9.3.4-P5" "" (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?  

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?)


> _______________________________________________
> bind-workers mailing list
> bind-workers at

More information about the bind-workers mailing list