On Fri, 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? >
Issues with payload size or fragmentation could occur anywhere in the path between your resolver and the server, so it's a game of intersecting components of paths where lower payloads fail and subtracting out the components of paths that succeed to help zero in on the problem area. More often than not the issue is closer to one of the ends. If replysizetest succeeds, then it's probably closer to them. You can also narrow down the PMTU. First determine what the message size would (likely) be by querying with TCP. Now issue a UDP query with bufsize 1 byte less than the message size to see if you get a response. If you get a (perhaps truncated) response, the PMTU is somewhere between the size of the message you received last and the size of the full response you received over TCP. If no response, split the difference between that and 512 and try again. DNSViz does something like this as part of its online analysis. Other tools might do something similar. > 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? > I would think that reducing the EDNS maximum UDP payload size is done on a per-server basis, not on a per-zone basis, but that's pure speculation. Casey _______________________________________________ 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
