[dns-operations] online version checks (was: re: New subscribers)
Paul Vixie
vixie at isc.org
Thu Dec 30 08:15:18 UTC 2010
> From: Jan-Piet Mens <jpmens+dnsops at gmail.com>
> Date: Thu, 30 Dec 2010 08:35:02 +0100
>
> On Wed, Dec 29, 2010 at 8:57 PM, Paul Vixie <vixie at isc.org> wrote:
> > i'm against this because it counts on all vendors using similar version
> > numbering schemes.
>
> Why similar numbering schemes? If the (suppose TXT RR) contains,
> say, semicolon-separated values, and the first is a version number,
> I don't see why that would impose similar numbering schemes on
> different vendors. Thinking along the lines of
>
> 1.4.7;2010-11-08;Unbound features & fixes
> 3.3;2010-01-20;PdnsRecursor feature
> 9.7.2-P3;2010-12-01;BIND maintenance release
if that's your example then i'm opposed to these constraints being imposed.
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. in your example you don't show owner names. in my
fanciful vision we might have
3.17.9.bind.software.isc.org. TXT "root exploit; upgrade to at least 9.17.8"
latest.17.9.bind.software.isc.org. TXT "9.17.8"
in order to say that bind9 9.17.3 has a root exploit vulnerability that
should be syslogged at startup and every day thereafter, and that the
latest 9.17.* version is 9.17.8.
whereas someone who doesn't use dotted multipart version numbers might want
a very different owner name schema, and someone whose software only runs
inside of embedded devices might have no use for "syslog" text.
again, no nominum "ans" instance is ever going to look up BIND's version
number information, so it literally can never matter whether they use the
same owner name schema or TXT formats. interoperability is an explicit
non-goal here, and any standards in this area would be pretty much useless.
More information about the dns-operations
mailing list