Until now we were detecting abusers, attackers, bogons, cloud providers (datacenters), public proxies, relays, and also tor exit nodes. Starting today, we are adding VPN IP addresses detection to the list. Our VPN dataset contains several millions of IP addresses updated daily.
The new field is named is_vpn and appears under the security object of API responses we return.
As always, we'd love to hear your thoughts on this new feature as well as what you'd like us to build next! Leave us a reaction or feedback below.
]]>Until now we were detecting abusers, attackers, bogons, cloud providers (datacenters), public proxies, relays, and also tor exit nodes. Starting today, we are adding VPN IP addresses detection to the list. Our VPN dataset contains several millions of IP addresses updated daily.
The new field is named is_vpn and appears under the security object of API responses we return.
As always, we'd love to hear your thoughts on this new feature as well as what you'd like us to build next! Leave us a reaction or feedback below.
]]>security.is_relay field to responses we return when you look up an IP address (as always, official client libraries have also been updated). The purpose of this new field is to identify IP addresses that are used by a relay node. Unlike VPNs, relay nodes are location-aware. Instead of bypassing geo-controls, a relay node pools multiple users behind the same IP address.
Using relay nodes is a manner to protect the identity and privacy of users behind individual IPs. Currently, we identify relay IP addresses from Apple Private Relay (APR).
When the new field is_relay returns true as value, then you know the request comes from devices making use of a relay node.
With the end of the year that’s also the time for us to thank you for an amazing 2021. See you in January, and have a wonderful holiday season!
]]>security.is_relay field to responses we return when you look up an IP address (as always, official client libraries have also been updated). The purpose of this new field is to identify IP addresses that are used by a relay node. Unlike VPNs, relay nodes are location-aware. Instead of bypassing geo-controls, a relay node pools multiple users behind the same IP address.
Using relay nodes is a manner to protect the identity and privacy of users behind individual IPs. Currently, we identify relay IP addresses from Apple Private Relay (APR).
When the new field is_relay returns true as value, then you know the request comes from devices making use of a relay node.
With the end of the year that’s also the time for us to thank you for an amazing 2021. See you in January, and have a wonderful holiday season!
]]>https://eu.api.ipregistry.coYou can use it in replacement of our default base URL (https://api.ipregistry.co) to ensure your requests and related data are processed in Europe and not transferred outside.
Indeed, when you send a request to endpoints using the new base URL, your request is forwarded to the closest Ipregistry node in Europe via an anycast load balancer. Then, the EU node process your request but associated data is not transferred outside Europe.
All existing endpoints and options described in our docs work the same.
Note that using our new dedicated EU base URL makes sense if you have users or servers in Europe. However, if your users or servers are located for instance in the US, you will experience higher latencies. In that case, you should keep our default base URL.
]]>https://eu.api.ipregistry.coYou can use it in replacement of our default base URL (https://api.ipregistry.co) to ensure your requests and related data are processed in Europe and not transferred outside.
Indeed, when you send a request to endpoints using the new base URL, your request is forwarded to the closest Ipregistry node in Europe via an anycast load balancer. Then, the EU node process your request but associated data is not transferred outside Europe.
All existing endpoints and options described in our docs work the same.
Note that using our new dedicated EU base URL makes sense if you have users or servers in Europe. However, if your users or servers are located for instance in the US, you will experience higher latencies. In that case, you should keep our default base URL.
]]>API endpoints returning data about an IP address are now including a new field named company. This field shares 3 pieces of information: the company’s name, domain name, and what type of company it is.
Official client libraries have been updated to support the new field. We suggest upgrading to the latest version if you are using one of these libraries.
Interested in accessing this new dataset as CSV for on-promise deployment? drop us a line.
]]>
API endpoints returning data about an IP address are now including a new field named company. This field shares 3 pieces of information: the company’s name, domain name, and what type of company it is.
Official client libraries have been updated to support the new field. We suggest upgrading to the latest version if you are using one of these libraries.
Interested in accessing this new dataset as CSV for on-promise deployment? drop us a line.
]]>
A recurring use case we heard about is to accept any request that comes from subdomains of a given domain name but block other domains.
Let’s say you are a SaaS provider and you host customer resources on a subdomain of a shared domain. For instance customer1.acme.com, customer2.acme.com, etc., and on these pages you are calling the Ipregistry API. Then, instead of allowing each subdomain individually, you can now express the same need using a wildcard, depicted by the * character.
Before:
The creation of new subdomains will no longer require updating origins on the Ipregistry dashboard. ]]>
A recurring use case we heard about is to accept any request that comes from subdomains of a given domain name but block other domains.
Let’s say you are a SaaS provider and you host customer resources on a subdomain of a shared domain. For instance customer1.acme.com, customer2.acme.com, etc., and on these pages you are calling the Ipregistry API. Then, instead of allowing each subdomain individually, you can now express the same need using a wildcard, depicted by the * character.
Before:
The creation of new subdomains will no longer require updating origins on the Ipregistry dashboard. ]]>