Bug 6724

(In reply to comment #0)

> 1 - Block/do not respond to queries so that no rules misfire purposefully. 
> This is the current policy.

This causes about 300% increase in query volume, as noted in https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6048#c23 et al.

> - The message on the rule would have to link to a generic page on SA's wiki
> regarding "free for some" services and would be uniform for all BLs.  It will
> specifically NOT lead to a subscription page for a vendor as SA is not an
> advertising service.

If the message would be returned by the DNSxL (as TXT record), that would assume the DNSxLs are only serving SA users. 

The SA-specific link can appear if it is generated by SA (eg as a result of detecting a "blocked" return value). 

> This solution could be implemented in current SA releases with a rules update

That is basically the idea behind bug 6668 which was for some reason not pursued further.

I've created an anchor link about this issue at:

http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block

Matthias, are you able to block/return no answers or return a last octet of 255 as a blocked answer.  And NOT return purposefully wrong answers?

If so, a rule like this would work, yes?

ifplugin Mail::SpamAssassin::Plugin::DNSEval
  header  RCVD_IN_DNSWL_BLOCKED        eval:check_rbl_sub('dnswl-firsttrusted', '^127\.0\.\d+\.255$')
  describe RCVD_IN_DNSWL_BLOCKED       ADMINISTRATOR NOTICE: The query to DNSWL was blocked.  See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information.
  score  RCVD)IN_DNSWL_BLOCKED         0.001
  tflags RCVD_IN_DNSWL_BLOCKED         nice net
endif

FYI, per URIBL:

We block at the bind level with split horizon.  So we return an NS record which resolves to 127.0.0.255.   So a recursive NS would receive that NS record and have no where else to go.  Effectively black holing it.  Perhaps this should be changed to something other than 127.0.0.255 to avoid confusion... maybe 127.0.0.1 would be better, or 127.0.0.0.

We do not respond with REFUSED at the bind level, as that just creates unnecessary added volume.

The only reason we use acl.rbldnsd at the rbldnsd level is to :refuse queries that are made directly to the rbldnsd nodes.  So if someone tries to bypass the split-horizon response upstream by hard-coding known good public mirrors IPs, they will still get a :refuse.


So the policy differs from implementation and hopefully URIBL will follow suit with a BLOCKED rule as noted above.

