Re: [EXTERNAL] DNS filtering in practice, Re: Charter DNS servers returning malware filtered IP addresses

[Delong.com via NANOG]

> On Nov 1, 2023, at 13:28, Michael Thomas  wrote:
> 
> 
> On 10/28/23 3:13 AM, John Levine wrote:
>> It appears that Michael Thomas  said:
 If you're one of the small minority of retail users that knows enough
 about the technology to pick your own resolver, go ahead.  But it's
 a reasonable default to keep malware out of Grandma's iPad.
>>> How does this line up with DoH? Aren't they using hardwired resolver
>>> addresses? I would hope they are not doing anything heroic.
>> Generally, no.  I believe that Chrome probes whatever resolver is configured
>> into the system and uses that if it does DoH or DoT.
>> 
>> At one point Firefox was going to send everything to their favorite
>> DoH resolver but they got a great deal of pushback from people who
>> pointed out that they had policies on their networks and they'd have
>> to ban Firefox.  Firefox responded with a lame hack
>> where you can tell your cache to respond to some name and if so
>> Firefox will use your resolver.
> 
> That's probably what I'm remembering with Firefox. But doesn't probing the 
> local resolver sort of defeat the point of DoH? That is, I really don't want 
> my ISP to be able to snoop on my DNS history. Sending it off to one of the 
> well known resolvers at least gives me a chance to know whether they are evil 
> or not because there aren't very many of them vs every random ISP out there. 
> Since nobody but people like us know about those resolvers it seems to me 
> that without preconfiguration meaningful DoH is pretty limited?

The point of DoH is to move the ability to monetize your DNS history away from 
the public resolver world and into the hands of the content providers and other 
DoH providers.

I’m not sure I see that as an improvement, but I guess it depends on who you 
want to donate to.

