BIND's dnstap writes response messages into the query_message field

Hi,

I was looking at some dnstap data generated by BIND (specifically the current bind9 package in Debian unstable) and saw that it was producing RESOLVER_RESPONSE messages incorrectly. E.g.:

type: MESSAGE
identity: "debian"
version: "BIND 9.18.4-2-Debian"
message:
  type: RESOLVER_RESPONSE
  query_time: !!timestamp 2022-08-19 21:15:39.551868
  response_time: !!timestamp 2022-08-19 21:15:39.559868
  socket_family: INET6
  socket_protocol: UDP
  query_address: ::
  response_address: 2001:4860:4802:36::a
  query_port: 58057
  response_port: 53
  query_zone: "google.com."
  query_message: |
    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25657
    ;; flags: qr aa ; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0 

    ;; QUESTION SECTION:
    ;www.google.com.    IN      A

    ;; ANSWER SECTION:
    www.google.com.     300     IN      A       172.253.124.105
    www.google.com.     300     IN      A       172.253.124.103
    www.google.com.     300     IN      A       172.253.124.147
    www.google.com.     300     IN      A       172.253.124.106
    www.google.com.     300     IN      A       172.253.124.99
    www.google.com.     300     IN      A       172.253.124.104

    ;; AUTHORITY SECTION:

    ;; ADDITIONAL SECTION:

    ;; EDNS: version 0; flags: do ; udp: 512
  response_message: |
    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25657
    ;; flags: qr aa ; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0 

    ;; QUESTION SECTION:
    ;www.google.com.    IN      A

    ;; ANSWER SECTION:
    www.google.com.     300     IN      A       172.253.124.105
    www.google.com.     300     IN      A       172.253.124.103
    www.google.com.     300     IN      A       172.253.124.147
    www.google.com.     300     IN      A       172.253.124.106
    www.google.com.     300     IN      A       172.253.124.99
    www.google.com.     300     IN      A       172.253.124.104

    ;; AUTHORITY SECTION:

    ;; ADDITIONAL SECTION:

    ;; EDNS: version 0; flags: do ; udp: 512

The same response message was written into both the query_message and response_message fields, which is not correct. The dnstap query_message field should only contain query messages (DNS wire-format messages with the QR flag set to 0), while the response_message field should only contain response messages (DNS wire-format messages with the QR flag set to 1).

For RESOLVER_QUERY dnstap messages the query_message field is typically filled in while the response_message is unset, and for RESOLVER_RESPONSE dnstap messages the query_message field is typically unset while the response_message field is filled in. Similarly for the other *_QUERY / *_RESPONSE pairs in dnstap.

Looking at the dns_dt_send() function here:

https://gitlab.isc.org/isc-projects/bind9/-/blob/968e7bce61dc8583e6b14d4ba984cf67f1e2e315/lib/dns/dnstap.c#L765-875

When dns_dt_send() is called with msgtype set to DNS_DTTYPE_RR, the contents of buf (containing the response message) get written into the dnstap response_message field on line 811. Then at line 818 the control flow falls through into the case handling for the *_QUERY dnstap message types and the same buf (containing the response message) gets written into the dnstap query_message field on line 835. (The comment on line 793 suggests that the whole switch/case block should only be handling the query/response time fields.)