crude. He just put some bogus NS records into his alternic.net zone so
that queries for www.alternic.net would pick up those bogus servers
and their associated A records. His "sophisticated hack" consisted of
This is true, and it is essentially the textbook/cookbook version of the
"poisoned resource-record" attack that was outlined by Johannes Erdfelt a
few months ago on Bugtraq.
What I am asserting to you is that there are variants on this attack which
are not currently fixed by BIND 8.1.1. On a related note, there are things
that can be done to strengthen DNS implementations (such as BIND) against
these attacks that do not involve DNSSEC.
So, again, I think you are either in error or we're not in understanding
on the meaning of the word "variant". Perhaps, by the word "variant", you
refer solely to attacks that involve modifications to a shell script, and
my reference to attacks that involve programming ability cease to be
classified as "variants" of the attack.
So, I'd like to convey the fact that, by using the word "variant", I refer
to attacks that operate at a protocol level in a manner resembling the
attack performed by Mr. Kashpureff.
Thanks for providing me with an opportunity to clarify this.
(This being still basically on-topic as it relates to the security of
a critical component..)
Would either you or Ben Black please give an example of a change that
fits the characteristics you have described? I see a lot of "Yes it
can. No it can't. Yes it can." but nobody has actually supplied any
_details_. Paul has written papers on DNS security, along with BIND
itself, and I'm inclined to believe him when he says there are no more
trivial fixes. If you know of one, why don't you share it? I'm not
asking for code, just a description of what you want changed. Then
someone will either implement it or find that it is flawed.
Here's a simple piece of input. If BIND 8.1.1 receives a DNS query
response with an invalid query ID, it logs it and drops the packet.
However, the invalid query ID is evidence of an attack in progress. Why
doesn't BIND parse the packet, find out what question is being answered,
and immediately re-issue the query with a different ID?
In other words, it's possible for BIND to detect that it is under attack
(in a response-forged query-ID guessing situation). BIND doesn't do
anything about this. Why?
Just the simplest suggestion I can come up with (without having this go
into multiple pages) to convey the idea that I am trying to be
constructive here.
I'm not sure this is the appropriate forum for this discussion
(*copout*Ididn'tstartthisthread*copout*), but if you want further details
as to my harebrained suggestions, I'm happy to give them!
>itself, and I'm inclined to believe him when he says there are no more
>trivial fixes. If you know of one, why don't you share it? I'm not
Fair enough.
Here's a simple piece of input. If BIND 8.1.1 receives a DNS query
response with an invalid query ID, it logs it and drops the packet.
However, the invalid query ID is evidence of an attack in progress. Why
doesn't BIND parse the packet, find out what question is being answered,
and immediately re-issue the query with a different ID?
If a copy of BIND _receives_ a query, decides it's bogus, logs it, and
drops it, then a question isn't _being_ answered, it's bing _asked_.
Why _would_ BIND re-issue a query. it hadn't _issued_ that query in
the first place. Or, in simpler terms, "huh"?
In other words, it's possible for BIND to detect that it is under attack
(in a response-forged query-ID guessing situation). BIND doesn't do
anything about this. Why?
This isn't so much a security bug, but more a lack of a security-enhancing
feature. It _certainly_ doesn't merit the veiled character assination
you've been using it to justify.
Just the simplest suggestion I can come up with (without having this go
into multiple pages) to convey the idea that I am trying to be
constructive here.
You've failed.
I'm not sure this is the appropriate forum for this discussion
(*copout*Ididn'tstartthisthread*copout*), but if you want further details
as to my harebrained suggestions, I'm happy to give them!
Time to move this to bind-workers, no? Perry, Paul?