IMHO you're right - you just happened to hit the bogus server (that doesn't support ENDS0?).
I think it's relevant that servers may accept +bufsize=<some-very-big-number> but still respond with a TC when the response is greater than some smaller threshold. I believe the only real way to test this is to actually request a payload close to the size you're looking for (which isn't too easy if you're talking directly to an authoritative server). On Jun 7, 2013, at 12:33 AM, Doug Barton <[email protected]> wrote: > I'm looking at some resolver logs and seeing the "success resolving $blah > after reducing the advertised EDNS UDP packet size to 512 octets" messages > for some authoritative servers run by organizations that I would think ought > to know better. :) I've tested the path on my side using > https://www.dns-oarc.net/oarc/services/replysizetest and both my IPv4 and > IPv6 paths show as clear (which I would expect of course). > > Is there any simple way test the remote side's actual capabilities? > > Meanwhile I've been trying 'dig +bufsize=4096' and it seems to succeed more > often than it fails. In one particular zone 4 of the 5 auth name server > addresses succeeded, but the one that failed failed with both +bufsize=4096 > and +bufsize=512. Is it possible that named (BIND 9.9.3-p1) just happened to > hit the failing server first, then it happened to work when it backed the > packet size off and tried another server? > > Insights welcome, > > Doug > -- Brian Somers [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
