BIND 9.11.4 dnstap not capturing updates

greg.rabil at greg.rabil at
Fri Aug 3 21:23:31 UTC 2018

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; };


-----Original Message-----
From: Evan Hunt [mailto:each at] 
Sent: Friday, August 3, 2018 4:34 PM
To: Robert Edmonds <edmonds at>
Cc: Rabil,AG,A Gregory,JTK2 R <greg.rabil at>; dot at; bind-users at
Subject: Re: BIND 9.11.4 dnstap not capturing updates

On Fri, Aug 03, 2018 at 04:18:45PM -0400, Robert Edmonds wrote:
> greg.rabil at 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 -- each at
Internet Systems Consortium, Inc.

More information about the bind-users mailing list