JdeBP>
JdeBP> <URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/web-squid-dns-client-options.html>
HN> Looks good, except that DNS replies larger than 512 bytes does not HN> need to fail.
DNS/UDP responses larger that 512 octets will never be sent in the first place, because squid's "internal" DNS client doesn't use to EDNS0 to advertise the ability to support them (which, of course, it doesn't, in any case). DNS/TCP responses larger than 512 octets will never be sent because squid's "internal" DNS client simply doesn't support DNS/TCP at all.
HN> If there is useable information in the first 512 bytes Squid HN> uses this which is usually sufficient.
It's invariably wrong, and squid's "internal" DNS client is badly broken for using any of the resource records in the response at all. A correctly written DNS client has no choice but to stop (and fall back to DNS/TCP) when it sees the TC bit set to 1 in a DNS/UDP response. It simply cannot rely on the rest of the response. DNS servers can vary wildly in their behaviours, from including no resource records at all in the response, to truncating the response in the middle of a resource record set, to truncating the response at exactly 512 octets even if that happens to be in the middle of a resource record. Using the resource records in the response as if they formed an answer is to use incomplete data, and possibly to falsely infer the non-existence of something that actually does exist. Indeed even merely attempting to decode the resource records in the response is fraught with peril. (I discover that others have already long since noticed that squid crashes when it receives certain forms of truncated DNS/UDP responses.)
