Re: stack overflow in getaddrinfo(3) with a small-sized stack in pthreads

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 29 Nov 2021 17:18:07 +0100
    From:        Joerg Sonnenberger <joerg%bec.de@localhost>
    Message-ID:  <YaT9P6a+AlEm3w7h%bec.de@localhost>

  | On Mon, Nov 29, 2021 at 08:38:35PM +0700, Robert Elz wrote:
  | > DNS queries (via UDP) are limited to max 512, as that is what the
  | > protocol always required, so can be handled by everything (or should be).
  |
  | Strictly speaking, it is the minimum MTU every IPv4 implementation is
  | supposed to allow. IPv6 bumped it to 1280.

I know this thread is largely dead by now, but no, that is not correct.

The minimum IPv4 MTU is 576 ... that's derived from 512 no doubt (512 + 64)
where the "+64" is (was) intended to allow for the headers (IP, TCP, and
perhaps something from the application) so as to permit 512 bytes of user
data to fit in a packet.   That's the number IPv6 raised to 1280 (1024 + 256,
calculated along similar lines - and enough below 1500 that encapsulations
can be wrapped around it, and still fit in a standard ethernet frame).

The size also allowed more rational multiplexing in the days where a
56kbps link was one of the fast ones.  56Kbps only allows about 12
"full sized" (576 bytes + link layer overhead) packets/second, anything
larger and one session would totally swamp the link.

[Aside: these days, the 64 isn't really big enough, when every TCP packet
carries the timestamp option - that by itself blows the budget.
Fortunately 576 byte MTU links have largely vanished completely now,
everything is bigger, and much faster.]

The DNS 512 byte limit came from the same thinking - with headers added
to fit in one unfragmented UDP packet (it could have been fractionally
larger, but not enough to make a difference).   If anything doesn't want
fragmentation, it is the DNS (for several reasons) - sending multiple
queries and getting smaller answers gives much better overall results than
using large, but fragmented, packets.

That still applies to initial query packets, but as has been noted here,
EDNS allows the query to inform the server what size can be handled in
the reply (replies are the packets where the 512 byte limit was stretched,
resulting in the need to retry with TCP, with all of the overhead, when
with most modern networks, the actual path MTU is considerably larger,
often 1500).

The proposed correction to change the large buffer used for sending a
query to something rational looks about right to me (I also agree that
it probably became large purely by accident - there's no reason to do that
deliberately).

kre