On Sep 17, 2007, at 12:40 PM, Matthias Leisi wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Asrg List,
I asked this question over at SPAM-L, but I think the question may
be of
interest to asrg(_at_)ietf as well:
- --- cut ---
Google was not helpful on this subject, so you may be able to help to
reveal the status of DNSxL notation for IPv6.
What would make sense, and what not? What has already been tried?
I think it would make sense to use something similar to the
reverse-dotted-quad notation used for IPv4, and use the same
request/response types (DNS A/TXT records -- there are enough bits of
information in a A response, no need for A6/AAAA).
Seems reasonable. But the only reason we use that now is because
it was an easy kludge in sendmail, not because there's anything
special, or even particularly good about it.
Using the "full format" of IPv6 encoding (like [1]), replacing ":" by
"." and reversing the whole thing would be the obvious notation, and
most similar to the IPv4 notation -- however, it seems like a great
waste of bandwidth to me.
Absolutely the wrong notation, IMO. Try listing a /49 using that
approach -
you'll end up with something like 32768 A records for the one range, as
compared to 8 for a nybble based notation.
Any better ideas?
- --- cut ---
On SPAM-L, the use of the PTR format was suggested:
windtunnel.rarpsl.com. 38400 IN AAAA
fe80::203:93ff:fe96:296c
c.6.9.2.6.9.e.f.f.f.
3.9.3.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
38400 IN PTR windtunnel.rarpsl.com.
Besides the bandwidth argument (is this a valid argument?)
Not really, no. You'd need to do the packet stuffing math and
some IP range distributions and suchlike to demonstrate that
the difference in size relative to fixed overhead isn't that great,
but it's really not a big deal.
against using
the "full PTR" format, I have a different thought:
Since Anti-Spam tools will need to be upgrade one way or the other
anyway, it may make sense to include a quasi standard for lookups for
larger (and non-octet-boundary) ranges.
If you want your database to consist of anything other than a list
of /128s then you do need to put in zone cuts to allow wildcards
(assuming you're piggybacking on DNS, which seems a reasonable
assumption for now).
IPv4 usage puts those zone cuts on 8 bit boundaries, which is a bit
large
for comfort, as it makes listing a /25 fairly tedious[1]. Four bit
cuts, using
hex digits rather than decimal integers, makes perfect sense[3].
Conveniently, that's exactly how IPv6 PTRs are defined, as you
show above[2].
Another interesting question would be "Would you ever check
for anything smaller than a /64?".
And, should there be an "I'm not dead" entry (127.0.0.2), and
perhaps an "I am dead" entry or response?
And, should the response not just say "This /128 is listed", but
rather "This /128 is listed as part of this larger /52" ?
I suspect these questions, and many more like them, are already
being touched on as part of the DNSBL BCP stuff people are
looking at, but I've not looked at recent drafts so I'm not sure.
Cheers,
Steve
[1] Yes, I know it's all generated by scripts, or on the fly from some
internal data structure, depending on which DNS server you're
using, but still...
[2] I'm supporting that IPv6 notation, amongst others, on my most
discriminating blacklists nofalsepositive.stopspam.samspade.org
and nofalsenegative.stopspam.samspade.org, should you want
to test any tools.
[3] Though I suspect that the multiply repeated nybbles will trigger
some bugs in poorly tested dns name compression code. :)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg