Re: DNSBL and IPv6

Steve Atkins <[email protected]>
Newsgroups gmane.ietf.asrg
Message-ID <[email protected]>
On Oct 19, 2012, at 5:25 PM, Dave Warren <[email protected]> wrote:

> On 10/19/2012 15:41, John Levine wrote:
>>>> What I feel needs to happen is that policy needs to put in place to RIRs
>>>> (via ISPs) can present "what is a customer" on a network level, and then
>>>> this information can be put into DNS somehow, and used for DNSBL.
>> Yeah, I've been talking to people on and off about this for over a
>> year.  Even though providers can lie about their allocation
>> granularity, most won't, and the ones that lie would probably merit
>> total blocking anyway.
> 
> I'm less worried about those that lie outright than those that just don't care either by not bothering to specify a policy at all (unless it becomes mandatory somehow), or have more granularity than can be clearly specified in a single policy.
> 
> For example, their policy might be to allocate at the /64 level, but unless they also prohibit customers from obtaining more than one /64...

The ability for customers to obtain more than one IPv4 /32 hasn't been too complex an issue for blacklist operators to deal with. Any blacklist operator who's successfully running an IPv4 blacklist can surely come up with reasonable (or unreasonable, I won't judge…) policies for IPv6.

The only relevant difference between v4 and v6 DNS based blacklisting is that the ability to easily hop around *within* your /64 makes it possible (easy) to blow the cache of a traditional caching DNS resolver if you do naive "look up a record based on the IPv6 address".

That doesn't affect the viability of source address based blacklisting. It doesn't affect the viability of distributing that data as DNS zone files (they suck for both v4 and v6, but they're usable). And it doesn't affect the viability of using DNS as the communication channel between an MX and a local authoritative blacklist server.

But it does mean that anyone wanting a recursive resolver in their distribution path might have to refine the process a little - which is what I assume John is looking at. 

(I'm betting that "mask the bottom 64 bits before querying" would work just fine, but I don't think we have enough v6 space in use yet to say for sure.)

Cheers,
  Steve
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.