BIND 9.11.4 dnstap not capturing updates
greg.rabil at bt.com
greg.rabil at bt.com
Fri Aug 3 20:11:53 UTC 2018
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.
From: Robert Edmonds [mailto:edmonds at mycre.ws]
Sent: Friday, August 3, 2018 3:08 PM
To: Tony Finch <dot at dotat.at>
Cc: Rabil,AG,A Gregory,JTK2 R <greg.rabil at bt.com>; bind-users at isc.org
Subject: Re: BIND 9.11.4 dnstap not capturing updates
Tony Finch wrote:
> greg.rabil at bt.com <greg.rabil at bt.com> wrote:
> > I use nsupdate to send a DDNS update to my zone, which is added
> > successfully. However, the dnstap.output does not record the DNS
> > update.
> I think (arguably) this is a limitation of the dnstap specification.
> It's defined in a Protocol Buffers declaration file (see the link
> below) and it only specifies message types for normal queries and
> responses. The types correspond roughly to tap points in the code - it
> isn't as low-level as you might expect, if you are imagining something
> that hooks into the network IO layer.
> If you want to record other kinds of messages (UPDATE, NOTIFY, etc.)
> it would probably be best to extend the dnstap `Type` enum, and add
> corresponding dns_dt_send() calls to BIND's code. But you should check
> with Robert Edmonds first :-)
The dnstap `Type` enum values specify where the message is being observed and whether it's an inbound or outbound message. The _QUERY and _RESPONSE variants are there as an optimization to avoid having to read the QR bit from the header, which I now think may have been a premature optimization . (IIRC, in theory the definition of the flag bits are opcode-dependent, but I believe in practice every known opcode defines a QR flag bit.) That is, the *_QUERY `Type` values mean QR=1, not OPCODE=QUERY.
For UPDATE, I don't think you need to add any new `Type` values. The responder (an authoritative nameserver?) can record the inbound queries as AUTH_QUERY and the outbound responses as AUTH_RESPONSE. The initiator (usually a dedicated tool like nsupdate?) can record the outbound queries as TOOL_QUERY and the inbound responses as TOOL_RESPONSE.
dnstap doesn't have any `Type` values for an authoritative nameserver that is an initiator. For NOTIFY, we might need to add AUTH_CLIENT_QUERY and AUTH_CLIENT_RESPONSE in order to distinguish the initiator and responder in a NOTIFY transaction between two authoritative nameservers.
 Probably 'query_message' and 'response_message' didn't need to be separate fields either, since no more than one should be set in any given payload.
More information about the bind-users