All of the articles I read that explains why there are 13 root dns servers saying each ip address takes 32 bytes and hence (13 x 32) = 416 bytes leaving up to 96 bytes for other protocol information. For example, see below

"At the time the DNS was designed, the IP address in use was IPv4, which contains 32 bits. For efficient networking and better performance, these IP addresses should fit into a single packet (using UDP, the DNS’s default protocol). Using IPv4, the DNS data that can fit into a single packet is limited to 512 bytes. As each IPv4 address requires 32 bytes, having 13 servers uses 416 bytes, leaving up to 96 bytes for the remaining protocol information."

Isn't each ip address is of 32-bit? What does it imply in the above statement where it states "each IPv4 address requires 32 bytes"? Why does 32-bit address take 32 bytes?

  • Like the case of unix.stackexchange.com/q/557612/5132 yesterday, nothing in this question is specific to Unix and Linux.
    – JdeBP
    Dec 18, 2019 at 11:51
  • 5
    I'm voting to close this question as off-topic because this should be posted on Super User
    – muru
    Dec 18, 2019 at 13:31
  • 1
    What course is going on, I wonder.
    – muru
    Dec 18, 2019 at 13:31

1 Answer 1


"... As each IPv4 address requires 32 bytes, having 13 servers uses 416 bytes, leaving up to 96 bytes for the remaining protocol information."

The DNS protocol never transmits just plain IP addresses, but properly formatted queries and answers composed of DNS resource records.

The "IPv4 address requires 32 bytes" probably does not refer to the size of the plain IP address, but to the size of the A resource record as formatted for transfer in the DNS protocol.

It looks like this value would have been accurate back when all root DNS servers had unique, non-systematic names, but since the root nameservers have now been re-named to the format x.ROOT-SERVERS.NET, the current state is a bit more complicated.

I just ran tcpdump on a BIND9 DNS server start-up, and it looks like the first A record will take just slightly more than 32 bytes, as it includes:

  • the full name a.root-servers.net (with one byte for the length of each name component and one zero byte at the end = 20 bytes total)
  • a 16-bit record type code (2 bytes)
  • a 16-bit record class code (2 bytes)
  • a 32-bit TTL value (4 bytes)
  • a 16-bit data length value (2 bytes)
  • a 32-bit IP address (4 bytes)

So if you're requesting the A records for the root DNS servers, the first answer record would actually take 34 bytes.

Any subsequent answer records in the same DNS message can refer back to any previously-mentioned name or part of one, so that if a.root-servers.net is mentioned in full, then b.root-servers.net can be expressed in just 4 bytes (2 bytes for the b part, 2 bytes to back-reference the root-servers.net suffix). As a result, any other A records for the root servers will take just 17 bytes each.

The actual start-up query by BIND9 is equivalent to dig . NS and happens over TCP rather than UDP.

As a result, the first answer record is a NS record of 31 bytes, listing the first root DNS server with full name. Subsequent NS records for the other root servers will take just 15 bytes each. As the A records presented as additional information will be able to back-reference each root server hostname in full, each A record for a root DNS server will take just 16 bytes. The response also includes the IPv6 AAAA records for the root nameservers. Even so, total length of the DNS response is just 1097 bytes.

  • So is it sending ASCII 1s and 0s? (this looks like someone was trying to optimise the un-optimal). Dec 18, 2019 at 10:30
  • @ctrl-alt-delor no, that would be just silly. A DNS response contains more than just the IP addresses. See my update.
    – telcoM
    Dec 18, 2019 at 12:03
  • So a coincidence? Dec 18, 2019 at 18:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.