lampe at hauke-lampe.de
Tue Jun 14 10:05:11 UTC 2011
On 13.06.2011 11:21, Jim Reid wrote:
> Well maybe. But who says the QNAME must be related to the BIND version
> that issues this lookup?
That's what I was getting at. If Paul wants to alert operators to new
security bugfixes, then the lookup should be keyed by
a "highest security bug ID", not by named's version number.
>> How about a zone listing vulnerabilities, linked by NSEC?
> This is a Stunningly Bad Idea. DNS RDATA is not a good place to
> implement linked lists, even though NSEC provides that capability as a
The idea was: If you're already polling security.bind9-bugs.isc.org/TXT
(or similar) for updates, you could also look at
3120.security.bind9-bugs.isc.org/NSEC. As long as it points back to the
zone apex, no new security bugs have been logged. If any new records
show up, BIND could read the TXT records and log them.
> What is the client expected to do while this "find if I've
> got any security bugs" quest was under way?
The same thing it always does. Upgrade information is purely
informational and must not affect the operation of the software.
> I'm not convinced that getting BIND to phone home (when? how often?) is
I agree there. But *if* it is implemented, it should not use the version
number itself because that's not a good indicator on the patch level.
> Next, what's to be done about vendors who fold their own tweaks into the
> code? Or mangle the version info to match their own release conventions?
> Think $LinuxDistro BIND version foo which is actually BIND x.y.z with
> (some of) the BIND x.y.z security patches applied.
That's why I would use a bug ID or CVE# instead of a version number.
> Maintaining the DNS infrastructure for security-holes.bind.isc.org (or
> whatever) will be a problem.
That zone could be generated from the changelog automatically.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: OpenPGP digital signature
More information about the bind-workers