A user flagged in Slack that they expected to see TTL information for a DNS HTTPS RR transaction, but didn't see it in dns.log. Our own dns-https pcap confirms this, since we don't handle the dns_HTTPS event anywhere. When I add a handler and wing the reply content for the moment to be the target name ...

event dns_HTTPS(c: connection, msg: dns_msg, ans: dns_answer, https: dns_svcb_rr)
        {
        hook DNS::do_reply(c, msg, ans, https$target_name);
        }

the dns.log entry ...

{
  "ts": 1632928690.50062,
  "uid": "CjtskI3McRjtV5a5D5",
  "id.orig_h": "192.168.1.99",
  "id.orig_p": 62978,
  "id.resp_h": "192.168.1.1",
  "id.resp_p": 53,
  "proto": "udp",
  "trans_id": 62111,
  "query": "cloudflare.com",
  "qclass": 1,
  "qclass_name": "C_INTERNET",
  "qtype": 65,
  "qtype_name": "HTTPS",
  "rcode": 0,
  "rcode_name": "NOERROR",
  "AA": false,
  "TC": false,
  "RD": true,
  "RA": false,
  "Z": 2,
  "rejected": false,
  "opcode": 0,
  "opcode_name": "query"
}

gains the following:

 {
   "ts": 1632928690.50062,
   "uid": "CjtskI3McRjtV5a5D5",
   "id.orig_h": "192.168.1.99",
   "id.orig_p": 62978,
   "id.resp_h": "192.168.1.1",
   "id.resp_p": 53,
   "proto": "udp",
   "trans_id": 62111,
+  "rtt": 0.027648210525512695,
   "query": "cloudflare.com",
   "qclass": 1,
   "qclass_name": "C_INTERNET",
@@ -17,8 +18,14 @@
   "AA": false,
   "TC": false,
   "RD": true,
-  "RA": false,
+  "RA": true,
   "Z": 2,
+  "answers": [
+    "."
+  ],
+  "TTLs": [
+    129.0
+  ],
   "rejected": false,
   "opcode": 0,
   "opcode_name": "query"

I'm seeing several such unhandled answer events: dns_HINFO_reply, dns_CAA_reply, dns_SVCB, dns_HTTPS, and potentially a few others that constitute answers but don't have a dns_answer argument.

So the question is how (whether?) to add these. Since we're sitting right on information that naturally enhances dns.log writes that already happen, it seems clear we should add handlers for these events and call do_reply. The next question is whether we should come up with reply strings for each of them, or if we should minimally just update the do_reply hook, which for some reason guards the update of the TTL by the presence of a reply string, and make it fill in the TTL regardless.

I'm leaning toward coming up with reply strings since again it's information we already have available, but that'll be a bit ad-hoc/partial. Thoughts?