DoT responses are split into two TLS frames
Summary
DNS message length and the rest of DNS message are sent as two separate TLS frames. This is not a protocol issue, it's just a subtle sub-optimality which triggers bugs in other non-compliant DoT clients (like Flamethrower 0.11.0 0ee1fba).
BIND version affected
Version v9.18 does not seem to be affected.
Steps to reproduce
Generally - do a DoT query and watch content of TLS stream in Wireshark. I'm using Flamethrower which does not recognize the split answer because of it's own bug.
- $ named -g -c named.conf
- $ export SSLKEYLOGFILE=/tmp/tlskeys
- $ tcpdump -n -i lo 'host 127.0.0.1 and port 853' -w /tmp/dot-answer-in-two-tls-frames.pcap
- $ flame 127.0.0.1 -q 1 -P dot -c 1 -l 5
- $ sudo pkill tcpdump
- Configure Wireshark to read /tmp/tlskeys file according to https://wiki.wireshark.org/TLS#extracting-decryption-secrets-to-a-text-file
- Inspect the PCAP: $ wireshark /tmp/dot-answer-in-two-tls-frames.pcap
What is the current bug behavior?
Packet with DNS answer looks like this:
Transmission Control Protocol, Src Port: 853, Dst Port: 46339, Seq: 1358, Ack: 515, Len: 99
Transport Layer Security
[2 Reassembled TLS segments (55 bytes): #13(2), #13(53)]
[Frame: 13, payload: 0-1 (2 bytes)]
[Frame: 13, payload: 2-54 (53 bytes)]
[Segment count: 2]
[Reassembled PDU length: 55]
[Reassembled PDU data: 0035394e81800001000100000001047465737403636f6d0000010001c00c0001000100000931000443e192f800002904d0000000000000]
Domain Name System (response)
Length: 53
Transaction ID: 0x394e
Flags: 0x8180 Standard query response, No error
...What is the expected correct behavior?
Preferably just one TLS frame with message length + payload.