Re: DNSBL and IPv6

On 2012-10-19 17:38:16 -0700, Steve Atkins wrote:
> On Oct 19, 2012, at 5:25 PM, Dave Warren <[email protected]> wrote:
> > 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".

A simple (maybe naive) idea to reduce cache poisoning would be to do
some kind of greylisting before doing the lookup: If you haven't seen
the address before, simply return a temporary error. If you have seen
it (within some time window), do the lookup. 

Is there a reason why a legitimate MTA (talking to MXs, not submission
servers) would want to hop around in its net?

 * IPv6 privacy extensions might be turned on by default and the admin
   might not bother to turn them off, but I think they are too slow to
   prevent delivery (although it will slow down most mails)
 * An admin of an MTA serving many customers might want to use a
   different IP address for each customer. But from the outside that 
   would just look like one MTA per customer, not a single MTA hopping
   around


> 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).

There are many more IPv6 addresses and even /64 nets than IPv4
addresses. It's theoretically possible to ship around a zone file with
/all/ IPv4 addresses (that would be less than 100GB). This isn't remotely 
possible for IPv6 space. It might be possible for allocated /64 nets
depending on how they are allocated (if every cell phone gets a /48 ...).
If you go down to the /128 level, a spammer doing the hopping maneuvre
could blow up your zone file beyond any reasonable limit.

> And it doesn't affect the viability of using DNS as the
> communication channel between an MX and a local authoritative
> blacklist server.
[...]

Right.

	hp

-- 
   _  | Peter J. Holzer    | Der eigene Verstand bleibt gefühlt messer-
|_|_) | Sysadmin WSR       | scharf. Aber die restliche Welt blickt's
| |   | [email protected]         | immer weniger.
__/   | http://www.hjp.at/ |   -- Matthias Kohrs in desd

_______________________________________________
Asrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/asrg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIVAwUBUIJTFvIOSFES/ihdAQK4lBAArGFB3DtlS+o056RfOQpGojIa5CcBtSFW
/TNcdHRzfjI4xztREro2osch7IlP1KqPhtUuemwqDCZTkwbEgMJ0RWsi+vCWxQ6T
6l4msYwYLKaJ/6UUr/OeZY0ZWEJ2W5T2EX0bxtyl2dscAWp4b8daQreKuDceiv3A
pD92X9sE0sXaanErX1XYQ1kkhU2AN944tJ3jhjJgFW7oNdv8iExr9J1IfzYYBk3f
C+CLasXQ5vLiknhn8z8Znli+reX2B2pRmbf8UYoCwEJhOXQW4Qg8ys0qjnR435FO
WZq/bcCWJ+uyhP7UQWicV1cZvc7Og2UiYRfsAGR63cWR3bjWLJkLpoVcTtAuQNWj
gKIr86Kbex1w7NaqzbG1os3l+SEyFyqf8TlOL7+1NdySf66hHnNVwEAdc8BlSxkv
Tc8K2o9LIieFAu6hLsHZBBXn1QGSiICUt+VQ4gyHRPTYSicll7rU+UYUCTcFQA36
plg7wnpkZ3MHCfH/07VePqKhArLyirGDfU27MHZW8t/hLCLcsGdkpTTpMO7ZmgHy
d61y+md4uzQ9l18RHVYgjHdL5QpqNRStm1RtBUVJYXJLWqiCDTSZgcEdjLYwjQ5o
ykuW5jb7LiC4zcpKASSI/DIyu3tIbk24tyGt3jkplICBIGJR0fVQy7hbKHob+kWT
gSRw7PC1JWE=
=boDC
-----END PGP SIGNATURE-----