"And the maximum size of an IP packet is 16 bit (via the IPv4 total length / IPv6 payload length). And that is now our limiting factor: 65536 bytes for DNS overhead + payload."
While they conclude the right size, this is incorrect. They seem to overlook that TCP DNS header has its own 2 byte length field (it's a 14 byte header). That is the limiting factor, nothing to do with the lower layers. If the DNS message itself is over 65514 it will require multiple IP packets due to TCP overhead and in practice MTU sizes are almost never over 9000 and usually <1500, so it's going to be split up at much lower sizes.
"'What about jumbo frames?' That doesn't really buy us anything, either, because TCP itself is also limited to 16 bits, albeit semi-indirectly via the 16-bit urgent pointer"
This isn't correct either. The urgent pointer (it's own can of worms) is completely ignored in non URG packets.
Yes that rubbed me the wrong way too. The author has a flawed understanding of TCP (from the application pov) and confused the DNS header with the TCP header. Apart from what you said about practically all TCP/IP packets on the internet being <= 1500 bytes and thus the reply being effectively delivered in multiple TCP packets, all this is completely opaque to the application layer. The application (DNS server) has no idea how many packets the data it's handing over to the kernel will be split into, what their size is, and in what order they arrive. At the same time, the client's DNS resolver has no idea what happened on the lower layers, like how many packets the data it receives was spread across, whether any of these were lost and needed to be resent, etc. What might happen is that the kernel tells your app that some data arrived, and when you go fetch it, it's not as many bytes as you expected, so you can guess that your data was split across multiple packets and where one of those boundaries was, but that's about it.
While they conclude the right size, this is incorrect. They seem to overlook that TCP DNS header has its own 2 byte length field (it's a 14 byte header). That is the limiting factor, nothing to do with the lower layers. If the DNS message itself is over 65514 it will require multiple IP packets due to TCP overhead and in practice MTU sizes are almost never over 9000 and usually <1500, so it's going to be split up at much lower sizes.
"'What about jumbo frames?' That doesn't really buy us anything, either, because TCP itself is also limited to 16 bits, albeit semi-indirectly via the 16-bit urgent pointer"
This isn't correct either. The urgent pointer (it's own can of worms) is completely ignored in non URG packets.