I should add that a resolver should be able to stop on the first NXDOMAIN. It’s only because we know there are mis-implementations of the protocol (returning NXDOMAIN rather that NOERROR for empty non-terminals) and mis-configurations (missing delegating NS records) that the default is to continue. If people where willing to put up with NXDOMAIN being returned rather than the data that is later found by continuing or not using QNAME minimisation the default could be changed. 'But it “works" when I ask Google' is a hard thing to fight against.
Mark > On 25 Jun 2024, at 07:00, Mark Andrews <ma...@isc.org> wrote: > > It’s just a false positive when the result is NXDOMAIN. Because people forget > to put delegating NS records in parent zones when both are served by the same > server the lookups continue on NXDOMAIN. There is an issue to address this. > > -- > Mark Andrews > >> On 25 Jun 2024, at 06:36, Peter <p...@citylink.dinoex.sub.org> wrote: >> >> On Fri, Jun 21, 2024 at 04:58:55PM +0200, Stephane Bortzmeyer wrote: >> ! On Fri, Jun 21, 2024 at 07:03:14AM +0000, >> ! 65;6800;1c Michael Batchelder <mich...@isc.org> wrote >> ! a message of 59 lines which said: >> ! >> ! > You'll need to fix these zones so that the response is NOERROR rather >> than NXDOMAIN. >> ! >> ! Yes and, if you want the whole context, you can read RFC 8020 >> ! <https://www.rfc-editor.org/info/rfc8020> and section 4 of RFC 7816 >> ! <https://www.rfc-editor.org/info/rfc7816>. >> >> >> Sure, I did that already. And I also talked to the maintainer of >> ns*.he.net, i.e. this one: >> >> ! > The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with >> NXDOMAIN to queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa >> ! > >> ! > You'll need to fix these zones so that the response is NOERROR rather >> than NXDOMAIN. >> >> And they seem to think, there is nothing wrong with that, because >> nobody ever has complained about that. >> >> >> Now I am really wondering: why do I, an unemployed old guy just >> running his own computer, suddenly find myself in between a root >> operator and the biggest v6 network on the planet? >> >> In other words: why do You guys no longer talk to each other? >> >> >> cheerio, >> PMc >> -- >> 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 > > -- > 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