Personally, I run my own resolvers and that doesn’t leak any data that wouldn’t 
have to be leaked anyway (after all, the DoH resolvers have to query the 
upstream authoritative servers on my behalf anyway, and with EDNS0, they’re 
likely passing along enough to deanonymize those queries, at least in my case.

YMMV

Owen

Re: [EXTERNAL] DNS filtering in practice, Re: Charter DNS servers returning malware filtered IP addresses

[Michael Thomas]

On 10/28/23 3:13 AM, John Levine wrote:

It appears that Michael Thomas  said:

If you're one of the small minority of retail users that knows enough
about the technology to pick your own resolver, go ahead.  But it's
a reasonable default to keep malware out of Grandma's iPad.

How does this line up with DoH? Aren't they using hardwired resolver
addresses? I would hope they are not doing anything heroic.

Generally, no.  I believe that Chrome probes whatever resolver is configured
into the system and uses that if it does DoH or DoT.

At one point Firefox was going to send everything to their favorite
DoH resolver but they got a great deal of pushback from people who
pointed out that they had policies on their networks and they'd have
to ban Firefox.  Firefox responded with a lame hack
where you can tell your cache to respond to some name and if so
Firefox will use your resolver.


That's probably what I'm remembering with Firefox. But doesn't probing 
the local resolver sort of defeat the point of DoH? That is, I really 
don't want my ISP to be able to snoop on my DNS history. Sending it off 
to one of the well known resolvers at least gives me a chance to know 
whether they are evil or not because there aren't very many of them vs 
every random ISP out there. Since nobody but people like us know about 
those resolvers it seems to me that without preconfiguration meaningful 
DoH is pretty limited?


Or maybe I just don't understand what problem they were trying to solve?

Mike

Re: Charter DNS servers returning invalid IP addresses

[Jason J. Gullickson via NANOG]

This is very interesting.

I did some poking-around and found other Squarespace customers with 
similar issues (in their case it was Google complaining that their sites 
were suspicious and therefore couldn't serve Google ads).  The leading 
theory is that the "canned" Squarespace sites are using an old version 
of some library or other piece of code that some software identifies as 
malware or otherwise dubious.


If I can figure out exactly what these services are upset about maybe I 
can take that to Squarespace and get them to fix it, but I'm not sure 
how far I'll get with what I know so far.



- Jason

On 2023-10-27 6:44 am, John Levine wrote:

It appears that J. Hellenthal via NANOG  said:

-=-=-=-=-=-

Maybe the site "has/had" a shopping cart infection at one point that 
has been found and eradicated at one point ?


Virustotal reported it four days ago, which suggests that whatever was
wrong with it is still wrong with it,

The usual (correct) response to "whitelist us because your malware
report is wrong" is "no, because it's not."

R's,
John

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

[Tim Burke]

Agreed, it should be 100% opt-in… and I don’t even like the idea of providing 
filtered DNS at all. 

But sadly, judging by the number of neighborhood Facebook group posts I see 
from people complaining about “their wifi being down” during yet another fiber 
cut, there are an increasingly large number of end users that expect their ISPs 
to provide a 100% idiot-proof solution. Security filtering is part of that 
solution, along with all of the ’set and forget’ mesh wifi systems that clog up 
spectrum worse than an overdriven CB radio. 

Certainly not bulletproof, but as the movie “Idiocracy” turns more and more 
into a documentary, I think solutions like this will become more commonplace. 
As long as clueful users can disable it without trouble, I’m perfectly fine 
with it.  

> On Oct 30, 2023, at 6:00 PM, Owen DeLong via NANOG  wrote:
> 
> 
> 
>> On Oct 30, 2023, at 07:58, Livingood, Jason  
>> wrote:
>> 
>> On 10/27/23, 19:01, "NANOG on behalf of Owen DeLong wrote:
>> 
>>> If it’s such a reasonable default, why don’t any of the public resolvers 
>>> (e.g. 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so?
>>> DNS isn’t the right place to attack this, IMHO.
>> 
>> Are we sure that the filtering is done in the default view - I would suggest 
>> the user check to ensure they don't have a filtering service (e.g. parental 
>> controls/malware protection) turned on. In my **personal** opinion, the 
>> default view should have DNSSEC validation & no filtering; users can always 
>> optionally select additional protection services that might include 
>> DNS-based filtering as well as other mechanisms. 
>> 
>> JL
>> 
> 
> Looks like 9.9.9.9 is filtered but ONLY for actual verified security threats, 
> not spam, etc.
> If you want unfiltered, they offer 9.9.9.10.
> 
> Cloudflare offers two different filtered services, but 1.1.1.1 remains 
> unfiltered.
> 
> 1.1.1.2 is “No Malware”
> 1.1.1.3 is “No Malware or Adult Content”
> 
> So yes, apparently one (and only one) public resolver now filters by default.
> 
> I stand by my statement… It should be an opt-in choice, not a default.
> 
> Owen
> 

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

[Owen DeLong via NANOG]

> On Oct 30, 2023, at 07:58, Livingood, Jason  
> wrote:
> 
> On 10/27/23, 19:01, "NANOG on behalf of Owen DeLong wrote:
> 
>> If it’s such a reasonable default, why don’t any of the public resolvers 
>> (e.g. 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so?
>> DNS isn’t the right place to attack this, IMHO.
> 
> Are we sure that the filtering is done in the default view - I would suggest 
> the user check to ensure they don't have a filtering service (e.g. parental 
> controls/malware protection) turned on. In my **personal** opinion, the 
> default view should have DNSSEC validation & no filtering; users can always 
> optionally select additional protection services that might include DNS-based 
> filtering as well as other mechanisms. 
> 
> JL
> 

Looks like 9.9.9.9 is filtered but ONLY for actual verified security threats, 
not spam, etc.
If you want unfiltered, they offer 9.9.9.10.

Cloudflare offers two different filtered services, but 1.1.1.1 remains 
unfiltered.

1.1.1.2 is “No Malware”
1.1.1.3 is “No Malware or Adult Content”

So yes, apparently one (and only one) public resolver now filters by default.

I stand by my statement… It should be an opt-in choice, not a default.

Owen

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

[Compton, Rich A]

No, Charter doesn't use those.  Charter runs its own anycasted recursive 
nameservers.

On 10/30/23, 2:46 PM, "NANOG on behalf of Livingood, Jason via NANOG" 
mailto:charter@nanog.org> on behalf of nanog@nanog.org 
> wrote:


CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.


On 10/30/23, 16:02, "John R. Levine" mailto:jo...@iecc.com> 
>> wrote:


> I have no idea whether Charter uses one of these, some other third party, 
or their own. 


They don't use those providers as far as I am aware. I've alerted someone from 
CHTR of this thread. 


JL







E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

[Livingood, Jason via NANOG]

On 10/30/23, 16:02, "John R. Levine" mailto:jo...@iecc.com>> 
wrote:

> I have no idea whether Charter uses one of these, some other third party, 
or their own. 

They don't use those providers as far as I am aware. I've alerted someone from 
CHTR of this thread. 

JL

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

[John R. Levine]

On Mon, 30 Oct 2023, Livingood, Jason wrote:

On 10/27/23, 19:01, "NANOG on behalf of Owen DeLong wrote:


If it’s such a reasonable default, why don’t any of the public resolvers (e.g. 
1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so?
DNS isn’t the right place to attack this, IMHO.


Are we sure that the filtering is done in the default view - I would suggest the 
user check to ensure they don't have a filtering service (e.g. parental 
controls/malware protection) turned on. In my **personal** opinion, the default 
view should have DNSSEC validation & no filtering; users can always optionally 
select additional protection services that might include DNS-based filtering as 
well as other mechanisms.


At Quad9 they are clear that 9.9.9.9 is filtered.  Cloudflare 1.1.1.1 is 
unfiltered, 1.1.1.2 filters malware, 1.1.1.3 malware and stuff unsuitable 
for children.


I have no idea whether Charter uses one of these, some other third party, 
or their own.  We must know someone there who could tell us.


Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

[Livingood, Jason via NANOG]

On 10/27/23, 19:01, "NANOG on behalf of Owen DeLong wrote:

> If it’s such a reasonable default, why don’t any of the public resolvers 
> (e.g. 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so?
> DNS isn’t the right place to attack this, IMHO.

Are we sure that the filtering is done in the default view - I would suggest 
the user check to ensure they don't have a filtering service (e.g. parental 
controls/malware protection) turned on. In my **personal** opinion, the default 
view should have DNSSEC validation & no filtering; users can always optionally 
select additional protection services that might include DNS-based filtering as 
well as other mechanisms. 

JL

Re: [EXTERNAL] Re: Charter DNS servers returning malware filtered IP addresses

[Glenn Kelley]

I agree it actually is wise for them to offer a filtered service for those
that want it but opt in for sure

On Fri, Oct 27, 2023, 12:35 PM Bryan Fields  wrote:

> On 10/27/23 7:49 AM, John Levine wrote:
> > But for obvious good reasons,
> > the vast majority of their customers don't
>
> I'd argue that as a service provider deliberately messing with DNS is an
> obvious bad thing.  They're there to deliver packets.
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>
>

Re: Charter DNS servers returning malware filtered IP addresses

[Tom Beecher]

>
> DNS isn’t the right place to attack this, IMHO.
>
...

> I’ve seen plenty of situations where the filters were just plain wrong and
> if the end user didn’t actively choose that filtration, the target site may
> be victimized without anyone knowing where to go to complain.


Not much different from IP Geolocation. Probably not the right solution to
many things, but people do it anyways., often causing problems that people
don't know where to go to complain.


On Fri, Oct 27, 2023 at 10:14 PM Owen DeLong via NANOG 
wrote:

> >> DNS isn’t the right place to attack this, IMHO.
> >
> > Why not (apart from a purity argument), and where should it happen
> instead? As others pointed out, network operators have a vested interest in
> protecting their customers from becoming victims to malware.
>
>
> Takedowns of the hostile target sites.
>
> You dismiss the purity argument, but IMHO, there’s merit to the purity
> argument.
>
> Any such DNS filtration, if provided, should be provided on an opt-in
> basis, not as a default.
>
> I’ve seen plenty of situations where the filters were just plain wrong and
> if the end user didn’t actively choose that filtration, the target site may
> be victimized without anyone knowing where to go to complain.
>
> Owen
>
>

Re: Charter DNS servers returning malware filtered IP addresses

[John Levine]

It appears that   said:
>* Owen DeLong [Sat 28 Oct 2023, 01:00 CEST]:
>>If it’s such a reasonable default, why don’t any of the public 
>>resolvers (e.g. 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so?
>
>It's generally a service that's offered for money. Quad9 definitely 
>offer it: https://www.quad9.net/service/threat-blocking

Not really for money.  Quad9, Cloudflare, and OpenDNS provide filtered DNS for 
free.

There are expensive versions for enterprise networks but there's
plenty of malware filtering DNS for users.

I'm with you about the purity argument. While it certainly would be
possible to use DNS filtering for political reasons (the "family
friendly" versions arguably do that), the amount of malware and phish
is a large and real threat.

By the way, don't miss Interisle's new report on the cybercrime
supply chain.  They (we, actually) found five millions domains
used in crime of at least a million were registered only to do crime.

https://interisle.net/CybercrimeSupplyChain2023.html

R's,
John

Re: [EXTERNAL] DNS filtering in practice, Re: Charter DNS servers returning malware filtered IP addresses

[John Levine]

It appears that Michael Thomas  said:
>> If you're one of the small minority of retail users that knows enough
>> about the technology to pick your own resolver, go ahead.  But it's
>> a reasonable default to keep malware out of Grandma's iPad.
>
>How does this line up with DoH? Aren't they using hardwired resolver 
>addresses? I would hope they are not doing anything heroic.

Generally, no.  I believe that Chrome probes whatever resolver is configured
into the system and uses that if it does DoH or DoT.

At one point Firefox was going to send everything to their favorite
DoH resolver but they got a great deal of pushback from people who
pointed out that they had policies on their networks and they'd have
to ban Firefox.  Firefox responded with a lame hack
where you can tell your cache to respond to some name and if so
Firefox will use your resolver.

R's,
John

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

[John R. Levine]

If it’s such a reasonable default, why don’t any of the public resolvers (e.g. 
1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so?


Oh my, you walked right into that one.

https://www.quad9.net/service/threat-blocking/

https://blog.cloudflare.com/introducing-1-1-1-1-for-families/

I'm also surprised nobody seems familiar with Vixie's Response Policy 
Zones, a widely supported way to put DNS filtering rules into your own DNS 
cache.


https://www.first.org/resources/papers/aa-dec2021/Protective-DNS-a-Boris-Slides.pdf


Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

[Delong.com via NANOG]

> On Oct 28, 2023, at 10:28, Jay R. Ashworth  wrote:
> 
> - Original Message -
>> From: "Owen DeLong via NANOG" 
> 
>>> For a network feeding a data center, sure. For a network like
>>> Charter's which is feeding unsophisticated nontechnical users, they
>>> need all the messing they can get.
>>> 
>>> If you're one of the small minority of retail users that knows enough
>>> about the technology to pick your own resolver, go ahead.  But it's
>>> a reasonable default to keep malware out of Grandma's iPad.
>>> 
>>> R's,
>>> John
>> 
>> If it’s such a reasonable default, why don’t any of the public resolvers 
>> (e.g.
>> 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so?
> 
> It's a reasonable default behavior *for default resolver servers for consumer
> eyeball networks*.
> 
> I knew that was what John meant, and I can't see any reason why you wouldn't 
> know it too, Owen; this isn't your first rodeo, either.

I knew that’s what he meant and I know what you mean. I still don’t agree.

Owen

Re: [EXTERNAL] Re: Charter DNS servers returning malware filtered IP addresses

[Glenn McGurrin via NANOG]

I'd agree and disagree, filtering the default isp provided dns server 
for consumer and possibly small business, reasonable, not without some 
issues, but reasonable.  Comcast style filter servers and intercept all 
dns headed to other dns servers and redirect them to your own servers 
and make it difficult to disable, unreasonable, if people deliberately 
choose to use different dns do NOT override that choice at an isp level 
(corporate/business firewalls are a bit of a different story), offering 
security filtered dns as a default isp provided server is a value add 
for many non technical users, filtering beyond security or making it 
difficult to use other dns servers is a detriment to users.


my view on small business's with static addresses are a little more 
complex, they are more likely to be doing things the filtering might 
break, but many of those things also are best done while running your 
own recursive resolver, so it may not actually matter that much, but 
definitely don't do a forced dns server via redirection of all dns 
queries for such users, honestly don't ever do that as an ISP without 
specific direct opt in, not opt in by not fighting with sales to remove 
a line from an order, or other "opt-in" that isn't actually customer 
initiated informed opt-in, I'm looking at you Comcast.


On 10/27/2023 5:20 PM, John Levine wrote:

It appears that Bryan Fields  said:

-=-=-=-=-=-
-=-=-=-=-=-
On 10/27/23 7:49 AM, John Levine wrote:

But for obvious good reasons,
the vast majority of their customers don't


I'd argue that as a service provider deliberately messing with DNS is an
obvious bad thing.  They're there to deliver packets.


For a network feeding a data center, sure. For a network like
Charter's which is feeding unsophisticated nontechnical users, they
need all the messing they can get.

If you're one of the small minority of retail users that knows enough
about the technology to pick your own resolver, go ahead.  But it's
a reasonable default to keep malware out of Grandma's iPad.

R's,
John

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

[Jay R. Ashworth]

- Original Message -
> From: "Owen DeLong via NANOG" 

>> For a network feeding a data center, sure. For a network like
>> Charter's which is feeding unsophisticated nontechnical users, they
>> need all the messing they can get.
>> 
>> If you're one of the small minority of retail users that knows enough
>> about the technology to pick your own resolver, go ahead.  But it's
>> a reasonable default to keep malware out of Grandma's iPad.
>> 
>> R's,
>> John
> 
> If it’s such a reasonable default, why don’t any of the public resolvers (e.g.
> 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so?

It's a reasonable default behavior *for default resolver servers for consumer
eyeball networks*.

I knew that was what John meant, and I can't see any reason why you wouldn't 
know it too, Owen; this isn't your first rodeo, either.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Charter DNS servers returning malware filtered IP addresses

[Owen DeLong via NANOG]

>> DNS isn’t the right place to attack this, IMHO.
> 
> Why not (apart from a purity argument), and where should it happen instead? 
> As others pointed out, network operators have a vested interest in protecting 
> their customers from becoming victims to malware.


Takedowns of the hostile target sites.

You dismiss the purity argument, but IMHO, there’s merit to the purity argument.

Any such DNS filtration, if provided, should be provided on an opt-in basis, 
not as a default.

I’ve seen plenty of situations where the filters were just plain wrong and if 
the end user didn’t actively choose that filtration, the target site may be 
victimized without anyone knowing where to go to complain.

Owen

Re: Charter DNS servers returning malware filtered IP addresses

[niels=nanog]

* Owen DeLong [Sat 28 Oct 2023, 01:00 CEST]:
If it’s such a reasonable default, why don’t any of the public 
resolvers (e.g. 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so?


It's generally a service that's offered for money. Quad9 definitely 
offer it: https://www.quad9.net/service/threat-blocking




DNS isn’t the right place to attack this, IMHO.


Why not (apart from a purity argument), and where should it happen 
instead? As others pointed out, network operators have a vested 
interest in protecting their customers from becoming victims to 
malware.



-- Niels.

Re: [EXTERNAL] Re: Charter DNS servers returning malware filtered IP addresses

[Eric Kuhnke]

When you have a sufficiently large mass of non-technical end users,
inevitably some percentage of them will end up doing something like
enabling WAN-interface-facing remote admin access,which then gets pwned and
turned into a botnet. It's a real problem at scale. Compromised CPE routers
in addition to people visiting virus/trojan laden webservers and infecting
their endpoint devices.

good example:

https://www.fortinet.com/blog/threat-research/condi-ddos-botnet-spreads-via-tp-links-cve-2023-1389



On Fri, Oct 27, 2023 at 3:37 PM John Levine  wrote:

> It appears that Bryan Fields  said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >On 10/27/23 7:49 AM, John Levine wrote:
> >> But for obvious good reasons,
> >> the vast majority of their customers don't
> >
> >I'd argue that as a service provider deliberately messing with DNS is an
> >obvious bad thing.  They're there to deliver packets.
>
> For a network feeding a data center, sure. For a network like
> Charter's which is feeding unsophisticated nontechnical users, they
> need all the messing they can get.
>
> If you're one of the small minority of retail users that knows enough
> about the technology to pick your own resolver, go ahead.  But it's
> a reasonable default to keep malware out of Grandma's iPad.
>
> R's,
> John
>

Re: [EXTERNAL] Re: Charter DNS servers returning malware filtered IP addresses

[Michael Thomas]

On 10/27/23 2:20 PM, John Levine wrote:

It appears that Bryan Fields  said:

-=-=-=-=-=-
-=-=-=-=-=-
On 10/27/23 7:49 AM, John Levine wrote:

But for obvious good reasons,
the vast majority of their customers don't

I'd argue that as a service provider deliberately messing with DNS is an
obvious bad thing.  They're there to deliver packets.

For a network feeding a data center, sure. For a network like
Charter's which is feeding unsophisticated nontechnical users, they
need all the messing they can get.

If you're one of the small minority of retail users that knows enough
about the technology to pick your own resolver, go ahead.  But it's
a reasonable default to keep malware out of Grandma's iPad.


How does this line up with DoH? Aren't they using hardwired resolver 
addresses? I would hope they are not doing anything heroic.


Mike

Re: [EXTERNAL] Charter DNS servers returning malware filtered IP addresses

[Owen DeLong via NANOG]

> On Oct 27, 2023, at 14:20, John Levine  wrote:
> 
> It appears that Bryan Fields  said:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>> On 10/27/23 7:49 AM, John Levine wrote:
>>> But for obvious good reasons,
>>> the vast majority of their customers don't
>> 
>> I'd argue that as a service provider deliberately messing with DNS is an 
>> obvious bad thing.  They're there to deliver packets.
> 
> For a network feeding a data center, sure. For a network like
> Charter's which is feeding unsophisticated nontechnical users, they
> need all the messing they can get.
> 
> If you're one of the small minority of retail users that knows enough
> about the technology to pick your own resolver, go ahead.  But it's
> a reasonable default to keep malware out of Grandma's iPad.
> 
> R's,
> John

If it’s such a reasonable default, why don’t any of the public resolvers (e.g. 
1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so?

DNS isn’t the right place to attack this, IMHO.

Owen

Re: [EXTERNAL] Re: Charter DNS servers returning malware filtered IP addresses

[John Levine]

It appears that Bryan Fields  said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>On 10/27/23 7:49 AM, John Levine wrote:
>> But for obvious good reasons,
>> the vast majority of their customers don't
>
>I'd argue that as a service provider deliberately messing with DNS is an 
>obvious bad thing.  They're there to deliver packets.

For a network feeding a data center, sure. For a network like
Charter's which is feeding unsophisticated nontechnical users, they
need all the messing they can get.

If you're one of the small minority of retail users that knows enough
about the technology to pick your own resolver, go ahead.  But it's
a reasonable default to keep malware out of Grandma's iPad.

R's,
John

Re: [EXTERNAL] Re: Charter DNS servers returning malware filtered IP addresses

[Bryan Fields]

On 10/27/23 7:49 AM, John Levine wrote:

But for obvious good reasons,
the vast majority of their customers don't


I'd argue that as a service provider deliberately messing with DNS is an 
obvious bad thing.  They're there to deliver packets.

--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net



OpenPGP_signature
Description: OpenPGP digital signature

Re: [EXTERNAL] Re: Charter DNS servers returning malware filtered IP addresses

[John Levine]

According to Bryan Fields :
>On 10/25/23 4:58 PM, Compton, Rich A wrote:
>> Charter uses threat intel from Akamai to block certain "malicious" domains.
>
>Does charter do this on signed domains too?

Of course.

If you want to run your own DNSSEC resolver and bypass their malware
protection, you are welcome to do so. But for obvious good reasons,
the vast majority of their customers don't.

R's,
John

Re: Charter DNS servers returning invalid IP addresses

[John Levine]

It appears that J. Hellenthal via NANOG  said:
>-=-=-=-=-=-
>
>Maybe the site "has/had" a shopping cart infection at one point that has been 
>found and eradicated at one point ?

Virustotal reported it four days ago, which suggests that whatever was
wrong with it is still wrong with it,

The usual (correct) response to "whitelist us because your malware
report is wrong" is "no, because it's not."

R's,
John

Re: Charter DNS servers returning invalid IP addresses

[Bjørn Mork]

"Jason J. Gullickson via NANOG"  writes:

> I've been working for a week or so to solve a problem with DNS
> resolution for Charter customers for our domain bonesinjars.com.  I've
> reached-out to Charter directly but since I'm not a customer I
> couldn't get any help from them.  I was directed by a friend to this
> list in hopes that there may be able to reach a Charter/Spectrum
> engineer who might be able to explain and/or resolve this one.
>
> A dig against Google's DNS servers correctly returns 4 A records:
>
> dig bonesinjars.com 8.8.8.8

Guess you wanted 

  dig bonesinjars.com @8.8.8.8

?

> ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)

This is not 8.8.8.8

> dig bonesinjars.com 24.196.64.53

still missing @

> ;; SERVER: 127.0.0.53#53(127.0.0.53)

This is not 24.196.64.53


Bjørn

Re: Charter DNS servers returning invalid IP addresses

[Bryan Fields]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/25/23 8:24 PM, Greg Dickinson wrote:
> He didn’t, I was just referencing Mimecast to indicate it was probably
> larger than Charter’s DNS.  Given the reports that someone else gave from
> Virustotal, it seems it’s more widespread than first reported.

Is there a link where this can be looked up?  I've not seen anything on
their website .

If you're going to quote me, please don't alter what I wrote, and please
trim the relevant parts of it.

Thanks,
- -- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAmU5twEACgkQYTmgYVLG
kUDrcA/+MxVAPG4lHhbcsRkKBHKelmnZmM3hmBaLtenn6wOmFJ1TrehBTVBi3+qy
5tREfH8HQ5E/V5iZe/yAkVWETjptYjbpnDS73D6XPTlZzzEs5Py6uv1TMdgGzZf5
twV00M4kfYmzwffKs0hAXuQ8VkKo9x3S9c3jE6MJhqlxtWFMKEVdJX5xlUid0HqQ
wt9KZxO4WVLdRKTfL9XWBh92Mccdo4rcwVFk4jvQDEnJvUg55TMhXNfQL/3a3PSG
Pc/fGgnS+qEM9XxkMHBpilPHb0CB4YRJ7aldSkOZgL/7LVmQ0JyTd+clDSVCKeck
FjHsWf/PRuBRMJHb3fT8mFDEQUltlTIfJr8gbOrV/GkFd0o9gmTYWLkvnUh70uhj
S8ZXlzZoEue1OW5L4KkiFKP1i878aYhyn+OWbl8iW0P3WxmpNP9ZHOEMzAOLajIE
WMK6DJpKBKl8DEsh4diSOPODySC4+mWnle1ZskGsPjTrLCAY+ukzI0k0idZRrFdV
ywaK6nFKGvXkLMJM00s7ibLwAtnn30epGoWHHErKOBFfaZ12oPERoCaFArdNbLZi
dxITHkYFaF70M+Jav/Jh4bf2baHwU/zTNdmDvgp8CjLgVF19439wgj8IeXrvqFQ+
VWLhlCj5D1GvblWi+GejK2dYLSfIWtIWL2CRCuGhHA1CpCdZvtI=
=Esxb
-END PGP SIGNATURE-

Re: [EXTERNAL] Re: Charter DNS servers returning invalid IP addresses

[Bryan Fields]

On 10/25/23 4:58 PM, Compton, Rich A wrote:
> Charter uses threat intel from Akamai to block certain "malicious" domains.

Does charter do this on signed domains too?
-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

RE: Charter DNS servers returning invalid IP addresses

[Greg Dickinson]

He didn’t, I was just referencing Mimecast to indicate it was probably larger 
than Charter’s DNS.  Given the reports that someone else gave from Virustotal, 
it seems it’s more widespread than first reported.

Greg Dickinson, CCNA
Network Engineer

[mid:ac0798f5d04aec2c4c40f9c44056646c8ba72bfb332f7f64d451d99665886...@getboxer.com/image001.png@01D2DDE3.06E76B70]

From: NANOG  On Behalf 
Of Bryan Fields
Sent: Wednesday, October 25, 2023 2:51 PM
To: nanog@nanog.org
Subject: Re: Charter DNS servers returning invalid IP addresses




This Message originates from outside Bryant Bank.   Please use caution when 
opening this correspondence, attachments or hyperlinks (URLs).  If you have 
questions, please contact IT Support.  Thank you.

On 10/25/23 2:41 PM, Greg Dickinson wrote:
> If it helps troubleshooting, when I click the domain in the email Mimecast
> tells me:
>
> “We checked the website you are trying to access for malicious and
> spear-phishing content and found it likely to be unsafe.”

I saw nothing referencing Mimecast in the original email. Where did you see 
this?

bonesinjars.com<https://secure-web.cisco.com/1QQZVslnfiRjBtYsKz_oXFZ_6WtTz9sVZ_f0uvfIVeQ2J1pIidIRXn6_jdq-yZOHUogW_K6VK7D0Z1XlMCU582_TcZAVhTdpiq9JxixxYbkJfGT49HwTOslxUlMJyF7N2kN6HGX2LhEGO9n3mr5OwxMrdseSfDjdEqt8CduYaiS4G2LDlbe8Dg2l0amB-7s_zlqczuasnjL0pQdK7KvyQKqUHW_aEjlr6tbm-Ot4IBuFYyVgFvyCt4ELqnUS74BeHrFwprUthd9Gs2KHJTNoJubcCC3u5rmijvsEmteQDOe-1FIdONODBxWbubyjpRccL/https%3A%2F%2Fprotect-usb.mimecast.com%2Fs%2FFF75CB1GO7fVEN2TNemvK%3Fdomain%3Dbonesinjars.com>
 is not signed with DNSSEC. This is trivial to setup and might
prevent some of this.

Probably not a good idea for your customers to rely on $BIGCABLE DNS servers.
--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net<https://secure-web.cisco.com/1IMgbVJ8gycWN6tw-46nbbWjKIELzO75mx5XvOPS1W9lFcp-t5iPb6Z6pom_P03J9roVyNep9lT5w4tQ38iAYBobJI4sey3-XZisw2KcRArZXNJsOQZ0GEd0TR2wOdJLQqdU170lylzPwbJ6UWgjTvMlPaCE_u7WdxOX9gCG7M20OzhYTA0TRtif-nRWHyCQKT7sBiFlPcItRDX_CLbnsg4NIjnn-NlUpGkbnCUe2x_MG5y8ed6IODpcaiWvjb4-1NPVharBH-SfJW3KRxmxaOtf-uxLSK2fZH91teBZ6v6HkeoLdoyWaprqZAWMuY_dd/https%3A%2F%2Fprotect-usb.mimecast.com%2Fs%2F76FZCDwK67fBgZGHZQHy_%3Fdomain%3Dbryanfields.net>


NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively for the individual or entity to which it is addressed. The 
message, together with any attachment, may contain confidential and/or 
privileged information. Any unauthorized review, use, print, save, copy, 
disclosure or distribution is strictly prohibited. If you have received this 
message in error, please immediately advise the sender by reply email and 
delete copies.  Thank you.

Charter DNS servers returning invalid IP addresses

[Sylvain BAYA]

Dear NANOG-er,

Hope this email finds you in good health!

Please see my comments below, inline...

Thanks,


Le 25/10/2023 à 18:50, Jason J. Gullickson via NANOG a écrit :


I've been working for a week or so to solve a problem with DNS 
resolution for Charter customers for our domain bonesinjars.com.  I've 
reached-out to Charter directly but since I'm not a customer I 
couldn't get any help from them.  I was directed by a friend to this 
list in hopes that there may be able to reach a Charter/Spectrum 
engineer who might be able to explain and/or resolve this one.


A dig against Google's DNS servers correctly returns 4 A records:


dig bonesinjars.com 8.8.8.8



...instead of the above, you could try the following command:

`dig bonesinjars.com. @9.9.9.9 +nsid +edns=0 +all +short`

Please, do note the sign `@` and the trailing dot `.`




[...]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26879
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;8.8.8.8.   IN  A



...this is unexpected! given what you said.



;; Query time: 35 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Oct 23 10:26:32 CDT 2023
;; MSG SIZE  rcvd: 36


Verizon, AT, Comcast and all other DNS servers we tested return the 
same 4 A records.  However the same dig against a Charter DNS 
(24.196.64.53) returns only 127.0.0.54:



dig bonesinjars.com 24.196.64.53




`dig cmnog.cm. @24.196.64.53 +nsid +edns=0 +all`

or

dig cmnog.cm. @`dig -x 24.196.64.53 +short` +nsid +edns=0 +all



; <<>> DiG 9.16.1-Ubuntu <<>> bonesinjars.com 24.196.64.53
[...]
;; QUESTION SECTION:
;bonesinjars.com.        IN    A

;; ANSWER SECTION:
bonesinjars.com.    60    IN    A    127.0.0.54

[...]

;; QUESTION SECTION:
;24.196.64.53.            IN    A




...it's not what you wanted to test!
`dig` understood it otherwise.

...associating the @ sign with the above IPv4 address
would have corrected the behavior of `dig`:
*@24.196.64.53*




;; ANSWER SECTION:
24.196.64.53.        86400    IN    A    24.196.64.53

;; Query time: 27 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
[...]


Any help understanding and addressing this is greatly appreciated!





Hi Jason,

Thanks for your email, brother.

...you should note that:

n#1. each of the command you shared above is not
producing the expected behavior. Please replace
it by the one i suggested, and observe the diff.

n#2. the DNS resolver you try to use appears to not
being, actually, available for any request.
Just try: `dig @24.196.64.53 cm.` or even:
`dig @24.196.64.53 ns1.charter.com.`

Maybe you should, first clarify what you needed to
achieve.

That said! maybe it's a simple matter of changing
a DNS resolver? have you ask to someone within
Charter's network to try with quad9, for example?
...or any other public DNS resolver, to be fair.

Hope this helps!

Shalom,
--sb.




Jason



--
Best Regards !

baya.sylvain [AT cmNOG DOT cm]
|cmNOG's Structure |cmNOG's 
Surveys |Subscribe to cmNOG's Mailing List 
|

__
#‎LASAINTEBIBLE‬|‪#‎Romains15‬:33«*Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec 
vous tous! ‪#‎Amen‬!*» #‎MaPrière‬ est que tu naisses de 
nouveau.#Chrétiennement‬
«*Comme une biche soupire après des courants d’eau, ainsi mon âme 
soupire après TOI, ô DIEU!*» (#Psaumes42:2)


OpenPGP_0x0387408365AC8594.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [EXTERNAL] Re: Charter DNS servers returning invalid IP addresses

[Compton, Rich A]

VirusTotal and other domain reputation sites say the domain is malicious.  
Specifically there have been multiple malware samples that were scanned (latest 
was 10-09-2023) that had this domain hard coded in it. 
https://www.virustotal.com/gui/domain/bonesinjars.com
You may want to get a new domain.  Other option is to contact Akamai and see if 
they can whitelist this domain.  Charter uses threat intel from Akamai to block 
certain "malicious" domains.

-Rich


On 10/25/23, 1:54 PM, "NANOG on behalf of Bryan Fields" 
mailto:charter@nanog.org> on behalf of br...@bryanfields.net 
> wrote:


CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.


On 10/25/23 2:41 PM, Greg Dickinson wrote:
> If it helps troubleshooting, when I click the domain in the email Mimecast
> tells me:
> 
> “We checked the website you are trying to access for malicious and
> spear-phishing content and found it likely to be unsafe.”


I saw nothing referencing Mimecast in the original email. Where did you see 
this?


bonesinjars.com is not signed with DNSSEC. This is trivial to setup and might 
prevent some of this.


Probably not a good idea for your customers to rely on $BIGCABLE DNS servers.
-- 
Bryan Fields


727-409-1194 - Voice
http://bryanfields.net 





E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Re: Charter DNS servers returning invalid IP addresses

[Bryan Fields]

On 10/25/23 2:41 PM, Greg Dickinson wrote:

If it helps troubleshooting, when I click the domain in the email Mimecast
tells me:

“We checked the website you are trying to access for malicious and
spear-phishing content and found it likely to be unsafe.”


I saw nothing referencing Mimecast in the original email.  Where did you see 
this?

bonesinjars.com is not signed with DNSSEC.  This is trivial to setup and might 
prevent some of this.


Probably not a good idea for your customers to rely on $BIGCABLE DNS servers.
--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: Charter DNS servers returning invalid IP addresses

[Jason J. Gullickson via NANOG]

That does help Greg.

I've heard from a few other folks on the list that the domain is 
considered suspicious by a few different providers like this.  It's a 
turnkey Squarespace gallery/ecommerce site so I'm not sure why it would 
be classified as a threat, but perhaps a previous domain holder was 
doing something that could have been and these reports are just 
outdated?


- Jason

On 2023-10-25 1:41 pm, Greg Dickinson wrote:

If it helps troubleshooting, when I click the domain in the email 
Mimecast tells me:


"We checked the website you are trying to access for malicious and 
spear-phishing content and found it likely to be unsafe."


Greg Dickinson, CCNA

Network Engineer

From: NANOG  On 
Behalf Of Mark Andrews

Sent: Wednesday, October 25, 2023 1:27 PM
To: Jason J. Gullickson 
Cc: nanog@nanog.org
Subject: Re: Charter DNS servers returning invalid IP addresses

This Message originates from outside Bryant Bank.   Please use caution 
when opening this correspondence, attachments or hyperlinks (URLs).  If 
you have questions, please contact IT Support.  Thank you.


It's being filtered. Only Charter can tell you why.

--

Mark Andrews

On 26 Oct 2023, at 05:07, Jason J. Gullickson via NANOG 
 wrote:


I've been working for a week or so to solve a problem with DNS 
resolution for Charter customers for our domain bonesinjars.com [1].  
I've reached-out to Charter directly but since I'm not a customer I 
couldn't get any help from them.  I was directed by a friend to this 
list in hopes that there may be able to reach a Charter/Spectrum 
engineer who might be able to explain and/or resolve this one.


A dig against Google's DNS servers correctly returns 4 A records:

dig bonesinjars.com [1] 8.8.8.8 [2]

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> bonesinjars.com [1] 
8.8.8.8 [2]

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31383
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bonesinjars.com [1].   IN  A

;; ANSWER SECTION:
bonesinjars.com [1].60  IN  A   198.49.23.145 [3]
bonesinjars.com [1].60  IN  A   198.185.159.145 
[4]

bonesinjars.com [1].60  IN  A   198.49.23.144 [5]
bonesinjars.com [1].60  IN  A   198.185.159.144 
[6]


;; Query time: 1039 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) [7] (UDP)
;; WHEN: Mon Oct 23 10:26:32 CDT 2023
;; MSG SIZE  rcvd: 108

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26879
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;8.8.8.8 [2].   IN  A

;; Query time: 35 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) [7] (UDP)
;; WHEN: Mon Oct 23 10:26:32 CDT 2023
;; MSG SIZE  rcvd: 36

Verizon, AT, Comcast and all other DNS servers we tested return the 
same 4 A records.  However the same dig against a Charter DNS 
(24.196.64.53 [8]) returns only 127.0.0.54 [9]


dig bonesinjars.com [1] 24.196.64.53 [8]

; <<>> DiG 9.16.1-Ubuntu <<>> bonesinjars.com [1] 24.196.64.53 [8]
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17691
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bonesinjars.com [1].INA

;; ANSWER SECTION:
bonesinjars.com [1].60INA127.0.0.54 [9]

;; Query time: 55 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) [7]
;; WHEN: Tue Oct 24 13:28:36 CDT 2023
;; MSG SIZE  rcvd: 60

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4658
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;24.196.64.53 [8].INA

;; ANSWER SECTION:
24.196.64.53 [8].86400INA24.196.64.53 [8]

;; Query time: 27 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) [7]
;; WHEN: Tue Oct 24 13:28:36 CDT 2023
;; MSG SIZE  rcvd: 57

Any help understanding and addressing this is greatly appreciated!

Jason


NOTICE: This electronic mail message and any files transmitted with it 
are intended exclusively for the individual or entity to which it is 
addressed. The message, together with any attachment, may contain 
confidential and/or privileged information. Any unauthorized review, 
use, print, save, copy, disclosure or distribution is strictly 
prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete copies.  Thank 
you.



Links:
--
[1] 
https://secure-web.cisco.com/1QYzTVngb5oZ1KLAZyMPvb_h9plEnlxSg987WNlsBgaLug2z-wCDx1wrGIgQ

RE: Charter DNS servers returning invalid IP addresses

[Greg Dickinson]

If it helps troubleshooting, when I click the domain in the email Mimecast 
tells me:

“We checked the website you are trying to access for malicious and 
spear-phishing content and found it likely to be unsafe.”



Greg Dickinson, CCNA
Network Engineer

[mid:ac0798f5d04aec2c4c40f9c44056646c8ba72bfb332f7f64d451d99665886...@getboxer.com/image001.png@01D2DDE3.06E76B70]

From: NANOG  On Behalf 
Of Mark Andrews
Sent: Wednesday, October 25, 2023 1:27 PM
To: Jason J. Gullickson 
Cc: nanog@nanog.org
Subject: Re: Charter DNS servers returning invalid IP addresses




This Message originates from outside Bryant Bank.   Please use caution when 
opening this correspondence, attachments or hyperlinks (URLs).  If you have 
questions, please contact IT Support.  Thank you.

It’s being filtered. Only Charter can tell you why.
--
Mark Andrews


On 26 Oct 2023, at 05:07, Jason J. Gullickson via NANOG 
mailto:nanog@nanog.org>> wrote:

I've been working for a week or so to solve a problem with DNS resolution for 
Charter customers for our domain 
bonesinjars.com<https://secure-web.cisco.com/1QYzTVngb5oZ1KLAZyMPvb_h9plEnlxSg987WNlsBgaLug2z-wCDx1wrGIgQQEYsHUdgOcjhswf6mSTPbxkpx_PSBYcpJqL3ro-v_aACZlNSMkqb3exaatMssNXfmJgrveUz-UxuXL2M6AawZ3YEd2vM7Kn-1B-sSpAmZc-6V7EyX6S7ooOf7RD6nlw33qjyxRPUak-lV6-AnanVZZWHYe0Ijj2I8HL4AXQguBAmbNk0MbHeyA8Ga1AuXMgXyQit9G2GXOjM0MvxVStf6Mv8skAFEdXbUFd_oPIdEKAMTJTlEuw2TG-foZB4ZVBC4mckU/https%3A%2F%2Fprotect-usb.mimecast.com%2Fs%2FSJmKC8XrW7CjJ2MFn0cqx%3Fdomain%3Dbonesinjars.com>.
  I've reached-out to Charter directly but since I'm not a customer I couldn't 
get any help from them.  I was directed by a friend to this list in hopes that 
there may be able to reach a Charter/Spectrum engineer who might be able to 
explain and/or resolve this one.

A dig against Google's DNS servers correctly returns 4 A records:

dig 
bonesinjars.com<https://secure-web.cisco.com/1QYzTVngb5oZ1KLAZyMPvb_h9plEnlxSg987WNlsBgaLug2z-wCDx1wrGIgQQEYsHUdgOcjhswf6mSTPbxkpx_PSBYcpJqL3ro-v_aACZlNSMkqb3exaatMssNXfmJgrveUz-UxuXL2M6AawZ3YEd2vM7Kn-1B-sSpAmZc-6V7EyX6S7ooOf7RD6nlw33qjyxRPUak-lV6-AnanVZZWHYe0Ijj2I8HL4AXQguBAmbNk0MbHeyA8Ga1AuXMgXyQit9G2GXOjM0MvxVStf6Mv8skAFEdXbUFd_oPIdEKAMTJTlEuw2TG-foZB4ZVBC4mckU/https%3A%2F%2Fprotect-usb.mimecast.com%2Fs%2FSJmKC8XrW7CjJ2MFn0cqx%3Fdomain%3Dbonesinjars.com>
 
8.8.8.8<https://secure-web.cisco.com/1imxdVmCYKyqq5wulvqemEVFHic8KD5Xk1Q4EqDP-l4FLBVdWJDIOSKp41SSdsFISBJV1TPTQY179COdaURZsSkdbtkyBBd44NKV3A0JKV3nzk3_LnalsOhuow7MuiyMbecMAup_h6gGYQ4SOepC2sVtx0EZqiF9AQ5wSSa_LXF_9b5yF7LShmlxRpl1VJAFF3lgjvglh119EKQGIlesw0u9fm6-P0xxB3-KWORmNACLchQhN4VOX4fAZrs0JD8uwyA61yG4PnOfBkCXk_vhDRTDWMd0ImD5Yq0jq0PIfmYKq9xjitIMY22qJtE1rSgAr/https%3A%2F%2Fprotect-usb.mimecast.com%2Fs%2FBzURC93vG7smZlKfEbQ7C%3Fdomain%3D8.8.8.8>

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> 
bonesinjars.com<https://secure-web.cisco.com/1QYzTVngb5oZ1KLAZyMPvb_h9plEnlxSg987WNlsBgaLug2z-wCDx1wrGIgQQEYsHUdgOcjhswf6mSTPbxkpx_PSBYcpJqL3ro-v_aACZlNSMkqb3exaatMssNXfmJgrveUz-UxuXL2M6AawZ3YEd2vM7Kn-1B-sSpAmZc-6V7EyX6S7ooOf7RD6nlw33qjyxRPUak-lV6-AnanVZZWHYe0Ijj2I8HL4AXQguBAmbNk0MbHeyA8Ga1AuXMgXyQit9G2GXOjM0MvxVStf6Mv8skAFEdXbUFd_oPIdEKAMTJTlEuw2TG-foZB4ZVBC4mckU/https%3A%2F%2Fprotect-usb.mimecast.com%2Fs%2FSJmKC8XrW7CjJ2MFn0cqx%3Fdomain%3Dbonesinjars.com>
 
8.8.8.8<https://secure-web.cisco.com/1imxdVmCYKyqq5wulvqemEVFHic8KD5Xk1Q4EqDP-l4FLBVdWJDIOSKp41SSdsFISBJV1TPTQY179COdaURZsSkdbtkyBBd44NKV3A0JKV3nzk3_LnalsOhuow7MuiyMbecMAup_h6gGYQ4SOepC2sVtx0EZqiF9AQ5wSSa_LXF_9b5yF7LShmlxRpl1VJAFF3lgjvglh119EKQGIlesw0u9fm6-P0xxB3-KWORmNACLchQhN4VOX4fAZrs0JD8uwyA61yG4PnOfBkCXk_vhDRTDWMd0ImD5Yq0jq0PIfmYKq9xjitIMY22qJtE1rSgAr/https%3A%2F%2Fprotect-usb.mimecast.com%2Fs%2FBzURC93vG7smZlKfEbQ7C%3Fdomain%3D8.8.8.8>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31383
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bonesinjars.com<https://secure-web.cisco.com/1QYzTVngb5oZ1KLAZyMPvb_h9plEnlxSg987WNlsBgaLug2z-wCDx1wrGIgQQEYsHUdgOcjhswf6mSTPbxkpx_PSBYcpJqL3ro-v_aACZlNSMkqb3exaatMssNXfmJgrveUz-UxuXL2M6AawZ3YEd2vM7Kn-1B-sSpAmZc-6V7EyX6S7ooOf7RD6nlw33qjyxRPUak-lV6-AnanVZZWHYe0Ijj2I8HL4AXQguBAmbNk0MbHeyA8Ga1AuXMgXyQit9G2GXOjM0MvxVStf6Mv8skAFEdXbUFd_oPIdEKAMTJTlEuw2TG-foZB4ZVBC4mckU/https%3A%2F%2Fprotect-usb.mimecast.com%2Fs%2FSJmKC8XrW7CjJ2MFn0cqx%3Fdomain%3Dbonesinjars.com>.
   IN  A

;; ANSWER SECTION:
bonesinjars.com<https://secure-web.cisco.com/1QYzTVngb5oZ1KLAZyMPvb_h9plEnlxSg987WNlsBgaLug2z-wCDx1wrGIgQQEYsHUdgOcjhswf6mSTPbxkpx_PSBYcpJqL3ro-v_aACZlNSMkqb3exaatMssNXfmJgrveUz-UxuXL2M6AawZ3YEd2vM7Kn-1B-sSpAmZc-6V7EyX6S7ooOf7RD6nlw33qjyxRPUak-lV6-AnanVZZWHYe0Ijj2I8HL4AXQguBAmbNk0MbHeyA8Ga1AuXMgXyQit9G2GXOjM0MvxVStf6Mv8skAFEdXbUFd_oPIdEKAMTJTlEuw2TG-foZB4ZVBC4mckU/https%3A%2F%2Fprotect-usb.mimecast.com%2Fs%2FSJmKC8XrW7CjJ2MFn0cqx%

Re: Charter DNS servers returning invalid IP addresses

[Mark Andrews]

It’s being filtered. Only Charter can tell you why. 

-- 
Mark Andrews

> On 26 Oct 2023, at 05:07, Jason J. Gullickson via NANOG  
> wrote:
> 
> 
> I've been working for a week or so to solve a problem with DNS resolution for 
> Charter customers for our domain bonesinjars.com.  I've reached-out to 
> Charter directly but since I'm not a customer I couldn't get any help from 
> them.  I was directed by a friend to this list in hopes that there may be 
> able to reach a Charter/Spectrum engineer who might be able to explain and/or 
> resolve this one.
> 
> A dig against Google's DNS servers correctly returns 4 A records:
> 
> 
> dig bonesinjars.com 8.8.8.8 
> 
> ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> bonesinjars.com 8.8.8.8 
> ;; global options: +cmd 
> ;; Got answer: 
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31383 
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 
> 
> ;; OPT PSEUDOSECTION: 
> ; EDNS: version: 0, flags:; udp: 65494 
> ;; QUESTION SECTION: 
> ;bonesinjars.com.   IN  A 
> 
> ;; ANSWER SECTION: 
> bonesinjars.com.60  IN  A   198.49.23.145 
> bonesinjars.com.60  IN  A   198.185.159.145 
> bonesinjars.com.60  IN  A   198.49.23.144 
> bonesinjars.com.60  IN  A   198.185.159.144 
> 
> ;; Query time: 1039 msec 
> ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) 
> ;; WHEN: Mon Oct 23 10:26:32 CDT 2023 
> ;; MSG SIZE  rcvd: 108 
> 
> ;; Got answer: 
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26879 
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 
> 
> ;; OPT PSEUDOSECTION: 
> ; EDNS: version: 0, flags:; udp: 65494 
> ;; QUESTION SECTION: 
> ;8.8.8.8.   IN  A 
> 
> ;; Query time: 35 msec 
> ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) 
> ;; WHEN: Mon Oct 23 10:26:32 CDT 2023 
> ;; MSG SIZE  rcvd: 36
> 
> 
> 
> Verizon, AT, Comcast and all other DNS servers we tested return the same 4 
> A records.  However the same dig against a Charter DNS (24.196.64.53) returns 
> only 127.0.0.54:
> 
> 
> 
> dig bonesinjars.com 24.196.64.53
> 
> ; <<>> DiG 9.16.1-Ubuntu <<>> bonesinjars.com 24.196.64.53
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17691
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 65494
> ;; QUESTION SECTION:
> ;bonesinjars.com.INA
> 
> ;; ANSWER SECTION:
> bonesinjars.com.60INA127.0.0.54
> 
> ;; Query time: 55 msec
> ;; SERVER: 127.0.0.53#53(127.0.0.53)
> ;; WHEN: Tue Oct 24 13:28:36 CDT 2023
> ;; MSG SIZE  rcvd: 60
> 
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4658
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 65494
> ;; QUESTION SECTION:
> ;24.196.64.53.INA
> 
> ;; ANSWER SECTION:
> 24.196.64.53.86400INA24.196.64.53
> 
> ;; Query time: 27 msec
> ;; SERVER: 127.0.0.53#53(127.0.0.53)
> ;; WHEN: Tue Oct 24 13:28:36 CDT 2023
> ;; MSG SIZE  rcvd: 57
> 
> 
> 
> Any help understanding and addressing this is greatly appreciated!
> 
> 
> 
> Jason

Charter DNS servers returning invalid IP addresses

[Jason J. Gullickson via NANOG]

I've been working for a week or so to solve a problem with DNS 
resolution for Charter customers for our domain bonesinjars.com.  I've 
reached-out to Charter directly but since I'm not a customer I couldn't 
get any help from them.  I was directed by a friend to this list in 
hopes that there may be able to reach a Charter/Spectrum engineer who 
might be able to explain and/or resolve this one.


A dig against Google's DNS servers correctly returns 4 A records:

dig bonesinjars.com 8.8.8.8

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> bonesinjars.com 8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31383
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bonesinjars.com.   IN  A

;; ANSWER SECTION:
bonesinjars.com.60  IN  A   198.49.23.145
bonesinjars.com.60  IN  A   198.185.159.145
bonesinjars.com.60  IN  A   198.49.23.144
bonesinjars.com.60  IN  A   198.185.159.144

;; Query time: 1039 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Oct 23 10:26:32 CDT 2023
;; MSG SIZE  rcvd: 108

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26879
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;8.8.8.8.   IN  A

;; Query time: 35 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Oct 23 10:26:32 CDT 2023
;; MSG SIZE  rcvd: 36

Verizon, AT, Comcast and all other DNS servers we tested return the 
same 4 A records.  However the same dig against a Charter DNS 
(24.196.64.53) returns only 127.0.0.54:


dig bonesinjars.com 24.196.64.53

; <<>> DiG 9.16.1-Ubuntu <<>> bonesinjars.com 24.196.64.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17691
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bonesinjars.com.INA

;; ANSWER SECTION:
bonesinjars.com.60INA127.0.0.54

;; Query time: 55 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Oct 24 13:28:36 CDT 2023
;; MSG SIZE  rcvd: 60

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4658
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;24.196.64.53.INA

;; ANSWER SECTION:
24.196.64.53.86400INA24.196.64.53

;; Query time: 27 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Oct 24 13:28:36 CDT 2023
;; MSG SIZE  rcvd: 57

Any help understanding and addressing this is greatly appreciated!

Jason

Re: SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Gavin Henry]

Hi,

I've just released https://sentrypeer.com

About SentryPeerHQ -> https://sentrypeer.com/about
Fully Open Source -> https://github.com/SentryPeer/SentryPeerHQ
Always free -> https://sentrypeer.com/pricing (for those that contribute
data by running an official SentryPeer node or their own honeypot)

Thanks,
Gavin.

On Tue, 29 Mar 2022 at 20:39, Gavin Henry  wrote:

> Hi all,
>
> Come a long way since Nov:
>
> https://github.com/SentryPeer/SentryPeer/releases/tag/v1.4.0
>
> Peer to peer bad_actor replication is now released. Deutsche Telekom
> "T-Pot - The All In One Honeypot Platform" included SentryPeer
> (https://github.com/telekom-security/tpotce/tree/22.x) and Kali Linux
> is coming - https://bugs.kali.org/view.php?id=7523#c15939
>
> Would love to have some testers onboard!
>
> Thanks,
> Gavin.
>


-- 
Kind Regards,

Gavin Henry.
Managing Director.

T +44 (0) 330 44 50 000
D +44 (0) 330 44 55 007
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghe...@suretec.co.uk

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/

Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: The James Gregory Centre, Campus 2,
Balgownie Road, Aberdeen. AB22 8GU.

Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

OpenPGP (GPG/PGP) Public Key: 0x8CFBA8E6 - Import from hkp://
pool.subkeys.pgp.net
or http://www.suretecgroup.com/0x8CFBA8E6.gpg

Re: What's a "normal" ratio of web sites to IP addresses...

[John McCormac]

On 31/03/2022 23:15, Bill Woodcock wrote:

…in a run-of-the-mill web hoster?

This is really a question specifically for folks with web-site-hosting 
businesses.

If you had, say, ten million web site customers, each with their own unique 
domain name, how many IPv4 addresses would you think was a reasonable number to 
host those on?  HTTP name-based virtual-hosting means that you could, 
hypothetically, pile all ten million into a single IP address.  At the other 
end of the spectrum, you could chew up ten million IPv4 addresses, giving a 
unique one to each customer.  Presumably the actual practice lies somewhere 
in-between.  But what ratio do people in that business think is reasonable?  
10:1?  100:1?  1,000:1?



Not exactly in the web hosting side of the business but I do run a 
website to IP survey for the gTLDs, the new gTLDs and some ccTLDs each 
month that covers approximately 248.3 million domain names.


It is a complex question because the use of IP addresses for websites 
has been changing. Some of the IPs with large numbers of websites are 
actually registrar/hoster holding page websites, sales or Pay Per Click 
parking, DDoS protection, redirectors or load balancers. There is also 
the dedicated versus shared hosting issue which sees large numbers of 
websites on shared hosting and fewer on dedicated hosting with single 
IPs. Virtual hosting also complicates things because it is not unusal to 
see multiple domain names in different TLDs (eg: .COM and .ccTLD) 
pointing to the same IP.


There were 12,300,576 distinct IP addresses (IPv4) in the March 2022 
survey. That also included a small number of private IPs, bogons and 
non-routed IPs.


These are the counts for the top 20 IPs.
34.102.136.180  26308511
3.33.152.1478897990
15.197.142.173  8896940
34.117.168.233  5920870
198.185.159.144 3614480
198.185.159.145 3601589
198.49.23.144   3600433
198.49.23.145   3600334
198.54.117.212  3143453
198.54.117.215  3143451
198.54.117.218  3143448
198.54.117.211  3143447
198.54.117.216  3143446
198.54.117.210  3143445
198.54.117.217  3143444
34.98.99.30 2929772
188.114.97.72708015
188.114.96.72708013
23.227.38.742535730
35.186.238.101  2152424

Some of those are load balancers/redirectors/holding/sales/PPC/DDoS 
protection IPs.


The number of IPs with a single website was 6,943,207. The average 
number of sites per IP was 24.3414. The limitations are that despite the 
large number of domain names in the survey, it is not a complete survey 
of all TLDs (some ccTLDs are not covered). Even though websites may have 
IPs, that does not necessarily mean that there is an webserver running 
on the IP. (That's getting into Web Usage measurement which determines 
how websites are being used or not used.)


Regards...jmcc
--
**
John McCormac  *  e-mail: j...@hosterstats.com
MC2*  web: http://www.hosterstats.com/
22 Viewmount   *  Domain Registrations Statistics
Waterford  *  Domnomics - the business of domain names
Ireland*  https://amzn.to/2OPtEIO
IE *  Skype: hosterstats.com
**

--
This email has been checked for viruses by AVG.
https://www.avg.com

Re: What's a "normal" ratio of web sites to IP addresses...

[Owen DeLong via NANOG]

> On Mar 31, 2022, at 16:47 , Bill Woodcock  wrote:
> 
> 
> 
>> On Apr 1, 2022, at 12:15 AM, Bill Woodcock  wrote:
>> …in a run-of-the-mill web hoster?
>> I’m happy to take private replies and summarize/anonymize back to the list, 
>> if people prefer.
> 
> I asked the same question on Twitter, and got quite a lot of answers in both 
> places pretty quickly.  Thus far, 23 answers, with an average of about 
> 490,000 and a median of 1,500.
> 
> Obviously there are a lot of different factors that go into this, but the two 
> that were cited most frequently were that user who want their own individual 
> IP drive the number down, while large load-balancing/caching infrastructures 
> drive the number up.
> 
> Thank you all very much.  I appreciate the education, and I hope it’s useful 
> to others as well!
> 
>-Bill
> 

I would think that the 490,000 is more likely to reflect “web servers” per 
address vs. “web sites” per address.

I think that your mention of load-balancing and caching somewhat prove (or at 
least support) my speculation here.

I suspect that when you talk about “web sites” instead of “web servers”, the 
number probably falls somewhere in the sub-1k range.

For clarity, “https://www.amazon.com/[ …]” is a web 
site. It is almost certainly served by many many servers.

Prior to SNI, it was mostly 1 web server per address. In 2018, major CDNs were 
just starting to consider
ending support for non-SNI clients.

Owen

Re: What's a "normal" ratio of web sites to IP addresses...

[Bill Woodcock]

> On Apr 1, 2022, at 12:15 AM, Bill Woodcock  wrote:
> …in a run-of-the-mill web hoster?
> I’m happy to take private replies and summarize/anonymize back to the list, 
> if people prefer.

I asked the same question on Twitter, and got quite a lot of answers in both 
places pretty quickly.  Thus far, 23 answers, with an average of about 490,000 
and a median of 1,500.

Obviously there are a lot of different factors that go into this, but the two 
that were cited most frequently were that user who want their own individual IP 
drive the number down, while large load-balancing/caching infrastructures drive 
the number up.

Thank you all very much.  I appreciate the education, and I hope it’s useful to 
others as well!

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: What's a "normal" ratio of web sites to IP addresses...

[David Hubbard]

I don't know that there is a normal as it likely depends heavily on the revenue 
per customer and the service's tolerance for giving out IP addresses.  It also 
depends heavily on the back end infrastructhre and what kind of service is 
being provided.  There's probably massive scale behind Cloudflare IP addresses. 
 There are middleware-style ecommerce and blog platforms where there is the 
same, i.e. lots of sites behind any given IP because every customer receives 
the same service from the same software; likely thousands or more per IP in 
that case.  As you get more custom, probably far less per IP as that's when 
sites tend to start being mapped to dedicated virtual machines / servers, 
shared hosting, etc. where it goes anywhere from a few hundred to one site on a 
dedicated server.

Sorry to go off on a tangent but this got me wanting to rant. __

Still, to this day, SEO "experts" continue to guide clients towards service 
platforms (hosting, ecommerce, blogs, etc.) where they know it remains possible 
to get an exclusive IP address because they are "sure" that will produce 
meaningful search positioning gains.  I started a thread on this topic on nanog 
about this back in what I think was 2003 because every business entity had an 
SEO expert insisting their various websites receive IP addresses on subnets 
that differed enough to be "distant" from one another because Google would 
otherwise penalize them.  I expressed frustration at that because it ensured 
sites that had no technical need for an exclusive IP address would get one 
anyway, wasting a rapidly depleting resource, and costing the provider in the 
process while they could still get address space.

A Google Director, Craig Silverstein, said this wasn't the case, but just 
casually in a slashdot interview.

Matt Cutts later refuted it directly in 2006:  
https://www.mattcutts.com/blog/myth-busting-virtual-hosts-vs-dedicated-ip-addresses/

And he made the point once more in a 2013 Youtube video.

Three semi-official statements on the subject, the most recent nine years ago.  
So, it hasn't done much to dissuade the SEO experts of continuing to steer 
their clients towards places they think an exclusive IP will be issued.  
Fortunately the huge rise of CDN's seems to be getting things back on track, 
because those can produce more meaningful SEO benefit from the faster transit 
to eyeballs, putting exclusive IP recommendations on the back burner.

David



On 3/31/22, 6:19 PM, "NANOG on behalf of Bill Woodcock" 
 wrote:

…in a run-of-the-mill web hoster?

This is really a question specifically for folks with web-site-hosting 
businesses.

If you had, say, ten million web site customers, each with their own unique 
domain name, how many IPv4 addresses would you think was a reasonable number to 
host those on?  HTTP name-based virtual-hosting means that you could, 
hypothetically, pile all ten million into a single IP address.  At the other 
end of the spectrum, you could chew up ten million IPv4 addresses, giving a 
unique one to each customer.  Presumably the actual practice lies somewhere 
in-between.  But what ratio do people in that business think is reasonable?  
10:1?  100:1?  1,000:1?

I’m happy to take private replies and summarize/anonymize back to the list, 
if people prefer.

Thanks!

-Bill

What's a "normal" ratio of web sites to IP addresses...

[Bill Woodcock]

…in a run-of-the-mill web hoster?

This is really a question specifically for folks with web-site-hosting 
businesses.

If you had, say, ten million web site customers, each with their own unique 
domain name, how many IPv4 addresses would you think was a reasonable number to 
host those on?  HTTP name-based virtual-hosting means that you could, 
hypothetically, pile all ten million into a single IP address.  At the other 
end of the spectrum, you could chew up ten million IPv4 addresses, giving a 
unique one to each customer.  Presumably the actual practice lies somewhere 
in-between.  But what ratio do people in that business think is reasonable?  
10:1?  100:1?  1,000:1?

I’m happy to take private replies and summarize/anonymize back to the list, if 
people prefer.

Thanks!

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Gavin Henry]

Hi all,

Come a long way since Nov:

https://github.com/SentryPeer/SentryPeer/releases/tag/v1.4.0

Peer to peer bad_actor replication is now released. Deutsche Telekom
"T-Pot - The All In One Honeypot Platform" included SentryPeer
(https://github.com/telekom-security/tpotce/tree/22.x) and Kali Linux
is coming - https://bugs.kali.org/view.php?id=7523#c15939

Would love to have some testers onboard!

Thanks,
Gavin.

Re: SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Gavin Henry]

This should help
https://github.com/SentryPeer/SentryPeer/blob/aea3b3762c7df9e4d19901fa2dd82fe93a38f4cf/CHANGELOG.md#unreleased

Re: SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Gavin Henry]

