Thanks Peter, idx.linkhealth.com is delegated to:
;; AUTHORITY SECTION: idx.linkhealth.com. 300 IN NS ns-858.awsdns-43.net. idx.linkhealth.com. 300 IN NS ns-1053.awsdns-03.org. idx.linkhealth.com. 300 IN NS ns-408.awsdns-51.com. idx.linkhealth.com. 300 IN NS ns-1732.awsdns-24.co.uk. but these servers are not authoritative for idx.linkhealth.com, but for linkhealth.com: ;; QUESTION SECTION: ;idx.linkhealth.com. IN SOA ;; ANSWER SECTION: idx.linkhealth.com. 30 IN CNAME eastus2.prodv4.idx.linkhealth.com. ;; AUTHORITY SECTION: linkhealth.com. 172800 IN NS ns-1053.awsdns-03.org. linkhealth.com. 172800 IN NS ns-1732.awsdns-24.co.uk. linkhealth.com. 172800 IN NS ns-408.awsdns-51.com. linkhealth.com. 172800 IN NS ns-858.awsdns-43.net. AND ;; ANSWER SECTION: linkhealth.com. 900 IN SOA ns-1053.awsdns-03.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 ;; AUTHORITY SECTION: linkhealth.com. 172800 IN NS ns-1053.awsdns-03.org. linkhealth.com. 172800 IN NS ns-1732.awsdns-24.co.uk. linkhealth.com. 172800 IN NS ns-408.awsdns-51.com. linkhealth.com. 172800 IN NS ns-858.awsdns-43.net. AND on top of that linkhealth.com is signed, but only on the delegated nameserver from .com: linkhealth.com. 172800 IN NS epla2.corpnamesvcs.com. linkhealth.com. 172800 IN NS epla1.corpnamesvcs.com. linkhealth.com. 172800 IN NS edns4.ultradns.net. linkhealth.com. 172800 IN NS edns4.ultradns.com. linkhealth.com. 172800 IN NS edns4.ultradns.biz. linkhealth.com. 172800 IN NS edns4.ultradns.org. linkhealth.com. 86400 IN DS 25889 8 2 84948FAAEE2C5A470DCDE74851886CB96AD412ED0B7D963C6026F915 ED7C053F linkhealth.com. 86400 IN DS 6902 8 2 2081CEA8CCE5D8BF2B6244102872557064A451307C21535DAD461036 0B2BD4D0 linkhealth.com. 86400 IN RRSIG DS 13 2 86400 20260815032957 20260808021957 41446 com. UXb6uhnL0Pc4L78yUntoPeHuagsMDwvKUV05QWOjxGV6KZ2sy3upb1oO ZTifeCOaS7+B233TrjrbAJWtuUyJ3Q== This is clearly wrong - they need to fix the idx.linkhealth.com. zone (recommended). Removing linkhealth.com. DS from .com zone might work too. This is typical: GIGO Garbage In Garbage Out. Thanks, Ondrej -- Ondřej Surý (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 10. 8. 2026, at 21:13, Peter DeVries <[email protected]> wrote: > > > 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 <[email protected]> on behalf of Crist Clark > <[email protected]> > 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ý > <[email protected]<mailto:[email protected]>> 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) > [email protected]<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 25. 7. 2026, at 09:28, Sachchidanand Upadhyay >> <[email protected]<mailto:[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 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ý <[email protected]<mailto:[email protected]>> >> To: "Sachchidanand Upadhyay"<[email protected]<mailto:[email protected]>> >> Cc: "bind-users"<[email protected]<mailto:[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) >> [email protected]<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 >> <[email protected]<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<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. > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
