Re: [Asrg] DNSxL notation for IPv6?

On Sep 18, 2007, at 11:23 AM, Matthias Leisi wrote:

> Douglas Otis schrieb:
>
> A large DNSBL has in the area of 5 mio entries. CPU and I/O load
> should not be a problem with IPv6 addresses.

We employ dynamic strategies utilizing somewhat normal RBL infrastructure deployed across a fair number of servers. For IPv4, more than a hundred million entries update daily. This goes beyond typical RBL entries. IPv6 is sure to greatly exacerbate these numbers. A strategy that attempts to ignore addresses that are specific to hosts within a network will necessitate an unmanageable number of exceptions. Even so, as many as 72 quadrillion networks would still require tracking, in addition to some subset of addresses within these networks.

>> The sheer number of IPv6 addresses impairs establishing
>> reputations, even at /64 CIDRs. IPv6 reputations are
>
> Even IPv4-based reputation suffers from a scaling problem.
>
> <shameless plug>That's why I believe that "enumerating goodness" is
> more powerful in the long run than "enumerating badness" and my
> motivation for building up dnswl.org</shameless plug>

Would the reputation start at 0, +1 or -1?

> ACK, IP addresses are just one element. OTOH, as long as signing
> mechanisms are not more widely deployed, and as long as domain
> names are free (as in beer) for some purposes, IP addresses and
> associated information (ranges, routes) remain important.

The current level of 0wned systems ensure shared IP addresses will never be a good solution. As long as email is free (as in free beer) vetting prior to submission will _never_ be sufficient.

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related ietf.org Links asrg imrg Request more information about Pantek

Splitting email messages into notification/message provides a separate channel where message origination can not be spoofed, DSNs are not needed, and undesired junk is never transferred. This change would permit email to retain a high level of delivery integrity, allow final recipients to establish their own acceptance policy, and ensure valid recipients are kept confidential. This change will not burden recipients with additional cryptographic processes. An email specific URI could be used as an identifier instead.

-Doug