DNS Anchors / DNS hints

[indigotime]

Introduction

Modern web applications frequently link to resources across multiple domains. When a user clicks a link or the page loads an external resource, the browser must perform a DNS lookup before establishing a connection. This introduces several challenges:

• Additional Network Round-Trip Time (RTT): DNS queries typically add 50-300ms of latency per domain, compounding with multiple external resources. This is particularly problematic on:

  1. Slow or intermittent connections (mobile networks, satellite, rural broadband)
  2. High-latency networks (geographically distant users, congested ISP infrastructure)

• DNS Resolver Unavailability: DNS resolvers may be inaccessible or misconfigured for various reasons:
  Network filtering or blocking (Aggressive adblocker configurations that block legitimate DNS queries, or DNS-level censorship in certain regions)
  ISP resolver outages or misconfiguration
  Captive portals and network restrictions
  Users with no access to acceptable DNS infrastructure

• Privacy Concerns: DNS queries reveal which domains a user is accessing to their configured DNS resolver (ISP, public resolver, or VPN provider), creating a privacy fingerprint separate from HTTPS traffic.

• No Graceful Fallback: When DNS resolution fails for any reason, standard web navigation becomes impossible, even when HTTPS connections would otherwise succeed.

Use Cases

• Network Performance Optimization: Pages can provide IP address hints to eliminate DNS lookup latency on slow or high-latency connections.
• Resolver Unavailability Mitigation: Pages can provide DNS data when the user's configured resolver is inaccessible (blocked, misconfigured, or offline) for any reason.
• Robust Adblocker Compatibility: Users with DNS-based adblockers can continue accessing legitimate services when aggressive filtering interferes with DNS resolution.
• Offline-First Applications: Progressive Web Apps can include DNS data for known resources when network connectivity is intermittent.
• Content Delivery: CDNs can optimize DNS resolution by providing direct IP hints to edge servers.
• Privacy Enhancement: Users can avoid disclosing browsing patterns to DNS providers by resolving locally.

Proposed Solution

Mechanism Overview

I propose a new HTML element and associated data format that allows pages to embed DNS resolution data. Browsers that support this mechanism will:

• Parse embedded DNS hints from the page
• Pre-populate their local DNS cache with this data
• Use the hints when resolving domains for subsequent navigation or resource loading
• Fall back to standard DNS resolution for domains not in the hints

HTML Element Definition & Data Format

Syntax:
<link rel="dns-hints" href="dns-records.json" />
or inline:

<script type="application/dns+json">
[  { "name": "example.com", "type": "A", "data": "93.184.216.34" },  { "name": "example.com", "type": "AAAA", "data": "2606:2800:220:1:248:1893:25c8:1946" },  { "name": "cdn.example.com", "type": "A", "data": "93.184.216.35" }]
</script>

Data Format

Recommendation: Use existing standardized DNS data formats:

• RFC 8427 JSON Representation of DNS Data (application/dns+json): Standard format used by DoH resolvers (Google DNS, Cloudflare DNS, etc.)
• Alternative: Zone file format (RFC 1035) for compatibility with traditional DNS tools
• Alternative: YAML or other structured formats if broader compatibility is needed

Advantage: Reuses established standards; no new format specification required. Developers can use existing DNS tools and libraries to generate hints.

Browser Behavior

Processing Rules

1. Parsing: Browsers MUST parse <script type="application/dns+json"> elements and external resources referenced by .
   Validation:

• Validate format compliance (RFC 8427 or alternative)
• Check DNSSEC signatures if present (see section 2.3.4)

2. Cache Population: Insert records into the browser's internal DNS cache with the specified TTL.
3. Fallback Behavior: If a domain is not in the hints, browsers MUST perform standard DNS resolution.
4. Expiration: Records expire after TTL seconds or when the page unloads (user preference).

DNSSEC-Based Trust Model

DNS hints are divided into two categories based on cryptographic validation:

Category A: DNSSEC-Signed Hints
Records that include valid DNSSEC signatures (RRSIG) are cryptographically authenticated and can be used without origin restrictions.

Processing:

• Browser validates DNSSEC signature chain against the root zone
• If validation succeeds, the record is authoritative
• Same-origin policy is NOT enforced
• Record is trusted equivalently to standard DNS resolution
  Use cases:
• CDNs can certify IP addresses for mirror networks
• Pages from Region X can embed DNSSEC-signed records from any domain
• Censorship-resistant applications can provide verified DNS data cross-origin

Category B: Unsigned Hints
Records without DNSSEC signatures follow same-origin policy.
Processing:

• Browser MUST enforce same-origin policy
• A page at https://example.com/page.html can provide hints for example.com and subdomains only
• Cross-origin unsigned hints are rejected
  Rationale: Prevents unsigned hints from hijacking unrelated domains.

User Control

Browsers MUST provide:

