[rbldnsd] Feature request: DNSSEC

[Kai Schlichting]

On 7/10/2008 at 2:51 PM, "Steven Champeon" <schampeo at hesketh.com> wrote:

> on Thu, Jul 10, 2008 at 01:29:58PM -0500, Lyle Giese wrote:
>> I think Michael is right. What is the gain from attacking DNSBL data?
>> 
>> How does the attacker make money? He makes money by steering web traffic
>> to compromised servers to push bot software to your desktop or to push
>> popups or ads to your desktop.
>> 
>> He does not make money attacking DNSBL data.

> If he's losing money by having his domains listed in a DNSBL, and now
> has the ability to poison cached records pertaining to those domain(s),
> I should think there's a rationale for attacking a DNSBL.


Cache-poisoning attacks are geared at the CLIENT side, not the server
side. That means, the attacker would have to successfully figure out:

- UDP port and DNS query-id pseudo-random schemes of the recursive resolver
  servers used by the MTAs of a system
- figure out which public mirrors of a DNSBL are predominantly hit by those
  resolvers
- be able to trigger outbound DNS queries on those resolvers (MTA infrastructure
  tends to use dedicated DNS servers that are virtually always secured
  against external recursive and non-recursive queries)
- win the race against the outbound queries against the public DNSBL mirrors,
  all of which he'd have to spoof with 100's to 1000's of packets within a
  very narrow window of opportunity

- The attacker will have to do this for every single ISP's MTA's DNS servers,
  and repeat it for every single IP listed in said DNSBL that he wishes
  to subvert this way.
- Given the relatively long TTLs on nameservers for DNSBLs, and general
  inability to observe which NS the caching resolvers are actually hitting,
  cache-poisoning the A records for the DNSBL's NS seems infeasible.
  The window of opportunity for the attack, when NS delegations (either
  from in-addr.arpa TLD to the main DNSBL domain, or the DNSBL domain to
  its specific sub-zone) for the DNSBL expire is almost infinitely small
  (for big sites, at most a few milliseconds, and big sites are the only
  ones worthy of attacks)
- Most caching resolvers will not cache records with an infinite (NS-provided)
  TTL, indeed most of them will have a configured limit of well under 8 hours,
  requiring re-poisoning every single sending IP in the cache multiple
  times a day.
- Attackers doing this for fixed IP ranges WILL be caught doing this, sooner
  or later.
- Virtually all large sites use rsync'd copies of DNSBLs, and never rely on
  DNS query traffic to 'world'

This completely stacks the cards against the attacker (pretty much to the point
where all Kings, Queens, Jokers and Aces have been removed from the deck),
and makes this attack non-feasible, non-effective and non-scalable.

The attack also seems to have absolutely minimal return value for spammers,
compared to the simple act of just shifting the spam traffic to originate from
a different IP or IP range.

As far as my incoming and outgoing MTA infrastructure is concerned, DNS
cache-poisoning is not robbing me of my sleep - there's plenty of other
things that can do that :P