[Asrg] Round 2 of the DNSBL BCP

[Chris Lewis]

Matthew Sullivan wrote:
> Chris Lewis wrote:

>> <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.

I do not think it onerous to suggest that existing DNSBLs that don't use 
127.0.0.2 should, and there is enough current practise to suggest it 
should be codified as a BCP.

Secondly, you'll notice I didn't say "considered shut down" or imply 
permanence.  If a DNSBL that publishes a 127.0.0.2 diagnostic _stops_ 
doing it, it is indeed operating out of specification (eg: what else is 
going wrong?) at least temporarily, and probably shouldn't be used 
further until it starts signalling 127.0.0.2 properly again.

By stating it this simply, it encourages automation, so if something 
breaks down, email servers _could_ automatically stop trusting the returns.

>> <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,

The wording above repeated - it was out of specification, and the rest 
of it is in doubt.  And in some situations it will cause unintended 
blocking.

It's not too onerous IMO to expect DNSBLs to do such elementary basic 
checking.

> 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.

Nobody is doing that - I don't want to suggest something too new.
> 
>> <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?)

This isn't the only MUST/SHOULD aimed at the DNSBL user, and I think 
it's important in this context.  Tho, it'd be repeated in a "using 
DNSBLs" BCP (if there ever was one).

>>>>>>    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'

Okay, I'll leave it alone for now.