[dns-operations] Way to test remote EDNS capability?

[Brian Somers]

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 <dougb at dougbarton.us> 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
bsomers at OpenDNS.com