The /128 issue with Linode (insofar as it relates to Spamhaus) has been
percolating for at least 5 years if I recall correctly, but no shorter
than the strong RFC-level guidelines of /64.
Linode will allocate at /64 on request, and has being doing so for about
just as long.
On 2021-11-25
On 11/25/21 6:07 AM, Mary via mailop wrote:
I think by default each client is assigned a single /128 IPv6 address
per server.
As a Linode customer, I can confirm, yes, Linode does share the /64
among may customers /by/ /default/.
It is trivial to get an independent /64 from Linode. Simply
It appears that Michael Peddemors via mailop said:
>See item one.
>
>> - Submits a JSON report to XYZ provider (https://blocklist.api.provider.com)
See RFC 5965, published 11 years ago.
Spamhaus has extensive facilities for ISPs that want to know what their users
are up to.
If you're not an
Aye. We use Debouncer for our notifications. HetrixTools has also proven
quite useful. Monitoring blacklists for a large number of IPs can scale
into a bit heavier of a task than some might assume up front.
But on that note, I worked for a very large cloud provider for a few
years. Really
Hi Mary,
On Fri, Nov 26, 2021 at 11:25:06AM +0200, Mary via mailop wrote:
> Would it be possible for the two sides (blocklists and a
> cloud/hosting providers) to come together and have some kind of
> automated notification?
As a tiny hosting provider we already receive notifications from
On 2021-11-26 11:25:06, Mary via mailop wrote:
>
> Thinking out loud...
>
> Would it be possible for the two sides (blocklists and a
> cloud/hosting providers) to come together and have some kind of
> automated notification?
The blocklists already provide a convenient API to the providers: if
On 2021-11-26 1:25 a.m., Mary via mailop wrote:
Thinking out loud...
Yes Mary.. in a perfect world.. but..
Would it be possible for the two sides (blocklists and a cloud/hosting
providers) to come together and have some kind of automated notification?
Sample automated conversation via
On 2021-11-26 2:24 a.m., Hetzner Blacklist via mailop wrote:
I manually check those lists every other day, and then use our abuse
system to send notifications to the respective clients. Hosters who have
implemented the API can do so automatically.
The obvious question, given that you manually
Am 26.11.2021 um 10:25 schrieb Mary via mailop:
Thinking out loud...
Would it be possible for the two sides (blocklists and a cloud/hosting
providers) to come together and have some kind of automated notification?
It is possible and it already works that way for a handful of blacklists.
Dnia 26.11.2021 o godz. 09:23:08 Hans-Martin Mosner via mailop pisze:
> "Unlike" refers to "blocks port 25 by default" in the line above,
> not to assigning /64s to customers. And yes, blocking outgoing port
> 25 would make a bit of a difference.
From a customer point of view (contrary to hosting
> Would it be possible for the two sides (blocklists and a cloud/hosting
> providers) to come together and have some kind of automated notification?
Objection, requires an interest in collaboration from hosting providers.
--
Atro Tossavainen, Chairman of the Board
Infinite Mho Oy, Helsinki,
Am 26.11.21 um 10:25 schrieb Mary via mailop:
Thinking out loud...
Would it be possible for the two sides (blocklists and a cloud/hosting
providers) to come together and have some kind of automated notification?
Possible - yes of course.
Doable as in both sides cooperating - when OVH,
Thinking out loud...
Would it be possible for the two sides (blocklists and a cloud/hosting
providers) to come together and have some kind of automated notification?
Sample automated conversation via JSON API:
- The blocklist adds a block for X net block
- Resolves the owner of the net block
Am Freitag, dem 26.11.2021 um 09:23 +0100 schrieb Hans-Martin Mosner
via mailop:
> Am 26.11.21 um 09:04 schrieb Bastian Blank via mailop:
> > On Fri, Nov 26, 2021 at 09:34:44AM +0200, Mary via mailop wrote:
> > > Unlike other providers like OVH and hetzner...
> > Hetzner does not assign less then
Correct, we automatically assign a /64 per server, and we've done that
since the beginning of our IPv6 support (2011 if memory serves me
correctly). A /56 is possible via a support request.
We also block port 25 by default for new cloud clients, though we've
only been doing that since April
Am 26.11.2021 um 08:34 schrieb Mary via mailop:
Linode blocks port 25 by default and requires manual intervention and a
"discussion" with support before they unblock it.
Unlike other providers like OVH and hetzner...
Hetzner Cloud has Port 25 blocked by default, you need to send a request
Am 26.11.21 um 09:04 schrieb Bastian Blank via mailop:
On Fri, Nov 26, 2021 at 09:34:44AM +0200, Mary via mailop wrote:
Unlike other providers like OVH and hetzner...
Hetzner does not assign less then a /64 in all their current products.
Bastian
"Unlike" refers to "blocks port 25 by default"
On Fri, Nov 26, 2021 at 09:34:44AM +0200, Mary via mailop wrote:
> Unlike other providers like OVH and hetzner...
Hetzner does not assign less then a /64 in all their current products.
Bastian
--
There is an order of things in this universe.
-- Apollo, "Who Mourns for Adonais?"
Linode blocks port 25 by default and requires manual intervention and a
"discussion" with support before they unblock it.
Unlike other providers like OVH and hetzner...
On 25 Nov 2021 23:18:51 -0500 John Levine via mailop wrote:
> It appears that Jarland Donnell via mailop said:
> >In all
It appears that Jarland Donnell via mailop said:
>In all fairness, some of these systems may have been deployed before we
>were all really certain that a /64 per customer was going to be an
>accepted standard.
A /64 per customer has always been the plan. There is no good reason
to assign
Fair enough too, the amount of crap coming from linode in recent weeks
exceeds the levels from gmail and outlook combined, both ipv4 and 6
usually they send about the same as the others, not more than both of
them together.
On 25/11/2021 21:15, Mary via mailop wrote:
I first noticed that
One thing that I think we can do to "help" in this instance is actually
list which addresses traffic has been seen from, rather than just
reporting the /64 being listed.
For this range - I'm only seeing 3 IPv6 addresses hitting traps
2a01:7e01::f03c:92ff:fed4:25b5 "YourBud " -
abuseable web
In all fairness, some of these systems may have been deployed before we
were all really certain that a /64 per customer was going to be an
accepted standard. You know how RFCs go, they're the law of the land
except when they're not, which is actually pretty often. By now most
should have
On 11/25/21 12:18 PM, Jay Hennigan via mailop wrote:
It's not a Spamhaus problem. Linode is beyond stupid. Linode has over
four billion /64s. The rest of the Internet treats a /64 as a single
user or subnet. Linode should be allocating each customer subnet a /64
as a minimum.
If you're a
On 11/25/21 06:22, Mary via mailop wrote:
But that is not a real solution is it?
Maybe linode and spamhaus can come up with a better solution between them?
It's not a Spamhaus problem. Linode is beyond stupid. Linode has over
four billion /64s. The rest of the Internet treats a /64 as a
On Thu, Nov 25, 2021 at 03:07:02PM +0200, Mary via mailop wrote:>> I
think Linode does not follow the /64 rule and assigns thousands of
customers within the 2a01:7e01::/64 block. They user a bunch of blocks,
depending on their data centre.>> I think by default each client is
assigned a single
On 25/11/2021 14:22, Mary via mailop wrote:
But that is not a real solution is it?
Maybe linode and spamhaus can come up with a better solution between them?
Why is it not a real solution?
It's a bigger problem than Linode and Spamhaus. (I refer to Linode
in my writings, but I don't
> Sure. Linode could decide to stop operating a public nuisance and
> police their sewer more effectively. Historically, Spamhaus has a
> long record of delisting network operators who reform their
> abuse-handling.
This isn't even about that. This is only about Linode cramming more
than one
On 2021-11-25 at 09:22:05 UTC-0500 (Thu, 25 Nov 2021 16:22:05 +0200)
Mary via mailop
is rumored to have said:
But that is not a real solution is it?
Maybe linode and spamhaus can come up with a better solution between
them?
Sure. Linode could decide to stop operating a public nuisance and
Hi,
I think Linode does not follow the /64 rule and assigns thousands of customers
within the 2a01:7e01::/64 block. They user a bunch of blocks, depending on
their data centre.
I think by default each client is assigned a single /128 IPv6 address per
server.
See
On Thu, Nov 25, 2021 at 04:22:05PM +0200, Mary via mailop wrote:
>
> But that is not a real solution is it?
It is because it's the right thing to do in the first place.
> Maybe linode and spamhaus can come up with a better solution between them?
I would not expect any changes on the policy of
Well, RIPE itself (https://www.ripe.net/publications/docs/ripe-690)
states that it's a best practice to assign to an end user no less than a /64
On 25/11/21 15:22, Mary via mailop wrote:
But that is not a real solution is it?
Maybe linode and spamhaus can come up with a better solution
But that is not a real solution is it?
Maybe linode and spamhaus can come up with a better solution between them?
On Thu, 25 Nov 2021 13:48:27 + Riccardo Alfieri via mailop
wrote:
> Hi Mary,
>
> please see:
> https://www.linode.com/community/questions/266/ipv6-64-blocks-on-linode
>
Hi Mary,
please see:
https://www.linode.com/community/questions/266/ipv6-64-blocks-on-linode
Linode can assign you a /64 that will probably solve your problems.
On 25/11/21 11:33, Mary via mailop wrote:
Hello everyone,
I noticed today that spamhaus.org is blocking large net blocks of IPv6
On Thu, Nov 25, 2021 at 03:07:02PM +0200, Mary via mailop wrote:
>
> I think Linode does not follow the /64 rule and assigns thousands of
> customers within the 2a01:7e01::/64 block. They user a bunch of blocks,
> depending on their data centre.
>
> I think by default each client is assigned a
I think Linode does not follow the /64 rule and assigns thousands of customers
within the 2a01:7e01::/64 block. They user a bunch of blocks, depending on
their data centre.
I think by default each client is assigned a single /128 IPv6 address per
server.
:(
On Thu, 25 Nov 2021 05:57:03
Blacklists tend to target a whole /64 at once for IPv6 and this is
standard behavior. I just looked at my two Linode VMs and both have one
IPv6 from the same /64. It's possible that Linode is assigning a /64 per
customer and that no one else is in the same /64 as you. This is a
reasonable
I first noticed that all outgoing emails that are using IPv6 addresses, are
being rejected by anyone using zen.spamhaus.org
I then tried a bunch of my addresses and they all tested as listed in
https://check.spamhaus.org/
Please see attached screenshot.
On Thu, 25 Nov 2021 12:52:18 +0200
On 25 Nov 2021, at 10:33, Mary via mailop wrote:
> I noticed today that spamhaus.org is blocking large net blocks of IPv6
> (2a01:7e01) owned by Linode. Pretty much all my clients hosted at Linode are
> being blocked en mass (for IPv6 only).
>
> Is there a way to inform spamhaus about this
On Thu, Nov 25, 2021 at 12:33:54PM +0200, Mary via mailop wrote:
> Hello everyone,
>
> I noticed today that spamhaus.org is blocking large net blocks of IPv6
> (2a01:7e01) owned by Linode. Pretty much all my clients hosted at Linode are
> being blocked en mass (for IPv6 only).
40 matches
Mail list logo
