What does it mean "lame-servers: info: success resolving"?
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
Re: What does it mean "lame-servers: info: success resolving"?
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 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
Re: What does it mean "lame-servers: info: success resolving"?
Yeah, right. Thank you. However, does that allow to infer anything about the
result of the queries that were put a few seconds before the resolver reached
that conclusion?
Best
Ale
--
On Fri 01/Dec/2023 11:17:25 +0100 Mark Andrews wrote:
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 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
--
--
Visithttps://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 athttps://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
--
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
Value of a DNSSEC validating resolver
At first glance, the concept of a validating resolver seemed like a good idea. But in practice, it is turning out to be a hassle. I'm starting to think, "If my clients want their answers validated, they should do it." If they *really* care about the quality of the answers they get, why should my clients be trusting *me* to validate them? Can someone make a good case to me for continuing to perform DNSSEC validation on my central resolvers? -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- 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
Re: Value of a DNSSEC validating resolver
A validating resolver is a prerequisite for validating clients to work. Clients don’t have direct access to the authoritative servers so the can’t retrieve good answers if the recursive servers don’t filter out the bad answers. Think of a recursive server as a town water treatment plant. You could filter and treat at every house and sometimes you still do like boiling water for baby formula but on the most part what you get out of it is good enough for consumption as is. -- Mark Andrews > On 2 Dec 2023, at 08:14, John Thurston wrote: > > > At first glance, the concept of a validating resolver seemed like a good > idea. But in practice, it is turning out to be a hassle. > > I'm starting to think, "If my clients want their answers validated, they > should do it." If they *really* care about the quality of the answers they > get, why should my clients be trusting *me* to validate them? > > Can someone make a good case to me for continuing to perform DNSSEC > validation on my central resolvers? > > -- > -- > Do things because you should, not just because you can. > > John Thurston907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > -- > 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
