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.

Regards,
Greg

-----Original Message-----
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 :-)
> 
> https://gitlab.isc.org/isc-projects/bind9/blob/master/lib/dns/dnstap.p
> roto#L69

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 [0]. (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.


[0] 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.

--
Robert Edmonds


More information about the bind-users mailing list