• Visibility: Users can inspect what DNS hints a page has provided (both signed and unsigned)
• Privacy Control: Users can globally disable DNS hints or per-origin
• Opt-out for unsigned hints: Users can disable category B hints while allowing DNSSEC-signed hints
• Logging: Optional logging of hint usage for debugging and transparency

DNSSEC Validation Requirements

For DNSSEC-signed hints:

• Full Chain Validation: Browser MUST validate the signature chain from the root zone to the target domain
• Algorithm Support: Support RSASHA256, ECDSAP256SHA256 minimum (RFC 6234, RFC 6605)
• Validation Failure: If DNSSEC validation fails, the hint is rejected and standard DNS resolution is used
• Trust Anchor: Browser uses DNSSEC root trust anchor (ICANN root key)

Priority and Caching Interaction

Record Priority (descending):

• DNSSEC-signed DNS hints (this proposal) — cryptographically verified
• User-configured DNS settings — explicit user choice
• Browser DNS cache (existing records without DNSSEC) — previously resolved
• Unsigned DNS hints (this proposal) — page-provided, same-origin restricted
• Standard DNS resolution — default fallback
  Browser Cache Replacement:
• DNSSEC-signed hints MAY replace existing browser cache entries (they are authoritative)
• Unsigned hints MUST NOT replace valid DNSSEC-signed cache entries
• User-configured settings always take precedence

Alternate Approaches

Existing solutions have significant limitations:

• DNS-over-HTTPS (DoH): Requires a trusted DoH endpoint; ineffective when all resolvers are blocked or unavailable.
• VPN/Proxy Solutions: Adds complexity, privacy risks, and may not be available or trusted.
• JavaScript and Browser Extension Workarounds: Require custom client-side code; not standardized and may be ineffective.

Privacy & Security Considerations

Same-Origin Policy (for Unsigned Hints)

Unsigned DNS hints MUST be subject to same-origin policy:

• A page at https://example.com/page.html can provide hints for example.com, sub.example.com, etc.
• It CANNOT provide hints for other.com
• Cross-origin unsigned hints are rejected
  Rationale: Prevents unauthorized modification of DNS resolution for unrelated domains.
  Exception: See section "DNSSEC-Based Trust Model" for DNSSEC-signed hints, which bypass this restriction.

DNSSEC Signature-Based Trust

For use cases requiring higher assurance and cross-origin hints, DNS hints MAY include DNSSEC signatures.
Benefits:

• Cryptographic proof of authenticity
• No origin restriction needed
• Resistant to man-in-the-middle injection
• Enables trusted mirror networks and CDN partnerships
  Considerations:
• Requires DNSSEC deployment by the authoritative domain
• Higher computational cost for validation
• Increases DNS data payload size

HTTPS Certificate Validation

CRITICAL: DNS hints do NOT change HTTPS certificate validation:

• The browser connects to the IP provided in the hint
• The TLS handshake MUST validate that the certificate's CN or SAN matches the domain name
• If the certificate doesn't match, connection FAILS (same as standard DNS resolution)

Injection Attack Mitigation

Threat: A page with DNS hints could be compromised, and hints could be injected.
Mitigations:

• DNSSEC Signatures: Use DNSSEC-signed hints to prevent tampering
• Subresource Integrity: Page authors can hash the DNS hints data to ensure integrity

Examples

###Scenario 1: Trusted CDN Partnership
Context: News organization partners with a CDN provider (cdn.trusted-partner.com) to distribute content. The CDN wants to guarantee that all IP addresses are authentic.

Solution (DNSSEC-Signed Hints - Cross-Origin):

<!DOCTYPE html><html><head>  <script type="application/dns+json">  [    {      "name": "cdn.trusted-partner.com",      "type": "A",      "TTL": 300,      "data": "203.0.113.50"    },    {      "name": "cdn.trusted-partner.com",      "type": "RRSIG",      "TTL": 300,      "data": "RRSIG A 8 3 300 20260601000000 20260531000000 12345 trusted-partner.com. [signature bytes]"    }  ]  </script></head><body>  <img src="https://cdn.trusted-partner.com/image.jpg" /></body></html>

Result:

• Browser validates DNSSEC signature
• Signature valid → Use hint without origin restriction
• Hint cannot be spoofed even if page is compromised
• CDN can update IPs frequently (TTL: 300s) without security regression

Scenario 2: News Site in Resolver-Unavailable Region

Context: A news organization publishes articles via https://news.example.com. Its CDN (cdn.example.com) is DNS-blocked in Region X due to censorship or misconfiguration.

Solution (Unsigned Hints - Same Origin):
<!DOCTYPE html><html><head> <script type="application/dns+json"> [ { "name": "cdn.example.com", "type": "A", "TTL": 1800, "data": "203.0.113.20" }, { "name": "cdn.example.com", "type": "AAAA", "TTL": 1800, "data": "2001:db8:cdn::1" } ] </script></head><body> <h1>Breaking News</h1> <img src="https://cdn.example.com/image1.jpg" /></body></html>
Result: Browser uses hints to bypass unavailable DNS resolver.