Subject: [Asrg] DNSxL notation for IPv6?

From: Matthias Leisi <[email-masked]>
Date: Mon, 17 Sep 2007 21:40:00 +0200

Hello Asrg List,

I asked this question over at SPAM-L, but I think the question may be of
interest to asrg@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).

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.

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

- -- Matthias

[1] 2001:0db8:0000:0000:0000:0000:1428:57ab

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Meng Weng Wong <[email-masked]>
Date: Mon, 17 Sep 2007 13:00:22 -0700

> What would make sense, and what not? What has already been tried?

We need better protocols.  DNS was never designed for this.

I believe a number of next-generation protocols have been developed,  
or are being developed.

At my company we use a very simple protocol; it runs on UDP with  
retry and failover to TCP, just like DNS.  The serialization codec is  
based on BitTorrent so it already has library support in many languages.

We'd be happy to opensource it and publish it as a standard for  
others to use.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 17 Sep 2007 13:30:21 -0700

On Sep 17, 2007, at 12:40 PM, Matthias Leisi wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello Asrg List,
>

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.

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

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

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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 17 Sep 2007 16:20:03 -0700

On Sep 17, 2007, at 1:00 PM, Meng Weng Wong wrote:

>> Google was not helpful on this subject, so you may be able to help  
>> to reveal the status of DNSxL notation for IPv6.
>>

DNS was not designed to handle SPF either.  SPF is a potential vector  
for dangerous reflected amplification attacks.  It is not safe to  
attempt to return _all_ IP addresses for _all_ systems which may  
process a message for a domain.  This list must be large and will  
entail many repeated transactions.  SPF chains these transactions  
through the use of text macros.  These macros can result in an  
unexpected attack that is not discerned by examination of messages or  
logs.

> I believe a number of next-generation protocols have been  
> developed, or are being developed.

Eventually, something other than an IP address is needed for  
validation.  IPv6 represents 72 quadrillion (10^15) networks  
containing 18,400 quadrillion identifiers.  In addition, there will  
be shared gateways transitioning between IPv4 and IPv6 versions.  Bad  
actors can overwhelming any attempt to track reputations validated by  
an IP address.  In addition, there are hundreds of millions of 0wned  
systems which have access to provider's outbound servers.  This is a  
problem that might scale when pushed to the edge.

> retry and failover to TCP, just like DNS.  The serialization codec  
> is based on BitTorrent so it already has library support in many  
> languages.

For many, spam levels exceed 99% of the overall email traffic.  To  
cope, connection status must be concluded within a few transactions.   
Bifurcation of message and notification offers advantages in that  
Delivery Status Notifications can be avoided when post processing a  
message that is not desired, and removes the need for source  
validation.  SPF was aimed at avoiding back scatter when processing  
is pipe-lined.  This approach reduces email integrity, and imposes a  
dangerous level of up front transactions.  Transfer-by-reference  
avoids most of these problems.  For this to work, domain tasting MUST  
END!  There MUST be a reasonable cost associated with the control of  
a domain.

> We'd be happy to opensource it and publish it as a standard for  

SCTP offers a better solution for specialized reputation services,  
even when tunnelled on UDP.  SCTP requires less connection set-up  
than TCP, avoids resource exhaustion attacks, source spoofing, and  
can handle thousands of simultaneous framed transactions per  
connection.  SCTP also uses an error detection scheme suitable for  
GigE when this becomes available. : )

-Doug

---

From: der Mouse <[email-masked]>
Date: Tue, 18 Sep 2007 03:40:09 -0400 (EDT)

> [...] the status of DNSxL notation for IPv6.

> What would make sense, and what not?  What has already been tried?

