Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default as of tomorrow)
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
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default as of tomorrow)
On Wed, 14 Dec 2011 10:24:47 +0100 Benny Pedersen m...@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)
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)
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)
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)
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