I had started down the path of adding a new enum. However, Robert's comment
made sense that the granularity of the enums is really for the QR bit and the
various points along the query resolution path, so I just used AUTH_QUERY for
prototyping purposes.
I could see it being useful to extend the enum to
AUTH_QUERY_UPDATE/AUTH_QUERY_RESPONSE, for example, and then extend the filters
accordingly. E.g. dnstap { auth query update; };
Regards,
Greg
-----Original Message-----
From: Evan Hunt [mailto:e...@isc.org]
Sent: Friday, August 3, 2018 4:34 PM
To: Robert Edmonds <edmo...@mycre.ws>
Cc: Rabil,AG,A Gregory,JTK2 R <greg.ra...@bt.com>; d...@dotat.at;
bind-us...@isc.org
Subject: Re: BIND 9.11.4 dnstap not capturing updates
On Fri, Aug 03, 2018 at 04:18:45PM -0400, Robert Edmonds wrote:
> greg.ra...@bt.com wrote:
> > Thanks Robert. I've added a few lines of code to BIND's client.c
> > source module to call dns_dt_send for updates with a type of
> > AUTH_QUERY, and it works as expected.
>
> > Is there any reason that you can think that it should not be part of
> > the standard BIND dnstap support? If not, I will gladly contribute
> > my change to the ISC.
>
> I can't think of any reason not to have support for dnstap logging of
> UPDATEs on the server side in BIND. It just wasn't a focus for the
> original dnstap design work, which was very STD13 focused.
The terminology's a little misleading since the QUERY and UPDATE opcodes are
two different things. But I guess the implication here is that for dnstap
purposes, we don't care about opcodes, and "query" is the same as "request".
I can't think of any reason not to tap update requests, but I do wonder whether
an extension to the type enum would reduce confusion.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
