On 04/22/10 15:22, Casey Deccio wrote:
Actually, what seems interesting to me is that the cutoff seems to be at a payload size of 1736, which happens to be the exact size of the complete response. Is this just coincidence?
Yes it is. With the bufsize set to 1735, the response that will actually come back will be truncated on an RR boundary. Try:
dig +ignore +bufsize=1735 +dnssec @dns1.uspto.gov uspto.gov dnskey You'll get an 1142 byte truncated response.
$ dig +bufsize=1735 +dnssec @dns1.uspto.gov uspto.gov dnskey ;; Truncated, retrying in TCP mode.
With the response at 1142 bytes, there are no UDP fragmentation issues and you'll get to retry with TCP.
$ dig +bufsize=1736 +dnssec @dns1.uspto.gov uspto.gov dnskey ;<<>> DiG 9.6.1-P3<<>> +bufsize=1736 +dnssec @dns1.uspto.gov uspto.govdnskey ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
Without the bufsize set as the actual response size, the full response will be sent and it will be dropped by whatever braindead device is filtering UDP fragments.
michael _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
