Subject: [Asrg] For DNSBLs, embedded IPv4 in IPv6

From: John Levine <[email-masked]>
Date: Sun, 3 Aug 2008 20:30:01 +0100 (IST)

Someone pointed out that in some popular dual stack systems, connections 
from IPv4 addresses appear as IPv6 addresses in :FFFF:0000:0000/96, which 
I gather is reasonably consistent with v6 standards.

The immediate question is whether to add a sentence or two to the DNSBL 
spec saying that if you have a DNSBL listing both v4 and v6 addresses, and 
you list a v4 address, you SHOULD or MUST also list the corresponding 
embedded v6 address.

The real question is who's got enough real v6 experience and expertise to 
answer all of these v6 questions.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 4 Aug 2008 10:26:45 +0200

John Levine wrote:

> Someone pointed out that in some popular dual stack systems,
> connections from IPv4 addresses appear as IPv6 addresses
> in :FFFF:0000:0000/96

Yes, that is what I meant when I mentioned RFC 4408, (ab)using
::FFFF:127.0.0.2 as an "obvious" test entry.  Another proposal
in the meeting was to use one of the IPv6 example addresses
for this purpose.  But I can't remember the example addresses
without my 4408 cheat sheet, an obvious entry would be better.

> The immediate question is whether to add a sentence or two
> to the DNSBL spec saying that if you have a DNSBL listing
> both v4 and v6 addresses, and you list a v4 address, you
> SHOULD or MUST also list the corresponding embedded v6

No.  It is the job of the clients to get this right, they are
supposed to ask for the IPv4 form of these addresses.  With
::FFFF:127.0.0.2 as a possible *exception* for test purposes.

 Frank

---

From: Tim Chown <[email-masked]>
Date: Mon, 4 Aug 2008 09:50:17 +0100

Hi,

An excellent reference for application developers is RFC4038.

If you have any issues or clarifications on this text, I know that
at the very least Pekka is still active, so may answer questions
regarding adding IPv6 capability to DNSBL.

My personal experience is that applications should use explicit
IPv4 or IPv6 addresses in configuration files (not mapped addresses).
This is perfectly normal, e.g. in Apache or sendmail configs.

One place you may see mapped addresses is typically in log files.

The late Itojun wrote a draft on why IPv6 mapped addresses on the
wire are considered harmful:
http://www.watersprings.org/pub/id/draft-itojun-v6ops-v4mapped-harmful-02.txt

What was the other issue?  Looking for some 'test' address where currently
127.0.0.2 is used for the IPv4-only application?   What is the purpose of 
the test address?

Tim

-- 
Tim

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 4 Aug 2008 12:44:33 +0200

> An excellent reference for application developers is RFC4038.

Thanks for the pointer.  This might be overkill for the rather
simple goals of a DNSBL with IPv6 addresses, but a reference to
RFC 3901 (mentioned in RFC 4038) can be added to the DNSBL I-D.

> Looking for some 'test' address where currently 127.0.0.2 is
> used for the IPv4-only application?   What is the purpose of 
> the test address?

The test address tells you that a DNSBL is alive and kicking.

If "name" 2.0.0.127.dnsbl.example. has an 127/8 "address", then
IP 127.0.0.2 is listed.  In theory this one "test string" can
be used for any DNSBL (IPv4, IPv6, both, more) and even RHSBL.

In practice some RHSBLs use something else, e.g., example.tld.
They have a 127/8 "address" for say example.tld.rhsbl.example.

It would be nice to have test entries for each type of list,
it makes no sense to bother pure RHSBLs with IP queries, etc.

Similar lists have test address that is *never* listed, that
allows to catch stupid errors (or stupid exit strategies of
list operators trying to shut down their service).

127.0.0.1 is never listed.  It is intuitive to extend this to
::1 and localhost.  How to extend the always listed 127.0.0.2
is less obvious, ::2 is the idea in the draft at the moment,
and IIRC "test" for RHSBLs.  In the meeting somebody proposed
to use "test.invalid" or only "invalid" instead of "test".

All okay, no last minute changes to the 2606bis I-D required.
But IPv6 is less clear, I proposed ::FFFF:127.0.0.2