On Fri, 26 Nov 2021, 18:59 Max Tulyev,  wrote:

> Hi Gavin,
>

Hi Max,


> I thought to do something similar ;)
>

What stopped you creating something? Or did you? Interested :)



> As I can see in the code, you count somebody as a bad actor just because
> of one UDP packet is received. It is a bad idea, because it is easy to
> spoof that packet and make a DoS against some good actor.
>

The next stage is to tag these probes as passive, then reply in SIP, like
you say and allow registrations and calls etc then mark them as aggressive.

I'm not actually replying to the packets, so no reflection attacks.


> Right way: you have to simulate a SIP dialog with this actor, i.e. reply
> them something and wait for the reaction. If the reaction will be like
> in a normal SIP call processing - congratulations, you found a hacker!
> If not, like you sent them a packet they do not expect - it is a DoS and
> a spoofed packet.
>

Agreed!

Thank you for reading and your reply.

>

Re: SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Max Tulyev]

Hi Gavin,

I thought to do something similar ;)

As I can see in the code, you count somebody as a bad actor just because 
of one UDP packet is received. It is a bad idea, because it is easy to 
spoof that packet and make a DoS against some good actor.


Right way: you have to simulate a SIP dialog with this actor, i.e. reply 
them something and wait for the reaction. If the reaction will be like 
in a normal SIP call processing - congratulations, you found a hacker! 
If not, like you sent them a packet they do not expect - it is a DoS and 
a spoofed packet.


