On Thu, 27 Feb 2025, Libor Peltan wrote: > just after a quick read, couldn't it be related to > https://github.com/rthalley/dnspython/issues/1150 and > https://github.com/rthalley/dnspython/pull/1151 ?
Thanks for this. I am not using the same dnspython features, but this did prompt me to look further. I now see I was confused and share some more notes below: > On 26. 02. 25 23:49, Jeremy C. Reed wrote: > > 1) OPT record with the requestors pay load size (class 1232) and edns rcode > > and flags (all zeros ttl), then 00 rdlength and 00 rdata field. > > > > 2) then 28 bytes I don't understand such as: Ahhh I now realize the knot was sending multiple DNS responses in the same packet. The OPT record above was in the additional section and then: > > 40 11be dc80 0000 0101 fa00 0000 01 40 11 == new response starts and indicates TCP 16401 bytes then begins the header again: be dc == txid 48860 80 00 == flags 1000000000000000 QR set and all rest is unset 00 01 == query count 1 01 fa == answer count 506 00 00 == auth section count zero 00 01 == addition section count 1 (the OPT record) > > 3) then an IXFR record because that is the question again So I had interspersed responses for the AXFR. So thanks for suggesting I look at dnspython. Does anyone know what RFC clearly explains about multiple DNS messages in a single response? And where is the knot code that divides up long responses into separate DNS messages? Again I saw this in the same TCP packets. And from multiple tcpdumps from BIND named I never saw this behavior. So I am curious. I will now look into my dnspython to see why it doesn't continue with the next DNS message (starting with the TCP count, DNS header, question section.) I'd like to know what RFC is clear about this behavior. --