You are apparently saying that this is *too* intuitive:  We
expect clients to use the (reverse) IPv4 presentation form
for all mapped addresses, and therefore an exception is not
KISS enough.  So maybe ::2 is fine, or I will learn whatever
IPv6 example address is used as test address, no big deal...

 Frank

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 4 Aug 2008 07:09:53 -0400 (EDT)

>> connections from IPv4 addresses appear as IPv6 addresses

Could someone explain why a DNSBL needs to return IPV6 addresses? Even 
assuming one wants to create a DNSBL that lists IPV6 addresses (which I 
don't think would be worthwhile*) the only place the V6 address appears is 
in the query hostname character string - the DNSBL reply only needs a 
handfull of values, which 127.0.0.X supplies without stress. The replies 
are never used as addresses. Are we worried that a DNSBL client 
nameservice library wouldn't support IPV4 addresses? That seems 
far-fetched. What am I missing?

Daniel Feenberg

---

From: John Levine <[email-masked]>
Date: 4 Aug 2008 13:01:55 -0000

>Could someone explain why a DNSBL needs to return IPV6 addresses?

I don't know anyone who thinks that a DNSBL should return anything
other than A and TXT records.  What leads you to believe otherwise?

R's,
John

---

From: Tim Chown <[email-masked]>
Date: Mon, 4 Aug 2008 14:41:20 +0100

> other than A and TXT records.  What leads you to believe otherwise?

My background is someone who has been running IPv6 (dual-stack) for 
quite a while in an enterprise, whose site has a history in producing
open source anti-spam solutions, and who 'stumbled' into the ASRG meeting
in Dublin after it started :)     It seems there are some questions 
about IPv6 for which I haven't quite yet done the context switch.

My understanding is that to check against an IPv6 address, an ip6.arpa
style entry is used with the DNSBL domain name appended, and this is 
looked up - if an A record comes back the client is deemed to be blacklisted,
with an optional TXT field stating the reason. 

I suspect one comment might be that in an IPv6-only environment, one
might prefer to use the presence of an AAAA record to determine whether 
an IPv6 client is blacklisted or not.    Perhaps the discussion in Dublin 
that I caught half of was what IPv6 address to use in the AAAA record 
if one was used for IPv6 DNSxLs? (where 127.0.0.2 is used for IPv4)

In practise with IPv6 you will almost certainly want to list a whole /64
since in most situations a client can essentially pick any IPv6 address
from its onlink /64 to use.

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Mon, 04 Aug 2008 15:42:09 +0200

> other than A and TXT records.  What leads you to believe otherwise?

A and TXT records were the way found, years ago, to implement DNSBL 
without creating new kind of DNS records.

In fact, as long as I understand, the A record is useful to return a 
machine handleable code allowing to specify, why the record is listed. 
The TXT record contains human readable information.

As long as IP address is the usual result of an A query, an IPv4 address 
is the result usually returned by DNSBLs.

If something should be done about that, it's only to improve coding, not 
to add another redundant type of result.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 4 Aug 2008 10:13:05 -0400 (EDT)

> other than A and TXT records.  What leads you to believe otherwise?

A missunderstanding perhaps? There has been a lot of discussion in this 
list about IPV6, after all. Is all this discussion about queries for the 
status of the IPV6 equivalents of 127.0.0.X for testing if the DNSBL 
covers IPV6 addresses? But aren't all IPV4 addresses expressible in IPV6 
format? Won't those addresses do?

Daniel Feenberg

---

From: John Levine <[email-masked]>
Date: 4 Aug 2008 14:20:22 -0000

>My understanding is that to check against an IPv6 address, an
>ip6.arpa style entry is used with the DNSBL domain name appended, and
>this is looked up - if an A record comes back the client is deemed to
>be blacklisted, with an optional TXT field stating the reason.

That's right.

>might prefer to use the presence of an AAAA record to determine
>whether an IPv6 client is blacklisted or not.

This has come up before -- the A record isn't an address, it's a bit
mask or a group of bit fields, and the code that interprets it should
be the same regardless of whether the original lookup was for a v4
address, a v6 address, or a domain name.

