Proposal: RPZ-EDE Enhancement and URI-R Redirection Record (IETF Draft for Review)

[Ondřej Surý]

[Resending to bind-users]

Hi Rais,

this is a bit complicated matter as original RPZ specification has this bit:

This document may not be modified, and derivative works of it may not
   be created, except to format it for publication as an RFC or to
   translate it into languages other than English.

I don’t know what plans are and why did you submit this as I-D, but the mess around original RPZ specification needs to be solved first before we make any amendments to it.

The other option might be multivendor effort that avoids IETF altogether.

Ondrej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 14. 10. 2025, at 12:33, Rais Ahmed <rais_ahmed at live.com> wrote:
> 
> 
> Hi,
> Please review and engage relevant group/teams.
> 
> Thanks
> From: Rais Ahmed <rais.ahmed at outlook.com>
> Sent: Tuesday, October 14, 2025 3:28 PM
> To: rpz at lists.isc.org <rpz at lists.isc.org>
> Cc: bind-users at lists.isc.org <bind-users at lists.isc.org>
> Subject: Proposal: RPZ-EDE Enhancement and URI-R Redirection Record (IETF Draft for Review)
>  
> Dear ISC and BIND community members,
> 
> I’d like to share a recently published Internet-Draft that proposes enhancements to DNS policy enforcement mechanisms, particularly around Response Policy Zones (RPZ) and Extended DNS Errors (EDE).
> 
> Draft: DNS Policy Redirection Mechanisms: RPZ-EDE Enhancement and URI-R Redirection Record
> https://datatracker.ietf.org/doc/draft-ahmed-dns-policy-redirect/
> 
> Abstract:
> This document defines two complementary mechanisms to improve user experience and policy transparency in DNS-based filtering. The first extends RPZ operation through the use of EDE signaling to provide explicit policy reasons and better client handling. The second introduces a new URI-REDIRECT (URI-R) Resource Record to enable secure redirection for HTTPS traffic, avoiding TLS certificate errors that occur when traditional IP substitution is used.
> 
> Both mechanisms are designed to be independent yet interoperable, providing flexible paths for resolver vendors and operators to enhance policy signaling and user redirection in a DNS-compliant way.
> 
> Given ISC’s role in the development and maintenance of BIND and RPZ, your feedback on operational feasibility, implementation considerations, or alignment with current BIND behavior would be invaluable.
> 
> Best regards,
> Rais Ahmed
> Transworld / DNS Infrastructure Projects
> Email: rais.ahmed at outlook.com
> 
> IETF Draft: https://datatracker.ietf.org/doc/draft-ahmed-dns-policy-redirect/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20251014/2dee0fef/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20251014/2dee0fef/attachment.sig>