headers
John Levine | 20 Jul 2008 05:10

Another dnsbl draft, now standards flavored

The IESG has expressed interest in my dnsbl draft turning into a standards 
track RFC rather than informational.  I've done another version of it 
to make it read like a standard, and there's also a few places where I 
invented some standard practices, e.g., standard test entries for IPv6 
DNSBLs.  Take a look, tell us if I got anything seriously wrong.

We're in the I-D blackout period, so I've posted xml, html, and txt at 
http://www.taugh.com/dnsbl

In related news, there WILL be an ASRG session in Dublin.  Who other than 
me is planning to be there?

Regards,
John Levine, johnl <at> iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener Schnitzel, please", said Tom, revealingly.
Permalink | Reply | 22 comments |
headers
Frank Ellermann | 20 Jul 2008 07:49
Picon
Picon

Re: Another dnsbl draft, now standards flavored

John Levine wrote:

> The IESG has expressed interest in my dnsbl draft turning
> into a standards track RFC rather than informational.

Good...

> Take a look, tell us if I got anything seriously wrong.

...skipping typos and editorial nits reported separately ::2
is interesting, as I didn't know it.  My intuitive idea for
an IPv6 test address would have been ::FFFF:127.0.0.2 based
on the IPv4 test address.  Never listing ::1 is clear, same
idea as for 127.0.0.1.  WTH is ::FFFF:127.0.0.2 in a DNSBL ?

0.0.0.2.0.0.F.7.F.F.F.F.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

Well, nobody said that IPv6 DNSBLs are pretty.

> http://www.taugh.com/dnsbl

A diff to -05 is still readable, <http://tinyurl.com/6budf7>

 Frank
Permalink | Reply | 15 comments |
headers
Frank Ellermann | 20 Jul 2008 15:32
Picon
Picon

Re: Another dnsbl draft, now standards flavored

> 0.0.0.2.0.0.F.7.F.F.F.F.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 

Some hours later, that's wrong.  Why do they need their own test
entry, they could as well support 2.0.0.127 like IPv4 lists, if
the only purpose is to check that the list is alive and kicking.

 Frank
Permalink | Reply | 14 comments |
headers
John Levine | 20 Jul 2008 17:40

Re: Another dnsbl draft, now standards flavored

>Some hours later, that's wrong.  Why do they need their own test
>entry, they could as well support 2.0.0.127 like IPv4 lists, if
>the only purpose is to check that the list is alive and kicking.

Many DNSBLs are operated by specialized servers that synthesize the
records from lists of CIDR ranges.  The IPv6 test entries really need
to be IPv6 addresses or you're demanding special code in the server
for the test addresses.

I picked ::2 as the test address because it was next to ::1,
just like 127.0.0.2 is next to 127.0.0.1.

R's,
John
Permalink | Reply | 13 comments |
headers
Frank Ellermann | 20 Jul 2008 18:10
Picon
Picon

Re: Another dnsbl draft, now standards flavored

John Levine wrote:

> The IPv6 test entries really need to be IPv6 addresses or
> you're demanding special code in the server for the test
> addresses.

> I picked ::2 as the test address because it was next to
> ::1, just like 127.0.0.2 is next to 127.0.0.1.

Ugh, I just send a separate mail.  Yes, it's clear why you
picked ::2.  Now IFF ::FFFF:a.b.c.d *MUST* be treated as 
IPv4 a.b.c.d by lists *and* clients, then ::FFFF:127.0.0.2
is the same as 127.0.0.2. 

You don't have that *MUST* yet, but it might make sense...

 Frank
Permalink | Reply | 12 comments |
headers
Larry M. Smith | 20 Jul 2008 20:01

Re: Another dnsbl draft, now standards flavored

John Levine wrote:
> The IESG has expressed interest in my dnsbl draft turning into a 
> standards track RFC rather than informational.  I've done another 
> version of it to make it read like a standard, and there's also a few 
> places where I invented some standard practices, e.g., standard test 
> entries for IPv6 DNSBLs.  Take a look, tell us if I got anything 
> seriously wrong.
> 
> We're in the I-D blackout period, so I've posted xml, html, and txt at 
> http://www.taugh.com/dnsbl
> 
> In related news, there WILL be an ASRG session in Dublin.  Who other 
> than me is planning to be there?
> 

