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:[email protected]]
Sent: Friday, August 3, 2018 4:34 PM
To: Robert Edmonds <[email protected]>
Cc: Rabil,AG,A Gregory,JTK2 R <[email protected]>; [email protected];
[email protected]
Subject: Re: BIND 9.11.4 dnstap not capturing updates
On Fri, Aug 03, 2018 at 04:18:45PM -0400, Robert Edmonds wrote:
> [email protected] 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 -- [email protected]
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
