How ISPs Implement Zero-Rating for YouTube/Netflix Despite HTTPS: DNS, SNI & IP Whitelisting Techniques


2 views

Modern ISPs face a technical challenge when implementing zero-rating policies (exempting specific services from data caps) in the HTTPS era. While all traffic appears encrypted at the transport layer, several techniques allow identification of service origins:

// Example packet flow showing encrypted HTTPS traffic
Client -> ISP Gateway -> CDN Server
[HTTPS Handshake] [Encrypted Payload]

The most straightforward method involves monitoring DNS queries before encryption begins:

nslookup youtube.com
Server:  dns.isp.com
Address:  192.168.1.1

Non-authoritative answer:
Name:    youtube-ui.l.google.com
Addresses:  142.250.190.46
          2607:f8b0:4009:809::200e

ISPs maintain domain whitelists for zero-rated services. When a client resolves domains like "youtube.com" or "netflix.com", the ISP flags subsequent connections to those IPs as exempt.

Even with HTTPS, the TLS handshake reveals the target hostname through SNI:

// Wireshark filter to observe SNI
tls.handshake.extensions_server_name == "youtube.com"

Modern DPI (Deep Packet Inspection) equipment can parse this unencrypted portion of the TLS handshake to identify services.

Large services typically use dedicated IP ranges that ISPs can map:

// Example of Google's ASN ranges
AS15169 - Google LLC
IPv4: 142.250.0.0/16
IPv6: 2607:f8b0::/32

ISPs maintain updated BGP routing tables and peering agreements to track these allocations.

Several edge cases complicate zero-rating:

  • CDN co-hosting (YouTube sharing IPs with other Google services)
  • QUIC protocol encryption (hides SNI in later versions)
  • DNS-over-HTTPS/TLS bypasses ISP DNS

Here's pseudocode for how an ISP might implement this:

function classify_traffic(packet):
    if packet.dest_ip in whitelisted_ranges:
        return ZERO_RATED
    
    if packet.protocol == TLS:
        sni = extract_sni(packet)
        if sni in whitelisted_domains:
            return ZERO_RATED
    
    if packet.dns_query:
        if any(domain in whitelist for domain in packet.dns_query):
            add_to_whitelist(packet.response_ips)
    
    return COUNTED

Upcoming TLS 1.3 extensions like ECH will encrypt SNI, potentially breaking current methods. ISPs may need to:

  1. Depend more on IP whitelisting
  2. Use machine learning to infer traffic patterns
  3. Leverage side-channel timing analysis

Modern ISPs face a significant challenge when implementing zero-rating policies (excluding certain services from data caps) in an encrypted internet landscape. With HTTPS encrypting both the URL and content, traditional Deep Packet Inspection (DPI) methods become less effective. Yet mobile carriers in countries like Poland successfully exempt platforms like YouTube from data caps. Let's explore the technical mechanisms behind this.

ISPs often begin with DNS query analysis. When your device requests youtube.com, the DNS query reveals the destination before encryption begins:

# Example DNS query capture (simplified)
nslookup youtube.com
Server:  dns.provider.com
Address:  192.168.1.1

Non-authoritative answer:
Name:    youtube.com
Addresses:  142.250.190.46
          142.250.190.78
          142.250.190.110

Carriers maintain extensive DNS mapping databases that associate domains with zero-rating policies. This method works but has limitations with CDNs and shared IP addresses.

Even with HTTPS, the Server Name Indication (SNI) field in TLS handshakes remains visible. ISPs can parse this unencrypted metadata:

# Example TLS Client Hello packet
Handshake Protocol: Client Hello
    Version: TLS 1.2
    Random: ...
    Session ID: ...
    Cipher Suites: ...
    Compression Methods: ...
    Extensions: ...
        Extension: server_name (len=19)
            Server Name Indication extension
                Server Name: youtube.com

Modern implementations often use ESNI (Encrypted SNI) or ECH (Encrypted Client Hello), but adoption remains limited, giving ISPs this visibility.

Major platforms publish their IP ranges (e.g., through AS numbers or public datasets). ISPs maintain and frequently update these mappings:

# Example IP range check (pseudocode)
def is_zero_rated(ip):
    youtube_ranges = [
        ("142.250.0.0", "142.251.255.255"),  # YouTube AS15169
        ("172.217.0.0", "172.217.255.255")   # Google ranges
    ]
    return any(low <= ip <= high for (low, high) in youtube_ranges)

Advanced carriers employ machine learning models that analyze traffic patterns without decrypting content:

  • Packet size distributions (video streaming has characteristic burst patterns)
  • Connection durations (long-lived TCP sessions typical of video)
  • Port usage (despite HTTPS, some services use distinct port combinations)

These methods aren't perfect. Consider these edge cases:

# Scenario 1: Shared Google IP serving multiple services
IP: 142.250.190.78
- Could be YouTube (zero-rated)
- Could be Google Drive (counted)
- Solved via additional SNI/port analysis

# Scenario 2: VPN tunneling
- All traffic appears as single VPN provider
- Zero-rating breaks unless VPN provider cooperates

The cat-and-mouse game continues as both platforms and ISPs evolve their techniques.