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.
