Internet-Draft                                             Rais Ahmed
Intended status: Experimental                                              Independent Submission
Expires: April 12, 2026                                    October 12, 2025

          DNS Policy Redirection Mechanisms:
    RPZ-EDE Enhancement and URI-R Redirection Record
                   draft-ahmed-dns-policy-redirect-00

Abstract

   This document defines two complementary mechanisms to improve
   user experience and policy transparency in DNS-based filtering.
   The first mechanism enhances Response Policy Zone (RPZ) operation
   through Extended DNS Error (EDE) signaling. The second introduces
   a new URI-REDIRECT (URI-R) Resource Record to support secure,
   application-level redirection for both HTTP and HTTPS traffic.
   Each mechanism can operate independently or together, enabling
   network operators and resolvers to provide safer, TLS-compliant
   redirection for policy-enforced domains.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   https://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   https://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 12, 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.

Table of Contents

   1. Introduction
   2. Problem Statement
   3. Overview of RPZ and EDE
   4. Mechanism 1: RPZ-EDE Policy Signaling
   5. Mechanism 2: URI-REDIRECT (URI-R) Record
   6. Illustrative Message Flow
   8. Security Considerations
   9. IANA Considerations
   10. References
   11. Author's Address

. Introduction

   DNS-based policy enforcement, such as through Response Policy Zones
   (RPZ), is widely used to protect users from malicious or restricted
   domains. Traditional redirection methods often substitute an IP
   address to display a warning page. However, for HTTPS traffic this
   causes TLS certificate mismatches and security warnings.

   This draft introduces two independent but complementary mechanisms
   to resolve this problem: an RPZ-EDE extension and a URI-REDIRECT
   record. Each can be implemented separately or together.

. Problem Statement

   When a resolver enforces policy using an RPZ redirect or CNAME
   substitution, browsers attempting to connect via HTTPS will
   encounter a certificate mismatch. The redirection IP does not
   match the queried domain, producing TLS errors such as
   "Your connection is not private."

   There is no existing DNS-based framework that both preserves
   HTTPS integrity and provides transparent user notification.

. Overview of RPZ and EDE

   Response Policy Zones (RPZ) allow DNS operators to define policies
   that alter query responses. Extended DNS Errors (EDE), as defined
   in RFC 8914, allow resolvers to return structured error codes and
   explanatory text.

   Integrating EDE with RPZ provides a mechanism to inform clients
   why a domain was blocked or altered without modifying the
   transport or redirection layer.

. Mechanism 1: RPZ-EDE Policy Signaling

   In this approach, RPZ is extended to include optional EDE fields.
   When a resolver blocks or rewrites a query, it returns an EDE code
   describing the policy reason (for example, "Malware Domain").

   Example:

     ;; ->>HEADER<<- opcode: QUERY; status: REFUSED
     ;; EDE: 15 (Blocked Due to Policy)
     ;; EDE Text: "Malicious domain detected by RPZ policy"

   Clients supporting EDE can render local warnings or internal
   pages explaining the block reason.

   Advantages:
     * No TLS handshake errors occur.
     * Fully compatible with DNSSEC and RPZ.
     * Backward-compatible with existing resolvers.

   Limitations:
     * Requires EDE-aware clients.
     * Cannot display rich HTML warning content.

. Mechanism 2: URI-REDIRECT (URI-R) Record

   The URI-R Resource Record allows resolvers to return a structured
   URI indicating a redirection target, rather than an IP address.
   This enables secure, HTTPS-compatible redirects.

   Example Record:

     blocked.example.com. IN URI-R 10 0 0 "https://safe.example.net/warning"

   Resolver Behavior:
     * On policy match, respond with URI-R instead of A/AAAA records.
     * Optionally include EDE for additional context.

   Client Behavior:
     * Interpret URI-R as an instruction to redirect to the specified
       HTTPS URI before establishing any TLS session with the blocked
       domain.

   Advantages:
     * Seamless HTTPS redirect without certificate errors.
     * Rich user interface and context display possible.

   Limitations:
     * Requires client/stub resolver support.
     * Introduces trust and validation complexity.

. Illustrative Message Flow

6.1 Current Behavior (Without RPZ-EDE or URI-R)

      +-----------+        +-----------+        +-----------+
      |   Client  | -----> |  Resolver | -----> | Malicious |
      |  Browser  | <----- |  (RPZ)    | <----- |  Domain   |
      +-----------+        +-----------+        +-----------+
             |                   |
             |------- TLS error (CERT mismatch) ------->|

6.2 RPZ-EDE Enabled Resolver

      +-----------+        +-----------+
      |   Client  | -----> |  Resolver |
      |  Browser  | <----- |  w/ EDE   |
      +-----------+        +-----------+
             |                   |
             |--- EDE Info: "Blocked due to policy" --->|
             |--- Local display of warning message ---->|

6.3 URI-R Enabled Resolver

      +-----------+        +-----------+        +-----------+
      |   Client  | -----> |  Resolver | -----> | Safe Site |
      |  Browser  | <----- |  w/ URI-R | <----- | warning   |
      +-----------+        +-----------+        +-----------+
             |                   |
             |--- Redirect to https://safe.example.net ---->|

   These flows show the difference between the traditional approach,
   RPZ-EDE signaling, and the new URI-R redirection model.

. Security Considerations

   Both mechanisms require trust in the recursive resolver. URI-R
   introduces additional considerations because it can alter client
   navigation behavior. Implementations MUST ensure URI-R responses
   originate only from trusted, DNSSEC-validated resolvers.

   RPZ-EDE and URI-R data MUST NOT be accepted from untrusted or
   unsigned DNS responses. Clients SHOULD detect and prevent redirect
   loops and ignore malformed URIs.

. IANA Considerations

   This document requests IANA to allocate a new DNS Resource Record
   type code for "URI-R" (URI-REDIRECT). It also suggests reserving
   additional Extended DNS Error codes for policy signaling under
   RPZ operation.

. References

   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
              Specification", STD 13, RFC 1035, November 1987.

   [RFC8914]  Kumari, W. and R. Hunt, "Extended DNS Errors (EDE)",
              RFC 8914, September 2020.

   [RPZ-ISC]  Internet Systems Consortium, "Response Policy Zone
              (RPZ) Technical Specification", 2021.

. Author's Address

   Rais Ahmed
   Independent Submission
   Email: rais.ahmed@outlook.com