Re: Increasing problems with geolocation/IPv4 access

Are you sure it’s really geolocation blocks? Or is it anonymizer and VPN service detection? The geoIP vendors typically sell both since one of anonymizers’ top applications is to evade geolocation. Have customers using peer-to-peer anonymizers wittingly or unwittingly? Customers with malware or

Re: Increasing problems with geolocation/IPv4 access

> What I’m actually looking for isn’t so much a soapbox but to find where the > [bad] data is coming from so it can be updated as appropriate. I’m also fine > with telling the customer to phone the service/bank/whatnot (which is what I > did in other cases and as much as I also personally

Re: Increasing problems with geolocation/IPv4 access

> On Jan 20, 2023, at 8:02 PM, Owen DeLong wrote: > > I will repeat what I have been saying since the first discussions of the > concept of ip geo-location some decades ago… > > An IP address is not tied to any of the following: > Location > Person > > An IP address may be

Re: Increasing problems with geolocation/IPv4 access

Even worse, some don’t even bother taking you off a list or correcting their records. In these cases I’ve had great luck once our lawyers get involved, but that really only works for US-based companies. Pretty sure the last company who used our IP space was just wrecking the internet for fun,

Re: Increasing problems with geolocation/IPv4 access

I will repeat what I have been saying since the first discussions of the concept of ip geo-location some decades ago… An IP address is not tied to any of the following: Location Person An IP address may be transiently tied to a host. The definition of transient in this case can

Re: Increasing problems with geolocation/IPv4 access

This is a real and growing problem. I have some networks that have experienced lengthy “no service” issues with streaming services such as Disney+ due to this, and it took many customer generated complaints and “NANOG hallway level” type human back channel escalations to actually get it

Re: Increasing problems with geolocation/IPv4 access

I’ve come to the conclusion that the geo-ip feed companies don’t give a damn about the legitimacy of their information and don’t research any of it. They just wait for the end user to complain to make the change. Had one today, in fact. They’re lame. -Mike > On Jan 20, 2023, at 16:33,

Increasing problems with geolocation/IPv4 access

I’ve been seeing an increasing problem with IP space not having the ability to be used due to the behaviors of either geolocation or worse, people blocking IP space after it’s been in-use for a period of time. Before I go back to someone at ARIN and say “your shiny unused 4.10 IP space” is

Re: txt.att.net outage?

It appears that Simmons, Jay via NANOG said: >-=-=-=-=-=- >This may be the issue Sorry, but no. >Here are some details on this Government protocol implemented by all Telecom >Carriers. > >Why it is being done? To support FCC mandate for STIR/SHAKEN, an industry set >of rules designed to

Weekly Global IPv4 Routing Table Report

This is an automated weekly mailing describing the state of the Global IPv4 Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to

Level 3 A and B DNS resolvers

I'm well aware these are not to be used by the public for DNS. My only concern is that it's used as one of several external hosts to look outside of our network. This is monitored through Spectrum (Charter) in southwest Ohio. Maybe a closer server was taken offline or it was unplugged for a

RE: txt.att.net outage?

This may be the issue Here are some details on this Government protocol implemented by all Telecom Carriers. Why it is being done? To support FCC mandate for STIR/SHAKEN, an industry set of rules designed to authenticate and validate CallerID information associated with phone calls using

Re: txt.att.net outage?

On Fri, Jan 20, 2023 at 9:15 AM William Herrin wrote: > On Thu, Jan 19, 2023 at 8:09 PM Dan Walters via NANOG > wrote: > > Know this is a longshot, any chance anyone from the txt.att.net domain > might be able to help us with what we believe is a blacklist block or > possibly an outage? > > We

Re: txt.att.net outage?

txt.att.net is returning MX records and those machines don't have port 444 open... Wouldn't you want to be sending something like a SNPP message instead? It's a much less convoluted delivery process and is almost real-time (no queuing). I guess it's been a decade or so

Re: txt.att.net outage?

FWIW, AT does not suggest using the txt.att.net email for anything critical. In a previous role I handled public safety CAD, and AT (and Verizon, if I remember correctly) made it very clear that if you want to be able to send anything other than a miniscule volume of texts through the

Re: txt.att.net outage?

On Thu, Jan 19, 2023 at 8:09 PM Dan Walters via NANOG wrote: > Know this is a longshot, any chance anyone from the txt.att.net domain might > be able to help us with what we believe is a blacklist block or possibly an > outage? > We deal with 911 cad dispatching and is affecting first

txt.att.net outage?

Know this is a longshot, any chance anyone from the txt.att.net domain might be able to help us with what we believe is a blacklist block or possibly an outage? We deal with 911 cad dispatching and is affecting first responders so looking to see if there is a faster way to resolution. Thanks,