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:  vorner
                       Type:         |                Status:  reviewing
  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      |
-------------------------------------+-------------------------------------
Changes (by dvv):

 * owner:  dvv => vorner


Comment:

 Replying to [comment:10 vorner]:
 > Hello
 >
 > I agree that the code does what it says, though the changelog could be
 more explicit on what fallback it is.

 changelog updated.

 > However, I'm not sure if this fallback behaviour is the right one to do.
 Does it make sense? For what I see, the behaviour of the name server is
 wrong. So making the usual fallback (where the server doesn't know edns at
 all) slower seems bad because of it. What use is the EDNS on tcp anyway?
 As the EDNS doesn't really work well for the server, we can assume it
 doesn't use it to pass any fancy options. And we don't need larger packets
 over TCP. So, it would probably make sense to fallback either to UDP
 without EDNS directly (and then do the usual TCP fallback, if needed
 because of size) or directly to TCP without EDNS. What is the advantage of
 this (your) way?

 In theory, it might be useful if we send a DNSSEC query to an upstream
 server that refuses to do EDNS over UDP. But at the moment, the resolver
 ignores DNSSEC-aware queries from clients, so it's kinda moot. I disabled
 the TCP fallback and just left the basic fallback to non-EDNS UDP in
 place.

 > Also, we may want to remember these things in the NSAS. I'm not sure if
 it supports flags for now, but it should be at last noted in some TODO we
 want to do it, and possibly create a ticket for it somewhere in backlog.

 That was the TODO part that jinmei found unnecessary at the moment. bind9
 uses a whole lot of heuristics to determine what an upstream server's
 malfunctions are, it may be useful to replicate some or all of that
 functionality, too.


 Thanks!

 Dima

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