[Asrg] Round 2 of the DNSBL BCP

[Matthew Sullivan]

Andrew D Kirch wrote:
> Chris Lewis wrote:
>   
>> 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.
>>     

As others indicated 'RHSBl'?

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

Yeah I know what you are saying but really do you want to have people 
start coding 'the DNSbl is shutdown if this does 127.0.0.2 does not exist'

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

The point I'm trying to make is that the presence of a test entry or not 
should not indicate any issue other than simple oversight or possible 
problem.  On the other hand I do agree that we need to come to some 
agreement that will cause a server or other automated process to 
discontinue using a DNSbl when instructed by way of a special return.  
Possible options I can see are:

Choose a specific entry to return for 'shutdown' ... suggestions so far:

127.0.0.2 when it doesn't exist. <- I disagree with this - reasons below
127.0.0.1 when returns positive. <- I disagree with this as 127.0.0.1 is 
undesirable in most DNSbl's but it is not an error.
255.255.255.255 when returns positive (my suggestion).
When *any*  lookup returns an address *not* in 127.0.0.0/8.  (This will 
catch all expired domains etc) <- don't recall the source, but would 
also be very agreeable to me.

> I've generally agreed with you, but I think this is a pretty low 
> barrier, and can fix issues for DNSBL's trying to shut down, especially 
> with third party software that use DNSBL's to filter spam.
>   

Each is entitled to their comments, I have no problem in a disagreement, 
I just think there are better ways that would not impact due to simple 
oversight or error.  We are looking for a definitive "see this behavior 
and drop this from the config" command/result if we use something simple 
it will negatively impact a lot of users in the event of a simple 
mistake.  Think on this - those who list the world... if they knew to 
use an address other than in 127.0.0.0/8 I'm sure they would have (even 
in OSIRU's case).  In the event of sitefinder morons and other similar 
DNS hijackers, the return of a valid (as in a routable/non RFC 1918) IP 
would cause the software to stop using the DNSbl/DNSbl results, rather 
than "listing the world".  Relying on the presence of 
2.0.0.127.some.domain to return an IP when valid means when the DNS is 
hijacked by a 'sitefinder' the world+dog is listed.


Does that explain my reasoning and persistence on the issue a bit more?

/ Mat