Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAO3VF8S1ZV-DaSMA-oj0bzSVNZzM7zSsMpzR73nH7=qsR+sKHQ@mail.gmail.com>
Date: Tue, 4 Jul 2023 12:17:05 +1200
From: Hamish Forbes <hamish.forbes@...il.com>
To: musl@...ts.openwall.com
Subject: DNS answer buffer is too small

In lookup_name.c the DNS answer buffer (ABUF_SIZE) is currently
hardcoded to 768 bytes, increased from 512 after TCP DNS was
implemented.

The DNS RFC is, unfortunately, not very explicit about the size of TCP
responses.
However it does have this little line:

> RFC 1035 4.2.2.
> The message is prefixed with a two byte length field which gives the message length, excluding the two byte length field.

Which you could interpret as the TCP response length is a 16bit
unsigned int, so 64K.
But that's also the raw (potentially compressed) DNS response, the
uncompressed response could be larger still.

As best I can tell (I am not a C programmer!) glibc is using a scratch
buffer which grows when the parsing function returns an ERANGE error.

If that's more complex than you want, maybe a good compromise would be
allocating 768 (or 512?) for UDP queries and expanding to 64k when a
query falls back to TCP?

Hamish

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.