From: Rich Felker <firstname.lastname@example.org>
To: Hamish Forbes <email@example.com>
Subject: Re: [musl] DNS answer buffer is too small
Date: Mon, 3 Jul 2023 23:29:19 -0400 [thread overview]
Message-ID: <20230704032918.GB4163@brightrain.aerifal.cx> (raw)
Thanks for sending an email where we can document this.
On Tue, Jul 04, 2023 at 12:17:05PM +1200, Hamish Forbes wrote:
> In lookup_name.c the DNS answer buffer (ABUF_SIZE) is currently
> hardcoded to 768 bytes, increased from 512 after TCP DNS was
> The DNS RFC is, unfortunately, not very explicit about the size of TCP
> 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.
"Compression" is not relevant; there is no "decompressed state" the
message is converted into. Everything is processed in the original DNS
protocol form, with "compression" (backpointers).
> 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?
Your report here is missing the motivation for why you might care to
have more than 768 bytes of response, which, as I understand it, is
because of CNAME chains. Otherwise, the buffer size is chosen to hold
the number of answer records the stub resolver is willing to accept,
and there is no problem.
Long CNAME chains are rather hostile and are not guaranteed to be well
supported -- AIUI recursive nameservers already impose their own
limits on the number of redirections in a chain, though I cannot find
any specification in the RFCs for this behavior or suggesting a value
for that limit, so if you can dig up what they actually do, this would
be useful to know. But it seems there are chains longer than what we
currently support out in the wild, which most software does support.
So the next step is nailing down exactly what the "requirement" here
is, so we can figure out what's the most reasonable and least costly
way to do it.
If there's some moderately small limit on the number of redirections
that recursive software supports, it may make sense to just increase
the buffer size to match that. If there really can be very large
chains, this is a mess.
next prev parent reply other threads:[~2023-07-04 3:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-04 0:17 Hamish Forbes
2023-07-04 3:29 ` Rich Felker [this message]
[not found] ` <CAO3VF8TnAX97Mt7h3MdzHScE-5660dcrZVn45p4vKXkYpbuicw@mail.gmail.com>
2023-07-04 4:19 ` Hamish Forbes
2023-07-04 16:07 ` Rich Felker
2023-07-05 0:18 ` Hamish Forbes
2023-07-05 3:41 ` Rich Felker
2023-07-05 11:24 ` A. Wilcox
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).