On Fri, Jan 7, 2011 at 8:19 AM, Chris Lewis <clewis(_at_)nortel(_dot_)com>
wrote:
It's nice to see public experiments in IPv6 DNSBLs, but, I really have to
wonder about the usefulness of it at the present time. Of the hundreds of
DNSBLs that exist, only a dozen or two block that much on their own. Couple
that with the dearth of IPv6 MTAs, I can't help thinking that such DNSBLs
are essentially useless except as proof-of-concept.
Even having proof-of-concepts is valuable -- otherwise, everybody will
wait for everybody else. Chicken, meet Egg :)
There has been quite some discussion on whether (more-or-less-)
arbitrary limits should be chosen ("only allow /64" etc), and some
proposals have appeared.
I now implemented an extremely simple proposal (note that this is
experimental only and not useful for production purposes). The basic
idea is that the server will *always* return multiple answers (up to
3):
1) The listed entry "below" the one requested
2) The listed entry "above" the one requested
3) If available, a "matching" entry
If two of the above overlap, only one will be returned. In general,
always at least two RRs should be returned. Each of the responses will
have a netmask, and additional data (ie, trust levels, reputation
score etc).
With that information, a "intelligent" application / query library can
greatly reduce the number of lookups required (eg when a spammer
enumerates all IPs in a IPv6-/64). On the other hand, this makes it
mathematically feasible to enumerate a complete DNSxL zone -- but I do
not consider this as an issue, at least not for dnswl.org.
The experimental server supports TXT and SRV records with essentially
the same information. It is single-threaded and not very efficiently
coded. But please feel free to test it:
:~> dig @ns-exp1.dnswl.org -t txt 2.0.0.127.exp.dnswl.org
;; ANSWER SECTION:
2.0.0.127.exp.dnswl.org. 3600 IN TXT "32" "10" "0"
34.244.255.125.exp.dnswl.org. 3600 IN TXT "32" "8" "2"
254.254.254.127.exp.dnswl.org. 3600 IN TXT "32" "10" "0"
:~> dig @ns-exp1.dnswl.org -t srv 2.0.0.127.exp.dnswl.org
;; ANSWER SECTION:
2.0.0.127.exp.dnswl.org. 3600 IN SRV 32 10 0 2.0.0.127.exp.dnswl.org.
2.0.0.127.exp.dnswl.org. 3600 IN SRV 32 8 2
34.244.255.125.exp.dnswl.org.
2.0.0.127.exp.dnswl.org. 3600 IN SRV 32 10 0
254.254.254.127.exp.dnswl.org.
The information for the two identical examples above is to be
interpreted as follows:
* Request for 127.0.0.2
* 127.0.0.2 has an exact match in the first of the three return RRs.
* 125.255.244.34/32 is the next entry "below", with category 8 and trustlevel 2
* 127.254.254.254/32 is the next entry "above" (a further test entry),
with cat 10 and trust 0
Another example:
:~> dig @ns-exp1.dnswl.org -t srv 254.5.210.128.exp.dnswl.org
254.5.210.128.exp.dnswl.org. 3600 IN SRV 24 11 2
0.5.210.128.exp.dnswl.org.
254.5.210.128.exp.dnswl.org. 3600 IN SRV 32 11 2
121.9.210.128.exp.dnswl.org.
* Request 128.210.5.254
* 128.210.5.254 is contained in the range 128.210.5.0/24, category 11, trust 2
* Next entry "above" is 128.210.9.121/32, cat 11, trust 2
* No next entry "below" is listed, because the range already serves
that purpose.
The list has two synthetical records to indicate the lower and upper bands:
:~> dig @ns-exp1.dnswl.org -t srv 0.0.0.0.exp.dnswl.org
:~> dig @ns-exp1.dnswl.org -t srv 255.255.255.255.exp.dnswl.org
Since I just hacked this together using existing Perl modules, the
data is only in IPv4, but the concept can easily be extended to IPv6
payload. This server will serve current dnswl.org data.
This approach has a number of benefits:
* No arbitrary cut-points
* Enables "intelligent" applications to avoid a lot of unnecessary requests
* Does require an application to walk down the tree from a root point
(and does not require DNSxL operators to artificially create such a
tree with synthesized records)
Some disadvantages:
* I don't know of a way to serve this off of a generic nameserver
(other than that nameserver being proxy to a "hidden master").
* DNSxL operators have less valuable logs because less specific
traffic hits their infrastructure.
I approached naturally from a whitelist point-of-view, so someone with
more experience in blacklists may have different approaches.
Rsync's batch-ish nature isn't quite why I mentioned latency. The latency
is zone rebuild time at the DNSBL server. With a zone file as large as the
XBL, say, even if you did some sort of incremental update directly off a
core DBMS in realish-time, I think you'd run into performance problems.
The latency is also in TTL. The lower the latency requirement, the
less is DNS the right tool for the job.
-- Matthias
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg