[dns-operations] online version checks

[Joe Greco]

> 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.

That's probably not a bad idea, at least with BIND there's already the
nameserver control channel, which could possibly serve such a purpose.
I'd actually love to see some other information exported.  Was it here
that I was talking about monitoring for failed zone transfers and the
like?

> > 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.

That'd be nifty, as long as vendors could commit to avoiding allowing
the URL's go stale, and yes, I recognize that your suggestion above is
a good way to go about that, but I'm a little cynical sometimes.

> 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.

You could always stick it in real TLD .VIX ...  ;-)

VERSION.BIND served a needed purpose at the time.  Much real engineering
gets done on the net through practical needs, and we've learned some
very useful things from the exercise.  For one, it's really sweet to be
able to ask the nameserver something like its version without opening
up another port/firewall rule/etc to attack.  It's also obscure enough
that many folks don't bother hiding it, and you can tend to tell those
who've read the documentation from those who haven't.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.