BIND 10 #1386: fallback from EDNS over UDP to plain DNS or EDNS/DNS over TCP is needed in real life

[BIND 10 Development]

#1386: fallback from EDNS over UDP to plain DNS or EDNS/DNS over TCP is needed in
real life
-------------------------------------+-------------------------------------
                   Reporter:  dvv    |                 Owner:  dvv
                       Type:         |                Status:  accepted
  defect                             |             Milestone:
                   Priority:  major  |  Sprint-20111220
                  Component:         |            Resolution:
  resolver                           |             Sensitive:  0
                   Keywords:  EDNS   |           Sub-Project:  DNS
  fallback                           |  Estimated Difficulty:  0
            Defect Severity:  High   |           Total Hours:  0
Feature Depending on Ticket:         |
  resolver                           |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by dvv):

 Replying to [comment:6 jinmei]:
 > Replying to [comment:4 dvv]:
 > > Added EDNS fallback functionality: first to EDNS over TCP and, if it
 fails, non-EDNS over UDP.
 >
 > Just wondering: what's the rationale of this behavior?  At least it
 seems to be quite
 > different from BIND 9's fallback algorithm.

 As I see it, ns[12345].msft.net are among the most used auth servers on
 the Internet, and while they reject EDNS over UDP with FORMERR, they still
 allow EDNS over TCP. So to preserve the EDNS functionality in one of the
 most common cases of FORMERR due to EDNS, I've added the fallback to TCP.
 Of course, it's all based on my highly subjective observations and
 conjectures, and if need be, we can easily get rid of this heuristic.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1386#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development