How Safari Handles Oblivious DNS over HTTPS (ODoH)

This article explains how the Safari web browser utilizes Oblivious DNS over HTTPS (ODoH) to protect user privacy by separating a user's IP address from their DNS queries. While standard DNS over HTTPS (DoH) encrypts domain name lookups, the DNS provider can still see who is making the request. Safari solves this by combining public-key encryption with a dual-server relay architecture—most notably used in iCloud Private Relay—ensuring that no single server or provider can simultaneously know both your identity and the websites you visit.

The Limitation of Standard DoH

To understand how Safari uses ODoH, it helps to look at the flaw in standard DoH. When you type a URL into a browser using standard DoH, your browser sends an encrypted request to a DNS resolver (like Cloudflare or Google) to get the website's IP address. Because the connection is direct, the DNS provider sees your IP address and decrypts your DNS query. This allows the provider to build a profile of your browsing history tied directly to your IP address.

Safari's Two-Hop ODoH Architecture

Safari prevents this data correlation by splitting the DNS resolution process between two separate entities operated by different companies. In the Apple ecosystem, this is composed of:

  1. The Client: The Safari browser running on your macOS or iOS device.
  2. The Oblivious Proxy (Ingress Proxy): A server operated by Apple.
  3. The Oblivious Target (DNS Resolver): A server operated by a trusted third-party DNS provider (such as Cloudflare).

Step-by-Step: How Safari Processes a Query

When you attempt to visit a website in Safari with ODoH enabled, the browser executes the following steps in milliseconds:

  • Step 1: Query Encryption. Before the DNS request ever leaves your device, Safari encrypts the DNS query using the public cryptographic key of the third-party Oblivious Target.
  • Step 2: Routing Through the Proxy. Safari sends this encrypted package over an HTTPS connection to Apple’s Oblivious Proxy. Because you are connecting directly to Apple's server, Apple knows your IP address. However, because the DNS query inside the package is encrypted with the third-party Target's key, Apple cannot read the website name you are requesting.
  • Step 3: Forwarding to the Target. The Oblivious Proxy strips your IP address from the request and forwards the encrypted DNS query to the Oblivious Target.
  • Step 4: Decryption and Resolution. The Oblivious Target receives the request. It only sees the IP address of Apple’s proxy, not yours. The Target uses its private key to decrypt the DNS query, looks up the IP address for the requested website, and encrypts the answer using a key provided in your original request.
  • Step 5: Returning the Answer. The Target sends the encrypted DNS response back to the Oblivious Proxy, which then blindly forwards it back to Safari.
  • Step 6: Final Connection. Safari decrypts the response, obtains the website's IP address, and loads the webpage.

Cryptographic Separation of Trust

Safari’s implementation of ODoH relies on the division of knowledge. By architectural design:

  • The Proxy (Apple) knows who you are (your IP address), but does not know what you are looking up.
  • The Target (DNS Provider) knows what is being looked up, but does not know who is asking.

Because Apple and the third-party DNS providers are separate entities locked under strict contractual and technical constraints not to collude, neither party can log your browsing behavior. Even if a malicious actor compromises the DNS provider, they will only see a massive stream of DNS queries originating from Apple's proxy servers, making it impossible to trace any specific query back to an individual Safari user's IP address.