24.11.21 23:19, Gavin Henry пише:

Hi all,

I hope you don't mind the post, but thought this might be of use and
in the spirit of release early, release often I've done an alpha
release:

https://github.com/SentryPeer/SentryPeer

There's a presentation too if you'd like to watch/read where I hope to
go with this:

https://blog.tadsummit.com/2021/11/17/sentrypeer/

Working on the API and web UI next, then the p2p part of it. Feel free
to submit any feature requests or have a play :-)

Thanks for reading and any feedback is welcome!

Re: SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Gavin Henry]

On Thu, 25 Nov 2021 at 00:53, Eric Kuhnke  wrote:
>
> Anecdotally, anyone that's had reason to manually go through logs for port 
> 5060 SIP for any public facing ipv4 /32 will see the vast amounts of random 
> "things" out there on the internet trying common extension password combos to 
> register.
>
> It's been a large amount of background noise on the internet for a very log 
> time now.

Hi Eric,

Have you done anything with this data before?

Thanks.

Re: SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Eric Kuhnke]

Anecdotally, anyone that's had reason to manually go through logs for port
5060 SIP for any public facing ipv4 /32 will see the vast amounts of random
"things" out there on the internet trying common extension password combos
to register.

It's been a large amount of background noise on the internet for a very log
time now.



