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

BIND 10 Development do-not-reply at isc.org
Fri Apr 8 12:15:14 UTC 2011


#598: Resolver DO bit, forwarder pass DO bit
-------------------------------------+-------------------------------------
                 Reporter:  jreed    |                Owner:  zhanglikun
                     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 vorner):

 * owner:  vorner => zhanglikun


Comment:

 Hello

 Replying to [comment:9 zhanglikun]:
 > > 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.

 So, if I understand it correctly, the goal is to get as large answer as
 possible and truncate it if needed, but the truncation doesn't happen yet?
 So another ticket should be opened for that?

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

 io_fetch.cc:170. But looking at it, it's Jelte's code, for some reason
 `git diff master...` showed that as well. Maybe I didn't have new enough
 master or something.

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

 The changelog is OK regarding the code, but I'm not sure if implementing
 the simplest forwarder is in scope of this ticket. Not that I'd propose
 removing the code, if it leads towards what we want, of course.

 Anyway, from the older comments, I might be little bit unclear, I meant
 changing RunningQuery→UpstreamQuery and leaving ForwardQuery as it is
 (since ForwardQuery was really good name, but the RunningQuery isn't and
 UpstreamQuery is mostly about resolver I believe).

 And is there some shared code left between the two? Or you removed almost
 everything from the forwarding version?

 Thanks

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


More information about the bind10-tickets mailing list