Well, I run a semi-private DNSBL myself ("private" because I don't
document it and the listing/delisting criteria are basically "whatever
I feel like", but "semi-" because it *is* available in the public DNS
for anyone to query who's crazy enough to want to).

For IPv6, I use reversed-nibble notation, basically taking the syntax
used for rDNS lookups, ripping off the .ip6.arpa, and slapping on the
appropriate DNSBL domain.  It works for me.

> Besides the bandwidth argument (is this a valid argument?)

I don't think so.  Reversed-nibble takes 64 bytes of DNS packet
contents (alternating length bytes and nibble-in-ASCII-hex bytes); I
don't consider this large enough to be an issue, especially since it
will normally occur only once per packet, even if multiple records are
returned, thanks to name compression.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: John Levine <[email-masked]>
Date: 18 Sep 2007 13:20:07 -0000

>> What would make sense, and what not?  What has already been tried?

In my DNSxL draft, soon to be an RFC we hope, I say that it's nibble
reversed hex, the same as v6 rDNS.

>returned, thanks to name compression.

Quite right.  Any normal v6 query or response should fit in a 512 byte
packet, and that's all that matters.

R's,
John

---

From: John Levine <[email-masked]>
Date: 18 Sep 2007 13:20:07 -0000

R's,
John

---

From: John Levine <[email-masked]>
Date: 18 Sep 2007 13:20:07 -0000

R's,
John

mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/asrg>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Sep 2007 10:57:13 -0700

On Sep 18, 2007, at 6:20 AM, John Levine wrote:

> In my DNSxL draft, soon to be an RFC we hope, I say that it's  
> nibble reversed hex, the same as v6 rDNS.
>
>> contents (alternating length bytes and nibble-in-ASCII-hex bytes);  
>> I don't consider this large enough to be an issue, especially  
>> since it will normally occur only once per packet, even if  
>> multiple records are returned, thanks to name compression.
>
> Quite right.  Any normal v6 query or response should fit in a 512  
> byte packet, and that's all that matters.

Nevertheless, IPv6 remains a problem for email.  IPv6 is problematic  
when attempting to construct ever larger and more dangerous SPF  
records, for example.

Section 1.3 indicates why reverse DNS lookup for IPv6 is being met  
with little enthusiasm.
http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping- 
considerations-05

Although the 64 bytes needed for reversed IPv6 address names impacts  
reverse lookups, and schemes like rfc4025, returning an A record is  
not a problem.  The zone size for programs like rbldnsd will  
necessitate additional servers.   The sheer number of IPv6 addresses  
impairs establishing reputations, even at /64 CIDRs.  IPv6  
reputations are unlikely to prove an effective deterrent and will  
likely cause the number of routes to explode even more rapidly.   
Placing all your fingers, toes, and other body parts in the IPv6 spam  
source damn is likely to be a wasted and ill-considered effort.  This  
effort will enjoy greater cache miss rates, increased packet sizes, a  
massive and expensive database, and more routes.  There are better  
approaches that do not depend upon the IP address as an identifier.

-Doug

---

From: Matthias Leisi <[email-masked]>
Date: Tue, 18 Sep 2007 20:06:58 +0200

> but it's really not a big deal.

Based on this argument (including the on-the-wire format) and
considering John L.'s DNSxL BCP, it seems reasonable to keep PTR-style
lookups.

> for anything smaller than a /64?".

Rarely, I guess, but that's rather a policy decision and should not have
an influence on the protocol.

> rather "This /128 is listed as part of this larger /52" ?

And one may want to query someting like "Which [how many, ...] addresses
in this /52 are listed?". But this is not IPv6 specific - it's something
I'd like to see for IPv6 DNSxLs as well.

I'm aware of lists that will return a 127/8 response if some threshold
of a range is listed, but a more powerful query/response mechanism would
help eg to aggregate reputation scores from multiple sources.

> looking at, but I've not looked at recent drafts so I'm not sure.

Partially - it is (rightly so) mostly a codification of what is
currently out there.

- -- Matthias

---

From: Matthias Leisi <[email-masked]>
Date: Tue, 18 Sep 2007 20:23:34 +0200

Douglas Otis schrieb:

> reverse lookups, and schemes like rfc4025, returning an A record is not
> a problem.  The zone size for programs like rbldnsd will necessitate
> additional servers.   

A large DNSBL has in the area of 5 mio entries. CPU and I/O load should
not be a problem with IPv6 addresses.

> The sheer number of IPv6 addresses impairs
> establishing reputations, even at /64 CIDRs.  IPv6 reputations are

Even IPv4-based reputation suffers from a scaling problem.

<shameless plug>That's why I believe that "enumerating goodness" is more
powerful in the long run than "enumerating badness" and my motivation
for building up dnswl.org</shameless plug>

> unlikely to prove an effective deterrent and will likely cause the
> number of routes to explode even more rapidly.  Placing all your
> fingers, toes, and other body parts in the IPv6 spam source damn is
> likely to be a wasted and ill-considered effort.  This effort will enjoy
> greater cache miss rates, increased packet sizes, a massive and
> expensive database, and more routes.  There are better approaches that
> do not depend upon the IP address as an identifier.

ACK, IP addresses are just one element. OTOH, as long as signing
mechanisms are not more widely deployed, and as long as domain names are
free (as in beer) for some purposes, IP addresses and associated
information (ranges, routes) remain important.

- -- Matthias

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 18 Sep 2007 15:49:37 -0400

> not be a problem with IPv6 addresses.

One of the DSBL variants has around 11 million, and one of the SORBs 
lists had 13m when I last looked.  We have run with both CBL (5m 
entries) and DSBL simultaneously, no problems.

Even when you combine them altogether into a single zone, where each 
entry has its own A record, rbldnsd still behaves pretty nicely.

Our zone file is ~500mb, and we do several million queries per day, and 
get sustained query rates of ~2-3 million/hour upon occasion.  CPU is 
still under ~5%.

Not a problem for reasonably modern hardware.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Sep 2007 15:18:17 -0700

On Sep 18, 2007, at 11:23 AM, Matthias Leisi wrote:

> Douglas Otis schrieb:
>
> A large DNSBL has in the area of 5 mio entries. CPU and I/O load  
> should not be a problem with IPv6 addresses.

We employ dynamic strategies utilizing somewhat normal RBL  
infrastructure deployed across a fair number of servers.  For IPv4,  
more than a hundred million entries update daily.  This goes beyond  
typical RBL entries.  IPv6 is sure to greatly exacerbate these  
numbers.  A strategy that attempts to ignore addresses that are  
specific to hosts within a network will necessitate an unmanageable  
number of exceptions.  Even so, as many as 72 quadrillion networks  
would still require tracking, in addition to some subset of addresses  
within these networks.

>> The sheer number of IPv6 addresses impairs establishing  
>> reputations, even at /64 CIDRs.  IPv6 reputations are
>
> <shameless plug>That's why I believe that "enumerating goodness" is  
> more powerful in the long run than "enumerating badness" and my  
> motivation for building up dnswl.org</shameless plug>

Would the reputation start at 0, +1 or -1?

> mechanisms are not more widely deployed, and as long as domain  
> names are free (as in beer) for some purposes, IP addresses and  
> associated information (ranges, routes) remain important.

The current level of 0wned systems ensure shared IP addresses will  
never be a good solution.  As long as email is free (as in free beer)  
vetting prior to submission will _never_ be sufficient.

Splitting email messages into notification/message provides a  
separate channel where message origination can not be spoofed, DSNs  
are not needed, and undesired junk is never transferred.  This change  
would permit email to retain a high level of delivery integrity,  
allow final recipients to establish their own acceptance policy, and  
ensure valid recipients are kept confidential.  This change will not  
burden recipients with additional cryptographic processes.  An email  
specific URI could be used as an identifier instead.

-Doug