On Wed, Nov 24, 2021 at 5:20 PM Gavin Henry  wrote:

> Hi all,
>
> I hope you don't mind the post, but thought this might be of use and
> in the spirit of release early, release often I've done an alpha
> release:
>
> https://github.com/SentryPeer/SentryPeer
>
> There's a presentation too if you'd like to watch/read where I hope to
> go with this:
>
> https://blog.tadsummit.com/2021/11/17/sentrypeer/
>
> Working on the API and web UI next, then the p2p part of it. Feel free
> to submit any feature requests or have a play :-)
>
> Thanks for reading and any feedback is welcome!
>
> --
> Kind Regards,
> Gavin Henry.
>

SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

[Gavin Henry]

Hi all,

I hope you don't mind the post, but thought this might be of use and
in the spirit of release early, release often I've done an alpha
release:

https://github.com/SentryPeer/SentryPeer

There's a presentation too if you'd like to watch/read where I hope to
go with this:

https://blog.tadsummit.com/2021/11/17/sentrypeer/

Working on the API and web UI next, then the p2p part of it. Feel free
to submit any feature requests or have a play :-)

Thanks for reading and any feedback is welcome!

-- 
Kind Regards,
Gavin Henry.

RE: IP addresses on subnet edge (/24)

[Brian Turnbow via NANOG]

> On 9/14/20 2:25 PM, Andrey Khomyakov wrote:
> > TL;DR I suspect there are middle boxes that don't like IPs ending in
> > .255. Anyone seen that?
> 
> Yes. We'd every so often get random complaints that "my friend can't reach
> my website but I can", etc., with not enough detail to track it down. The
> problem would disappear when we moved it to another IP address.
> 
> Because of this, we stopped allocating customer websites on .0 and .255 IP
> addresses about 10 years ago, instead using them for internal / controlled
> access purposes where we could investigate any problems.
> (Which never occur. )

We have started using .0 and .255  again in the past two years more or less.  
here is what one NAS shows 26 .255 users and 21 .0  users

asr1006-jn1#sh user | count \.255$
Number of lines which match regexp = 26
asr1006-jn1#sh user | count \.0$
Number of lines which match regexp = 21

We do occasionally have to change an IP but it is rare and for the most part 
things just work.
This is much different to 10 years ago where it was impossible to use them and 
we needed to exclude them from our pools.

A plus,  it is kind of fun when a super consultant calls and says he can't use 
a broadcast/network address for nat or a vpn endpoint.

Brian

RE: IP addresses on subnet edge (/24)

[Joe Klein]

You could have them try the AWS E2 reachability site to confirm if this is the 
case.

https://ec2-reachability.amazonaws.com/

Many of their test nodes end with .255 or .0. There are a few ending with 
255.255 and several that end with 0.0.

I’m not sure what the website test actually does (ICMP versus TCP test or 
something else), but you can also connect to those IPs (at least the two that I 
just tested) over port 80, to test the full handshake. You mentioned 
ClientHello/ServerHello, these nodes don't respond over port 443 (only saw 
SYN). Kinda makes sense given they're IP addresses.

-joe



From: NANOG  On Behalf Of 
Andrey Khomyakov
Sent: Monday, September 14, 2020 16:26
To: Nanog 
Subject: IP addresses on subnet edge (/24)

 
 External Mail
 
TL;DR I suspect there are middle boxes that don't like IPs ending in .255. 
Anyone seen that?

