[dns-operations] online version checks

[Paul Vixie]

there are four replies here.  note that this no longer seems BIND specific
to me, and i know that virtually all name server vendors are represented on
this mailing list, and i consider this 'feature research' to be a vital
activity for the whole DNS community, not just the BIND community.

---

> From: Florian Weimer <fweimer at bfk.de>
> Date: Fri, 31 Dec 2010 08:11:29 +0000
> 
> * Paul Vixie:
> > this is not a situation where one vendor's name server will ever need to
> > look up another vendor's version information.  interoperability really is
> > a nonsequitur here.
> 
> You might want to run your software inventory against vendor-supplied
> version information, though.  There are already existing standards for
> related data (OVAL, SCAP).
> 
> I find it hard to believe that someone who doesn't keep track of
> installed software versions will spot the additional unexpected log
> message, by the way.

this is an argument for some kind of pluggable API, where a running server
should be able to tell the local management systems what its version is and
what URL the management system could use to find upgrade information about
that version in some standardized form.  this is in case the name server
does not have external access and cannot find this information for itself,
but where the name server's vendor does make it available in standard form
from the vendor's own web site using a URL that was shippined with the name
server, like xml://8.17.9.bind.software.isc.org/ or similar.

---

> Date: Fri, 31 Dec 2010 10:38:36 +0100
> From: bert hubert <bert.hubert at netherlabs.nl>
> 
> On Fri, Dec 31, 2010 at 08:11:29AM +0000, Florian Weimer wrote:
> > I find it hard to believe that someone who doesn't keep track of
> > installed software versions will spot the additional unexpected log
> > message, by the way.
> 
> Indeed. From an operational standpoint, I would appreciate an SNMP trap or
> some other flag that says 'this piece of software thinks it should be
> updated' and another one 'this piece of software insists that it be
> updated'.

this, also, is an argument for some kind of pluggable API.  not every
management system uses SNMP traps in this way, and asking every name
server vendor to add SNMP trap functionality might not have a wonderful
cost:benefit ratio when measured on a global scale.  on the other hand
those who want such traps could script them using the same pluggable API
i mentioned above in my answer to florian.

---

> From: Joe Greco <jgreco at ns.sol.net>
> Date: Fri, 31 Dec 2010 06:12:18 -0600 (CST)
> 
> My own experience is that the ClamAV (I think) model of e-mailing a
> notice when important things need attention is useful, but that does
> not always scale too well to a larger organization.
> 
> I'd *like* to be able to have better ways to monitor nameservers, but
> some of what would be most useful really requires support in the code
> itself, or from ISC.

just noting that the above-mentioned pluggable API would seem to be the
right way to allow those who want such e-mail to script it for themselves
while keeping the code that decides when to send the e-mail out of the
name server itself.

---

> From: Joe Greco <jgreco at ns.sol.net>
> Date: Fri, 31 Dec 2010 06:54:30 -0600 (CST)
> 
> > I like both e-mail and SNMP traps to a management system - but this
> > should be configurable and default to off.
> 
> If we're discussing wishful thinking, it'd be nice to have a queryable
> flag in the nameserver, maybe alongside the VERSION.BIND stuff.
> 
> UPGRADE.BIND -> available, required
> 
> This doesn't work, however, for nameservers that don't have access to
> the public Internet.  For those cases, it'd be more practical to have
> a way for a network monitoring system to discover whether or not a
> given version of BIND needed to be updated.

this insight leads me to suggest that UPGRADE.BIND (as in your example)
be a TXT RRset containing the URL that the local management system could
use to find version-specific vendor-specific upgrade information.

===

noting, i think if we're going to do something like this it should be an
IETF standard and that the fake top level domain ".BIND" should not be
used.  for one thing, now that ICANN is opening up the GTLD space, the
".BIND" TLD might actually end up being a real name some day.  i do like
using DNS to learn non-DNS things from the local name server, but i now
see "VERSION.BIND" as a mistake.  perhaps the IETF DNSEXT WG should try
to reserve "._DOMAIN" for this and populate it with VERSION and UPGRADE,
with other stuff no doubt to follow later.

***