Re: Different RPZ behavior for IDN domains between BIND 9.20.23 and 9.20.26
Crist Clark <[email protected]> Sat, 25 Jul 2026 08:35:06 -0700
| Newsgroups | gmane.network.dns.bind.user |
|---|---|
| Message-ID | <CAAcrURLXQJX9t7AGnUfXMnTe6HXCq+NZ=gL2D17ZguD9zz9jiQ@mail.gmail.com> |
--===============4548709277028441835== Content-Type: multipart/alternative; boundary="00000000000074398f0657713ca1" --00000000000074398f0657713ca1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99d 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=E2=80=99t also happen to be dow= nstream from another caching resolver? On Sat, Jul 25, 2026 at 12:33=E2=80=AFAM Ond=C5=99ej Sur=C3=BD <ondrej@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=C5=99ej Sur=C3=BD (He/Him) > [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 25. 7. 2026, at 09:28, Sachchidanand Upadhyay <[email protected]> > 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 authoritativ= e > 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.2= 6 > logs the rewrite failure for the same query. > > > > Regards, > > Sachchidanand Upadhyay > > > > > > > > > > > > > > From: Ond=C5=99ej Sur=C3=BD <[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.2= 3 > and 9.20.26 > > > > What is the rule to trigger this? It is hard to debug without seeing th= e > exact ruleset that=E2=80=99s being used. > > > > Ondrej > > -- > > Ond=C5=99ej Sur=C3=BD (He/Him) > > [email protected] > > > > ADHD brain at work: I sometimes lose track of my inbox. Please feel fre= e > 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 < > [email protected]> wrote: > > > > =EF=BB=BFHello, > > > > 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 usin= g > 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,ba= dresp: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. > > --00000000000074398f0657713ca1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">I=E2=80=99d put money on the fact that that domain is fun= damentally broken with CNAME at apex as having something to do with it.</di= v><div dir=3D"auto"><br></div><div dir=3D"auto">The BIND instance having th= e problem wouldn=E2=80=99t also happen to be downstream from another cachin= g resolver?</div><div><br><div class=3D"gmail_quote gmail_quote_container">= <div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jul 25, 2026 at 12:33=E2=80= =AFAM Ond=C5=99ej Sur=C3=BD <<a href=3D"mailto:[email protected]">ondrej@is= c.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:= 1ex">Well, if xn--i1bn6adp9emg4dcbcajdeflxp1gua1n7bt10abief.xn--11b7cb3a6a.= xn--h2brj9c<br> matches bad-domain1.example. then something is definitely wrong.<br> <br> If you are not willing to share the exact reproducer than there's littl= e we can do to help you.<br> <br> Ondrej<br> --<br> Ond=C5=99ej Sur=C3=BD (He/Him)<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br> <br> 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!<br> <br> My working hours and your working hours may be different. Please do not fee= l obligated to reply outside your normal working hours.<br> <br> > On 25. 7. 2026, at 09:28, Sachchidanand Upadhyay <<a href=3D"mailto= :[email protected]" target=3D"_blank">[email protected]</a>> wrote:<br> > <br> > Hi Ondrej,<br> > <br> > Thank you for your response. <br> > <br> > Each listed domain in the RPZ is rewritten via a CNAME to a single pol= icy domain, and that policy domain has an A record in its authoritative zon= e.<br> > <br> > For example:<br> > <br> > bad-domain1.example.=C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0 <a href=3D"http:/= /policy.example.net" rel=3D"noreferrer" target=3D"_blank">policy.example.ne= t</a>.<br> > bad-domain2.example.=C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0 <a href=3D"http:/= /policy.example.net" rel=3D"noreferrer" target=3D"_blank">policy.example.ne= t</a>.<br> > bad-domain3.example.=C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0 <a href=3D"http:/= /policy.example.net" rel=3D"noreferrer" target=3D"_blank">policy.example.ne= t</a>.<br> > bad-domain4.example.=C2=A0 =C2=A0 CNAME=C2=A0 =C2=A0 <a href=3D"http:/= /policy.example.net" rel=3D"noreferrer" target=3D"_blank">policy.example.ne= t</a>.<br> > <br> > and in the authoritative zone:<br> > <br> > <a href=3D"http://policy.example.net" rel=3D"noreferrer" target=3D"_bl= ank">policy.example.net</a>.=C2=A0 =C2=A0 =C2=A0A=C2=A0 =C2=A0 =C2=A0 =C2= =A0 <IP address><br> > <br> > <br> > The same RPZ ruleset works correctly on BIND 9.20.23, while BIND 9.20.= 26 logs the rewrite failure for the same query.<br> > <br> > Regards,<br> > Sachchidanand Upadhyay<br> > <br> > <br> > <br> > <br> > <br> > <br> > From: Ond=C5=99ej Sur=C3=BD <<a href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a>><br> > To: "Sachchidanand Upadhyay"<<a href=3D"mailto:supadhyay@= nkn.in" target=3D"_blank">[email protected]</a>><br> > Cc: "bind-users"<<a href=3D"mailto:[email protected]= rg" target=3D"_blank">[email protected]</a>><br> > Date: Fri, 24 Jul 2026 17:12:09 +0530<br> > Subject: Re: Different RPZ behavior for IDN domains between BIND 9.20.= 23 and 9.20.26<br> > <br> > What is the rule to trigger this? It is hard to debug without seeing t= he exact ruleset that=E2=80=99s being used.<br> > <br> > Ondrej<br> > --<br> > Ond=C5=99ej Sur=C3=BD (He/Him)<br> > <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>= <br> > <br> > ADHD brain at work: I sometimes lose track of my inbox. Please feel fr= ee to send a gentle nudge if you're waiting on a reply!<br> > <br> > My working hours and your working hours may be different. Please do no= t feel obligated to reply outside your normal working hours.<br> > <br> > On 24. 7. 2026, at 13:04, Sachchidanand Upadhyay via bind-users <<a= href=3D"mailto:[email protected]" target=3D"_blank">bind-users@list= s.isc.org</a>> wrote:<br> > <br> > =EF=BB=BFHello, <br> > <br> > I am observing different RPZ behavior for an IDN domain after upgradin= g from BIND 9.20.23 to 9.20.26 and would appreciate any guidance.<br> > <br> > Environment:<br> > <br> > BIND 9.20.23: Works as expected<br> > BIND 9.20.26: Fails<br> > The BIND configuration and RPZ configuration are identical on both ver= sions.<br> > <br> > 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.2= 3 using the same configuration. Below are the logs<br> > <br> > 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--i1bn6adp9emg= 4dcbcajdeflxp1gua1n7bt10abief.xn--11b7cb3a6a.xn--h2brj9c stop on qresult in= rpz_rewrite(): failure<br> > 24-Jul-2026 15:37:16.288 query-errors: info: client @0x7fd386c93800 &l= t;client_IP>#41889 (xn--i1bn6adp9emg4dcbcajdeflxp1gua1n7bt10abief.xn--11= b7cb3a6a.xn--h2brj9c): view internal: query failed (failure) for xn--i1bn6a= dp9emg4dcbcajdeflxp1gua1n7bt10abief.xn--11b7cb3a6a.xn--h2brj9c/IN/A at quer= y.c:7651<br> > 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--i1bn6adp9emg4dcbcajdeflxp1gua= 1n7bt10abief.xn--11b7cb3a6a.xn--h2brj9c,referral:1,restart:2,qrysent:4,time= out:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:4]<br> > <br> > If anyone has encountered this issue before or is aware of a workaroun= d or solution, I would be grateful for your suggestions.<br> > <br> > Regards,<br> > Sachchidanand Upadhyay<br> > <br> > <br> > -- <br> > Visit <a href=3D"https://lists.isc.org/mailman/listinfo/bind-users" re= l=3D"noreferrer" target=3D"_blank">https://lists.isc.org/mailman/listinfo/b= ind-users</a> to unsubscribe from this list.<br> > <br> > <br> <br> -- <br> Visit <a href=3D"https://lists.isc.org/mailman/listinfo/bind-users" rel=3D"= noreferrer" target=3D"_blank">https://lists.isc.org/mailman/listinfo/bind-u= sers</a> to unsubscribe from this list.<br> <br> </blockquote></div></div> --00000000000074398f0657713ca1-- --===============4548709277028441835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list. --===============4548709277028441835==--