diff options
author | Rich Felker <dalias@aerifal.cx> | 2022-09-25 22:48:12 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2022-10-19 14:01:31 -0400 |
commit | dec8f0a4fa7aa533c843e6eaec862be674ff3a1a (patch) | |
tree | d09af6325d48afde054df2b5783263df15d6346f /src/misc | |
parent | 8c408937da4cb7f6460972a0f645694304de3c8c (diff) | |
download | musl-dec8f0a4fa7aa533c843e6eaec862be674ff3a1a.tar.gz musl-dec8f0a4fa7aa533c843e6eaec862be674ff3a1a.tar.xz musl-dec8f0a4fa7aa533c843e6eaec862be674ff3a1a.zip |
dns query core: detect udp truncation at recv time
we already attempt to preclude this case by having res_send use a sufficiently large temporary buffer even if the caller did not provide one as large as or larger than the udp dns max of 512 bytes. however, it's possible that the caller passed a custom-crafted query packet using EDNS0, e.g. to get detailed DNSSEC results, with a larger udp size allowance. I have also seen claims that there are some broken nameservers in the wild that do not honor the dns udp limit of 512 and send large answers without the TC bit set, when the query was not using EDNS. we generally don't aim to support broken nameservers, but in this case both problems, if the latter is even real, have a common solution: using recvmsg instead of recvfrom so we can examine the MSG_TRUNC flag.
Diffstat (limited to 'src/misc')
0 files changed, 0 insertions, 0 deletions