[rbldnsd] ip6tset and the RFC5782 test IPv6 don't like each other
Alex Lasoriti
lasoriti at spamteq.com
Thu Oct 10 02:21:45 MSK 2013
Hi all,
I am working on the IPv6 setup for the Spamhaus lists that will soon be
extended to cover the v6 space.
I stumbled on this problem.
For XBL (malware-infected systems) the plan is to use ip6tset: all
listings will be /64, so it seems to be exactly the right dataset type
for this BL, and in fact I think this type was designed for this kind
of applications. Surely using ip6trie instead would be a waste of resources.
As the man page says regarding ip6tset:
This dataset wants the /64s listed as four ip6 words, for example:
2001:20fe:23:41ed
So the last 64 bits are simply thrown away, they do not appear as they
are not relevant. So far, so good.
Now, let us meet RFC5782 which defines (in section 5) the proper
test addresses. It says:
IPv6-based DNSxLs MUST contain an entry for ::FFFF:7F00:2 (::FFFF:
127.0.0.2), and MUST NOT contain an entry for ::FFFF:7F00:1 (::FFFF:
127.0.0.1), the IPv4-Mapped IPv6 Address [RFC4291] equivalents of the
IPv4 test addresses.
You now see the problem. The full expanded version of the test address is
0000:0000:0000:0000:0000:ffff:7f00:0002
but if I cut away the last 64 bits I remain with
0000:0000:0000:0000
and that is obviously _not_ a meaningful test address.
Solutions, considering that not including a functional IPv6 test
address is out of question:
1) we go ip6trie
2) we ignore RFC5782 and choose another test address in the
most significant 64 bits
3) rbldnsd is changed somehow (/128 made possible in ip6tset at
least for "special" records)
4) RFC5782 is changed and the revised version picks up a test address
in the high 64 bits. For instance, one could adopt the 6to4 scheme
and choose 2002:7f00:0002:0000 as test address.
No one of them seems particularly desirable.
Thoughts?
Alex
More information about the rbldnsd
mailing list