Hi Ondrej,
Thank you for your response.
Each listed domain in the RPZ is rewritten via a CNAME to a single policy
domain, and that policy domain has an A record in its authoritative zone.
For example:
bad-domain1.example. CNAME policy.example.net.
bad-domain2.example. CNAME policy.example.net.
bad-domain3.example. CNAME policy.example.net.
bad-domain4.example. CNAME policy.example.net.
and in the authoritative zone:
policy.example.net. A <IP address>
The same RPZ ruleset works correctly on BIND 9.20.23, while BIND 9.20.26 logs
the rewrite failure for the same query.
Regards,
Sachchidanand Upadhyay
From: Ondřej Surý <[email protected]>
To: "Sachchidanand Upadhyay"<[email protected]>
Cc: "bind-users"<[email protected]>
Date: Fri, 24 Jul 2026 17:12:09 +0530
Subject: Re: Different RPZ behavior for IDN domains between BIND 9.20.23 and
9.20.26
What is the rule to trigger this? It is hard to debug without seeing the exact
ruleset that’s being used.
Ondrej
--
Ondřej Surý (He/Him)
mailto:[email protected]
ADHD brain at work: I sometimes lose track of my inbox. Please feel free to
send a gentle nudge if you're waiting on a reply!
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
On 24. 7. 2026, at 13:04, Sachchidanand Upadhyay via bind-users <
mailto:[email protected] > wrote:
Hello,
I am observing different RPZ behavior for an IDN domain after upgrading from
BIND 9.20.23 to 9.20.26 and would appreciate any guidance.
Environment:
BIND 9.20.23: Works as expected
BIND 9.20.26: Fails
The BIND configuration and RPZ configuration are identical on both versions.
The queried domain is an IDN. The domain itself is not present in the RPZ, yet
BIND 9.20.26 logs an "RPZ QNAME rewrite failed" message for the query, while
the same query is resolved successfully on BIND 9.20.23 using the same
configuration. Below are the logs
24-Jul-2026 15:37:16.288 query-errors: debug 3: client @0x7fd386c93800
<client_IP>#41889
(xn--i1bn6adp9emg4dcbcajdeflxp1gua1n7bt10abief.xn--11b7cb3a6a.xn--h2brj9c):
view internal: rpz QNAME rewrite
xn--i1bn6adp9emg4dcbcajdeflxp1gua1n7bt10abief.xn--11b7cb3a6a.xn--h2brj9c stop
on qresult in rpz_rewrite(): failure
24-Jul-2026 15:37:16.288 query-errors: info: client @0x7fd386c93800
<client_IP>#41889
(xn--i1bn6adp9emg4dcbcajdeflxp1gua1n7bt10abief.xn--11b7cb3a6a.xn--h2brj9c):
view internal: query failed (failure) for
xn--i1bn6adp9emg4dcbcajdeflxp1gua1n7bt10abief.xn--11b7cb3a6a.xn--h2brj9c/IN/A
at query.c:7651
24-Jul-2026 15:37:16.288 query-errors: debug 4: fetch completed for
xn--i1bn6adp9emg4dcbcajdeflxp1gua1n7bt10abief.xn--11b7cb3a6a.xn--h2brj9c/A in
0.042000: failure/deadlock found
[domain:xn--i1bn6adp9emg4dcbcajdeflxp1gua1n7bt10abief.xn--11b7cb3a6a.xn--h2brj9c,referral:1,restart:2,qrysent:4,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:4]
If anyone has encountered this issue before or is aware of a workaround or
solution, I would be grateful for your suggestions.
Regards,
Sachchidanand Upadhyay
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
