Legacy Application IPs

The application block in the JSON payload provides general information about the given application: label, description, logos, tag name and more. See the application attribute documentation for more information on the JSON payload details.

"application": {
    "id": 120,
    "tag": "netify.twitter",
    "label": "Twitter",
    "full_label": "Twitter",
    "description": "Twitter is a ...",
    "home_page": {
        "url": "https://twitter.com",
        "text": "Twitter"
    },
    "category": {
        "id": 24,
        "tag": "social-media",
        "label": "Social Media"
    },
    "active": true,
    "favicon": "https://static.netify.ai/...",
    "icon": "https://static.netify.ai/...",
    "logo": "https://static.netify.ai/...",
    "favicon_source": "app",
    "icon_source": "app",
    "logo_source": "app"
}

The domain list contains all the domain definitions used to detect an application. For example, the following is a sample of domains used to match the Twitter application:

• t.co
• twimg.com
• twitter.com
• twimg.com.akahost.net
• twitter.map.fastly.net
• etc.

These domains are used to identify application network traffic flows via Netify DPI processing. The hostnames coming from TLS SNI, TLS certificate common names, HTTP headers, DNS requests, DNS hinting, and any hostname that pops out of deep packet inspection are compared to the domain lists.

Please note: for companies with large portfolios of applications, the subdomains can be important differentiators. For example, the googleapis.com domain is part of the Google domain list, but the youtubei.googleapis.com domain is part of Google-owned YouTube domain list.

If a domain belongs to a platform, the metadata is attached to the payload. See the Domain Object documentation for more information on the JSON payload details.

Domain List JSON Overview

"domain_list": [
    {
        "id": 2737771,
        "label": "twimg.com.akahost.net",
        "category": {
            "id": 24,
            "tag": "social-media",
            "label": "Social Media"
        },
        { Platform Object }
    }

Domain List JSON Example

"domain_list": [
    {
        "id": 2737771,
        "label": "twimg.com.akahost.net",
        "category": {
            "id": 24,
            "tag": "social-media",
            "label": "Social Media"
        },
        "platform": {
            "id": 1002,
            "tag": "akamai",
            "label": "Akamai",
            "category": {
                "id": 2,
                "tag": "cdn",
                "label": "CDN"
            },
        }
    },

Some applications run across large network blocks. For example, Microsoft Teams connects to specific network blocks for video conferencing. In these cases, the cidr_list and cidr_type properties will appear in the dataset. The cidr_type will be one of the following three values:

• dedicated
• hosted
• multiproduct

Dedicated: CIDRs in this category are dedicated to serving the application. For example, Telegram CIDRs are not used by any other application -- it's all Telegram.

Hosted: CIDRs in this category are hosting other applications. For example, the Amazon AWS CIDRs can be used to identify all of AWS, but many applications are hosted on his network.

Multiproduct: CIDRs in this category belong to one organization, but are shared amongst different products. For example, the Apple CIDR list will have traffic from the following applications: iCloud, Apple Mail, Apple TV, etc.

If an application does not have any defined CIDR blocks, the cidr_type and cidr_list keys will not exist.

CIDR List and Type JSON Example

"cidr_type": "dedicated",
"cidr_list": [
    {
        "network": "8.25.194.0/23",
        "version": "ipv4"
    },
    {
        "network": "8.25.196.0/23",
        "version": "ipv4"
    },
    ...

The network CIDR list is derived from data provided directly from application vendors, Netify-derived network traffic analysis, and autonomous system number (ASN) definitions. These networks are fairly static, but there are at least a few changes to network CIDR lists every week.

The active IPs associated with the application but not part of the cidr_list blocks are provided in the active_ip_list field of the payload. Basically, the combination of the cidr_list and active_ip_list provides a complete list of networks/IPs used by the application. The data is derived from Netify DPI network traffic analysis. See adjacent sample.

If an IP belongs to a platform, the metadata is attached to the payload. However, to minimize the size of the payload, a subset of the fields in the platform are provided. See the Platform Object documentation for more information.

Though many IP addresses serving applications are fairly static, IPs do get re-used. For example, most Amazon CloudFront CDN IPs for a specific application can change every week or so. This Application IPs data feed actively purges stale IP addresses. However, if you are looking for historical statistics for application IPs, please visit the IP Stats Data Feed page.

It is very common for applications to use shared IPs. Here are three common shared IP scenarios:

• Content delivery networks
• Third party platforms, e.g. a third-party mail services
• Multi-app organizations, e.g. the YouTube and Gmail apps both use shared Google infrastructure

Active IP List JSON Overview

"active_ip_list": [
    {
        "address": "13.33.166.245",
        "version": "ipv4",
        "shared": false,
        "shared_score": 5,
        { Platform Object (minified) }
    }
}

Active IP List JSON Example

"active_ip_list": [
    {
        "address": "13.33.166.245",
        "version": "ipv4",
        "shared": false,
        "shared_score": 5,
        "platform": {
            "id": 1006,
            "tag": "amazon-cloudfront",
            "label": "Amazon CloudFront",
            "category": {
                "id": 2,
                "tag": "cdn",
                "label": "CDN"
            },
            ...
        }
    },