Jump to content

More Ripe access denied


Recommended Posts

Spamcop server? got blocked today for a lookup of

whois 2.191.104.35[at]whois.ripe.net

with message

%ERROR:201: access denied for 184.94.240.95

%

% Sorry, access from your host has been permanently

% denied because of a repeated excessive querying.

% For more information, see

% http://www.ripe.net/data-tools/db/faq/faq-...1-access-denied

A manual whois finds:

...

% Abuse contact for '2.176.0.0 - 2.191.255.255' is 'R.javidi[at]tci.ir'

...

abuse-mailbox: ripe[at]dci.ir

abuse-mailbox: R.javidi[at]tci.ir

...

remarks: Please for any abuse report write to abuse[at]mail.dci.co.ir

That is a /12 block, which I would expect spamcop to keep cached information about. Also need to either convince ripe to allow (volume) exceptions for spamcop, or find a way to spread the load better to keep this sort of error from prevent reporting of span sources 'behind' Ripe lookups. If there were a way to securely automate it, I could do the lookups locally (for my own reports), and pass the results to spamcop. *MY* volume is unlikely to every get high enough for Ripe to block the querys.

Link to comment
Share on other sites

Very strange. SpamCop isn't supposed to be querying RIPE. We cache their data.

- Don D'Minion - SpamCop Admin -

- Service[at]Admin.SpamCop.net -

Well that makes sense then. It would appear to be a software bug. Are the "nomaster" reports being processed somewhere, which would include this kind of problem? Is there a practical way of automatically getting this information in front of someone’s eyes. Without relying on a user to check what the problem was and post message.
Link to comment
Share on other sites

  • 3 weeks later...

Here is another:

http://www.spamcop.net/sc?action=refreshcm...0whois.ripe.net

Cache refresh disabled to avoid rate-limiting of whois servers
[refresh cache]

$ whois 93.83.16.70[at]whois.ripe.net

[whois.ripe.net]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

%ERROR:201: access denied for 184.94.240.95
%
% Sorry, access from your host has been permanently
% denied because of a repeated excessive querying.
% For more information, see
% http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-201-access-denied

% This query was served by the RIPE Database Query Service version 1.75 (DB-2)


Link to comment
Share on other sites

I got another one that failed. This seems to be a recurring / intermittent glitch where spamcop is doing a lookup instead of using the cached Ripe data, although this one shows a temporary failure instead of permanent.

$ whois 95.111.80.166[at]whois.ripe.net

[whois.ripe.net]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

%ERROR:201: access denied for 184.94.240.91
%
% Queries from your IP address have passed the daily limit of controlled objects.
% Access from your host has been temporarily denied.
% For more information, see
% http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-201-access-denied

% This query was served by the RIPE Database Query Service version 1.75 (DB-4)

A manual whois finds:

$ whois 95.111.80.166[at]whois.ripe.net
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%	   To receive output for a database update, use the "-B" flag.

% Information related to '95.111.80.0 - 95.111.87.255'

% Abuse contact for '95.111.80.0 - 95.111.87.255' is 'ripe[at]mobiltel.bg'

inetnum:		95.111.80.0 - 95.111.87.255
netname:		MOTOPISTA-SOF
descr:		  Motopista quarter
descr:		  Megalan Network Real IP address space
country:		BG
admin-c:		MNET
tech-c:		 MNET
status:		 ASSIGNED PA
mnt-by:		 MNT-MEGALAN
source:		 RIPE # Filtered

role:		   Megalan Network hostmaster
address:		Megalan Network Ltd.
address:		1, Kukush str.
admin-c:		TD939-RIPE
tech-c:		 AA83-RIPE
tech-c:		 boko
tech-c:		 SG4736-RIPE
tech-c:		 DT9876
tech-c:		 II9999
nic-hdl:		MNET
mnt-by:		 MNT-MEGALAN
source:		 RIPE # Filtered

% Information related to '95.111.0.0/17AS35141'

route:		  95.111.0.0/17
descr:		  BG-MEGALAN-20081219
origin:		 AS35141
mnt-by:		 MNT-MEGALAN
source:		 RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.75 (DB-2)

Link to comment
Share on other sites

  • 2 weeks later...

I got another ripe lookup failure. Since previous information is that spamcop is supposed to be using cached information, here is one level 'higher' information, to hopefully track down one of the cases where the lookups go down the wrong path.

Tracking message source: 130.193.202.166:
Display data:

"whois 130.193.202.166[at]whois.arin.net" (Getting contact from whois.arin.net )
   Redirect to ripe
   Display data:
   "whois 130.193.202.166[at]whois.ripe.net" (Getting contact from whois.ripe.net)
   whois.ripe.net 130.193.202.166 (nothing found)

I know nothing about how the background code works, but that makes me think that since the original lookup went to arin, the code to use the ripe cache got bypassed, and the normal redirect kicked in. Need to add to (or fix) the redirect code to notice that it should use the cached data.

Side node: The arin results included

# Query terms are ambiguous. The query is assumed to be: # "n 130.193.202.166"
Link to comment
Share on other sites

  • 8 months later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...