I think I know what is going on. There is a variable ‘maxlabels’ that is used in the binary search that optimised the closest enclosure search. That updated value was being use later rather than it's original value when determining the NSEC3 that proves the NOQNAME resulting in the wrong NSEC3 being added to the response.
> On 22 Apr 2025, at 00:55, akritrim® Intelligence™ via bind-users > <bind-users@lists.isc.org> wrote: > > version: BIND 9.20.8-1+0~20250416.117+debian12~1.gbp1ea9dd-Debian (Stable > Release) <id:> (<<REDACTED>>) > running on localhost: Linux x86_64 6.1.0-33-cloud-amd64 #1 SMP > PREEMPT_DYNAMIC Debian 6.1.133-1 (2025-04-10) > boot time: Sun, 20 Apr 2025 15:40:59 GMT > last configured: Sun, 20 Apr 2025 15:40:59 GMT > configuration file: /etc/bind/named.conf > CPUs found: 1 > worker threads: 1 > number of zones: 10 (0 automatic) > debug level: 0 > xfers running: 0 > xfers deferred: 0 > xfers first refresh: 0 > soa queries in progress: 0 > query logging is ON > response logging is OFF > memory profiling is INACTIVE > recursive clients: 0/900/1000 > recursive high-water: 0 > tcp clients: 0/150 > TCP high-water: 25 > server is up and running > > > is this any way related to this? > > From 9.20.8 release notes: > > Restore NSEC3 closest-encloser lookup improvements. > > A performance improvement for finding the closest encloser when generating > authoritative responses from NSEC3 zones was previously reverted after a bug > was found that could trigger an assertion failure. ([GL #4460], [GL #4950], > and [GL #5108]) The bug has now been fixed, and the performance improvement > has been restored. [GL #5204] > > > > On 21/04/2025 7:12 pm, Mark Andrews wrote: >> What does ‘rndc status’ return? >>> On 21 Apr 2025, at 13:05, akritrim® Intelligence™ via bind-users >>> <bind-users@lists.isc.org> wrote: >>> Thank you for your help. it does give insights into the problem. >>> if you check dnsviz history, this does not happen everytime. >>> the bind version is BIND 9.20.8-1+0~20250416.117+debian12~1.gbp1ea9dd-Debian >>> obtained from: https://www.isc.org/download/ —-> >>> https://bind.debian.net/bind >>> there are no firewalls or load balancers. these are directly connected to >>> internet. i was running BIND 9.18 official debian package and got no errors >>> like this. >>> On 21/04/2025 4:46 am, Crist Clark wrote: >>>> The version of BIND and where you got it would be a good start. Any load >>>> balancers, firewalls, etc. between the server and internet that might touch >>>> the DNS records? >>>> True DNSSEC gurus please check my math. >>>> DNSvis is correct. You're not sending the proper NSEC3 records. Like the >>>> RFC says, "It takes three to tango," or NSEC3 denial of existence. You sent >>>> two. For a name where two levels of label don't exists, >>>> l5tz4.1i89a.akritrim.net >>>> You should send back three NSEC3 records, >>>> 1) NSEC3 record that proves 1i89a.akritrim.net ( >>>> 18QMAAOCT0HPNGCPD9MLONVAK13DS8HT) does not exist. >>>> 2) NSEC3 record for akritrim.net (N1MI0QA6QNO2L00GAT0PE6PEGGHHI48P). >>>> 3) NSEC3 record proving the wildcard, *.akritrim.net ( >>>> 6L23GRBE4JIMA1A0G8DSBBUT32V6VCO1), does not exist. >>>> But you're not, you're only sending two, >>>> N1MI0QA6QNO2L00GAT0PE6PEGGHHI48P.akritrim.net. 600 IN NSEC3 1 0 0 - >>>> QDO3A5R9G64L616H1K2FF3SUMFPPRV3J A NS SOA MX TXT AAAA RRSIG DNSKEY >>>> NSEC3PARAM CDS CDNSKEY CAA >>>> 67QJN06FLKRQCT38S4FF08EP31NDRL8S.akritrim.net. 600 IN NSEC3 1 0 0 - >>>> 6LPNNJIVL1267OV5QQSBFLMFIDHMHJ8P TXT RRSIG >>>> Those are two I'd expect to see for (2) and (3), but where is (1)? >>>> But it's weirder. For this name, >>>> ebzoq.ik7ub.akritrim.net >>>> You are sending three NSEC3, but one doesn't look like the right one. You >>>> should send, >>>> 1) NSEC3 record that proves 1i89a.akritrim.net ( >>>> S2NOKIAA732BLNNSEMCJ8KV74H6ICUEP) does not exist. >>>> 2) NSEC3 record for akritrim.net (N1MI0QA6QNO2L00GAT0PE6PEGGHHI48P). >>>> 3) NSEC3 record proving the wildcard, *.akritrim.net ( >>>> 6L23GRBE4JIMA1A0G8DSBBUT32V6VCO1), does not exist. >>>> But these get sent, >>>> N1MI0QA6QNO2L00GAT0PE6PEGGHHI48P.akritrim.net. 600 IN NSEC3 1 0 0 - >>>> QDO3A5R9G64L616H1K2FF3SUMFPPRV3J A NS SOA MX TXT AAAA RRSIG DNSKEY >>>> NSEC3PARAM CDS CDNSKEY CAA >>>> I559SEFHCJO35HED2LU4N68B44CA281V.akritrim.net. 600 IN NSEC3 1 0 0 - >>>> KOGD0HOUD9R7BAB4LKQR2E9ALI57C7N0 A AAAA RRSIG CAA >>>> 67QJN06FLKRQCT38S4FF08EP31NDRL8S.akritrim.net. 600 IN NSEC3 1 0 0 - >>>> 6LPNNJIVL1267OV5QQSBFLMFIDHMHJ8P TXT RRSIG >>>> The first and last are the same two we got previously and line up with (2) >>>> and (3). But we get this other one that doesn't line up with (1). But what >>>> I /think/ that might be is the record that would prove >>>> ebzoq.ik7ub.akritrim.net (IAT39F3MSSGS2D4O255VNHB67V2GCNVI) does not exist >>>> in its place. >>>> On Sun, Apr 20, 2025 at 10:29 AM akritrim® Intelligence™ via bind-users < >>>> bind-users@lists.isc.org> wrote: >>>>> i didn't specifically ask for your help. i don't know why you replied. yes >>>>> i do need help but this doesn't mean i can read your mind. >>>>> so let me know what 'bits' of information should i share that will >>>>> meaningfully help me. ( this is equivalent to saying ' >>>>> if you need anything specific let me know.') >>>>> today language models are more context aware. >>>>> and if you don't want to share what do you 'need' then leave it be, i >>>>> don't want your help. >>>>> On April 20, 2025 5:17:46 PM UTC, "Ondřej Surý" <ond...@isc.org> wrote: >>>>> > >>>>> >> On 20. 4. 2025, at 17:57, akritrim® Intelligence™ via bind-users < >>>>> bind-users@lists.isc.org> wrote: >>>>> >> >>>>> >> anyways, if you need anything specific let me know. >>>>> > >>>>> >Well, I don't really need anything, you've asked for help here, not I. >>>>> I've already told you what is needed, >>>>> >you didn't follow my advice :shrug:. The bits of information you have >>>>> provided are not sufficient to meaningfully >>>>> >help you. >>>>> > >>>>> >Ondrej >>>>> >-- >>>>> >Ondřej Surý (He/Him) >>>>> >ond...@isc.org >>>>> > >>>>> >My working hours and your working hours may be different. Please do not >>>>> feel obligated to reply outside your normal working hours. >>>>> > >>>>> > >>>>> akritrim® Intelligence™ >>>>> -- >>>>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe >>>>> from this list >>>>> ISC funds the development of this software with paid support >>>>> subscriptions. Contact us at https://www.isc.org/contact/ for more >>>>> information. >>>>> bind-users mailing list >>>>> bind-users@lists.isc.org >>>>> https://lists.isc.org/mailman/listinfo/bind-users >>> -- >>> akritrim® Intelligence™ >>> -- >>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from >>> this list >>> ISC funds the development of this software with paid support subscriptions. >>> Contact us at https://www.isc.org/contact/ for more information. >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > -- > akritrim® Intelligence™ > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
