Can't make whois queries from IPv6 address
Linode
Linode Staff
'Whois' queries from my Linode's IPv6 address are blocked by RIPE. I get the following error message:
% 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 <REDACTED>
%
% 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.96 (HEREFORD)
What can I do?
4 Replies
bthompson
Linode Staff
Since you can’t change your Linode’s SLAAC address, a workaround could be using an ip6tables postrouting rule to make outbound connections from an address in a /64 pool. In the extremely rare case that a particular pool address is blocked as well, you have another 18,446,744,073,709,551,615 to choose from. After statically configuring an address from your pool, add the following:
ip6tables -t nat -A POSTROUTING -s $SLAAC_IPv6 -o eth0 -j SNAT --to-source $POOL_IPv6
An example of this from one of my own Linodes:
ip6tables -t nat -A POSTROUTING -s 2600:3c03::f03c:92ff:fe9b:80c8 -o eth0 -j SNAT --to-source 2600:3c03:e000:03f3::2
The access log on my web server is just showing the pool address:
2600:3c03:e000:3f3::2 - - [17/Dec/2019:14:50:42 +0000] "HEAD / HTTP/1.1" 200 207 "-" "curl/7.52.1"
2600:3c03:e000:3f3::2 - - [17/Dec/2019:14:50:43 +0000] "HEAD / HTTP/1.1" 200 207 "-" "curl/7.52.1"
2600:3c03:e000:3f3::2 - - [17/Dec/2019:14:50:44 +0000] "HEAD / HTTP/1.1" 200 207 "-" "curl/7.52.1"
2600:3c03:e000:3f3::2 - - [17/Dec/2019:14:50:45 +0000] "HEAD / HTTP/1.1" 200 207 "-" "curl/7.52.1"
2600:3c03:e000:3f3::2 - - [17/Dec/2019:14:50:46 +0000] "HEAD / HTTP/1.1" 200 207 "-" "curl/7.52.1"
All that said, this is really just a workaround to the problem, not a solution. The better approach would be to contact the RIPE Database administration ripe-dbm@ripe.net team to request further access, as noted in the information link they provided. Try to work with them to get the SLAAC address unblocked altogether.
Just throwing this out there, consider this a me too. Only an issue from the SLAAC IPv6 - v4 is just fine. Due to what I'm doing on that linode, I'm actually avoiding v6 mostly, and do not have a pool address assigned to it.
I did e-mail ripe, should I hear back, I will follow up here for other googlers
~j
UPDATE: RIPE unblocked the address space for the time being. It'll probably happen again.
You write:
Due to what I'm doing on that linode, I'm actually avoiding v6 mostly, and do not have a pool address assigned to it.
If you run a mail transfer agent on your Linode, you will find that Comcast (just say no!) doesn't like email sent from IPv6 addresses either. This is appears to be mostly due to Comcast's own laziness and not because of any technical reason.
-- sw
This is an amazing thread that has helped so many people, one of whom
wrote in to point out the following:
After adding the rule (like in bthompson's post)
ip6tables -t nat -A POSTROUTING -s $SLAAC_IPv6 -o eth0 -j SNAT --to-source $POOL_IPv6
You might wish to save it so that it will persist across reboots. Check man ip6tables-save for your system's configuration, but generally:
ip6tables-save > /etc/iptables/rules.v6 # Debian-based systems
ip6tables-save >/etc/sysconfig/ip6tables # RHEL-based systems