[rbldnsd] v4-in-v6 queries seen in the wild

[Alex Lasoriti]

I analyzed the flux of queries relative to IPv6 addresses that is
currently coming to the Spamhaus mirrors  (even if at this stage
every IPv6 query is still getting NXDOMAIN as answer and the IPv6 
service has not been announced yet... but of course mail servers 
don't know that and generate those queries anyway!).

While their overall number is still very tiny, about 12% of them 
refer to IPs in ::ffff:0:0/96 - the so-called 'v4-in-v6' space
(excluding queries for the test addresses).

So there are some mail servers around that see IPv4 addresses 
embedded in an IPv6 framework rather than in their native form,
and they send out IPv6 queries to get BL informations about 
these IPv4 addresses - without bothering to convert them into their 
native IPv4 representation.

You see where I am going: right now, if a zone has both an IPv4 and
an IPv6 dataset attached, these two spaces are treated as entirely
separate and independent.  So, A.B.C.D may be listed but it's 
v6-in-v4 counterpart ::ffff:A.B.C.D may not be listed.  So a query for
::ffff:A.B.C.D will return NXDOMAIN and the mail will go through.

So the question that arises is: should rbldnsd be made aware of the
v4-in-v6 convention and 'check the other space', in order to satisfy
the needs of these clients ?

So, for instance, a query for A.B.C.D would imply, besides checking 
the IPv4 space for A.B.C.D listings, also checking the IPv6 space
for ::ffff:A.B.C.D listings. Then all the results from both spaces 
would be stacked in the output packet.  The same could happen for 
::ffff:A.B.C.D queries (which is the case that really matters): the 
IPv4 space would be examined alongside with the IPv6 space and the 
results stacked together.

An alternative approach could be to enforce absence of IPv6 listings
in ::ffff:0:0/96, and require examination of the IPv4 datasets only
to answer IPv6 queries in that range.

Of course, one could also generate v4-in-v6 datasets from the v4 
datasets and add them to the v6 space without changing the code, but 
this seems quite inefficient as a permanent solution, burning 
additional memory and I/O resources.

I emphasize that this does not seem to be a serious problem by any means
at this stage, but of course it is our duty to think about what may
happen in the future, particularly if more and more application
codes are implemented with the IPv6 stack only (following RFC3493 
sections 3.7 and 5.3) and do not bother to convert the DNS queries
going out into the standard IPv4 format.

Alex Lasoriti
Spamhaus Technology