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:  closed
  defect                             |             Milestone:
                   Priority:  major  |  Sprint-20111220
                  Component:         |            Resolution:  fixed
  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):

 * status:  reviewing => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:12 vorner]:
 > 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.

 I would assume that if a server supported EDNS, it would do that not just
 over TCP, but over UDP, too. And yet we have a very real example of the
 msft.net servers that do not. I still think it'd be useful to have a
 measure of last resort of trying DNSSEC over TCP when UDP fails. Of
 course, we need to track it all in NSAS.

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

 Opening new tickets about EDNS and/or the DO flag might be discussed
 during the call.

 > I believe it can be merged.

 Merged.

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