RE: [musl] DNS answer buffer is too small

[Hamish Forbes <hamish.forbes@gmail.com>]

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

[0] https://www.netmeister.org/blog/dns-size.html
[1] https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-max-recursion-depth
[2] https://groups.google.com/g/comp.protocols.dns.bind/c/1GoKujM2Ylw/m/l_DuNxWFiCUJ
[3] https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-max-query-restarts