(In reply to comment #2)

> Matthias, are you able to block/return no answers or return a last octet of 255
> as a blocked answer.  And NOT return purposefully wrong answers?

Technically, we can return whatever rbldnsd can return, ie any A value. 

> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>   header  RCVD_IN_DNSWL_BLOCKED        eval:check_rbl_sub('dnswl-firsttrusted',
> '^127\.0\.\d+\.255$')

I would prefer an occasional lookup to "blocked.example.org" (or even "status.example.org" returning a number of HTTP-like status codes), but I agree with the comment made elsewhere that it takes non-trivial amount of code to implement this. 

As a second-best solution, the ..._BLOCKED is probably OK. Just the last octet as 255 is possibly not very unique for other lists. Would 127.255.255.255 stand out more? 

>   tflags RCVD_IN_DNSWL_BLOCKED         nice net

Possibly also avoid autolearning?

(In reply to comment #3)
> FYI, per URIBL:
> 
> We block at the bind level with split horizon.  So we return an NS record which
> resolves to 127.0.0.255.   So a recursive NS would receive that NS record and
> have no where else to go.  Effectively black holing it.  Perhaps this should be
> changed to something other than 127.0.0.255 to avoid confusion... maybe
> 127.0.0.1 would be better, or 127.0.0.0.
> 
> We do not respond with REFUSED at the bind level, as that just creates
> unnecessary added volume.
> 
> The only reason we use acl.rbldnsd at the rbldnsd level is to :refuse queries
> that are made directly to the rbldnsd nodes.  So if someone tries to bypass the
> split-horizon response upstream by hard-coding known good public mirrors IPs,
> they will still get a :refuse.
> 
> 
> So the policy differs from implementation and hopefully URIBL will follow suit
> with a BLOCKED rule as noted above.

till SA does some magic, one could add a ruleset like:

urirhssub       URIBL_BLACK_BLOCKED   multi.uribl.com.        A   255
body            URIBL_BLACK_BLOCKED   eval:check_uridnsbl('URIBL_BLACK_BLOCKED')
describe        URIBL_BLACK_BLOCKED   DNS IP blocked from querying URIBL.com
tflags          URIBL_BLACK_BLOCKED   net
score           URIBL_BLACK_BLOCKED   -1.8

urirhssub       URIBL_GREY_BLOCKED    multi.uribl.com.        A   255
body            URIBL_GREY_BLOCKED    eval:check_uridnsbl('URIBL_GREY_BLOCK')
describe        URIBL_GREY_BLOCKED    DNS IP blocked from querying URIBL.com
tflags          URIBL_GREY_BLOCKED    net
score           URIBL_GREY_BLOCKED    -0,5

urirhssub       URIBL_RED_BLOCK       multi.uribl.com.        A   255
body            URIBL_RED_BLOCK       eval:check_uridnsbl('URIBL_RED_BLOCK')
describe        URIBL_RED_BLOCK       DNS IP blocked from querying URIBL.com
tflags          URIBL_RED_BLOCK       net
score           URIBL_RED_BLOCK       0.001

That would get the message thru, without hurting

Created attachment 5018 [details]
Proposed Sandbox rules

The attached rules implement a blocked description for URIBL and DNSWL.

If DNSWL concurs that this will alleviate the need to block queries with purposefully wrong responses, we can re-enable DNSWL scoring by default.

Additionally, the next step that I believe all would like to see is code that monitors for these _BLOCKED rules and if they trigger, it stops similar lookups for 1 hour.

The bad part is that already we can see the deviation with two BLs.  One using DNSEval and one using URIDBSBL.

Anyone got a centralized concept they can think of for implementing a block?

Created attachment 5019 [details]
Revised Proposed Sandbox Rule

I'm unsure but I think we need to force publish the rule and set the score in 50_scores.cf rather than have this go through masscheck.

(In reply to comment #7)
> Created attachment 5019 [details]
> Revised Proposed Sandbox Rule
> 
> I'm unsure but I think we need to force publish the rule and set the score in
> 50_scores.cf rather than have this go through masscheck.


+1 to: 25_uribl.cf & 50_scores.cf

(In reply to comment #8)
> (In reply to comment #7)
> > Created attachment 5019 [details]
> > Revised Proposed Sandbox Rule
> > 
> > I'm unsure but I think we need to force publish the rule and set the score in
> > 50_scores.cf rather than have this go through masscheck.
> 
> 
> +1 to: 25_uribl.cf & 50_scores.cf

I'd prefer to keep the block rules together so they are uniform rather than split them per RBL.  Perhaps 25_dnsbl_block.cf & 50_scores.cf?

score URIBL_BLACK_BLOCKED 0.001
score URIBL_GREY_BLOCKED 0.001
score URIBL_RED_BLOCK 0.001

Wouldn't URIBL_BLACK / URIBL_GREY / URIBL_RED also hit, whenever those hit, due to them being urirhssub rules with "a single decimal or hex" value, so it's checking for a bit mask, not equality?
So we'd need scores that negate the scores of the URIBL rules?

score URIBL_BLACK_BLOCKED 0 -1.775 0 -1.725
score URIBL_GREY_BLOCKED 0 -1.084 0 -0.424
score URIBL_RED_BLOCKED -0.001

(In reply to comment #10)
> score URIBL_BLACK_BLOCKED 0.001
> score URIBL_GREY_BLOCKED 0.001
> score URIBL_RED_BLOCK 0.001
> 
> Wouldn't URIBL_BLACK / URIBL_GREY / URIBL_RED also hit, whenever those hit, due
> to them being urirhssub rules with "a single decimal or hex" value, so it's
> checking for a bit mask, not equality?
> So we'd need scores that negate the scores of the URIBL rules?
> 
> score URIBL_BLACK_BLOCKED 0 -1.775 0 -1.725
> score URIBL_GREY_BLOCKED 0 -1.084 0 -0.424
> score URIBL_RED_BLOCKED -0.001

what I sugegsted above...

(In reply to comment #10)
> score URIBL_BLACK_BLOCKED 0.001
> score URIBL_GREY_BLOCKED 0.001
> score URIBL_RED_BLOCK 0.001
> 
> Wouldn't URIBL_BLACK / URIBL_GREY / URIBL_RED also hit, whenever those hit, due
> to them being urirhssub rules with "a single decimal or hex" value, so it's
> checking for a bit mask, not equality?
> So we'd need scores that negate the scores of the URIBL rules?
> 
> score URIBL_BLACK_BLOCKED 0 -1.775 0 -1.725
> score URIBL_GREY_BLOCKED 0 -1.084 0 -0.424
> score URIBL_RED_BLOCKED -0.001

Hmm, isn't 255 a bitmask of all the other bits?  We need a response such as 16 or 32 or something that is a single bit.  That way we can fire ONLY the block rule otherwise we aren't meeting the parameters of Solution 2.

The response from the RBL cannot fire off other rules as it is untenable to try and maintain opposite abs scores.

On the users list Dave Warren suggested checking a test value on the DNSxLs to determine if they should be used.  I just wanted to point out there's some related stuff in an RFC:  

"IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes.  IPv4-based DNSxLs MUST NOT contain an entry for 127.0.0.1."
- http://tools.ietf.org/html/rfc5782#section-5

Maybe it would be appropriate to interpret intentional non-conformance with that as indication that you're being blocked, or for any other reason you should not use that list.  Seems like it might be more useful to test for a value for 127.0.0.2 instead of a lack of a value for 127.0.0.1, so it would do the right thing if all queries are blocked.

I'm not arguing for or against either method, just pointing out relevant contents of an RFC.  I'm still curious where this state is going to get stored.

Steve Freegard pointed out on IRC this additional bit of relevant BCP draft:

http://tools.ietf.org/html/draft-irtf-asrg-bcp-blacklists-10#section-3.4

   Note: In Section 3.4 it is noted that some DNSBLs have shut down in
   such a way to list all of the Internet.  Further, in Section 3.5,
   DNSBL operators MUST NOT list 127.0.0.1.  Therefore, a positive
   listing for 127.0.0.1 SHOULD indicate that the DNSBL has started
   listing the world and is non-functional.  Similarly, a domain-based
   DNSBL SHOULD NOT ever list the reserved domain INVALID, and a
   positive listing for INVALID SHOULD indicate that the DNSBL is non-
   functional.

He also pointed out that it's only a draft.  

There's also:  "If this indicator is missing (query of 127.0.0.2 returns NXDOMAIN), the DNSBL should be considered non-functional."

Hmm, I don't like the idea of maintaining a set a negated scores. The following approach avoids this. Also, we really only need a single BLOCKED indicator rule, not three.

  urirhssub URIBL_BLOCKED multi.uribl.com. A 255

  meta URIBL_$(color)  __URIBL_$(color) && ! URIBL_BLOCKED

Plus, of course, rename the current rules to make them non-scoring sub-rules as used in the above meta.

An alternative to the meta rule method above, the existing urirhssub rules might simply be changed to use another available option as subtype, instead of the current bitmask. Particularly, if a single URI will not be listed in multiple colors, an exact dot-quad would do easily instead of the bitmask.


Just avoid the rules triggering on the BLOCKED value. Exclude that, don't add more rules to negate scores.

An additional benefit is, that along with the BLOCKED rule hitting, the admins might eventually wonder why the DNSBL itself never hits. (The approach with negative scores will make the DNSBL appear to be stunningly effective glimpsing over the stats.)

RE - Comment #14:  We don't have to rely on a draft but can rely on the most current published RFC (5782) on the topic which says the same thing.  Presumedly, the cited draft would update or obsolete that RFC.

The issue then becomes:  Should we drop any use of a DNS-based-list which does not follow follow RFC 5782 (and its successors), especially when they return codes in the 127/8 range which are not meant to be actual determinations of the data they contain?  I say yes.  From RFC 1035, refusal to answer should be signalled with a "REFUSED" query RC, but if data were returned, it should indicate an A record with an address OUTSIDE of 127/8.  I would personally suggest to these DNS-list maintainers returning "0.0.0.0" to indicate a non-response.  All-zeros makes sense for a "null answer."  Defining a "non-response due to abuse" code within 127/8 is irresponsible considering the BCP of the RFC.

In a prior post (in a related issue), I did consider (and rejected the decision) that SA test for validity all DNS-lists upon startup by querying for "127.0.0.1" (NXDOMAIN or 0 answers expected) and "127.0.0.2" (1+ answer(s) expected).  I rejected that position because if the entire world (or a significant portion) rebooted at once, we would effectively be executing a denial of service attack (by flooding) on the DNS-lists.

OK, so URIBL has asked to use bit 1 and changed their ACL so if they return a block, bit 1 is used.

I updated 25_uribl.cf to include their block rule and a score of 0.001 in 50_scores.cf.

#URIBL BLOCK RULES - Bit 1 means your DNS has been blocked and this rule should be triggered to notify you.
urirhssub       URIBL_BLOCKED   multi.uribl.com.        A   1
body            URIBL_BLOCKED   eval:check_uridnsbl('URIBL_BLOCKED')
describe        URIBL_BLOCKED   ADMINISTRATOR NOTICE: The query to URIBL was blocked.  See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information.
tflags          URIBL_BLOCKED   nice net noautolearn

Also updated http://wiki.apache.org/spamassassin/DnsBlocklists#preview to include a link to URIBL.

svn commit -m 'Implementation of a proposed Block Notification Rule for URIBL using bit 1 - Bug 6724' rules
Sending        rules/25_uribl.cf
Sending        rules/50_scores.cf
Transmitting file data ..
Committed revision 1213921.



Matthias, if you can decide on a bit (not a bitmask) to return for DNSWL blocks, we can add the notification rule.  

And if this moves you to change your decision to implement the purposefully wrong DNS response, we can move DNSWL back to default configuration.

Then we'll keep the ticket open and perhaps someone can work on a way to make spamd recognize that the BLOCK rule is triggered and hold off on subsequent DNSBL queries for 1 hour.

(In reply to comment #17)
> OK, so URIBL has asked to use bit 1 and changed their ACL so if they return a
> block, bit 1 is used.

Makes sense with the URIBL return values, and prevents any other rule from triggering at the same time. Obsoletes any rule adjustments per comment 15.

> Matthias, if you can decide on a bit (not a bitmask) to return for DNSWL
> blocks, we can add the notification rule.  

Since the BLOCKED indicating return value is entirely non-standard, we are free to pick any value that fits the DNSxL.

DNSWL return values for the last octet are not bitmask encoded, and the SA rules use exact matching. Thus, *any* unused return value in 127/8 is possible. No need to decide on a single bit, but a number, including 255.

"... hold off on subsequent DNSBL queries for 1 hour."

I just made a suggestion to the authors of the above cited draft, and in my suggestion, I indicated that perhaps queries to the offending DNS-based list be disabled until reconfiguration or manual restart without a time limit.  We don't know what time quantum the list maintainer may hae selected over which to determine excessive queries or even if such is a constant (vs. lengthened periods for each time a query source is blocked, including "permanently").  Although one hour may be reasonable for a "first" test after detecting a problem, maybe subsequent retries after continued failure should be much later.  In that respect, I suggest starting with 1 hour, but then add half the time for each subsequent failure, producing a series:  1, 1.5, 2.25, 3.375, 5.0625, ....

(In reply to comment #19)
> "... hold off on subsequent DNSBL queries for 1 hour."
> 
> I just made a suggestion to the authors of the above cited draft, and in my
> suggestion, I indicated that perhaps queries to the offending DNS-based list be
> disabled until reconfiguration or manual restart without a time limit.  We
> don't know what time quantum the list maintainer may hae selected over which to
> determine excessive queries or even if such is a constant (vs. lengthened
> periods for each time a query source is blocked, including "permanently"). 
> Although one hour may be reasonable for a "first" test after detecting a
> problem, maybe subsequent retries after continued failure should be much later.
>  In that respect, I suggest starting with 1 hour, but then add half the time
> for each subsequent failure, producing a series:  1, 1.5, 2.25, 3.375, 5.0625,
> ....

I like the exponential delay but something like 5% extra instead of 50% might be better.  Otherwise in just one day, you are going to have massive retry delays.  

Plus 1 query per hour = 24 queries a day versus over 100K per day.  I think 1 per hour is going to be a really good number to start with and won't need much modification.

> Matthias, if you can decide on a bit (not a bitmask) to return for DNSWL
> blocks, we can add the notification rule.  

Based on KB's notes, 255 is acceptable for DNSWL because it's not implemented with a bitmask.
 
> And if this moves you to change your decision to implement the purposefully
> wrong DNS response, we can move DNSWL back to default configuration.
> 
> Then we'll keep the ticket open and perhaps someone can work on a way to make
> spamd recognize that the BLOCK rule is triggered and hold off on subsequent
> DNSBL queries for 1 hour.

I have no problem with a different exponential or geometric based delay value between 1.0 and 1.5.  However, consider that some list may base its timeout from a ban list not on how long a query source has been listed (i.e. the first query) but on how much time has passed since the last query attempt.  Such would favor a greater rate of delay increase in finding the appropriate window where queries are once again allowed.  5% is too low for that case.  Let's make it adminstrator configurable with a default of 10% (or a multiplier 1.1/check-cycle).

(In reply to comment #17)
> tflags          URIBL_BLOCKED   nice net noautolearn

tflags nice documentation: "The test is intended to compensate for common false positives, and should be assigned a negative score."

Correct on the FP part (false positive rule hit, in this case, not overall classification). Has an informative *positive* score of 0.001 though. ;)

OK, not actually an issue I guess, since it kind of describes the intention regardless of strictly following the docs to the letter.


However, the committed rule probably lacks the reuse flag. All other URIBL rules have it set. Missing the reuse flag on the BLOCKED rule would cause the DNSBL queries to be performed during mass-check, no?

(In reply to comment #17)

> Matthias, if you can decide on a bit (not a bitmask) to return for DNSWL
> blocks, we can add the notification rule.  

As already pointed out in comment #21, we don't return a bitmask, but a simple/single value in the last octet. 127.0.0.255 is fine.

> And if this moves you to change your decision to implement the purposefully
> wrong DNS response, we can move DNSWL back to default configuration.

SA is not the only user of our public nameserver infrastructure, so there may still be abusive use of that infrastructure that requires measures above and beyond SA's _BLOCKED rule.

We will add measures against such situations to the dnswl.org zone to avoid that certain queries even reach the list.dnswl.org zone nameservers (similar to what presumably URIBL is doing).

Together, this makes it unlikely that we need to resort back to the "127.0.10.3" answer ever.

Implemented RCVD_IN_DNSWL_BLOCKED. Disabled by zero score override for now, just like the other DNSWL rules. To be enabled when bug 6718 gets reverted.

50_scores.cf: Moved the score lines for URIBL and DNSWL BLOCKED rules into their respective, existing (ifplugin guarded) sections. Scores now set for individual score-sets. Same for URIBL_RED.

25_uribl.cf: Fixed description, escaped the anchor hash in the URI. Added reuse option for URIBL_BLOCKED.

rulesrc/10_force_active.cf: Force publish the BLOCKED rules.

Committed revision 1214333.


The DNSWL rules file 70_dnswl.cf probably should be moved out of the sandbox eventually.

(In reply to comment #24)
> We will add measures against such situations to the dnswl.org zone to avoid
> that certain queries even reach the list.dnswl.org zone nameservers (similar to
> what presumably URIBL is doing).
> 
> Together, this makes it unlikely that we need to resort back to the
> "127.0.10.3" answer ever.

Awesome, thanks, Matthias. Got any idea when that response change might be done? I'd be happy to re-enable DNSWL once this is settled.

As a quick test case, ask Google's public DNS for it's own listing.

  dig @8.8.8.8 +short 8.8.8.8.list.dnswl.org

(In reply to comment #25)
> Implemented RCVD_IN_DNSWL_BLOCKED. Disabled by zero score override for now,
> just like the other DNSWL rules. To be enabled when bug 6718 gets reverted.

I'm pleased with Matthias' comments in #23 and I believe other PMC members are as well.

Matthias, are those changes implemented so we can re-enabled DNSWL?

> 50_scores.cf: Moved the score lines for URIBL and DNSWL BLOCKED rules into
> their respective, existing (ifplugin guarded) sections. Scores now set for
> individual score-sets. Same for URIBL_RED.
> 
> 25_uribl.cf: Fixed description, escaped the anchor hash in the URI. Added reuse
> option for URIBL_BLOCKED.
> 
> rulesrc/10_force_active.cf: Force publish the BLOCKED rules.
> 
> Committed revision 1214333.

Other than taking out the nice flag which I agreed with comments above likely shouldn't exist, looks good to me.  I am unsure if setting a score in 50_scores.cf AND the forcepublish is needed for 25_uribl.cf rules but I can't see how it hurts.  I was planning to do the same thing.

svn commit -m 'Removed nice flag on _BLOCKED rules'
Sending        rules/25_uribl.cf
Sending        rulesrc/sandbox/felicity/70_dnswl.cf

> 
> The DNSWL rules file 70_dnswl.cf probably should be moved out of the sandbox
> eventually.

I could make this argument for all of the sandbox rules that are published but that's a higher-level issue than for this ticket.

> Other than taking out the nice flag which I agreed with comments above likely
> shouldn't exist, looks good to me.  I am unsure if setting a score in
> 50_scores.cf AND the forcepublish is needed for 25_uribl.cf rules but I can't
> see how it hurts.  I was planning to do the same thing.

Frankly, dunno either. But I figured mimicking what's done for the excellent performing rules like URIBL_BLACK won't hurt for a rule not even supposed to ever hit in mass-checks. After all, we *want* these rules to be published.

> svn commit -m 'Removed nice flag on _BLOCKED rules'

Revision 1214416

> > The DNSWL rules file 70_dnswl.cf probably should be moved out of the sandbox
> > eventually.
> 
> I could make this argument for all of the sandbox rules that are published but
> that's a higher-level issue than for this ticket.

Agreed. Just mentioned it, since it's a complete rule-set file for DNSWL, similar to 25_uribl.cf, even featuring the copyright header.

(In reply to comment #27)

> Matthias, are those changes implemented so we can re-enabled DNSWL?

This will happen over the weekend, as I'm currently tied up in $DAYJOB.

(In reply to comment #2)

> http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
> 
> Matthias, are you able to block/return no answers or return a last octet of 255
> as a blocked answer.  And NOT return purposefully wrong answers?

As we speak, various updates are propagating to the mirrors. Significant abuser of the public nameserver infrastructure will now be redirected to a different view of the parent zone. This view is different from the main zone in the following ways:

* The SOA rname YOU.ARE.BLOCKED.FROM.dnswl.org. 
* The zone has a TXT RR "You are blocked from using list.dnswl.org through public nameservers"
* The "list" sub-zone does not have the a.ns, b.ns etc RRs, but only one: "you.are.blocked.from.using.dnswl.org.thorugh.public.nameservers.invalid."
* Has a TXT RR for quick-and-dirty manual testing: "amiblocked.dnswl.org" which contains "Yes".

This should avoid any unnecessary queries and limit collateral damage.

There are now no more entries that would return "high trust" result in cases where we want admins/operators to fix something on their end. 
  
>   header  RCVD_IN_DNSWL_BLOCKED        eval:check_rbl_sub('dnswl-firsttrusted',
> '^127\.0\.\d+\.255$')

We can basically return any A record, but will wait for the outcome of the discussion in bug 6728 (esp comment #11 suggesting the use of 0.0.0.0).

(In reply to comment #30)
> (In reply to comment #2)
> 
> > http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
> > 
> > Matthias, are you able to block/return no answers or return a last octet of 255
> > as a blocked answer.  And NOT return purposefully wrong answers?
> 
> As we speak, various updates are propagating to the mirrors. Significant abuser
> of the public nameserver infrastructure will now be redirected to a different
> view of the parent zone. This view is different from the main zone in the
> following ways:
> 
> * The SOA rname YOU.ARE.BLOCKED.FROM.dnswl.org. 
> * The zone has a TXT RR "You are blocked from using list.dnswl.org through
> public nameservers"
> * The "list" sub-zone does not have the a.ns, b.ns etc RRs, but only one:
> "you.are.blocked.from.using.dnswl.org.thorugh.public.nameservers.invalid."
> * Has a TXT RR for quick-and-dirty manual testing: "amiblocked.dnswl.org" which
> contains "Yes".
> 
> This should avoid any unnecessary queries and limit collateral damage.

Neat!

 
> There are now no more entries that would return "high trust" result in cases
> where we want admins/operators to fix something on their end. 
> 
> >   header  RCVD_IN_DNSWL_BLOCKED        eval:check_rbl_sub('dnswl-firsttrusted',
> > '^127\.0\.\d+\.255$')
> 
> We can basically return any A record, but will wait for the outcome of the
> discussion in bug 6728 (esp comment #11 suggesting the use of 0.0.0.0).


As the commit is already done checking for 127.0.X.255, this is a simple IP address change handled by sa-update AND we are already using another 127 bit for URIBL, I see no reason to hold things up based on Comment 11 at this time.  

If you can implement this with 127.0.0.255, then the blocked rule is already live and I can then turn back on the scoring for DNSWL.

Regards,
KAM

(In reply to comment #31)

> > This should avoid any unnecessary queries and limit collateral damage.
> 
> Neat!

There will be some finetuning necessary, as I see some resolvers being unhappy about the .invalid nameserver (doing three retries; I'll try out some variations over the next couple of days to assess impact & avoid collateral damage). 

> As the commit is already done checking for 127.0.X.255, this is a simple IP
> address change handled by sa-update AND we are already using another 127 bit
> for URIBL, I see no reason to hold things up based on Comment 11 at this time.  
> 
> If you can implement this with 127.0.0.255, then the blocked rule is already
> live and I can then turn back on the scoring for DNSWL.

Some are already receiving 127.0.0.255 (those asking the parent-zone nameservers directly), others will start to get them as soon as I switch it on (sometime tonight, I'm currently on the road).

(In reply to comment #31)
> If you can implement this with 127.0.0.255, then the blocked rule is already
> live and I can then turn back on the scoring for DNSWL.

Is there a reason not to re-enable DNSWL now?  It's no-longer violating SA requirements, right?  I wonder if you're assuming DNSWL doesn't want to be re-enabled in SA until blocking is handled, but I think Matthias wouldn't have commented what he did if that were the case.

(In reply to comment #32)
> There will be some finetuning necessary, as I see some resolvers being unhappy
> about the .invalid nameserver (doing three retries; I'll try out some
> variations over the next couple of days to assess impact & avoid collateral
> damage). 

I'm sure I'm not the only one interested in more information on that (and the increase in load you mentioned when returning the DNS rcode REFUSED).  Maybe on the dev list?

Aprogas in #bind on irc.freenode.net was trying to find somewhere in the RFCs a definition of how things are supposed to respond to various rejections (REFUSED, NXDOMAIN), as far as re-querying, and I don't think he found so much as a "SHOULD".  

Although re-querying when you've been told to go to the "invalid" tld seems more clearly broken.

(In reply to comment #33)
> (In reply to comment #31)
> > If you can implement this with 127.0.0.255, then the blocked rule is already
> > live and I can then turn back on the scoring for DNSWL.
> 
> Is there a reason not to re-enable DNSWL now?  It's no-longer violating SA
> requirements, right?  I wonder if you're assuming DNSWL doesn't want to be
> re-enabled in SA until blocking is handled, but I think Matthias wouldn't have
> commented what he did if that were the case.
> 

Agreed.  I already had it prepped ready to go:

svn commit -m 'Turning DNSWL back on now that they don not return FPs for abusive queriers - bug 6724'   
Sending        rules/50_scores.cf
Transmitting file data .
Committed revision 1220844.