In __res_msend_rc(), the IPv6-disabled fallback check uses conf->ns[nns]
inside a loop controlled by i, so it tests a fixed slot instead of
walking configured nameservers. This reads one past the array's size.

Use conf->ns[i] so the loop correctly detects whether all configured
nameservers are IPv6-only.

sll_addr is a member of sockaddr_ll, but it is misspelled as
ssl_addr in comment.

Please cc me back when reply.

Signed-off-by: RocketDev <marocketbd@gmail.com>

some recent compilers have adopted a dubious interpretation of the C
specification for union initializers, that when the initialized member
is smaller than the size of the union, the remaining padding does not
have to be zero-initialized. in the interests of not depending on any
particular interpretation, place the larger member first so it's
initialized and ensures the whole object is zero-filled.

Per RFC 5952, ties for longest sequence of zero fields must be broken
by choosing the earliest, but the implementation put the leading
sequence of zeros at a disadvantage. That's because for example when
compressing "0:0:0:10:0:0:0:10" the strspn(buf+i, ":0") call returns 6
for the first sequence and 7 for the second one – the second sequence
has the benefit of a leading colon.

Changing the condition to require beating the leading sequence by not
one but two characters resolves the issue.

__res_send returns the full answer length even if it didn't fit the
buffer, but __dns_parse expects the length of the filled part of the
buffer.

This is analogous to commit 77327ed064bd57b0e1865cd0e0364057ff4a53b4,
which fixed the only other __dns_parse call site.

The name resolution would abort when getting more than 63 records per
request, due to what seems to be a left-over from the original code.
This check was non-breaking but spurious prior to TCP fallback
support, since any 512-byte packet with more than 63 records was
necessarily malformed. But now, it wrongly rejects valid results.

Reported by Daniel Stefanik in Alpine Linux aports issue 15320.

the __dns_parse code used by the stub resolver traditionally included
code to reject label pointers to offsets past a 512 byte limit,
despite never processing the label contents, only stepping over them.
when commit 51d4669fb97782f6a66606da852b5afd49a08001 added support for
tcp fallback, this limit was overlooked, and as a result, it was at
least theoretically possible for some valid large answers to be
rejected on account of these offsets.

since the limit was never serving any useful purpose, just remove it.

in the event of chained CNAMEs, the answer to a query will contain the
entire CNAME chain, not just one CNAME record. previously, the answer
buffer size had been chosen to admit a maximal-length CNAME, but only
one. a moderate-length chain could fill the available 768 bytes
leaving no room for an actual address answering the query.

while the DNS RFCs do not specify any limit on the length of a CNAME
chain, or any reasonable behavior is the chain exceeds the entire 64k
possible message size, actual recursive servers have to impose a
limit, and a such, for all practical purposes, chains longer than this
limit are not usable. it turns out BIND has a hard-coded limit of 16,
and Unbound has a default limit of 11.

assuming the recursive server makes use of "compression" (pointers),
each maximal-length CNAME record takes at most 268 bytes, and thus any
chain up to length 16 fits in at most 4288 bytes.

this patch increases the answer buffer size to preserve the original
intent of having 512 bytes available for address answers, plus space
needed for a maximal CNAME chain, for a total of 4800 bytes. the
resulting size of 9600 bytes for two queries (A+AAAA) is still well
within what is reasonable to place in automatic storage.

The received length field in the message may be greater than the
size of the 'answer' buffer in which the message resides. Currently,
ABUF_SIZE is 768. And if we get a larger 'alens[i]', it will result
in an out-of-bounds reading in __dns_parse().

To fix this, limit the length to the size of the received buffer.

EAI_OVERFLOW should be propagated as ERANGE to inform the caller about
the need to expand the buffer.