Folks, 
We are troubleshooting a strange issue where some of our customers cannot 
establish a successful connection with our HTTP front end. In addition to 
checking the usual things like routing and interface errors and security policy 
configurations, hopening support tickets with the load balancer vendor so far 
all to no avail, we did packet captures.
Based on the packet captures we receive a SYN, we reply with SYN-ACK, but the 
client never actually receives that SYN-ACK. In a different instance the 3-way 
completes, followed by TLS client hello to us, we reply with TLS Server Hello 
and that server hello never makes it to the client.
And again, this is only affecting a small subset of customers thus suggesting 
it's not the load balancer or the edge routing configuration (in fact we can 
traceroute fine to the customer's IP).
So far the only remaining theory that remains is that there are middle boxes 
out there that do not like IPs ending in .255. The service that the clients 
can't get to is hosted on two IPs ending in .255
Let's just say they are x.x.121.255 and x.x.125.255. We even stood up a basic 
"hello world" web server on x.x.124.255 with the same result. Standing up the 
very same basic webserver on x.x.124.250 allows the client to succeed.
So far we have a friendly customer who has been working with us on 
troubleshooting the issue and we have some pcaps from the client's side 
somewhat confirming that it's not the customer's system either.
This friendly customer is in a small 5 people office with Spectrum business 
internet (that's the SYN-ACK case). The same customer tried hopping on his LTE 
hotspot which came up as Cellco Partnership DBA Verizon Wireless with the same 
result (that's the TLS server hello case). That same customer with the same 
workstation drives a town over and he can get to the application fine (we are 
still waiting for the customer to let us know what that source IP is when it 
does work).
Before you suggest that those .255 addresses are broadcasts on some VLAN, they 
are not. They are injected as /32s using a routing protocol, while the VLAN 
addressing is all RFC1918 addressing.

--Andrey

Re: IP addresses on subnet edge (/24)

[Jeremy Visser]

On Tue, Sep 15, 2020 at 8:26 AM Töma Gavrichenkov  wrote:

> Also .0 and .1.
>
> Yes, there was some kind of a strange behavior with those addresses
> before.  We excluded those from rotation back in 2011 when that was really
> biting us.  There's an impression that this issue has become much less
> troubling over the years, didn't have time to investigate though.
>

Yep, I once had a customer (circa 2013–2014) who couldn't load
https://www.stgeorge.com.au/ because they (a PPP–based user, where
addressing is point to point, effectively /32 each end if you like) had an
IP address ending in .0, despite it being in the middle of an otherwise
larger pool. Some middlebox forming opinions about an address it has no
business forming an opinion about.

Re: IP addresses on subnet edge (/24)

[Robert L Mathews]

On 9/14/20 2:25 PM, Andrey Khomyakov wrote:
> TL;DR I suspect there are middle boxes that don't like IPs ending in
> .255. Anyone seen that?

Yes. We'd every so often get random complaints that "my friend can't
reach my website but I can", etc., with not enough detail to track it
down. The problem would disappear when we moved it to another IP address.

Because of this, we stopped allocating customer websites on .0 and .255
IP addresses about 10 years ago, instead using them for internal /
controlled access purposes where we could investigate any problems.
(Which never occur. )

-- 
Robert L Mathews, Tiger Technologies, http://www.tigertech.net/

Re: IP addresses on subnet edge (/24)

[Mark Andrews]

You may want to do traceroute using syn/ack packets to find the offending piece 
of equipment (may require modifying traceroute to set the syn and ack).

> On 15 Sep 2020, at 07:25, Andrey Khomyakov  wrote:
> 
> TL;DR I suspect there are middle boxes that don't like IPs ending in .255. 
> Anyone seen that?
> 
> Folks,
> We are troubleshooting a strange issue where some of our customers cannot 
> establish a successful connection with our HTTP front end. In addition to 
> checking the usual things like routing and interface errors and security 
> policy configurations, hopening support tickets with the load balancer vendor 
> so far all to no avail, we did packet captures.
> Based on the packet captures we receive a SYN, we reply with SYN-ACK, but the 
> client never actually receives that SYN-ACK. In a different instance the 
> 3-way completes, followed by TLS client hello to us, we reply with TLS Server 
> Hello and that server hello never makes it to the client.
> And again, this is only affecting a small subset of customers thus suggesting 
> it's not the load balancer or the edge routing configuration (in fact we can 
> traceroute fine to the customer's IP).
> So far the only remaining theory that remains is that there are middle boxes 
> out there that do not like IPs ending in .255. The service that the clients 
> can't get to is hosted on two IPs ending in .255
> Let's just say they are x.x.121.255 and x.x.125.255. We even stood up a basic 
> "hello world" web server on x.x.124.255 with the same result. Standing up the 
> very same basic webserver on x.x.124.250 allows the client to succeed.
> So far we have a friendly customer who has been working with us on 
> troubleshooting the issue and we have some pcaps from the client's side 
> somewhat confirming that it's not the customer's system either.
> This friendly customer is in a small 5 people office with Spectrum business 
> internet (that's the SYN-ACK case). The same customer tried hopping on his 
> LTE hotspot which came up as Cellco Partnership DBA Verizon Wireless with the 
> same result (that's the TLS server hello case). That same customer with the 
> same workstation drives a town over and he can get to the application fine 
> (we are still waiting for the customer to let us know what that source IP is 
> when it does work).
> Before you suggest that those .255 addresses are broadcasts on some VLAN, 
> they are not. They are injected as /32s using a routing protocol, while the 
> VLAN addressing is all RFC1918 addressing.
> 
> --Andrey

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: IP addresses on subnet edge (/24)

[Töma Gavrichenkov]

Peacez

On Tue, Sep 15, 2020, 12:26 AM Andrey Khomyakov 
wrote:

> TL;DR I suspect there are middle boxes that don't like IPs ending in .255.
> Anyone seen that?
>

Also .0 and .1.

Yes, there was some kind of a strange behavior with those addresses
before.  We excluded those from rotation back in 2011 when that was really
biting us.  There's an impression that this issue has become much less
troubling over the years, didn't have time to investigate though.

--
Töma

>

Re: IP addresses on subnet edge (/24)

[Tom Hill]

On 14/09/2020 22:25, Andrey Khomyakov wrote:
> TL;DR I suspect there are middle boxes that don't like IPs ending in
> .255. Anyone seen that?

Yes, but not for many, MANY years. I would expect that this service
might not like addresses ending in .0 either?

It was ca. 2010, when I started receiving an increasing number of
complaints that connections from addresses ending in .0 or .255 were
failing toward my (at the time) hosted services. This behaviour was
eventually* narrowed to iptables rules carelessly included with 'Atomic
Secured Linux' that purposely blackholed connections if the source
address' most specific octet happened to contain .0 or .255.

I'm sure that 'ASL' wasn't the only piece of software to have shipped
with this default behaviour, so should you discover any box of any sort,
configuration (or age) blindly hampering the connectivity for addresses
with all-1s or all-0s in any of the three most-specific octets, please
take this as infallible permission to promptly introduce it to the
nearest body of water. :)

* I still have AAISP - my home ISP at the time - to thank for routing me
a /30 with a .255 address in it! It wouldn't have been as easy to
resolve without that - very few UK consumers were being assigned
addresses with .255 in them at the time.

-- 
Tom

Re: IP addresses on subnet edge (/24)

[Warren Kumari]

On Mon, Sep 14, 2020 at 5:28 PM Andrey Khomyakov
 wrote:
>
> TL;DR I suspect there are middle boxes that don't like IPs ending in .255. 
> Anyone seen that?

Windows XP/Windows 2003 both had an issue where addresses ending in
.255 wouldn't work, regardless of the mask. It seems unlikely that
there are middleboxes that are still that old kicking around (largely
because they would likely have been 0wned and tossed out), but...

There used to be a knowledge base article on this -
http://support.microsoft.com/kb/281579 according to my bookmarks, but
it has disappeared...

W


>
> Folks,
> We are troubleshooting a strange issue where some of our customers cannot 
> establish a successful connection with our HTTP front end. In addition to 
> checking the usual things like routing and interface errors and security 
> policy configurations, hopening support tickets with the load balancer vendor 
> so far all to no avail, we did packet captures.
> Based on the packet captures we receive a SYN, we reply with SYN-ACK, but the 
> client never actually receives that SYN-ACK. In a different instance the 
> 3-way completes, followed by TLS client hello to us, we reply with TLS Server 
> Hello and that server hello never makes it to the client.
> And again, this is only affecting a small subset of customers thus suggesting 
> it's not the load balancer or the edge routing configuration (in fact we can 
> traceroute fine to the customer's IP).
> So far the only remaining theory that remains is that there are middle boxes 
> out there that do not like IPs ending in .255. The service that the clients 
> can't get to is hosted on two IPs ending in .255
> Let's just say they are x.x.121.255 and x.x.125.255. We even stood up a basic 
> "hello world" web server on x.x.124.255 with the same result. Standing up the 
> very same basic webserver on x.x.124.250 allows the client to succeed.
> So far we have a friendly customer who has been working with us on 
> troubleshooting the issue and we have some pcaps from the client's side 
> somewhat confirming that it's not the customer's system either.
> This friendly customer is in a small 5 people office with Spectrum business 
> internet (that's the SYN-ACK case). The same customer tried hopping on his 
> LTE hotspot which came up as Cellco Partnership DBA Verizon Wireless with the 
> same result (that's the TLS server hello case). That same customer with the 
> same workstation drives a town over and he can get to the application fine 
> (we are still waiting for the customer to let us know what that source IP is 
> when it does work).
> Before you suggest that those .255 addresses are broadcasts on some VLAN, 
> they are not. They are injected as /32s using a routing protocol, while the 
> VLAN addressing is all RFC1918 addressing.
>
> --Andrey



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

IP addresses on subnet edge (/24)

[Andrey Khomyakov]

TL;DR I suspect there are middle boxes that don't like IPs ending in .255.
Anyone seen that?

Folks,
We are troubleshooting a strange issue where some of our customers cannot
establish a successful connection with our HTTP front end. In addition to
checking the usual things like routing and interface errors and security
policy configurations, hopening support tickets with the load balancer
vendor so far all to no avail, we did packet captures.
Based on the packet captures we receive a SYN, we reply with SYN-ACK, but
the client never actually receives that SYN-ACK. In a different instance
the 3-way completes, followed by TLS client hello to us, we reply with TLS
Server Hello and that server hello never makes it to the client.
And again, this is only affecting a small subset of customers thus
suggesting it's not the load balancer or the edge routing configuration (in
fact we can traceroute fine to the customer's IP).
So far the only remaining theory that remains is that there are middle
boxes out there that do not like IPs ending in .255. The service that the
clients can't get to is hosted on two IPs ending in .255
Let's just say they are x.x.121.255 and x.x.125.255. We even stood up a
basic "hello world" web server on x.x.124.255 with the same result.
Standing up the very same basic webserver on x.x.124.250 allows the client
to succeed.
So far we have a friendly customer who has been working with us on
troubleshooting the issue and we have some pcaps from the client's side
somewhat confirming that it's not the customer's system either.
This friendly customer is in a small 5 people office with Spectrum business
internet (that's the SYN-ACK case). The same customer tried hopping on his
LTE hotspot which came up as Cellco Partnership DBA Verizon Wireless with
the same result (that's the TLS server hello case). That same customer with
the same workstation drives a town over and he can get to the application
fine (we are still waiting for the customer to let us know what that source
IP is when it does work).
Before you suggest that those .255 addresses are broadcasts on some VLAN,
they are not. They are injected as /32s using a routing protocol, while the
VLAN addressing is all RFC1918 addressing.

--Andrey

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[William Guo]

Would love to have the hulu contact as well.

Thanks, Drew and Josh.

On Fri, Dec 13, 2019 at 4:05 AM Josh Luthman 
wrote:

> Can you share the contact information for the next person that runs into
> this problem?
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
> On Thu, Dec 12, 2019 at 2:01 PM Drew Weaver 
> wrote:
>
>> We’ve had success contacting Hulu and having them mark the tiny range of
>> applicable IPs as not being “cloud”.
>>
>>
>>
>> *From:* NANOG  *On
>> Behalf Of *Eric Fulton
>> *Sent:* Thursday, December 5, 2019 2:37 PM
>> *To:* Mark Tinka 
>> *Cc:* nanog@nanog.org
>> *Subject:* Re: Hulu thinks all my IP addresses are "business class", how
>> to reach them?
>>
>>
>>
>> This happened to us as well.  We've had probably over 100 requests over
>> the last few years, but thankfully most of our customers are fine with just
>> not purchasing Hulu.  We've only lost below 5 customers from this issue.
>>
>>
>> EF
>>
>>
>>
>> Treasure State Internet & Telegraph
>>
>> 406.204.4777
>>
>> http://tsi.io
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 27, 2019 at 3:32 AM Mark Tinka  wrote:
>>
>>
>>
>> On 21/Nov/19 12:32, t...@pelican.org wrote:
>>
>> > If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip
>> to the US and watch them on my laptop, no-one is screaming that I'm
>> violating someone's geographic distribution rights by doing so.
>>
>> They would if it was possible to track you. Whenever I played DVD's or
>> BD's with my PS3/PS4, I sometimes hit issue because those boxes were
>> online, vs. my regular DVD player which wasn't.
>>
>> Offline DVD tech. is old school.
>>
>> Because tracking can be done with 2019 tech. due to VoD and its use of
>> the Internet, they will scream.
>>
>> Mark.
>>
>>

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Josh Luthman]

Can you share the contact information for the next person that runs into
this problem?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Thu, Dec 12, 2019 at 2:01 PM Drew Weaver  wrote:

> We’ve had success contacting Hulu and having them mark the tiny range of
> applicable IPs as not being “cloud”.
>
>
>
> *From:* NANOG  *On Behalf
> Of *Eric Fulton
> *Sent:* Thursday, December 5, 2019 2:37 PM
> *To:* Mark Tinka 
> *Cc:* nanog@nanog.org
> *Subject:* Re: Hulu thinks all my IP addresses are "business class", how
> to reach them?
>
>
>
> This happened to us as well.  We've had probably over 100 requests over
> the last few years, but thankfully most of our customers are fine with just
> not purchasing Hulu.  We've only lost below 5 customers from this issue.
>
>
> EF
>
>
>
> Treasure State Internet & Telegraph
>
> 406.204.4777
>
> http://tsi.io
>
>
>
>
>
>
>
>
>
> On Wed, Nov 27, 2019 at 3:32 AM Mark Tinka  wrote:
>
>
>
> On 21/Nov/19 12:32, t...@pelican.org wrote:
>
> > If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip
> to the US and watch them on my laptop, no-one is screaming that I'm
> violating someone's geographic distribution rights by doing so.
>
> They would if it was possible to track you. Whenever I played DVD's or
> BD's with my PS3/PS4, I sometimes hit issue because those boxes were
> online, vs. my regular DVD player which wasn't.
>
> Offline DVD tech. is old school.
>
> Because tracking can be done with 2019 tech. due to VoD and its use of
> the Internet, they will scream.
>
> Mark.
>
>

RE: Hulu thinks all my IP addresses are "business class", how to reach them?

[Drew Weaver]

We’ve had success contacting Hulu and having them mark the tiny range of 
applicable IPs as not being “cloud”.

From: NANOG  On Behalf Of Eric 
Fulton
Sent: Thursday, December 5, 2019 2:37 PM
To: Mark Tinka 
Cc: nanog@nanog.org
Subject: Re: Hulu thinks all my IP addresses are "business class", how to reach 
them?

This happened to us as well.  We've had probably over 100 requests over the 
last few years, but thankfully most of our customers are fine with just not 
purchasing Hulu.  We've only lost below 5 customers from this issue.

EF

Treasure State Internet & Telegraph
406.204.4777
http://tsi.io




On Wed, Nov 27, 2019 at 3:32 AM Mark Tinka 
mailto:mark.ti...@seacom.mu>> wrote:


On 21/Nov/19 12:32, t...@pelican.org<mailto:t...@pelican.org> wrote:

> If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the 
> US and watch them on my laptop, no-one is screaming that I'm violating 
> someone's geographic distribution rights by doing so.

They would if it was possible to track you. Whenever I played DVD's or
BD's with my PS3/PS4, I sometimes hit issue because those boxes were
online, vs. my regular DVD player which wasn't.

Offline DVD tech. is old school.

Because tracking can be done with 2019 tech. due to VoD and its use of
the Internet, they will scream.

Mark.

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Eric Fulton]

This happened to us as well.  We've had probably over 100 requests over the
last few years, but thankfully most of our customers are fine with just not
purchasing Hulu.  We've only lost below 5 customers from this issue.

EF

Treasure State Internet & Telegraph
406.204.4777
http://tsi.io




On Wed, Nov 27, 2019 at 3:32 AM Mark Tinka  wrote:

>
>
> On 21/Nov/19 12:32, t...@pelican.org wrote:
>
> > If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip
> to the US and watch them on my laptop, no-one is screaming that I'm
> violating someone's geographic distribution rights by doing so.
>
> They would if it was possible to track you. Whenever I played DVD's or
> BD's with my PS3/PS4, I sometimes hit issue because those boxes were
> online, vs. my regular DVD player which wasn't.
>
> Offline DVD tech. is old school.
>
> Because tracking can be done with 2019 tech. due to VoD and its use of
> the Internet, they will scream.
>
> Mark.
>

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Mark Tinka]

On 21/Nov/19 12:32, t...@pelican.org wrote:

> If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the 
> US and watch them on my laptop, no-one is screaming that I'm violating 
> someone's geographic distribution rights by doing so.

They would if it was possible to track you. Whenever I played DVD's or
BD's with my PS3/PS4, I sometimes hit issue because those boxes were
online, vs. my regular DVD player which wasn't.

Offline DVD tech. is old school.

Because tracking can be done with 2019 tech. due to VoD and its use of
the Internet, they will scream.

Mark.

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Mark Tinka]

On 19/Nov/19 20:17, Doug McIntyre wrote:

>
> If I knew why they considered my IP addresses "business" IP addresses,
> I could possibly change something?

Perhaps because it's static :-)?

Also, why are business people on Hulu during business hours :-).

Mark <= who asks while taking a work Zoom call in nothing + slippers
with a glass of wine in front of Netflix at home :-)...

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Mark Tinka]

On 19/Nov/19 20:38, Blake Hudson wrote:

>
>
> Thanks Doug. I'm interested in following your thread because we have
> some IP ranges we intentionally wanted to be classified as static or
> non-residential by other entities so that our customers on these
> ranges could operate their own email servers. This was done through a
> combination of reverse DNS including the word "static" (or similar)
> and the SpamHaus PBL listings (or similar). At the same time, we would
> not want Hulu to stop providing services to these customers due to
> this classification. Ultimately, I guess it's up to Hulu who they want
> to serve as a customer of theirs, but as a network operator providing
> access to to the internet (including access to services like Hulu) I'm
> sure we would be negatively impacted by such a decision on the part of
> Hulu causing to devalue the utility our services.

Dropped Hulu within 2 months of signing up, back in 2016.

If it ain't local, we ain't buyin', and Hulu seem to have little
interest in spreading.

Mark.

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Aaron C. de Bruyn via NANOG]

Bad wording on my part.  I wasn't trying to imply their statement was
true--just a bit of humor.

-A

On Fri, Nov 22, 2019 at 6:09 PM Owen DeLong  wrote:

>
>
> On Nov 22, 2019, at 17:47 , Aaron C. de Bruyn via NANOG 
> wrote:
>
> On Fri, Nov 22, 2019 at 8:52 AM Blake Hudson  wrote:
>
>> This is absolutely an issue with Xbox Live/Sony PSN or RBLs used by mail
>> servers for reputation purposes. For better or worse these systems equate
>> one IPv4 address == one user (and possibly one IPv6 /64 == one user). My
>> opinion is that this may be a reasonable or "good enough" assumption
>>
>
> Talk to someone who has been sued for downloading or sharing movies.
> They'll swear on their own grave that one IP can never equal one user. ;)
>
> -A
>
>
> I’ll swear it’s a horrible assumption.
>
> Personally, I use many IP addresses each day.
> Some of them are also used by others.
> Some of them are not.
>
> Equating IP Address <-> Person relationships as being anything remotely
> resembling 1:1 is beyond absurd. To do so with an IPv6 /64 is even more so.
>
> Considering it to be reasonable or “good enough” is so far from valid I
> don’t even know where to begin.
>
> Owen
>
>

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Doug McIntyre]

On Fri, Nov 22, 2019 at 05:05:20AM +, Mike Lewinski wrote:
> Question: is anyone who is currently suffering this issue also doing 1:many 
> NAT? Or running a proxy server that might cause multiple clients to all 
> appear from the same IP address? I believe NAT might be the cause of one of 
> our customer's complaints wrt content provider blocking.


I'm the OP.

We do not do CGNAT or any sort of proxying. It is straight up one
public IP per access customer, with their NAT'd DSL router taking the
public IP. Nor do we offer any sort of VPN services. Just because of
our past history, all access customers are static IPs, so many of them
have had the same IP for over a decade (ie. highly unlikely that I have
a bad apple hopping a dynamic pool and ruining it for all). 

Furthermore, we have 3 disjoint ARIN PIR blocks. All three of them are
blocked across the whole range. So, somebody at Hulu took a look
at our AS, and blocked all we announce.

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Owen DeLong]

> On Nov 22, 2019, at 17:47 , Aaron C. de Bruyn via NANOG  
> wrote:
> 
> On Fri, Nov 22, 2019 at 8:52 AM Blake Hudson  <mailto:bl...@ispn.net>> wrote:
> This is absolutely an issue with Xbox Live/Sony PSN or RBLs used by mail 
> servers for reputation purposes. For better or worse these systems equate one 
> IPv4 address == one user (and possibly one IPv6 /64 == one user). My opinion 
> is that this may be a reasonable or "good enough" assumption
> 
> Talk to someone who has been sued for downloading or sharing movies.  They'll 
> swear on their own grave that one IP can never equal one user. ;)
> 
> -A

I’ll swear it’s a horrible assumption.

Personally, I use many IP addresses each day.
Some of them are also used by others.
Some of them are not.

Equating IP Address <-> Person relationships as being anything remotely 
resembling 1:1 is beyond absurd. To do so with an IPv6 /64 is even more so.

Considering it to be reasonable or “good enough” is so far from valid I don’t 
even know where to begin.

Owen

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Aaron C. de Bruyn via NANOG]

On Fri, Nov 22, 2019 at 8:52 AM Blake Hudson  wrote:

> This is absolutely an issue with Xbox Live/Sony PSN or RBLs used by mail
> servers for reputation purposes. For better or worse these systems equate
> one IPv4 address == one user (and possibly one IPv6 /64 == one user). My
> opinion is that this may be a reasonable or "good enough" assumption
>

Talk to someone who has been sued for downloading or sharing movies.
They'll swear on their own grave that one IP can never equal one user. ;)

-A

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Mike Lewinski]

Question: is anyone who is currently suffering this issue also doing 1:many 
NAT? Or running a proxy server that might cause multiple clients to all appear 
from the same IP address? I believe NAT might be the cause of one of our 
customer's complaints wrt content provider blocking.

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Crist Clark]

Probably because a market would quickly pop up to sell or rent accounts
created in one region to others.

On Thu, Nov 21, 2019, 2:32 AM t...@pelican.org  wrote:

> On Wednesday, 20 November, 2019 21:25, "William Herrin" 
> said:
>
> > This is why you don't go after Hulu. You go after the content owners who
> > conspired to compel Hulu to limit distribution in a way that tortiously
> > interferes with your contract with your eyeball customers.
>
> Am I the only one who's baffled in the context of a paid service why so
> much focus is put on where the consumption takes place (hard), and so
> little on where the transaction take place (easy)?
>
> I understand, even if I don't necessarily always agree with, market
> segmentation, differentiated pricing, accurate P for different business
> units, etc, that mean for example if you're a US citizen you need to pay
> Disney US the prevailing US price to watch Disney content, but if you're an
> EU citizen you need to pay Disney EMEA the prevailing EU price to watch
> Disney content.  Surely that transaction is the thing content creators and
> distributors care about?
>
> If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to
> the US and watch them on my laptop, no-one is screaming that I'm violating
> someone's geographic distribution rights by doing so.  If a US citizen is
> paying for Hulu, from a US billing address, on a US credit card, but
> happens to be watching from their hotel in Italy, why does anyone care?
>
> I can see why it's different and more complicated for content that's
> provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation
> for paid services seems a terrible waste of time and effort on both sides.
>
> Or am I woefully naive, and it's actually trivial for a non-US resident to
> come up with a US credit card and billing address to pay for the service?
>
> Regards,
> Tim.
>
>
>
>
On Thu, Nov 21, 2019, 2:32 AM t...@pelican.org  wrote:

