From: Hamish Forbes <firstname.lastname@example.org>
Subject: RE: [musl] DNS answer buffer is too small
Date: Tue, 4 Jul 2023 16:19:16 +1200 [thread overview]
Message-ID: <CAO3VF8RHHvPv1tD6Zi5NPCDCuxy_bjXb1AhRsm0_dS2kDE4NvA@mail.gmail.com> (raw)
On Tue, 4 Jul 2023 at 15:29, Rich Felker <email@example.com> 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
a.example.com 10 IN CNAME b.example.com.
b.example.com 10 IN CNAME c.example.com.
n.example.com 10 IN A 127.0.0.1.
With a max length per CNAME of 255 this could quickly blow out the 768
> 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 I came across while investigating all this stuff is
> 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 to 7, although that appears 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 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 :)
next prev 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] ` <CAO3VF8TnAX97Mt7h3MdzHScE-5660dcrZVn45p4vKXkYpbuicw@mail.gmail.com>
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
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).