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:  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 vorner):

 * owner:  vorner => dvv


Comment:

 Hello

 Replying to [comment:11 dvv]:
 > > 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 the DO flag in 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.

 Well, my thinking was, if the server really supported DNSSEC, the authors
 must have tried it at last little bit and they would have found out it
 doesn't work over UDP. So not being able to answer EDNS correctly could
 IMO be a good approximation of not supporting DNSSEC.

 > > 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.

 I agree with that. However, I still think we want to remember what we
 found out about the servers, to not need to query multiple times just to
 trigger the heuristic again. Anyway, it's not goal of this ticket.

 I believe it can be merged.

 Thanks

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