New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
This is entirely a you problem. If you wanted a server with German IPs you should've confirmed that before you purchased the server.
You are kind enough to refund him. Most providers don't.
If he was provided the IP already before ordering the server, then he is aware of the IP geo?
you are ignorant and unethical.
or maybe you had to put in product details that you are selling a german server with non german ips?
Hosting providers dont determine Geo IP, Geo ip changes all the time currently it thinks like 2 of my subnets are announced in Chicago for some reason, I have already sent 3 corrections to them in the past saying it was in Miami FL and not Chicago, its not possible to control these Geo IP Providers
theres no such thing as a german ip address or a netherlands ip address
exactly YOU had to send the correction because its a you problem and not a client problem.
theres no such thing as a goodleaf-cloud or muzingahosting in sub-elsewhere. hetzner becomes vultr, red becomes blue and plus is minus.
What makes an IP address "German"? Last I checked, Germany as a country doesn't own any IP addresses beyond ones used for public service. Do you want the IP address to speak fluent German or something?
Funnily enough this doesn't apply to some other countries. You can easily define a Japanese IP address (JPNIC) or a Chinese IP address (CNNIC), but this does not exist inside of RIPE or ARIN so you're all outta luck.
It's the client's problem because they expected something that is not in the product description. The server is physically located in Germany and it's subject to German laws and jurisdiction. The server was sold as a "German" server. The server was not sold as a "German Server that Geolocates to Germany on Every GeoIP Database in Existence".
In the same way that you cannot expect to be able to stream US Disney+ on a server you buy just because it's located in the US, you cannot expect that a server will geolocate to Germany on every GeoIP database in existence just because it's advertised to be "German".
Frankly your entitlement is pretty astounding.
its not a YOU problem its not a problem at all I just didnt want clients contacting me asking why their service is in Chicago when they ordered Miami, realisticly I dont have to do anything because the geo ip means litreally nothing to anybody and they get it wrong 24/7 I just stopped submitting changes since they revert them so much lookup 192.41.102.2 for example 1 ip database shows it as being in washington state rest are correct and say Miami FL
I've usually seen this banner pop up when someone has your /24 block in their geofeed, worth contacting ipinfo.io & maxmind and get your geofeed up and running, once those 2 accept it, others will most likely follow.
That is quite normal. We live in an entitled generation. Usually this is how troubles started, but who's got time to read history about past entitled civilizations? We're all entitled to rights and opinions without reading anything these days.
Anyway, back on subject: nice professionalism and transparency @Advin - such dignity is quite rare in these troubled times we live in. Keep it up in transparency.
It is in fact possible to feed them correct info constantly.
I believe this is not something that everyone can update if you're renting IPs, unfortunately. You can manually distribute the geofeed to IP providers as well, which we did, but not all IP databases will follow it closely (e.g., we gave our geofeed to MaxMind, but as you can see here, they still haven't updated it or listened to our geofeed).
That's an interesting one. Considering it's just updating the object you'd hope people renting would be willing to update.
From my experience when it's attached to the inetnum object MaxMind follow it 100% but sometimes takes months to fully go through their DB.
You're right though, as with submitting corrections you're just hinting to them when they should say, sometimes they pull other data in that's incorrect but adding to the inetnum has been the most reliable way I've found.
@safakb
Any service owner can choose to follow any data source of IP geolocation or make their own.
And any data source can follow any rules to distinguish the geolocation of IP addresses.
Like Cloudflare and Google, you don't even know how their rule works as many operators meet problems correcting their prefix for geo related issues, which never got fixed.
It's out of your server provider's control, even nothing related to tech. It's just someone's decision (your case is someone in Cloudflare).
Try to learn a lesson that if you need something widely distinguished in specified geolocation, ask or find its test IP and test it yourself on your target service.
I think Advin should give you this information directly or indirectly before you buy.
Don't be so lazy and transfer all the risk to your provider, be kind.
You can use a german vps with its IP tested ok for your target service as the outgoing route for your dedicated server. This should be the urgent solution.
&
You two are wrong. I will quote my old post as there's no need to rewritte that.
EU is not one country. Some local services work only with IPs allocated by local LIRs. Or at least IP subnet properly edited in RIPE database to reflect proper location (although this doesn't guarantee success).
If service in Germany wants to limit access only to German area they will limit access to IPs allocated by German LIRs hence we're saying "German IP".
RIPE databases: https://ftp.ripe.net/pub/stats/ripencc/2024/
Example from RIPE database:
ripencc|IT|ipv4|2.58.208.0|1024|20190322|allocated
ripencc|NL|ipv4|2.58.212.0|1024|20190322|allocated
ripencc|PL|ipv4|2.58.216.0|1024|20190322|allocated
ripencc|FI|ipv4|2.58.220.0|1024|20190322|allocated
(IT = Italy, NL = Netherlands, PL = Poland, FI = Finland...)
Small private geolocation services like maxmind, Ip2location etc... don't not help you here. IP subnet needs to be allocated by RIPE directly to the German LIR (ISP, hosting...) or like said at least properly edited in RIPE db to reflect proper location.
They same way work some other services. As example I am from EU, but it took some time (years...) for Spotify to come to my country. In case I wanted to have access to the Spotify I needed to use IP from some other EU country which already had Spotify service available.
Same goes with (sports, etc...) broadcasting rights limited to certain area.
Life would be much easier if everyone would use just those small private geolocation databases like maxmind, Ip2location... but in reality just small portion of the internet use them. All bigger players like Google, MS, etc... have their own databases and many other use just RIR (RIPE, APNIC) databases.
You can't really win here unless you use IP by local LIR (local ISP/DC).
Vouch for ADVIN AND FRO!
Hi,sorry to hear that. But from my experience, ips can be geolocation ips or broacasted ips when you buy a server. If a client doesnot let the provider know he/she needs geolocation ips, the server ips will be allocated randomly. If my client asks for changing the ips to geolocation ips after receiving login email, we will change it. But in different companies, there are different ip swift and refund policy.
This isn't a good distinction, because largely RIPE does not verify what address you put on your ORG. You can become a German LIR without being a German person or company by just putting some German address as your WHOIS. While sure it's slightly more meaningful then IP geolocation in terms of being a "German" IP, it's also just obviously not a good definition.
Also, LIRs don't allocate IPs. RIPE allocates IPs. Most ISPs lease and buy IP addresses from other ISPs all the time. Any leased IPs will not be directly allocated to the ISP, so any check that only allows IPs allocated to German LIRs will not work.
@ehhthing
I explained the difference in why people (or services) see an IP address allocated from an RIR (Regional Internet Registry) to an LIR (ie. German Local Internet Registry) and then sub-allocated to a local ISP with a properly maintained database as a "German IP", as opposed to an IP allocated by an RIR to an LIR and then sub-allocated to a foreign ISP assigned in a non-Local area.
While RIPE cannot guarantee the accuracy, or completeness or availability of the RIPE Database or of the data contained therein, the Maintainer is responsible for keeping all data maintained by them accurate and up-to-date.
Breaking TOS is not excuse for invalid data in the database, so this what you're saying isn't really an argument.
Also, by design, LIRs sub-allocate IP address space to ISPs (LIR's customers) for the purpose of subsequent distribution.
Leasing, buying, and moving IP blocks all over the world have become common due to the shortage of IPs, and this has changed our modern-day perspective on the issue, so I partially agree with what you said ins your second paragraph (and I mentioned something similar yesterday here:
https://lowendtalk.com/discussion/comment/3962363/#Comment_3962363 )
You're wrong. This could not happen absolutely.
By choosing to break the rule, you can create this kind of ORG object in RIPE database,
but when it is used by any resources like ASN, your fake ORG object should get fixed forcibly.
You could never spoof RIPE this way.
Also according to RIPE's latest policy, they add a locked item "country:" to every ORG object which could not be changed normally. "country:" should always the same as your legal entity address, no exception.
Wow long thread. Didn't get to read it all. But I'm sure folks have already mentioned various geo IP databases can be out of sync.
You can test the server's IP across several geo IP databases listed in dropdown menu at https://www.iplocation.net/bulk-ip-lookup to see what each database reports back for the IP. The dropdown menu allows you to test your IP against the following databases - IP2Location, IpinfoAPI, DbipAPI, ipdataAPI, IpGeolocationAPI, Ipregistry, Ipapi_co, Ipbase, CriminalIp.
If you use a web host that has more one geographical location, you have a higher chance of IP's geolocation data being out of date from my experience.
If IP geolocation is important, it should really be something to ask the web host BEFORE you order
brilliant. i'll order a lada niva (https://www.google.com/search?sca_esv=60f5b356054dd9ee&q=lada+niva) from you and get a bmw x7.
IPDB operator's problem.
i've seen many cases like this, if you want to satisfy your client and keep it, then you have to replace ip or update ip data, if you don't give a fk for service quality and want to lose it then we go with your logic and make it look like a client problem.
It's not client obligation to update your ip data wtf.
Client ordered a german server and it was by default expecting german ip data unless specified otherwise. the very fact that you saying the ip has not been populated properly in every database is a problem that you must fix. how is this so hard to understand kekw
Even AWS IPs are not always geolocated correctly (some ap-northeast-2 regions show up as U.S. for example). As long as the client requested a German server and Advin fulfilled the request, I don’t see a problem here. TBH if a user is buying a $700/mo service, (s)he should have done his/her due diligence (maybe rent a cheaper/smaller VM first on the same subnet?)
You missed the point.
You can't judge a whole server and service quality only from the IP (specifically geo-fcking-db's IP)
If I was the OP, I would check the provided IP before gone with it.
And I think it's like a "normal habit" before you buy a server even just to check the latency only.
Especially it's $699 server to run an urgently crucial's project.
how is this so hard to understand kekw