You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "David F. Skoll" <df...@roaringpenguin.com> on 2011/12/13 15:21:47 UTC
DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default
as of tomorrow)
I think we need an informational RFC that specifies best-practices for
a DNS{B,W}L to inform clients that they have been blocked.
For example, a testpoint like:
blocked.dnsbl.example.org
could return an A record for name servers that are blocked and NXDOMAIN
for others. This might even work out-of-the-box for some existing lists
that return an A record for any query (or it may not, if they expect
a reverse-dotted-quad.)
It could even return a TXT record giving the reason for the block.
Anyway, assuming this idea is widely-accepted (hahaha!), it would be pretty
easy to make something that periodically tests your list of DNSBLs and
disables those that are blocking your query.
Regards,
David.
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default
as of tomorrow)
Posted by Axb <ax...@gmail.com>.
On 2011-12-13 15:21, David F. Skoll wrote:
> I think we need an informational RFC that specifies best-practices for
> a DNS{B,W}L to inform clients that they have been blocked.
>
> For example, a testpoint like:
>
> blocked.dnsbl.example.org
>
> could return an A record for name servers that are blocked and NXDOMAIN
> for others. This might even work out-of-the-box for some existing lists
> that return an A record for any query (or it may not, if they expect
> a reverse-dotted-quad.)
>
> It could even return a TXT record giving the reason for the block.
>
> Anyway, assuming this idea is widely-accepted (hahaha!), it would be pretty
> easy to make something that periodically tests your list of DNSBLs and
> disables those that are blocking your query.
there is a BCP for BLs floating around which addresses some if not all
of this... MAAWF, RFC.. not sure which
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default
as of tomorrow)
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 12/13/2011 9:21 AM, David F. Skoll wrote:
> I think we need an informational RFC that specifies best-practices for
> a DNS{B,W}L to inform clients that they have been blocked.
>
> For example, a testpoint like:
>
> blocked.dnsbl.example.org
>
> could return an A record for name servers that are blocked and NXDOMAIN
> for others. This might even work out-of-the-box for some existing lists
> that return an A record for any query (or it may not, if they expect
> a reverse-dotted-quad.)
>
> It could even return a TXT record giving the reason for the block.
>
> Anyway, assuming this idea is widely-accepted (hahaha!), it would be pretty
> easy to make something that periodically tests your list of DNSBLs and
> disables those that are blocking your query.
This was mentioned as a possibility and it's a good idea.
But from SA's perspective, though, it means that it requires code. And
the big issue is NOT the delays. The big issue is the purposefully wrong
answers.
The code-requirement for a fix means that this new policy is delayed at
least 6 months after a major release for SA based on
http://wiki.apache.org/spamassassin/ReleaseGoals. So if we miss this
code getting into 3.4.0, that means it waits until 3.5.0 (or 4.0.0) + 6
months. If someone wants to submit code to actually do it, that'd be
great. But it's a got a delay before it matters either way.
I've opened a ticket
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6724 towards an
immediate solution.
regards,
KAM
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by
default as of tomorrow)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Wed, 14 Dec 2011 10:24:47 +0100
Benny Pedersen <me...@junc.org> wrote:
> good intention, but if dns is blocket there is no result anyway so it
> does not work
If DNS is completely blocked, then there's not much harm done. If a DNSBL
returns a hit for any query, then there's a lot of harm done and there should
be a way to let a client know.
Regards,
David.
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by
default as of tomorrow)
Posted by Benny Pedersen <me...@junc.org>.
On Wed, 14 Dec 2011 10:18:52 -0500, Kevin A. McGrail wrote:
> Not quite. We are working on return codes that lead to the end the
> purposefully wrong answers for DNSBLs so Blocked doesn't mean
> blackholing the requests. Confusing, I know.
yes, its a hell out there in dns world, rbldnsd only support udp while
bind required udp/tcp on top of that some severs still blackhole my ipv4
address in there dns servers, if that does not get better i will simply
disable DNSEval plugin in future
sorbs still use rbldnsd as front end servers :(
who can send me a named.conf that ONLY do queryes with udp ?
might be more simple just disable DNSEval :(
and now today my asus eee 1001ha does not boot windows xp, super that i
still have another asus eee that works, eee PC 2G Surf (512M mem, 2048M
harddisk, win xp)
it host freenas very well on that hardware
>
> Regards,
> KAM
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default
as of tomorrow)
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 12/14/2011 4:24 AM, Benny Pedersen wrote:
> On Tue, 13 Dec 2011 09:21:47 -0500, David F. Skoll wrote:
>> I think we need an informational RFC that specifies best-practices for
>> a DNS{B,W}L to inform clients that they have been blocked.
>
> good intention, but if dns is blocket there is no result anyway so it
> does not work
Not quite. We are working on return codes that lead to the end the
purposefully wrong answers for DNSBLs so Blocked doesn't mean
blackholing the requests. Confusing, I know.
Regards,
KAM
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by
default as of tomorrow)
Posted by Benny Pedersen <me...@junc.org>.
On Tue, 13 Dec 2011 09:21:47 -0500, David F. Skoll wrote:
> I think we need an informational RFC that specifies best-practices
> for
> a DNS{B,W}L to inform clients that they have been blocked.
good intention, but if dns is blocket there is no result anyway so it
does not work