[Asrg] Round 2 of the DNSBL BCP

[Matthew Sullivan]

Chris Lewis wrote:
> Matthew Sullivan wrote:
>
>   
>> SORBS has listed 127.0.0.1 in the past, though never used it as a return 
>> code.  It occurred due to error, but it was an easy one - the relay 
>> tester was triggered to test localhost by someone first setting up an 
>> open relay then sending spam, then within hours changing the DNS record 
>> to return 127.0.0.1 for the host.  Result, a request for a valid 
>> hostname was put in the system then before it was tested someone changed 
>> the target IP to localhost.  This was fixed fairly promptly but it was 
>> not an indicator of a shutdown.  I believe other DNSBls have listed 
>> 127.0.0.1 on occasion.
>>     
>
> I think I've figured out how this supposed to be said (pardon the raw 
> XML). 

Ugh! ;-)


> As for accidental listings - perhaps we should say something about 
> "SHOULD implement coding checks in DNSBLs" to avoid listing of bits that 
> the DNSBL isn't supposed to?  That would go in the section about 
> reserved et. al.
>
> What do you think of this version?
>
> <t>Most DNSBLs follow a convention of entries for IPs in
> 127.0.0.0/8 (127.0.0.0-127.255.255.255) to
> provide online indication of whether the DNSBL is operational.
> Many DNSBLs arrange to have a query
> of 127.0.0.2 return an A record indicating that the IP is listed.
> See <xref target="DNSBL-EMAIL" /></t>
>
> <t>If this indicator is missing (query of 127.0.0.2 returns NXDOMAIN),
> the DNSBL should be considered non-functional.</t>
>   

No - there are a few that do not have that address at the moment (they 
probably should), but as another example - autoexpiry of the SORBS Proxy 
DBs wiped out the test entrys until I hardcoded them in the DNSBl export 
script to put the entries in regardless of a matching lookup. Consider 
the following (not the wording, only the intent):

 If 127.0.0.2 is missing the user should look at the status of the DNSbl 
as it MAY be due to zone shutdown.

> <t>Note: In <xref target="down" /> it is noted that some DNSBLs
> have shut down in such a way to list all of the Internet.  Further,
> in <xref target="reserved" />, DNSBL operators MUST NOT list
> 127.0.0.1.  Therefore, a positive listing for 127.0.0.1 SHOULD
> also be an indicator that the DNSBL is non-functional.</t>
>   

Well the accidental inclusion of 1.0.0.127.dnsbl.sorbs.net did not 
indicate the DNSbl was non-functional, which is why I suggested using 
either 255.255.255.255/32 (or earlier 0.0.0.1/32) the former is 
theoretically impossible as a valid *usable* host address, the latter 
is, just as 127.0.0.1, is a valid address.

> <t>Other results, such as 127.0.0.3, may have different meanings.
> This operational flag usage and meaning SHOULD be published on the
> DNSBL's web site, and the DNSBL user SHOULD periodically test the
> DNSBL.</t>
>   

Agreed, though that is a client operation rather than a DNSBl operation. 
(The other BCP/RFC/Section?)


>>>>>    Some mail systems are unable to differentiate between these various
>>>>>    results or flags, however, so a public DNSBL MUST NOT include
>>>>>    opposing or widely different meanings -- such as 127.0.0.23 for
>>>>>    "sends good mail" and 127.0.0.99 for "sends bad mail" -- within the
>>>>>    same DNS zone.
>>>>>       
>>>>>           
>>>> Not sure why this is a MUST NOT. If people are dumb enough to use a  
>>>> mixed list in a broken way they get what they deserve. What's the  
>>>> justification?
>>>>     
>>>>         
>>> "Suicidal administrator" prevention.  JD suggested it.  I like it, but 
>>> I'm not committed to it.  Thoughts?
>>>       
>
>   
>> I disagree, simply:  not in the same zone - but no problem with the same 
>> DNSBl.
>>     
>
> Would a SHOULD NOT instead be sufficient?  A reword is probably better.
>   

I did not read it correctly the first time around - read as 'the same 
DNSbl' - not as 'the same DNS zone'

Regards,

Mat