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

[BIND 10 Development]

#598: Resolver DO bit, forwarder pass DO bit
-------------------------------------+-------------------------------------
                 Reporter:  jreed    |                Owner:  vorner
                     Type:  defect   |               Status:  reviewing
                 Priority:  major    |            Milestone:
                Component:           |  Sprint-20110419
  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 zhanglikun):

 * owner:  zhanglikun => vorner


Comment:

 Replying to [comment:8 vorner]:
 > Hello
 >
 > Is it possible you didn't push your changes? Because I didn't find
 anything new in the repository.

 sorry, please see the latest change in trac598

 >
 > > Replying to [comment:6 vorner]:
 > > > 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?
 >
 > I didn't look last time as closely, but isn't the same buffer sent back?
 Is the message really parsed and rendered again?

 No, the buffer size from client is ingored now, that's always think it
 support the max buffer size of forwarder. BTW, according the RFC, the
 edns0 information should not be forwarded.

 >
 > > I don't think it's a problem, forwarder should always use the max
 buffer size it supports, when geting the response, cache it for the coming
 same query from other clients. If the forwarder find

 client's buffer is smaller, forwarder should set TC bit and reply to
 client.

 > asio itself provides a function that reads the whole amount of data for
 you, retrying the read if the previous one was shorter. You have a loop
 where you keep retrying read until you have enough data, this can be
 simplified (or did I look at older code?).

 Could you mention the code where I should use async_read?


 > So, what changelog entry do you propose?

 possible entry is:
 [trac598] Implement the simplest forwarder, which pass everything throught
 except QID, port number, and the response will not be cached.

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