BIND 9.11.4 dnstap not capturing updates

[Robert Edmonds]

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.proto#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