In DNS Protocol design, UDP transport Block size (payload size) has been limited to 512-Bytes to optimize performance whilst generating minimal network traffic.
The 512 byte payload guarantees that DNS packets can be reassembled if fragmented in transit. Also, generally speaking there’s less chance of smaller packets being randomly dropped.
The IPv4 standard specifies that every host must be able to reassemble packets of 576 bytes or less. With an IPv4 header (20 bytes, though it can be as high as 60 bytes w/ options) and an 8 byte UDP header, a DNS packet with a 512 byte payload will be smaller than 576 bytes.
Total Length: 16 bits
https://tools.ietf.org/html/rfc791 Total Length说明
As @RyanRies says: DNS can use TCP for larger payloads and for zone transfers and DNSSEC. There’s a lot more latency when TCP comes into play because, unlike UDP, there’s a handshake between the client and server before any data begins to flow.
A related note: the reason there will always be 13 root DNS resolver names (a.root-servers.net through m.root-servers.net) is because that is the maximum number that can fit in a DNS response to a query for the root without exceeding the 512 byte limit. Thus, even as we add more physical servers to the root DNS infrastructure, logically there will always remain thirteen root servers. –
Modern DNS is not actually limited to 512 bytes payload for UDP anymore.
With EDNS0 in use a larger payload size can be specified, which is also commonly the case for DNSSEC-aware clients.
The support for larger payloads over UDP has been a double-edged sword, however, it is in part the reason why using nameservers for amplification attacks has become more popular as you can achieve better amplification if the attacker uses a query that gets a large response.
- See rfc2671 for the nitty-gritty details of EDNS0