BIND 10 #598: Resolver DO bit, forwarder pass DO bit

BIND 10 Development do-not-reply at isc.org
Tue Mar 29 17:35:54 UTC 2011


#598: Resolver DO bit, forwarder pass DO bit
-------------------------------------+-------------------------------------
                 Reporter:  jreed    |                Owner:  zhanglikun
                     Type:  defect   |               Status:  reviewing
                 Priority:  major    |            Milestone:
                Component:           |  Sprint-20110405
  resolver                           |           Resolution:
                 Keywords:           |            Sensitive:  0
Estimated Number of Hours:  0.0      |  Add Hours to Ticket:  0
                Billable?:  1        |          Total Hours:  0
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => zhanglikun


Comment:

 Hello

 I made editorial fixes, like line wrapping or updating comments.

 But I have some comments on the code:
  * In IOFetch, you set EDNS if it is supported by the client. However, the
 UDP size is set to the servers maximal size, which can be larger than what
 the client supports. What will happen if the answer fits into our buffer,
 but doesn't fit into the client's buffer?
  * You might want to use async_read, that does the looping in case of TCP
 for you (at last the ASIO documentation says so).
  * The RunningQuery was a name describing the query is „in progress“.
 However, both the query to upstream server for recursive resolving and the
 forwarding query kind of belong to this category, so the RunningQuery
 might be confusing, when there's a ForwardQuery as well. And the name
 wasn't a good one from the beginning. Could this be a good time to change
 the name to, lets say, UpstreamQuery or something like that?
  * The RunningQuery and ForwardQuery have quite some variables and
 functions in common, that are copy-pasted there twice. It would be great
 if there was a common ancestor for them and the same methods were put into
 it, so they are only once in the code.
  * As the bug was user-visible, it probably should have a changelog entry.

 Thanks

-- 
Ticket URL: <https://bind10.isc.org/ticket/598#comment:6>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list