marka at isc.org
Tue Jun 14 01:49:28 UTC 2011
In message <56321.1308013927 at nsa.vix.com>, Paul Vixie writes:
> > From: Mark Andrews <marka at isc.org>
> > Date: Tue, 14 Jun 2011 11:04:09 +1000
> > latest TXT <version list>
> > supported TXT <version list> not eol and no known vulnerabil
> > 9.0.0 TXT <cve list>/"*"/"-" "*" no longer maintained (N yea
> > after eol)
> > 9.4.1 TXT <cve list>/"*"/"-" "-" no known vulnerabilities.
> > 9.4.2 TXT <cve list>/"*"/"-"
> > 9.8.0b1 TXT <cve list>/"*"/"-" only listed until end of beta/rc period
> i think you mean 0.0.9, 1.4.9, 2.4.9, and 0b1.8.9, in the above example.
Actually I don't think there is any benefit in reversing it as we
are not delegating away chunks of namespace. in-addr.arpa, ip6.arpa
and enum delegate away chunks of namespace and you need to reverse
the labels to do so.
> (not that i'm sure this is what i'd recommend doing, but in any case let's
> put the most significant label on the right if we put stuff in the dns.)
> the thing that pains folks is that the qname will express their version
> number. even if someone is comfortable having ISC receive this information
> (which as michael graff pointed out would help us allocated resources since
> we'd have some idea of how many people run each old version), they might
> not be comfortable exposing this information in the clear to passive dns
> and any deep packet inspection machinery that's on the path to ISC.
cve TXT <version> <cve list>
TXT <version> <cve list>
cve TXT <cve> <version list>
TXT <cve> <version list>
The only thing here is that we will reach the 64K limit at some
point would need to trim the RRset or provide a link to the next
Alternatively we could have a record that list all versions and the
update checker justs asks for everything on that list discarding
what it doesn't use.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-workers