It means that the servers for the zone doesn’t fully implement the DNS
protocol. NS queries for intermediate names are not getting the expected
answer.
--
Mark Andrews
> On 1 Dec 2023, at 21:10, Alessandro Vesely <ves...@tana.it> wrote:
>
> Hi all,
>
> I have this in BIND 9.18.19-1~deb12u1-Debian' logs:
>
> north:log$ grep '148.19.188.64.list.dnswl.org' named-qu.log.0
> 30-Nov-2023 15:58:23.901 queries: info: client @0x7f281e72ff68
> 127.0.0.1#54827 (148.19.188.64.list.dnswl.org): view internal: query:
> 148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
> 30-Nov-2023 15:58:28.909 queries: info: client @0x7f281e6add68
> 127.0.0.1#54827 (148.19.188.64.list.dnswl.org): view internal: query:
> 148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
> 30-Nov-2023 15:58:30.357 queries: info: client @0x7f2817485f68
> 127.0.0.1#53802 (148.19.188.64.list.dnswl.org): view internal: query:
> 148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
> 30-Nov-2023 15:58:31.621 queries: info: client @0x7f281f459f68
> 127.0.0.1#53122 (148.19.188.64.list.dnswl.org): view internal: query:
> 148.19.188.64.list.dnswl.org IN A + (127.0.0.1)
>
> north:log$ grep '148.19.188.64.list.dnswl.org' named.log.0
> 30-Nov-2023 15:58:35.689 lame-servers: info: success resolving
> '148.19.188.64.list.dnswl.org/A' after disabling qname minimization due to
> 'ncache nxdomain'
>
> north:log$ grep '148.19.188.64.list.dnswl.org' named-dnssec.log.0
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: starting
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: attempting negative response validation from
> message
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: in validator_callback_nsec
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: resuming validate_nx
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: nonexistence proof(s) not found
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: checking existence of DS at 'org'
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: checking existence of DS at 'dnswl.org'
> 30-Nov-2023 15:58:35.689 dnssec: debug 3: view internal: validating
> 148.19.188.64.list.dnswl.org/A: marking as answer (proveunsecure (4))
>
> The success arrived several seconds after. Does this mean that the (first)
> queries failed? The dnssec log seems to indicate that the IP was not listed.
>
> The queries in the first half of the 15:58 minute were part of an SPF
> evaluation. (The SPF record contains an exists:%{ir}.list.dnswl.org
> mechanism.). The SPF evaluation returned "error". I'm trying to understand
> whether the cause was a DNS hiccup.
>
> Is this a kind of error that could be orchestrated remotely?
>
>
> TIA
> Ale
> --
>
>
>
> --
> 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
