mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Hamish Forbes <>
Subject: RE: [musl] DNS answer buffer is too small
Date: Tue, 4 Jul 2023 16:19:16 +1200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, 4 Jul 2023 at 15:29, Rich Felker <> wrote:
> 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.

Yes, sorry, a response can contain a chain of CNAMEs like 10 IN CNAME 10 IN CNAME
... 10 IN A

With a max length per CNAME of 255 this could quickly blow out the 768
byte limit.

> 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.

Are you referring to the 48 MAXADDRS limit?
That's also possibly a problem in edge cases though, isn't it?
AIUI that was chosen as the maximum number of IP responses that can
fit in a 512 byte UDP response.
With TCP DNS implemented now, is that still a safe assumption?

It seems nuts to be returning more than 48 addresses but the DNS spec
doesn't prevent it,
so I bet it's being done somewhere!

This post[0] I came across while investigating all this stuff is
somewhat related

> 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.

Bind defaults[1] to 7, although that appears[2] to only be when it has
to switch to another NS.
So if the CNAME chain is all in the same zone... that's only  a depth of 1

Looks like Unbound defaults[3] to 11.
Although it also has a slightly confusing 'target-fetch-policy' which
looks to limit depth in a similar way to Bind, maybe...

> 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.

I have a strong suspicion that this is, in fact, going to be a mess :)

> Rich


  parent reply	other threads:[~2023-07-04  4:19 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
     [not found]   ` <>
2023-07-04  4:19     ` Hamish Forbes [this message]
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

Reply instructions:

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).