On Sun, Sep 17, 2023 at 12:32:11PM +0200, Christoph via Pdns-users wrote:
> Thanks for looking into this.
> I've filed it as a github issue now.
>
> As a workaround I'm now trying to block these DNS queries in dnsdist, so
> they do not reach recursor and the logs:
>
> addAction(QTypeRule(qtype f
Thanks for looking into this.
I've filed it as a github issue now.
As a workaround I'm now trying to block these DNS queries in dnsdist, so
they do not reach recursor and the logs:
addAction(QTypeRule(qtype from the logs), RCodeAction(DNSRCode.NOTIMP))
best regards,
Christoph
On Sat, Sep 16, 2023 at 05:40:42PM +0200, Otto Moerbeek via Pdns-users wrote:
> On Sat, Sep 16, 2023 at 05:19:01PM +0200, Otto Moerbeek via Pdns-users wrote:
>
> > On Sat, Sep 16, 2023 at 12:04:16PM +0200, Christoph via Pdns-users wrote:
> >
> > > Hello,
> > >
> > > we changed our recursor logl
On Sat, Sep 16, 2023 at 05:19:01PM +0200, Otto Moerbeek via Pdns-users wrote:
> On Sat, Sep 16, 2023 at 12:04:16PM +0200, Christoph via Pdns-users wrote:
>
> > Hello,
> >
> > we changed our recursor loglevel from 3 to 2 with the intention to avoid
> > logging these events because they contain qn
On Sat, Sep 16, 2023 at 12:04:16PM +0200, Christoph via Pdns-users wrote:
> Hello,
>
> we changed our recursor loglevel from 3 to 2 with the intention to avoid
> logging these events because they contain qnames:
>
> msg="qtype unsupported" error="Cannot push task" subsystem="taskq" level="0"
> p
level="0"
I noticed this part of the log entry just now.
Which could mean that this is an emergency loglevel entry and therefore
expected at loglevel 2.
Is there any other way to avoid logging qnames in these events?
best regards,
Christoph
___
Pdns-
Hello,
we changed our recursor loglevel from 3 to 2 with the intention to avoid
logging these events because they contain qnames:
msg="qtype unsupported" error="Cannot push task" subsystem="taskq"
level="0" prio="Error" tid="6" ts="..." name="..." netmask=""
qtype="TYPE65535"
but these event
