Different RPZ behavior for IDN domains between BIND 9.20.23 and 9.20.26

Mon Aug 10 19:13:50 UTC 2026

We are also seeing behavior similar to this.  The record is idx.linkhealth.com.   It is an apex CNAME pointing to a record underneath it.   Unfortunately, it worked under 9.20.23 but not under 9.20.26.  Google and cloudflare resolve the CNAME completely, BIND 9.20.26-S1 returns SERVFAIL.   The domain seems clearly broken to me but of course we're being asking to justify what changed to break it.   Anything we can throw back at them in addition to "fix your domain" would be appreciated.

We use RPZ extensively but I don't have any RPZ records that should impact this zone or any of it's delegation.

Thank you,
Peter

________________________________________
From: bind-users <bind-users-bounces at lists.isc.org> on behalf of Crist Clark <cjc+bind-users at pumpky.net>
Sent: Saturday, July 25, 2026 11:35 AM
To: Ondřej Surý
Cc: bind-users
Subject: Re: Different RPZ behavior for IDN domains between BIND 9.20.23 and 9.20.26

[External - Do not click links or open attachments unless you know the sender.]

I’d put money on the fact that that domain is fundamentally broken with CNAME at apex as having something to do with it.

The BIND instance having the problem wouldn’t also happen to be downstream from another caching resolver?

On Sat, Jul 25, 2026 at 12:33 AM Ondřej Surý <ondrej at isc.org<mailto:ondrej at isc.org>> wrote:
Well, if xn--i1bn6adp9emg4dcbcajdeflxp1gua1n7bt10abief.xn--11b7cb3a6a.xn--h2brj9c
matches bad-domain1.example. then something is definitely wrong.

If you are not willing to share the exact reproducer than there's little we can do to help you.

Ondrej
--
Ondřej Surý (He/Him)
ondrej at isc.org<mailto:ondrej at isc.org>

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 25. 7. 2026, at 09:28, Sachchidanand Upadhyay <supadhyay at nkn.in<mailto:supadhyay at nkn.in>> wrote:
>
> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__policy.example.net&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Lea6_V5bU6XrfETv7xxEltnUFZn_xmR8GJ5tMmkq3A0&m=oOO1GvUNOVnDQYxaeDVDAA_PYY2C2oWsRpr37-1sKMsDE4zrwXtDo-RyYxDsIeWB&s=wGfC7qHZNE2qntwjcFczR5HJlBccPT6kDAeve2uXc4I&e=>.
> bad-domain2.example.    CNAME    policy.example.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__policy.example.net&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Lea6_V5bU6XrfETv7xxEltnUFZn_xmR8GJ5tMmkq3A0&m=oOO1GvUNOVnDQYxaeDVDAA_PYY2C2oWsRpr37-1sKMsDE4zrwXtDo-RyYxDsIeWB&s=wGfC7qHZNE2qntwjcFczR5HJlBccPT6kDAeve2uXc4I&e=>.
> bad-domain3.example.    CNAME    policy.example.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__policy.example.net&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Lea6_V5bU6XrfETv7xxEltnUFZn_xmR8GJ5tMmkq3A0&m=oOO1GvUNOVnDQYxaeDVDAA_PYY2C2oWsRpr37-1sKMsDE4zrwXtDo-RyYxDsIeWB&s=wGfC7qHZNE2qntwjcFczR5HJlBccPT6kDAeve2uXc4I&e=>.
> bad-domain4.example.    CNAME    policy.example.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__policy.example.net&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Lea6_V5bU6XrfETv7xxEltnUFZn_xmR8GJ5tMmkq3A0&m=oOO1GvUNOVnDQYxaeDVDAA_PYY2C2oWsRpr37-1sKMsDE4zrwXtDo-RyYxDsIeWB&s=wGfC7qHZNE2qntwjcFczR5HJlBccPT6kDAeve2uXc4I&e=>.
>
> and in the authoritative zone:
>
> policy.example.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__policy.example.net&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Lea6_V5bU6XrfETv7xxEltnUFZn_xmR8GJ5tMmkq3A0&m=oOO1GvUNOVnDQYxaeDVDAA_PYY2C2oWsRpr37-1sKMsDE4zrwXtDo-RyYxDsIeWB&s=wGfC7qHZNE2qntwjcFczR5HJlBccPT6kDAeve2uXc4I&e=>.     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ý <ondrej at isc.org<mailto:ondrej at isc.org>>
> To: "Sachchidanand Upadhyay"<supadhyay at nkn.in<mailto:supadhyay at nkn.in>>
> Cc: "bind-users"<bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>>
> 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)
> ondrej at isc.org<mailto:ondrej at isc.org>
>
> 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 <bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.isc.org_mailman_listinfo_bind-2Dusers&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Lea6_V5bU6XrfETv7xxEltnUFZn_xmR8GJ5tMmkq3A0&m=oOO1GvUNOVnDQYxaeDVDAA_PYY2C2oWsRpr37-1sKMsDE4zrwXtDo-RyYxDsIeWB&s=hDQXFCyXHrW7E3D254t6rNdp9NlJU7ZlUPq9a3hK9B4&e=> to unsubscribe from this list.
>
>

--
Visit https://lists.isc.org/mailman/listinfo/bind-users<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.isc.org_mailman_listinfo_bind-2Dusers&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Lea6_V5bU6XrfETv7xxEltnUFZn_xmR8GJ5tMmkq3A0&m=oOO1GvUNOVnDQYxaeDVDAA_PYY2C2oWsRpr37-1sKMsDE4zrwXtDo-RyYxDsIeWB&s=hDQXFCyXHrW7E3D254t6rNdp9NlJU7ZlUPq9a3hK9B4&e=> to unsubscribe from this list.