> On Wednesday, 20 November, 2019 21:25, "William Herrin" 
> said:
>
> > This is why you don't go after Hulu. You go after the content owners who
> > conspired to compel Hulu to limit distribution in a way that tortiously
> > interferes with your contract with your eyeball customers.
>
> Am I the only one who's baffled in the context of a paid service why so
> much focus is put on where the consumption takes place (hard), and so
> little on where the transaction take place (easy)?
>
> I understand, even if I don't necessarily always agree with, market
> segmentation, differentiated pricing, accurate P for different business
> units, etc, that mean for example if you're a US citizen you need to pay
> Disney US the prevailing US price to watch Disney content, but if you're an
> EU citizen you need to pay Disney EMEA the prevailing EU price to watch
> Disney content.  Surely that transaction is the thing content creators and
> distributors care about?
>
> If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to
> the US and watch them on my laptop, no-one is screaming that I'm violating
> someone's geographic distribution rights by doing so.  If a US citizen is
> paying for Hulu, from a US billing address, on a US credit card, but
> happens to be watching from their hotel in Italy, why does anyone care?
>
> I can see why it's different and more complicated for content that's
> provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation
> for paid services seems a terrible waste of time and effort on both sides.
>
> Or am I woefully naive, and it's actually trivial for a non-US resident to
> come up with a US credit card and billing address to pay for the service?
>
> Regards,
> Tim.
>
>
>
>

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[William Herrin]

On Thu, Nov 21, 2019 at 10:22 AM Blake Hudson  wrote:
> t...@pelican.org wrote on 11/21/2019 4:32 AM:
> > Or am I woefully naive, and it's actually trivial for a non-US resident
to come up with a US credit card and billing address to pay for the service?

1. Buy a prepaid debit card.
2. Rent a mailbox at Mailboxes Etc. or a similar company.
3. Log in to the prepaid card's web site and enter the address of your
rented mailbox as the billing address.


> Tim, like you, I've been baffled by this choice as well. Why streaming
> video providers continue to choose a costly and convoluted path when a
> less convoluted and cheaper path exists to reach (seemingly) the same
> destination I will never know.

Again, streaming video providers did not make this choice. Content owners
did, and made its enforcement a contractual requirement for leasing that
content to the streaming video providers.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Blake Hudson]

t...@pelican.org wrote on 11/21/2019 4:32 AM:

On Wednesday, 20 November, 2019 21:25, "William Herrin"  said:


This is why you don't go after Hulu. You go after the content owners who
conspired to compel Hulu to limit distribution in a way that tortiously
interferes with your contract with your eyeball customers.

Am I the only one who's baffled in the context of a paid service why so much 
focus is put on where the consumption takes place (hard), and so little on 
where the transaction take place (easy)?

I understand, even if I don't necessarily always agree with, market segmentation, 
differentiated pricing, accurate P for different business units, etc, that 
mean for example if you're a US citizen you need to pay Disney US the prevailing US 
price to watch Disney content, but if you're an EU citizen you need to pay Disney 
EMEA the prevailing EU price to watch Disney content.  Surely that transaction is 
the thing content creators and distributors care about?

If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the 
US and watch them on my laptop, no-one is screaming that I'm violating 
someone's geographic distribution rights by doing so.  If a US citizen is 
paying for Hulu, from a US billing address, on a US credit card, but happens to 
be watching from their hotel in Italy, why does anyone care?

I can see why it's different and more complicated for content that's provided 
free but geo-constrained (e.g. BBC iPlayer), but IP geolocation for paid 
services seems a terrible waste of time and effort on both sides.

Or am I woefully naive, and it's actually trivial for a non-US resident to come 
up with a US credit card and billing address to pay for the service?

Regards,
Tim.



Tim, like you, I've been baffled by this choice as well. Why streaming 
video providers continue to choose a costly and convoluted path when a 
less convoluted and cheaper path exists to reach (seemingly) the same 
destination I will never know. Perhaps one company did it that way so 
others just copied the mistake? Perhaps providers feel it's necessary 
because not all of them require transactions with a billing/mailing 
address all the time (think free/trial services or gift cards)? One can 
only attempt to conceive of the inconceivable...

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Tom Beecher]

>
> If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to
> the US and watch them on my laptop, no-one is screaming that I'm violating
> someone's geographic distribution rights by doing so.  If a US citizen is
> paying for Hulu, from a US billing address, on a US credit card, but
> happens to be watching from their hotel in Italy, why does anyone care?
>

Hulu probably doesn't. But many content owners are still riding that Region
Locking Hype Train in the face of all the available evidence that it
doesn't really do anything but create a nuisance.  And they do pretty much
have you over the barrel, since you likely don't have another option.


On Thu, Nov 21, 2019 at 5:34 AM t...@pelican.org  wrote:

> On Wednesday, 20 November, 2019 21:25, "William Herrin" 
> said:
>
> > This is why you don't go after Hulu. You go after the content owners who
> > conspired to compel Hulu to limit distribution in a way that tortiously
> > interferes with your contract with your eyeball customers.
>
> Am I the only one who's baffled in the context of a paid service why so
> much focus is put on where the consumption takes place (hard), and so
> little on where the transaction take place (easy)?
>
> I understand, even if I don't necessarily always agree with, market
> segmentation, differentiated pricing, accurate P for different business
> units, etc, that mean for example if you're a US citizen you need to pay
> Disney US the prevailing US price to watch Disney content, but if you're an
> EU citizen you need to pay Disney EMEA the prevailing EU price to watch
> Disney content.  Surely that transaction is the thing content creators and
> distributors care about?
>
> If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to
> the US and watch them on my laptop, no-one is screaming that I'm violating
> someone's geographic distribution rights by doing so.  If a US citizen is
> paying for Hulu, from a US billing address, on a US credit card, but
> happens to be watching from their hotel in Italy, why does anyone care?
>
> I can see why it's different and more complicated for content that's
> provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation
> for paid services seems a terrible waste of time and effort on both sides.
>
> Or am I woefully naive, and it's actually trivial for a non-US resident to
> come up with a US credit card and billing address to pay for the service?
>
> Regards,
> Tim.
>
>
>

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[t...@pelican.org]

On Thursday, 21 November, 2019 12:00, "Rob Seastrom"  said:

>> On Nov 21, 2019, at 05:33, "t...@pelican.org"  wrote:
>>
>> Or am I woefully naive, and it's actually trivial for a non-US resident to 
>> come
>> up with a US credit card and billing address to pay for the service?
> 
> It’s a thing.   Need a US address but fairly straightforward.  Ask your
> favorite border hopping Canadian.
> 

Fair enough - thanks for the info.  These days, you have to show up in person 
at a branch with a passport to open almost any kind of bank account here, 
following a money-laundering crackdown, so I was assuming it ought to be a 
sufficiently-strong check to satisfy rights-holders.

Regards,
Tim.

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[t...@pelican.org]

On Wednesday, 20 November, 2019 21:25, "William Herrin"  said:

> This is why you don't go after Hulu. You go after the content owners who
> conspired to compel Hulu to limit distribution in a way that tortiously
> interferes with your contract with your eyeball customers.

Am I the only one who's baffled in the context of a paid service why so much 
focus is put on where the consumption takes place (hard), and so little on 
where the transaction take place (easy)?

I understand, even if I don't necessarily always agree with, market 
segmentation, differentiated pricing, accurate P for different business 
units, etc, that mean for example if you're a US citizen you need to pay Disney 
US the prevailing US price to watch Disney content, but if you're an EU citizen 
you need to pay Disney EMEA the prevailing EU price to watch Disney content.  
Surely that transaction is the thing content creators and distributors care 
about?

If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the 
US and watch them on my laptop, no-one is screaming that I'm violating 
someone's geographic distribution rights by doing so.  If a US citizen is 
paying for Hulu, from a US billing address, on a US credit card, but happens to 
be watching from their hotel in Italy, why does anyone care?

I can see why it's different and more complicated for content that's provided 
free but geo-constrained (e.g. BBC iPlayer), but IP geolocation for paid 
services seems a terrible waste of time and effort on both sides.

Or am I woefully naive, and it's actually trivial for a non-US resident to come 
up with a US credit card and billing address to pay for the service?

Regards,
Tim.

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Owen DeLong]

> On Nov 20, 2019, at 12:44 , Brandon Martin  wrote:
> 
> On 11/20/19 3:31 PM, Owen DeLong wrote:
>> As an ISP, there might be something there, but, you’d have to prove that you 
>> had a significant number of customers that left for that specific reason and 
>> you’d have to show the actual damages that resulted. Easy to estimate, very 
>> hard to prove.
> 
> Not only hard to prove, but the armchair lawyer in my has an inkling that 
> you'd have to show that they did it intentionally or went beyond being dumb 
> or knowledgeable about it and were somehow negligent.  The former seems even 
> more difficult than proving actual damages, and the latter seems like it may 
> not even apply or be possible.

Correct me if I’m wrong, but being dumb about it _IS_ negligent, isn’t it?

> What irks me most about these situations as an operator, and indeed something 
> that may push back on my previous statement of intent or negligence not being 
> possible/applicable, is that the services often make their geofencing/IP 
> classification system failures out as being the fault of the user's 
> telecommunications service provider when, in fact, the user's service 
> provider often has absolutely no direct control over what happens and, even 
> where they do have some form of direct control such as through a documented 
> operations-appeals channel, are still at the mercy of the service doing the 
> fencing/classification to correct the error.  At minimum, this could damage 
> customer good will toward their service provider.

Yep… Hence what I proposed as regulation to help curtail this BS.

> (And kudos where it's due to the providers who do NOT make such issues appear 
> to be the fault of the user's telecommunications service provider and instead 
> provide a real, useful means for the user to directly contact the content 
> provider to resolve the issue)

Who are they? I want to shift my services to them if I can. (So far, I haven’t 
found any)

Owen

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Ethan O'Toole]

This is why you don't go after Hulu. You go after the content owners who
conspired to compel Hulu to limit distribution in a way that tortiously
interferes with your contract with your eyeball customers. Then, before


Which in many cases is groups like the Screen Actors Guild and the music 
industry. As I understand it much of the music in TV shows require 
licensing and sometimes different license holders exist for a song 
depending on country.


While the television industry self-inflicts pain to it's userbase 
it's easier for the users to just pirate the content.



- Ethan

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[William Herrin]

On Wed, Nov 20, 2019 at 12:32 PM Owen DeLong  wrote:
> The problem here is that identifying class members is very hard (most
class members wouldn’t realize why they were not getting Hulu, and Hulu
probably either quickly corrects the problem on their end or blames the
ISP), meaning they wouldn’t realize their ability to join the class.
>
> As an individual customer, Hulu will refund your money and tell you to
piss off. That’s about all you’re likely to recover in the court case, too.
>
> As an ISP, there might be something there, but, you’d have to prove that
you had a significant number of customers that left for that specific
reason and you’d have to show the actual damages that resulted. Easy to
estimate, very hard to prove.

This is why you don't go after Hulu. You go after the content owners who
conspired to compel Hulu to limit distribution in a way that tortiously
interferes with your contract with your eyeball customers. Then, before
you've spent much money (filing lawsuits and notifying the defendants only
costs in the hundreds of dollars), you suggest to their respective counsels
that they didn't actually intend to exclude your customers and that if Hulu
weren't so reckless in their implementation you'd be inclined to drop the
matter.


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Brandon Martin]

On 11/20/19 3:31 PM, Owen DeLong wrote:
As an ISP, there might be something there, but, you’d have to prove that 
you had a significant number of customers that left for that specific 
reason and you’d have to show the actual damages that resulted. Easy to 
estimate, very hard to prove.


Not only hard to prove, but the armchair lawyer in my has an inkling 
that you'd have to show that they did it intentionally or went beyond 
being dumb or knowledgeable about it and were somehow negligent.  The 
former seems even more difficult than proving actual damages, and the 
latter seems like it may not even apply or be possible.


What irks me most about these situations as an operator, and indeed 
something that may push back on my previous statement of intent or 
negligence not being possible/applicable, is that the services often 
make their geofencing/IP classification system failures out as being the 
fault of the user's telecommunications service provider when, in fact, 
the user's service provider often has absolutely no direct control over 
what happens and, even where they do have some form of direct control 
such as through a documented operations-appeals channel, are still at 
the mercy of the service doing the fencing/classification to correct the 
error.  At minimum, this could damage customer good will toward their 
service provider.


(And kudos where it's due to the providers who do NOT make such issues 
appear to be the fault of the user's telecommunications service provider 
and instead provide a real, useful means for the user to directly 
contact the content provider to resolve the issue)

--
Brandon Martin

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Owen DeLong]

>> 
> I suppose a Hulu subscriber could dispute the charge or file a suit (class 
> action?) for damages: "Hulu took my money, but didn't provide the services 
> they advertised." As an ISP, some of us might even be in a position where we 
> encounter losses due to Hulu's (mis)classification resulting in customers 
> moving to the competition; I would think that would be sufficient grounds for 
> a suit.

The problem here is that identifying class members is very hard (most class 
members wouldn’t realize why they were not getting Hulu, and Hulu probably 
either quickly corrects the problem on their end or blames the ISP), meaning 
they wouldn’t realize their ability to join the class.

As an individual customer, Hulu will refund your money and tell you to piss 
off. That’s about all you’re likely to recover in the court case, too.

As an ISP, there might be something there, but, you’d have to prove that you 
had a significant number of customers that left for that specific reason and 
you’d have to show the actual damages that resulted. Easy to estimate, very 
hard to prove.

So in this particular case, I think Hulu is tragically safe from being held 
accountable.

I think the best solution would be something like this…

If congress were to revise the DMCA to provide a provision similar to the 
following:

1.  Digital Rights Management
Content producers and Content owners have the right to enforce their copyright 
through automated means
known as “Digital Rights Management” (DRM).

DRM mechanisms may include, but are not limited to any of the following:
+   IP Address based geographical location inference and content limitations
+   Efforts to avoid delivery of services to users of Virtual Private 
Networks
+   Software locks or limitations preventing playback based on machine 
configuration, software status,
or other variables.
+   Self-destructive content

2.  Duties of Content Producers and Content Owners
Content producers and Content owners must, however, ensure that any form of DRM 
employed in this
process does not in any way curtail the legitimate rights of end users who have 
lawfully purchased,
licensed, or otherwise through fair use or other mechanism obtained legitimate 
rights to the content.

3.  Rights of Consumers
The fair trade commission shall maintain a mechanism for consumers to report 
and document instances
where their content rights have been infringed, abridged, or otherwise hindered 
by DRM. Through this
process, the FTC shall investigate all credible complaints and make a 
determination of fact whether
the consumer’s rights were violated.

In such an instance where the FTC determines consumers rights were violated, 
the Content Owner,
Content Producer, and any Content Providers involved shall be jointly and 
severally liable for the following
damages:
+   Restitution to each affected consumer of the full cost (if any) 
born by the consumer in obtaining the
infringed rights.
+   A DRM free copy of the content in the same format(s) and usable 
with the same playback
mechanism(s) provided to each affected consumer.
+   A fine payable to the united States not to exceed $10,000 per 
incident per affected consumer.
+   Reimbursement to the FTC for all costs of the investigation and 
any process(es) related to
enforcement of any judgment resulting from the investigation.

In the event that a Content Owner, Producer, or Provider wishes to appeal an 
FTC ruling, the appeal
shall be heard in the circuit court of appeals covering the largest fraction of 
the affected consumers known
to be affected at the time of the ruling. While awaiting said hearing, the 
restitution to affected consumers
and DRM free copy shall be provided not less than 60 days after the initial 
ruling.

Owen

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Blake Hudson]

Owen DeLong wrote on 11/20/2019 11:51 AM:



On Nov 20, 2019, at 07:38 , Tom Beecher > wrote:


Never did figure out if it was stupidity
or malice driving that.


Personally I think it's neither; it's just $.

They could invest in a robust system to accurately identify what they 
chose not to allow to access the service. Or, they can choose to run 
with a 'close enough' system with some legitimate users caught in the 
middle.


They've most likely done the math and decided that the revenue lost 
from people getting caught up in inaccurate blocking is small enough 
that the investment in a more accurate method isn't worth it. This is 
unfortunately the more common decision in this age of worship at the 
Altar of Maximum Shareholder Value.


I think you are exactly right here. It’s yet another example of how 
the incentives around DRM are all messed up and are creating economic 
bias in favor of screwing consumers as much as possible without 
loosing too much revenue.


What is needed is either a more conscientious consumer base that will 
see this and react by voting with their wallets, or, regulation which 
provides more costly penalties for screwing over legitimate consumers.


