paul wrote:
Michelle,
Thanks for your email. Please specifically look at ticket 260695. I created the ticket on January 5th at about 1:30EST. Immediately I got my response from the robot.
See my other message in addition.
I replied a few minutes later with:
67.196.137.188/32
TTL is right. PTR is right.
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.
From your email, it is my understanding this should have went to a human. I have no idea why my IP address wasn't accepted in the first place. And I have no idea why I didn't get a human response.
So go back to the robot response and tell me where it says it'll be sent to a human...please...?
A couple suggestions: -program the robot to give the exact reason why it is denying: TTL wrong or PTR indicates dynamic or whatever
It does give several responses, however the more exact the response the more issues we have had with people not understanding the reply. Our response has been to format the message with a link to the FAQ where there is a lot more of a detailed response. I will review the response with your suggestions and see if we can change it to some sort of compromise.
-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: http://nemesis.sorbs.net:82/<first octet>/<second octet>/<network>.txt eg: http://nemesis.sorbs.net:82/67/196/67.196.137.0.txt 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. Michelle