SORBS on autopilot?

Fri Jan 15 17:26:12 UTC 2010

Michelle,

-- 
Paul

In the beginner's mind there are many possibilities, but in the expert's mind there are few.
Shunryu Suzuki

On Fri, 15 Jan 2010, Michelle Sullivan wrote:

> That is my view, however most (if not all) of the tickets were for the /22 
> not the /32 which is why it was rejected.

On all of my tickets but one the robot said:

"I've analyzed the following IP space, based on the text of your
request:

67.196.137.188/32"

>
>> From your email, it is my understanding this should have went to a human. I 
>
> So go back to the robot response and tell me where it says it'll be sent to a 
> human...please...?

Until you told me it was going to a human, I didn't know.  In fact, I only 
replied to the robot out of frustration; who would reply to a robot 
expecting a different answer the second time?

Its been 10 days without a response, maybe my ticket got caught up some 
where?

>> -kind of leaping to conclusions here, but possibly the robot is caching 
>> DNS?  Which means even if what was broken had been fixed, the robot 
>> wouldn't see it?
>
> The robot caches results for 48 hours to prevent people launching DoS attacks 
> on our systems as well as yours.  The results are easily checked here:
>

Perhaps require them to login.

> http://nemesis.sorbs.net:82/<first octet>/<second octet>/<network>.txt
>
> eg:
>
> http://nemesis.sorbs.net:82/67/196/67.196.137.0.txt
>

Access to this would have helped a lot.  Atleast I would have had some 
place to start.  I see the last scan was on Jan 12th.  I see an error I 
can't really account for.

> In this case you can easily see why the robot was unable to process the 
> request...  PTR's were requested from the nominated authoritive servers, only 
> to receive a "NODATA" response (commonly seen if TCP responses are required 
> or CNAMEs are returned without the PTR.)
>
> There is an issue with the robot and some correctly assigned classless 
> delegations due to the way we process the data, there are various catches to 
> correct this and re-process the network with a more reliable (but 
> considerably more resource hungry) method.  Unfortunately it's not fool proof 
> though, which is why we tell people to respond to the robot response to get a 
> human to review it.  If anyone out there is knowledgable in Perl, C and DNS 
> and wants to take a shot at fixing that issue I'd love to have the help.

I seem to have gotten caught in a corner case then?  Because as far as I 
can see everything is setup correctly on my end.

Your help would be appreciated.

>
> Michelle
>