> Perhaps the discussion in Dublin that I caught half of was what IPv6
> address to use in the AAAA record if one was used for IPv6 DNSxLs?
> (where 127.0.0.2 is used for IPv4)

Right -- that's the incoming address, not the result.  We need one
test address that is always listed, and one that is never listed,
ideally both from address ranges which like 127/8 should never appear
on an actual network.

>from its onlink /64 to use.   

Agreed.  Existing DNSBLs either use specialized servers which use a
table of listed CIDR ranges to synthesize result records, or else
ordinary DNS wildcards, e.g., to list 192.168/16 you'd include
*.168.192.example.org.  As far as I know, those both should be equally
doable with v6 addresses.

R's,
John

---

From: John Levine <[email-masked]>
Date: 4 Aug 2008 14:20:22 -0000

That's right.

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 04 Aug 2008 11:30:38 -0400

> The TXT record contains human readable information.

Right: MOST DNSBLs return A records to bitmap/flag listings.

However, there are a few DNSBLs that return machine-readable in the TXT. 
  Eg: routeviews.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 4 Aug 2008 16:03:38 -0000

>However, there are a few DNSBLs that return machine-readable in the TXT. 

I think routeviews is great, but I wouldn't really call it a DNSBL.

Are there any DNSBLs which give yes/no answers wth TXT records rather
than A records?

R's,
John

---

From: John Levine <[email-masked]>
Date: 4 Aug 2008 16:03:38 -0000

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 4 Aug 2008 15:56:28 -0700

> other than A and TXT records.  What leads you to believe otherwise?

Agreed.  Keep answers to A and TXT records.  Just different names are  
being questioned.  A records provide 4095 different values which seems  
more that adequate.  Internally, we are using 16 bits filtered against  
customer preferences.  When memory becomes limited, TXT records seem  
the first items dropped from the answer.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 4 Aug 2008 16:13:40 -0700

On Aug 4, 2008, at 3:56 PM, Douglas Otis wrote:
> Agreed.  Keep answers to A and TXT records.  Just different names  
> are being questioned.  A records provide 4095 different values which  
> seems more that adequate.  Internally, we are using 16 bits filtered  
> against customer preferences.  When memory becomes limited, TXT  
> records seem the first items dropped from the answer.

Sorry, this was just considering our internal use.  We expose some  
bits to customers, and others are masked for internal sub-categories.   
The overall range of an A record, where the upper octet is 127 and the  
value 127.0.0.1 is avoided, would be 16,777,214.  Many customers base  
acceptance on whether no answer and no error is returned, and then  
never examine the content of the A record.

-Doug

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 04 Aug 2008 22:16:09 -0400

> I think routeviews is great, but I wouldn't really call it a DNSBL.

DNS-Based-List.  The BCP claims it is.  Sorta.
> Are there any DNSBLs which give yes/no answers wth TXT records rather

SA treats text record returns from some DNSBLs as being listed.  Or at 
least the version I looked at did.  But that doesn't really count.

Can't think of any at the moment.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: der Mouse <[email-masked]>
Date: Mon, 4 Aug 2008 23:23:24 -0400 (EDT)

> A records provide 4095 different values which seems more that
> adequate.

...uh?  A single A record provides 4294967296 different values.
Restrict yourself to 127/8 and you still have 16777216 different
possible values.  (In each case, add one if you count an empty answer
section as another possible return "value".)

And this is easy to expamd.  Using multiple A records provides, in
theory, 2^4294967296 different possible return statuses, though most of
them seriously blow out packet size limits.

/~\ 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
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Florian Weimer <[email-masked]>
Date: Tue, 05 Aug 2008 23:23:30 +0200

* John Levine:

> The immediate question is whether to add a sentence or two to the
> DNSBL spec saying that if you have a DNSBL listing both v4 and v6
> addresses, and you list a v4 address, you SHOULD or MUST also list the
> corresponding embedded v6 address.

I think the client should use the original IPv4 address, not the mapped
IPv6 address for the DNSBL lookup.  Otherwise, you essentially bloat the
zone by a factor of two (slightly more even).

It's not an issue if you view DNSBLs as something close to an RPC
mechanism.  But if you do that, you'll eventually diverge from the DNS
protocol proper.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg