[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAO3VF8RHHvPv1tD6Zi5NPCDCuxy_bjXb1AhRsm0_dS2kDE4NvA@mail.gmail.com>
Date: Tue, 4 Jul 2023 16:19:16 +1200
From: Hamish Forbes <hamish.forbes@...il.com>
To: musl@...ts.openwall.com
Subject: RE: DNS answer buffer is too small
On Tue, 4 Jul 2023 at 15:29, Rich Felker <dalias@...c.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
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.
