JdeBP Not quite.
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.)
