a BIND 4.9.6 or 8.1.1 server is immune. so, you could upgrade. to so do,
see http://www.isc.org/isc/ which will lead you to ftp://ftp.isc.org/isc/.
(the root name servers are all running modern software at this point.)
alternic's corruption works by locating authoritative name servers via the
"NS RR"'s published in various zones. if you run these as authoritative-
only (recursion disabled) then they will never fetch any data from anywhere.
(the root name servers are configured this way, for example.) the downside
is that you can't list such nameservers in your "resolv.conf" files or PC
equivilents (Control Panel\\Networking\\TCP IP Settings, or some such rot.)
this means you need more name servers if you separate recursive from non-
recursive.
if you run these as authoritative-
only (recursion disabled) then they will never fetch any data from anywhere.
(the root name servers are configured this way, for example.) the downside
is that you can't list such nameservers in your "resolv.conf" files or PC
equivilents (Control Panel\\Networking\\TCP IP Settings, or some such rot.)
this means you need more name servers if you separate recursive from non-
recursive.
Correct me if I'm wrong, but this implies that nameservers whose sole
purpose is to act as primary and secondary for customer domains can run
with recursion disabled. I.e. all those nameservers whose identity is
readily discernable from public databases such as the Internic, RIPE, etc.,
could run in this configuration as long as they are not also intended to do
lookups for local machines on your local network.
Correct me if I'm wrong, but this implies that nameservers whose sole
purpose is to act as primary and secondary for customer domains can run
with recursion disabled. I.e. all those nameservers whose identity is
readily discernable from public databases such as the Internic, RIPE, etc.,
could run in this configuration as long as they are not also intended to do
lookups for local machines on your local network.
That's the way we run ours (non-recursive) It keeps performance up too
while keeping tabs on memory usage. In fact, we secondary commonly
accessed domains directly from their authoritative nameservers and keep
regular tabs on them to ensure our pointers are correct.
Well, Alternic's persona-non-grata (Eugene) is about to find himself in a
LOT of hot water for what he's done.
I have been told by a media figure who called me that the civil charges,
including a petition to seize *all* of his hardware, are being read
tomorrow. I expect that there may be criminal issues involved here
as well.
Playing "hahaha, www.biteme.eugene resolves now" is a childish prank of
no significance. Hijacking someone else's web site using the same trick,
however, is an entirely different thing and is no laughing matter.
I'm with Paul on this one (see, Paul, we can agree on something once in a
while -- update your code to either 4.9.6 or (preferrably) 8.1.1
Immune to which attack? The poisoned resource-record attack? The ID
guessing attack? How have you confirmed that 8.1.1 is not vulnerable to
related attacks?
Since, as you say, this has an "operations" context (the integrity of the
Internet domain service in realistic danger), it might be appropriate and
appreciated for you to detail the steps you and the ISC have taken to
resolve these problems in BIND 8.1.1. Does 8.1.1 validate resource
records? Does it use random query IDs?
My understanding of Kashpureff's attack was that it was of minimal
complexity (specifically, that he ripped off some kid's cname-bouncing
script). I am therefore concerned at what appears to be the use of his
apparently unsophisticated attack as a metric for the security of BIND
8.1.1.
-- update your code to either 4.9.6 or (preferrably) 8.1.1