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 + (12
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:
>
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
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
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 cou
5 matches
Mail list logo