I realize that its been years since I have provided any input on this 
document...  I do have some questions, perhaps they are better late than 
never.

--8<-----------------------------------------------------------------

 > 2.1.  IP address DNSxL
 >
[...]
 > If a range of addresses is listed in the DNSxL, the DNSxL MUST
 > contain an A record (or a pair of A and TXT records) for every
 > address in the DNSxL.  Conversely, if an IP address is not listed in
 > the DNSxL, there MUST NOT be any records for the address.
[...]
(Continue reading)

Permalink | Reply | 4 comments |
headers
SM | 20 Jul 2008 20:33

Re: Another dnsbl draft, now standards flavored

At 20:10 19-07-2008, John Levine wrote:
>We're in the I-D blackout period, so I've posted xml, html, and txt 
>at http://www.taugh.com/dnsbl

The is an ongoing discussion about posting I-Ds during this 
period.  I assume that this is the version that will be discussed in Dublin.

As the intended status is now Standard Track, it would be good to 
review the IPv6 angle.  Currently, there's only Section 2.4 that covers IPv6.

Regards,
-sm
Permalink | Reply | 0 comments |
headers
John Levine | 21 Jul 2008 00:39

Re: Another dnsbl draft, now standards flavored

>Ugh, I just send a separate mail.  Yes, it's clear why you
>picked ::2.  Now IFF ::FFFF:a.b.c.d *MUST* be treated as 
>IPv4 a.b.c.d by lists *and* clients, then ::FFFF:127.0.0.2
>is the same as 127.0.0.2. 

I don't see that in the IPv6 documents, and in any event, this draft
is about DNSBLs, not IPv6 theology.

As I read it, if you want to embed v4 addresses in v6, here's where
you do it, but in fact nobody does.

R's,
John
Permalink | Reply | 11 comments |
headers
John Levine | 21 Jul 2008 00:42

Re: Another dnsbl draft, now standards flavored

>Currently DNSBLs are seeing a fair amount of requests for AAAA records. 
>  I'm currently wondering if these could/should be treated as requests 
>for A records, as it is quite possible that the DNSBL client is 
>completely unaware that these requests are being done by the resolver.

Hmmn.  What AAAA record would you return?  This strikes me as a place
where, if anything, the draft should be clearer that the values are
always A records, not do something kludgy for the benefit of unknown
broken software.

>Perhaps something could be said to warn about the domain name 
>aftermarket, and that clients might want to quantify the return values 
>to ensure that A records exist within 127/8.  Historically domain names 
>hosting the DNSBL have expired and the new owners install wild-card records.

That's the point of the MUST/MUST NOT tests described later.

> > 2.3.  Combined IP address DNSxL

>Perhaps a recommendation that DNSBL operators not combine there IPv4 and 
>IPv6 lists, instead using sublists for each could be inserted here.

Why not?  As it says later, if you want to use the same zone for v4 and
v6 addresses, it'll work OK since there's no overlap in the names.

> > A few name-based DNSBLs encode e-mail addresses using a convention
> > adapted from DNS SOA records, with the mailbox name encoded as the
> > first component of the domain name, so an entry for fred <at> invalid.edu
> > would have the name fred.invalid.edu.doms.example.net:
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Frank Ellermann | 21 Jul 2008 07:29
Picon
Picon

Re: Another dnsbl draft, now standards flavored

John Levine wrote:

> A list needs to be either all domains or all 
> e-mail addresses.  Do we need to call that out?

You could remove the concept of "e-mail" lists,
I wouldn't miss it for a second.  Twisting local
parts into DNS labels is black magic, and with
quoted-strings it gets surreal.

Half of the SPF-EAI draft argues non-stop why
this is a bad idea, a security issue, won't work
with some less capapable DNS APIs designed for
(roughly) LDH + underscore, an interoperability
nightmare (e.g., semantic content of quoted-pair,
embedded dots), and generally the worst part in
SMTP, EAI, and SPF.

 Frank
Permalink | Reply | 2 comments |

Gmane