Owen

I suppose a Hulu subscriber could dispute the charge or file a suit 
(class action?) for damages: "Hulu took my money, but didn't provide the 
services they advertised." As an ISP, some of us might even be in a 
position where we encounter losses due to Hulu's (mis)classification 
resulting in customers moving to the competition; I would think that 
would be sufficient grounds for a suit.

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Owen DeLong]

> On Nov 20, 2019, at 07:38 , Tom Beecher  wrote:
> 
> Never did figure out if it was stupidity
> or malice driving that.
> 
> Personally I think it's neither; it's just $.  
> 
> They could invest in a robust system to accurately identify what they chose 
> not to allow to access the service. Or, they can choose to run with a 'close 
> enough' system with some legitimate users caught in the middle. 
> 
> They've most likely done the math and decided that the revenue lost from 
> people getting caught up in inaccurate blocking is small enough that the 
> investment in a more accurate method isn't worth it. This is unfortunately 
> the more common decision in this age of worship at the Altar of Maximum 
> Shareholder Value. 

I think you are exactly right here. It’s yet another example of how the 
incentives around DRM are all messed up and are creating economic bias in favor 
of screwing consumers as much as possible without loosing too much revenue.

What is needed is either a more conscientious consumer base that will see this 
and react by voting with their wallets, or, regulation which provides more 
costly penalties for screwing over legitimate consumers.

Owen

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Tom Beecher]

>
> Never did figure out if it was stupidity
> or malice driving that.
>

Personally I think it's neither; it's just $.

They could invest in a robust system to accurately identify what they chose
not to allow to access the service. Or, they can choose to run with a
'close enough' system with some legitimate users caught in the middle.

They've most likely done the math and decided that the revenue lost from
people getting caught up in inaccurate blocking is small enough that the
investment in a more accurate method isn't worth it. This is unfortunately
the more common decision in this age of worship at the Altar of Maximum
Shareholder Value.

On Wed, Nov 20, 2019 at 12:20 AM Valdis Klētnieks 
wrote:

> On Tue, 19 Nov 2019 13:39:56 -0500, Tom Beecher said:
>
> > They are essentially equating 'business' with 'VPN provider'.
>
> Not at all surprised.
>
> Many moons ago, I had a Tor *relay* running on one machine in my home
> network,
> and Hulu decided that my connections from a *different* home machine were
> "VPN".  Now, if I were running a Tor *exit* node, I'd be totally OK with
> them
> rejecting my non-Tor connections because they were NATed to the same
> outside IP
> address - but Hulu should never have seen any packets from the relay and
> if I
> *was* using a VPN I'd have a *different* IP address.
>
> Near as I could determine, they were screen scraping the list of Tor relays
> and conflating them with exit nodes. Never did figure out if it was
> stupidity
> or malice driving that.
>

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Valdis Klētnieks]

On Tue, 19 Nov 2019 13:39:56 -0500, Tom Beecher said:

> They are essentially equating 'business' with 'VPN provider'.

Not at all surprised.

Many moons ago, I had a Tor *relay* running on one machine in my home network,
and Hulu decided that my connections from a *different* home machine were
"VPN".  Now, if I were running a Tor *exit* node, I'd be totally OK with them
rejecting my non-Tor connections because they were NATed to the same outside IP
address - but Hulu should never have seen any packets from the relay and if I
*was* using a VPN I'd have a *different* IP address.

Near as I could determine, they were screen scraping the list of Tor relays
and conflating them with exit nodes. Never did figure out if it was stupidity
or malice driving that.


pgpzxIsEJcPBX.pgp
Description: PGP signature

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Tom Beecher]

They are essentially equating 'business' with 'VPN provider'.

On Tue, Nov 19, 2019 at 1:25 PM Matt Hoppes <
mattli...@rivervalleyinternet.net> wrote:

> Why are "businesses" not allowed to watch HULU?
>
> On 11/19/19 1:17 PM, Doug McIntyre wrote:
> > On Mon, Nov 18, 2019 at 10:55:01AM -0600, Blake Hudson wrote:
> >> Doug, out of curiosity, what does Hulu do once they have classified your
> >> IP ranges as "business class"? Charge customers a different rate? Offer
> >> different content? Refuse service?
> >
> > They won't let any of my customers connect, blocking them with a
> > specific error number to reference by their support. When they do, Hulu
> > is either telling them that they are using a VPN (when we don't offer
> > any services like that), and then to whitelist them, they have to have
> > a "residential" IP address and not the "business" IP address we are
> > giving them, and won't go any further. Or they just say they can't
> > connect from the "business" IP addresses.
> >
> > If I knew why they considered my IP addresses "business" IP addresses,
> > I could possibly change something? But this seems to be an arbitrary
> > decision they changed about a week and a half ago for all my netblocks.
> >
> >
>

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Mike Hammett]

Hulu is the worst-run streaming service, mostly because they don't cooperate 
with ISPs in the least. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Doug McIntyre"  
To: nanog@nanog.org 
Sent: Monday, November 18, 2019 10:41:06 AM 
Subject: Hulu thinks all my IP addresses are "business class", how to reach 
them? 

I've been offering residential and business ISP services for a long time. 

Hulu recently blocked my customers from accessing their service, because my 
ARIN IP address blocks are "business class" instead of residential. 

I've tried to find a contact for them as I am not a customer, the 
supportrequ...@hulu.com address mentioned in NANOG previously is just 
an autoresponder that says open a ticket online (once you are logged into your 
account). 

Does anybody have a contact for them that I can discuss what they are 
looking at to determine if my IP addresses are "residential" 
vs. "business" class? 

Thanks. 

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Matt Hoppes]

Why are "businesses" not allowed to watch HULU?

On 11/19/19 1:17 PM, Doug McIntyre wrote:

On Mon, Nov 18, 2019 at 10:55:01AM -0600, Blake Hudson wrote:

Doug, out of curiosity, what does Hulu do once they have classified your
IP ranges as "business class"? Charge customers a different rate? Offer
different content? Refuse service?


They won't let any of my customers connect, blocking them with a
specific error number to reference by their support. When they do, Hulu
is either telling them that they are using a VPN (when we don't offer
any services like that), and then to whitelist them, they have to have
a "residential" IP address and not the "business" IP address we are
giving them, and won't go any further. Or they just say they can't
connect from the "business" IP addresses.

If I knew why they considered my IP addresses "business" IP addresses,
I could possibly change something? But this seems to be an arbitrary
decision they changed about a week and a half ago for all my netblocks.

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Doug McIntyre]

On Mon, Nov 18, 2019 at 10:55:01AM -0600, Blake Hudson wrote:
> Doug, out of curiosity, what does Hulu do once they have classified your 
> IP ranges as "business class"? Charge customers a different rate? Offer 
> different content? Refuse service?

They won't let any of my customers connect, blocking them with a
specific error number to reference by their support. When they do, Hulu
is either telling them that they are using a VPN (when we don't offer
any services like that), and then to whitelist them, they have to have
a "residential" IP address and not the "business" IP address we are
giving them, and won't go any further. Or they just say they can't
connect from the "business" IP addresses. 

If I knew why they considered my IP addresses "business" IP addresses,
I could possibly change something? But this seems to be an arbitrary
decision they changed about a week and a half ago for all my netblocks.

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Blake Hudson]

Doug, out of curiosity, what does Hulu do once they have classified your 
IP ranges as "business class"? Charge customers a different rate? Offer 
different content? Refuse service?



Doug McIntyre wrote on 11/18/2019 10:41 AM:

I've been offering residential and business ISP services for a long time.

Hulu recently blocked my customers from accessing their service, because my
ARIN IP address blocks are "business class" instead of residential.

I've tried to find a contact for them as I am not a customer, the
supportrequ...@hulu.com address mentioned in NANOG previously is just
an autoresponder that says open a ticket online (once you are logged into your 
account).

Does anybody have a contact for them that I can discuss what they are
looking at to determine if my IP addresses are "residential"
vs. "business" class?

Thanks.

Re: Hulu thinks all my IP addresses are "business class", how to reach them?

[Brian Ellwood]

Have you tried reaching out to ipad...@hulu.com?

—
Brian Ellwood
Senior Systems Engineer
INOC Data Centers
O: 518-689-4350

> On Nov 18, 2019, at 11:41, Doug McIntyre  wrote:
> 
> I've been offering residential and business ISP services for a long time.
> 
> Hulu recently blocked my customers from accessing their service, because my
> ARIN IP address blocks are "business class" instead of residential.
> 
> I've tried to find a contact for them as I am not a customer, the
> supportrequ...@hulu.com address mentioned in NANOG previously is just
> an autoresponder that says open a ticket online (once you are logged into 
> your account). 
> 
> Does anybody have a contact for them that I can discuss what they are
> looking at to determine if my IP addresses are "residential"
> vs. "business" class?
> 
> Thanks.
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Hulu thinks all my IP addresses are "business class", how to reach them?

[Doug McIntyre]

I've been offering residential and business ISP services for a long time.

Hulu recently blocked my customers from accessing their service, because my
ARIN IP address blocks are "business class" instead of residential.

I've tried to find a contact for them as I am not a customer, the
supportrequ...@hulu.com address mentioned in NANOG previously is just
an autoresponder that says open a ticket online (once you are logged into your 
account). 

Does anybody have a contact for them that I can discuss what they are
looking at to determine if my IP addresses are "residential"
vs. "business" class?

Thanks.

Re: IP addresses being attacked in Krebs DDoS?

[Alexander Maassen]

Just give me thise ips so i can add em in dronebl


Kind regards,
Alexander Maassen
- Technical Maintenance Engineer Parkstad Support BV- Maintainer DroneBL- 
Peplink Certified Engineer

 Oorspronkelijk bericht Van: Brett Glass <na...@brettglass.com> 
Datum: 25-09-16  22:01  (GMT+01:00) Aan: NANOG <nanog@nanog.org> Onderwerp: IP 
addresses being attacked in Krebs DDoS? 
As an ISP who is pro-active when it comes to security, I'd like to 
know what IP address(es) are being hit by the Krebs on Security 
DDoS attack. If we know, we can warn customers that they are 
harboring infected PCs and/or IoT devices. (And if all ISPs did 
this, it would be possible to curtail such attacks and plug the 
security holes that make them possible.)

--Brett Glass, LARIAT.NET

Re: IP addresses being attacked in Krebs DDoS?

[Patrick W. Gilmore]

On Sep 25, 2016, at 6:35 PM, Brett Glass <na...@brettglass.com> wrote:
> At 03:50 PM 9/25/2016, Patrick W. Gilmore wrote:

>> What Brett is asking seems reasonable, even useful. Unfortunately, it is not 
>> as simple as posting a list of addresses on a website.
>> 
>> Many devices are compromised because of default user/pass settings. 
>> Publishing a list of IP addresses which are so trivially compromised is 
>> handing the miscreants a gift.
> 
> I think you may have misunderstood my request. I am not asking for the IP 
> addresses of the bots, but the address or addresses which they are attacking. 
> I can then scan outgoing packets for those destination addresses, and -- if I 
> see them -- work my way back to the customers who are unknowingly harboring 
> infected devices. Those devices could be PCs, Webcams, DVRs, even 
> thermostats The customers may not know that they have changeable 
> passwords or backdoors.
> 
> By doing this, we can not only enhance our users' security but forestall 
> complaints. We have had more than one customer quit because an infected 
> device on his or her network impacted the quality of video streaming or 
> VoIP... and, of course, he blamed the ISP. Everyone ALWAYS blames the ISP. ;-)

I did read it the other way.

It’s his website, which you can read about on … his website, 
http://krebsonsecurity.com/. (And for everyone on this list, it should be 
trivial to figure out who helped him get the website back up.) Or his twitter 
feed. Or lots of articles about it. Or lots of mailing lists. Or … etc.

-- 
TTFN,
patrick

Re: IP addresses being attacked in Krebs DDoS?

[Damian Menscher via NANOG]

On Sun, Sep 25, 2016 at 1:01 PM, Brett Glass  wrote:

> As an ISP who is pro-active when it comes to security, I'd like to know
> what IP address(es) are being hit by the Krebs on Security DDoS attack. If
> we know, we can warn customers that they are harboring infected PCs and/or
> IoT devices. (And if all ISPs did this, it would be possible to curtail
> such attacks and plug the security holes that make them possible.)
>

130.211.45.45 (it's just the one IP, not DNS-balanced).

Thanks for your interest in cleaning up your infected customers!  10,000
ASNs to go

Damian
-- 
Damian Menscher :: Security Reliability Engineer :: Google :: AS15169

Re: IP addresses being attacked in Krebs DDoS?

[Brett Glass]

At 03:50 PM 9/25/2016, Patrick W. Gilmore wrote:

What Brett is asking seems reasonable, even useful. Unfortunately, 
it is not as simple as posting a list of addresses on a website.


Many devices are compromised because of default user/pass 
settings. Publishing a list of IP addresses which are so trivially 
compromised is handing the miscreants a gift.


I think you may have misunderstood my request. I am not asking for 
the IP addresses of the bots, but the address or addresses which 
they are attacking. I can then scan outgoing packets for those 
destination addresses, and -- if I see them -- work my way back to 
the customers who are unknowingly harboring infected devices. Those 
devices could be PCs, Webcams, DVRs, even thermostats The 
customers may not know that they have changeable passwords or backdoors.


By doing this, we can not only enhance our users' security but 
forestall complaints. We have had more than one customer quit 
because an infected device on his or her network impacted the 
quality of video streaming or VoIP... and, of course, he blamed the 
ISP. Everyone ALWAYS blames the ISP. ;-)


--Brett Glass

Re: IP addresses being attacked in Krebs DDoS?

[Patrick W. Gilmore]

On Sep 25, 2016, at 4:01 PM, Brett Glass <na...@brettglass.com> wrote:

> As an ISP who is pro-active when it comes to security, I'd like to know what 
> IP address(es) are being hit by the Krebs on Security DDoS attack. If we 
> know, we can warn customers that they are harboring infected PCs and/or IoT 
> devices. (And if all ISPs did this, it would be possible to curtail such 
> attacks and plug the security holes that make them possible.)

[Pardon the slightly less than specific details below. Must be careful about 
disclosing names or information which is not public yet.]

What Brett is asking seems reasonable, even useful. Unfortunately, it is not as 
simple as posting a list of addresses on a website.

Many devices are compromised because of default user/pass settings. Publishing 
a list of IP addresses which are so trivially compromised is handing the 
miscreants a gift.

We have done things like this with open DNS resolvers and open NTP servers. 
(THANK YOU JARED!!!) However, we had a hope of the administrators fixing the 
problem, and they were at least somewhat easier to find.

This list is different. Harder to find, harder to fix. Grandma is unlikely to 
think about logging into her webcam and changing the admin password - to say 
nothing of reading NANOG in the first place. Hell, even if she did, how exactly 
do you remove malware from a SmartTV?

Obviously we do not consider Brett a bad actor. It is likely we can work 
something out with ISPs like Brett and give them the addresses on their network 
which need remediation. But this is not a five minute job. Plus most of the 
people working on this do so in their spare time. So please be patient as the 
lists are gathered, sorted, and offered in a reasonable manner.

If you are a member of the various secops lists, more info will be forthcoming. 
If not, I’m sure someone will make information available in wider channels. 

To be clear, I am not doing this work personally, so do not email me. The 
people who are doing this work deserve a hearty and huge thanks from the 
community. If you know one of them, buy them a drink or dinner, or at least 
give them a hug. :) I know I will be doing so in Dallas if they let me.

-- 
TTFN,
patrick

IP addresses being attacked in Krebs DDoS?

[Brett Glass]

As an ISP who is pro-active when it comes to security, I'd like to 
know what IP address(es) are being hit by the Krebs on Security 
DDoS attack. If we know, we can warn customers that they are 
harboring infected PCs and/or IoT devices. (And if all ISPs did 
this, it would be possible to curtail such attacks and plug the 
security holes that make them possible.)


--Brett Glass, LARIAT.NET

IP Addresses

[A MEKKAOUI]

Hi

Anyone can help on how to get IP addresses, purchase or lease or any broker
who can help. Your help will be appreciated.

 

Thank you

 

KARIM